Gedistribueerde afstemming in de bouw

RRBOUWRAPPORT 129

Gedistribueerde afstemming in de bouw

GEDISTRIBUEERDE AFSTEMMING IN DE BOUW

vv1

RRBOUWRAPPORT 129

Gedistribueerde afstemming in de bouw

vv2



Voorwoord Het voorliggende rapport heeft als doel om bij te dragen aan een verbetering van de betrouwbaarheid van planningen in de bouw. Het blijkt namelijk dat in de dagelijkse bouwpraktijk deze betrouwbaarheid te wensen overlaat. Het gevolg hiervan is dat onnodig veel tijd en geld verloren gaat bij de realisatie van bouwwerken. In dit rapport wordt geanalyseerd door welke oorzaken planningen onbetrouwbaar zijn, wat hiervan de gevolgen zijn en wat hiervoor mogelijke oplossingsrichtingen zijn. Vanuit een van de oplossingsrichtingen is een prototype van een planningstool ontwikkeld. Deze tool ondersteunt met name de afstemming tussen bouwpartners. Voor een optimaal resultaat zal deze tool breed gebruikt moeten worden. Om hiermee een start te maken wordt de planningstool op een aantal projecten van bedrijven uit de begeleidingscommissie in de praktijk getest. Veel dank gaat uit naar de leden van de begeleidingscommissie en INITI8 B.V., die dit rapport mede mogelijk hebben gemaakt door hun kennis en ervaring beschikbaar te stellen. Voor de begeleiding van het onderzoek is een commissie samengesteld, bestaande uit: J. van Ravenswaaij BAM Techniek ing. M.J. de Waal Bouwbedrijf Boot M.R. Heppener Dura Vermeer Bouw Amsterdam BV J.H.G. Broeren Bouwmij Janssen R. Kusters Steenhandel Kusters P.G Jonker INITI8 drs. I. Miller INITI8 ing. B.C.P. Janssen BCP-Janssen Venray ing. A.J. van Wingerden Bouwend Nederland

Zoetermeer, oktober 2007

Stichting Research Rationalisatie Bouw (RRBouw) Zilverstraat 69, 2718 RP Zoetermeer Postbus 340, 2700 AH Zoetermeer ISBN 978-90-78963-05-9 Vormgeving en druk: Fokkerprinting & More Amsterdam

vv4



Inhoudsopgave

1 INLEIDING

1 INLEIDING....................................................................................................................................... 1 1.1 Probleemstelling............................................................................................................................... 2 1.2 Doelstelling....................................................................................................................................... 2 1.3 Aanpak ............................................................................................................................................ 2 2

Vooronderzoek................................................................................................................................. 4

2.1 Organisatie in de bouw..................................................................................................................... 5 2.2 Afstemming in de bouw.................................................................................................................... 6 2.3 Informatie in de bouw....................................................................................................................... 6 2.4 Planning in de bouw......................................................................................................................... 7 2.5 Het inbouwen van buffers................................................................................................................. 8 2.6 Oorzaken en gevolgen................................................................................................................... 10 2.7 Conclusies vooronderzoek............................................................................................................. 14 3

Conceptuele oplossing................................................................................................................... 16

3.1 Aanpak onzekerheid door informatie.............................................................................................. 16 3.2 Aanpak onzekerheid door planning................................................................................................ 17 3.3 Concept oplossing.......................................................................................................................... 17 3.4 Werkwijze van de oplossing........................................................................................................... 18 4

Al jaren verschijnen er studies over faalkosten in de bouw. Globaal gesproken variëren de berekeningen en schattingen van 5% tot 20% van de omzet welke aan faalkosten verloren gaan. Veelal blijft het steken bij deze constatering, hooguit strandt het in goede bedoelingen om er iets aan te doen. Dit project wil een aanzet geven om daadwerkelijk in de branche stappen te zetten die hierin verandering brengen. Als eerste moeten we ons realiseren dat een bouwproject een complex logistiek project is, dat continu vraagt om er voor te zorgen dat: De juiste man met de juiste informatie en het juiste materiaal (en materieel) op het juiste moment op de juiste plaats is. Het gaat hier om logistiek die verder gaat dan het bekijken waar een voorraad stenen neer gezet moet worden of wat de capaciteit van een kraan moet zijn. Ondanks hulpmiddelen voor het ontwerp, de werkvoorbereiding en planning komt de invulling van de logistiek, in de hiervoor genoemde ruime betekenis, in de praktijk vaak neer op de ervaring en het “fingerspitzengefüll” van projectleiders en uitvoerders. Het logistieke bouwproces is zo complex en wordt door de hierna te noemen punten zodanig gefrustreerd dat het verloop verre van ideaal is. Niet altijd zijn de gevolgen (faalkosten) zichtbaar omdat de bouwbranche heeft leren leven met het gegeven dat het proces ‘nu eenmaal zo loopt’. Het corrigeren van zaken die niet goed gegaan zijn is vaak zo ingebakken in de taak van een uitvoerder dat hij het als een “normaal” onderdeel van zijn taak ervaart. Daarnaast wordt er in de (calculatie-)normen door alle partijen rekening mee gehouden. De belangrijkste factoren die het bouwproces complex, moeilijk en frustrerend maken, kunnen als volgt worden samengevat:

Prototype........................................................................................................................................ 22

4.1 Testen van het prototype................................................................................................................ 22 5

Conclusies & Aanbevelingen.......................................................................................................... 23

5.1 Implementatie................................................................................................................................. 23

Bijlage.................................................................................... DVD met presentatie van het protoype


Vaak is informatie niet (tijdig) bekend. Ondanks dikke bestekken en vele tekeningen blijkt veel benodigde informatie, die nodig is om een bouwwerk te realiseren, niet (tijdig) aanwezig te zijn. Vaak ook is de aanwezige informatie tegenstrijdig of onduidelijk. Veel tijd is er tijdens het bouwproces nodig om de benodigde informatie boven tafel te krijgen. Soms is onduidelijk wie mag of moet beslissen. Soms zitten er financiële consequenties aan de uiteindelijke informatiebeslissing, met ook weer alle gevolgen van dien. Beslistrajecten staan vaak onder tijdsdruk, omdat de keuzes nodig zijn voor de voorbereiding en uitvoering, wat de zorgvuldigheid van de beslissing niet te goede komt. Kortom: De tijd die nodig is om boven tafel te halen wat er gemaakt moet worden gaat ten koste van het regelen van een goed logistiek proces. De vastlegging en verspreiding van de informatie laat vaak te wensen over. De informatie die ontstaat na de fase van contract, met daarbij bestek, tekeningen en eventueel andere documenten, wordt op allerlei manieren, vaak niet structureel, vastgelegd. Faxen, brieven, e-mails, verslagen en “tussen de oren”. De aanwezige informatie is daarom zeer verspreid. Dat de juiste informatie dan niet altijd op de juiste plaats aanwezig is, is natuurlijk niet verwonderlijk. De bouwkolom werkt zeer gefragmenteerd. Zowel aan de ontwerpende en ontwikkelende, maar zeker ook aan de uitvoerende kant zijn er veel verschillende bedrijven bij een project betrokken, met ieder hun eigen belangen en agenda’s. Dit compliceert het informatiedistributieprobleem, maar bovendien wordt de planning van de werkzaamheden hierdoor steeds moeilijker. De planning van een project dient uiteindelijk in de uitvoering ook te stroken met de planningen van alle onder- en nevenaannemers die aan een project werken. Hoe meer partijen, neven- en onderaannemers, hoe moeilijker. Aangezien bij nagenoeg ieder project steeds weer in andere samenstellingen van partijen wordt gewerkt is het


ook moeilijk structurele afspraken te maken. Er is dus een direct gebrek aan afstemmingen tussen de verschillende planningen van al deze partijen die bij het bouwproces betrokken zijn. Continue onzekerheid in de bouwplanning door verschillende storingen. Ten gevolge van weersomstandigheden, verkeerde informatie, gebrekkige afstemming met andere partijen, gaan partijen (tijds)ruimte inbouwen in hun planningen. Bij een afhankelijkheid van werkzaamheden treedt dan een waar domino-effect op. Aannemers en onderaannemers worden bovendien geconfronteerd met pieken en dalen in hun planningen ten gevolge van expliciete wensen van hun opdrachtgevers waardoor ze soms toezeggingen doen waarvan ze weten dat ze deze niet waar kunnen maken.

De bovenstaande problematiek wordt gevoed door het feit dat in basis alle (vaak tientallen) partijen die betrokken zijn bij het ontwikkelen, ontwerpen en uitvoeren van een bouwproject zich primair laten leiden door hun eigen belang.

1.1 Probleemstelling Zoals uit de inleiding al blijkt, is de werkelijke bouwtijd bij bouwprojecten vaak te lang en is er vaak sprake van relatief hoge faalkosten. Hierbij spelen samengevat twee factoren een belangrijke rol, te weten: een gebrek aan (tijdige) informatie en een gebrekkige onderlinge planningsafstemming. Om deze redenen is het dan ook niet eenvoudig een bouwproject op een gestroomlijnde manier, met minimale faalkosten te realiseren.

1.2 Doelstelling Doelstelling van dit project is het aantonen van de mogelijkheden van gedistribueerde projectplanning en informatievastlegging in de bouwbranche door het opzetten en testen van een prototype van de voorgestelde oplossing.

1.3 Aanpak Het gebrek aan afstemming tussen planningen is lastig om te overwinnen. Vooral het feit dat het operationele proces wordt gevormd door vele verschillende autonome partijen maakt het moeilijk. Alle partijen streven immers hun eigen commerciële doelen na. De benoemde problematiek ontstaat onder andere omdat in de bouw veel verschillende partijen moeten samenwerken. Die samenwerking wordt echter wel steeds gericht op het optimaliseren van het eigen proces en niet het gehele proces. In de bouwpraktijk betekent dat dus dat de onderaannemer weliswaar optimalisatie nastreeft, maar zich daarbij richt op zijn eigen werkzaamheden. Het project waar zijn werk onderdeel vanuit maakt is de ‘zorg’ van de hoofdaannemer. INITI8 B.V. heeft veel ervaring opgedaan in de logistiek- en de zorgsector met vergelijkbare problemen. Bij de aanpak van die problemen is gebruik gemaakt van gedistribueerde planningen afstemmingstechnieken. In dit project is bekeken of een dergelijke aanpak ook voor de bouwsector toegevoegde waarde kan bieden. De aanpak van het project is stapsgewijs als volgt opgebouwd: 1. Vooronderzoek 2. Definiëren conceptuele oplossing 3. Opzet, test prototype en rapportage


1. Vooronderzoek Zoals in de inleiding is weergegeven weten partijen wel ongeveer waardoor de problemen in de praktijk worden veroorzaakt. Doorgaans worden daarbij oorzaken en gevolgen door elkaar heen genoemd. Door het doen van een grondig vooronderzoek wordt het mogelijk om duidelijk te krijgen wat nu werkelijk de factoren zijn die de problemen veroorzaken. Pas wanneer duidelijk is welke factoren de problemen veroorzaken wordt het zinvol iets aan een oplossing te doen. Ook wordt hierbij in detail uitgezocht hoe de mensen in de praktijk met planning omgaan. Wat doen ze op welk moment, wat vindt men belangrijk en wat niet, welke zaken spelen een rol bij het maken van de onderlinge afspraken? Deze gegevens zijn bij het uitwerken van een conceptuele oplossing van groot belang. Een opsomming van oorzaken en gevolgen alleen is echter niet voldoende. Het is van belang ook helder te krijgen hoe de verschillende van belang zijnde factoren elkaar beïnvloeden. Eigenlijk, hoe de dynamiek rond de problemen in elkaar zit. Om die reden is in het project bij het analyseren gebruik gemaakt van systeemdynamica. Voordat met systeemdynamica aan de slag gegaan kan worden is basismateriaal nodig. Om die rede is een gericht literatuuronderzoek uitgevoerd. Daarbij is echter alleen de literatuur die ingaat op de afstemming van planningen relevant. Naast het literatuuronderzoek zijn veel interviews bij mensen uit de praktijk afgenomen. Bij de interviews is gekozen voor een zo goed mogelijke verdeling over de verschillende rollen die in een bouwproces ingevuld worden. Daarbij moet gedacht worden aan de rol van het architectenbureau, het bouwbedrijf (projectleider, werkvoorbereider, uitvoerder) de onderaannemer en de leverancier. Bij het analyseren en verwerken van het basismateriaal in een systeemdynamisch model is gebruik gemaakt van de controlefunctie door een klankbordgroep. De klankbordgroep bestond uit een selectie van mensen met verschillende rollen in het bouwproces. Overigens zijn de leden van de klankbordgroep ook allen geïnterviewd. Deze aanpak heeft er voor gezorgd dat de conclusies die gaandeweg zijn getrokken steeds konden worden gevalideerd door mensen uit de praktijk.

2. Definiëren conceptuele oplossing Nadat uit het vooronderzoek is gebleken welke factoren een belangrijke veroorzaker zijn van de problemen die de bouwsector dagelijks ervaart en nadat de precieze werkwijze van de ‘planners’ in het proces duidelijk is, is gestart met het formuleren van een oplossingsconcept. Om gebruik te maken van eerdere ervaringen is gaandeweg het onderzoek steeds gekeken en vergeleken met de logistieke sector. Echter, ondanks dat de logistieke sector veel lijkt op de bouwsector zijn de sectoren niet hetzelfde. Vooraf stond dus ook niet vast dat het in de logistieke sector succesvolle concept ook voor de bouwsector geschikt zou zijn. Op basis van de in het vooronderzoek verkregen kennis is daarom specifiek voor de bouwsector een oplossingsconcept geformuleerd.

3. Opzet en test prototype Na de ontwikkeling van een conceptuele oplossing moet deze vertaald worden in een technische oplossing. Door een prototype te ontwikkelen kon, eveneens in samenspraak met de klankbordgroep, bekeken worden of wat in concept goed lijkt te werken ook daadwerkelijk in de praktijk toepasbaar zal zijn. In dit deel van het onderzoek gaat het dus om het vertalen van het concept in software. Het betreft hier een prototype en dus nog geen applicatie die direct in de praktijk kan worden ingezet. Met het prototype kunnen potentiële gebruikers echter wel beoordelen of de functionaliteit zoals deze geboden wordt daadwerkelijk waarde toevoegt. Wanneer dit het geval is ligt het voor de hand het prototype verder uit te werken en in een praktijksituatie te testen. In deze fase van het project zijn tevens de conclusies en aanbevelingen geformuleerd. Met de betrokken partijen is hierbij bekeken of en zo ja hoe een eventuele vervolgaanpak vorm zou kunnen krijgen. Eén en ander is in samenspraak met Stichting RRBouw gebeurd. Als laatste activiteit in dit project dient het rapporteren te worden vermeld. Het resultaat daarvan ligt op dit moment voor u.


2 Vooronderzoek Zoals in de inleiding aangegeven is het zaak grondig te onderzoeken waarom ‘de bouw’ wordt geconfronteerd met de problemen zoals hiervoor beschreven. Het binnen begroting en conform de planning afronden van projecten blijkt keer op keer een haast ondoenlijke opgave. Waar zit dat nou precies in? Welke zaken spelen daarbij precies een rol? Doel van het vooronderzoek was om dit duidelijk te maken. Om een duidelijk beeld te creëren is natuurlijk informatie nodig. Informatie uit de bouwpraktijk; van mensen en uit de literatuur. Gelijktijdig met een literatuuronderzoek is een aanvang genomen met het doen van interviews. In de bouwwereld wordt heden ten dage gewerkt in een organisatievorm waarbij de medewerkers duidelijke, eigen taken hebben. Of misschien, een organisatievorm waarin verschillende rollen worden ‘gespeeld’. Dat heeft tot gevolg dat men bij het creëren van een duidelijk overzicht van de werkwijze in de bouw met verschillende mensen van de verschillende taken apart zal moeten spreken. Dat is in dit project dan ook precies zo opgepakt. Vooraf is een overzichtje gecreëerd van de rollen die bij de aansturing en afstemming rond bouwprojecten een belangrijke rol spelen. De rollen die het meeste bij aansturing en afstemming in het proces te maken hebben bij de hoofdaannemer, onderaannemer en leverancier zijn: 4 4 4 4 4

Bedrijfsleider Projectleider Werkvoorbereider Uitvoerder Leverancier

Deze rollen of functies spelen tijdens het bouwproces een belangrijke rol in het sturen en onder controle houden van het bouwproces. Maar ook bijvoorbeeld een architect heeft een grote invloed op de gang van zaken bij een bouwwerk. Verder zijn leveranciers ook partijen die op het juiste moment de juiste goederen moeten leveren. Het logistiek organisatorische en planningsdeel van hun werk kan sterk versoepelend of verslechterend werken. Om die reden is ook gesproken met een architect en een leverancier. Als we spreken over een bouwproject dan is het logisch dat in eerste instantie de zaken worden bekeken vanuit het perspectief van de hoofdaannemer. Hij is diegene die uiteindelijk de ‘touwtjes in handen heeft’. Hij moet zorgen voor een zo soepel mogelijk proces. Hij moet de klant op het juiste moment een goed functionerend bouwwerk opleveren. Hierbij moet worden opgemerkt dat hoofdaannemers soms ook onderaannemers zijn. In dit onderzoek wordt vanuit het perspectief van een project gekeken naar de rol zoals ingevuld door de hoofdaannemer en die van de onderaannemer.

Functies Bedrijfsleider Projectleider Werkvoorbereider Uitvoerder Architect Leverancier Overig(onderzoeksbureau)

Aantal 8 4 2 3 1 1 1

partijen (qua planning en qua informatie) voor problemen zorgt. In de volgende paragrafen is in detail, per onderwerp, weergegeven wat de knelpunten zijn.

2.1 Organisatie in de bouw De bouwwereld is traditioneel van aard. De wijze waarop de bouw in Nederland is georganiseerd is vooral ontstaan tijdens de wederopbouw na de Tweede Wereldoorlog. In die periode was het produceren van veel van hetzelfde het devies. Op veel plaatsen in Nederland moesten (grote) wijken opnieuw worden gerealiseerd en wel in een zo kort mogelijke tijd. In die tijd was er (ook) een schaarste op het gebied van goed opgeleid personeel. Omdat er toch veel en snel gebouwd moest worden moest iedereen die kon werken en die beschikbaar was meebouwen aan Nederland. Dat was alleen mogelijk door het van oorsprong ambachtelijke werk op te delen in deelhandelingen. Zo konden veel mensen heel vaak hetzelfde werk doen en hoefde ze daarvoor niet een hele opleiding te volgen. In feite is in de huidige bouwwereld deze indeling naar verschillende (deel)taken nog ongewijzigd aanwezig. Tegenwoordig werken veel specialisten aan deze verschillende deeltaken als ZZP’er. Behalve een duidelijke verdeling van het werk in specialistische (deel)taken, is in de bouwbranche ook een duidelijke splitsing tussen denken en doen zichtbaar. De doeners worden niet lastig gevallen met regelen coördinatiewerk. Het zijn de denkers die daarvoor moeten zorgen. Maar de denkers moeten ook zorgen voor het bewaken van kwaliteit en voortgang. Doorgaans hebben de denkers echter weinig of geen ervaring met het ‘doen’. De denkers staan hoger in de hiërarchie van de organisatie. Deze denkers nemen de meeste beslissingen, zij houden het overzicht. Daarin worden deze leidinggevenden bijgestaan door gespecialiseerd stafpersoneel, zoals bijvoorbeeld de werkvoorbereider. Bij het aansturen van de doeners worden doorgaans gedetailleerde werkinstructies gegeven. De zelfstandigheid van de doeners is dan ook meestal beperkt. Overigens is dat bij de kleinere aannemers vaak niet het geval. Daar is doorgaans sprake van een vakman die een aantal ondersteunende collega’s heeft en die zelfstandig allerlei zaken regelt zoals bijvoorbeeld inkoop van materialen. Deze traditionele manier van organiseren was gezien de omstandigheden net na de oorlog een logisch gevolg. Het ging daarbij immers vooral om massaproductie. De bouwwereld wordt nu echter geconfronteerd met ontwikkelingen waar de traditionele organisatievorm minder geschikt voor is. Opdrachtgevers hebben steeds meer individuele wensen. Daarbij wil de opdrachtgever het liefst op het allerlaatste moment nog wijzigingen door kunnen voeren. Tevens wil de opdrachtgever direct de prijsconsequenties weten van de door hem gewenste alternatieven en keuzes. Op deze gewenste flexibiliteit is de organisatievorm van de bouwwereld onvoldoende ingericht. Daarnaast zijn er vanuit de overheid steeds meer en strengere regels waar rekening mee moet worden gehouden. Ook de tijd is steeds beperkter. Na opdrachtverlening wordt door de klant verwacht dat er direct met de bouw begonnen wordt en dat alles zeker binnen de gestelde termijnen wordt gerealiseerd. De opdrachtgevers hebben een duidelijke professionaliseringsslag doorgemaakt en zijn een veel sterkere gesprekspartner voor de bouwwereld geworden. De wijze waarop aanbesteding en opdrachtverlening door de tijd heen zijn ontwikkeld hebben er bovendien voor gezorgd dat de inkopers van opdrachtgevers met name op prijs sturen. De kwaliteit van de bouwer en het te bouwen bouwwerk staan ogenschijnlijk op het tweede plan. Als klap op de vuurpijl wordt de sector ook nog geconfronteerd met grote problemen op de arbeidsmarkt. Er is veel te weinig geschoold personeel beschikbaar en de kwaliteit van de geschoolde arbeiders is onvoldoende hoog.

Zoals in de inleiding al eerder beschreven is, is vooral de afstemming tussen de veelheid aan partijen een ogenschijnlijk groot probleem. Om die reden is het dus ook belangrijk de zaken vanuit het perspectief van de onderaannemer te bezien. In de interviewronde is dan ook gesproken met de bedrijfsleider van een typische onderaannemer. Nadat duidelijk was welke rollen/functies relevant waren om in interviews verder uit te diepen is contact gelegd met mensen die in de praktijk dergelijke rollen invullen. In de onderstaande tabel zijn de functies weergegeven van de geïnterviewde personen. In de gesprekken werd steeds duidelijker dat er inderdaad sprake is van een structureel probleem waar nodig een oplossing voor moet komen. In de gesprekken bleek keer op keer dat de afstemming tussen

In de praktijk wordt de huidige manier van werken gekenschetst door een duidelijke opdeling van het bouwproces in allerlei deelactiviteiten. Een project wordt gerealiseerd door verschillende disciplines. Denk maar aan: acquisitie, ontwerp, constructie, tekenen, calculatie, inkoop en uitvoering. De laatste discipline, de uitvoering, is ook weer verdeeld in allerlei vakploegen. Vakploegen als ruwbouwtimmerlieden, metselaars, gipswandploegen, vlechters, elektriciens, et cetera. Het werk wordt als het ware in stukken opgedeeld en door die verschillende vakploegen uitgevoerd. Zoals al eerder aangegeven is er een sterke trend zichtbaar naar het als zelfstandig ondernemer werken in opdracht van hoofdaannemers: de zogenaamde ZZP’ers.



De hoeveelheid (onder)onderaannemers wordt dus ook steeds groter. Al deze partijen moeten samen het bouwwerk realiseren, rekening houdend met de externe factoren zoals beschreven. Dus strenge regels, tijdsdruk, ontbrekende of tegenstrijdige informatie, veel veranderingen bij de opdrachtgever, enzovoorts. Dat realiseren kan alleen maar als er goed wordt afgestemd tussen alle betrokkenen onderling.

2.2 Afstemming in de bouw Zoals al aangegeven bestaat er een sterke scheiding tussen doeners en denkers. Dat houdt in dat het regelen afstemwerk wordt gedaan door daarvoor verantwoordelijke personen en niet door de vakploegen zelf. De projectleiding en de werkvoorbereiding houden zich bezig met de planning, de voorbereiding en het overleg met verschillende partijen. De uitvoerder op de bouw is met name verantwoordelijk voor het aansturen van de vakploegen en de individuele bouwvakkers. Uiteindelijk is de uitvoerder diegene die ervoor dient te zorgen dat het werk voortgaat zoals het gepland is. Gezien de veelheid aan (deel)taken en de veelheid aan partijen is dat geen eenvoudige opgave. Traditioneel was de uitvoerder een man die zijn sporen in het bouwen voldoende had verdiend voordat hij als uitvoerder aan het werk zal ging. Door de veranderende omstandigheden is het niet meer per definitie zo dat een uitvoerder een zeer ervaren bouwvakker is. Daarnaast is niet elke uitvoerder even goed in staat om daadwerkelijk overzicht te houden en de ploegen ook zo te sturen als nodig is. De traditionele organisatie in de bouw, waarbij activiteiten zijn opgesplitst en waar een grote diversiteit aan vakspecialisten betrokken is, en waar een sterke scheiding tussen denken en doen bestaat, wordt meer en meer geconfronteerd met problemen. Problemen als afstemmingsverliezen en overbelasting van sturende medewerkers, bijvoorbeeld uitvoerders. De afstemverliezen komen tot uitdrukking in bijvoorbeeld: 4 herstelkosten 4 wachten door kleine onderbrekingen van het werk 4 overwerk en hoger tempo 4 speelruimte in de planning 4 normvervuiling 4 onderbreking van het werk door tussendoor klussen (omschakelingsverlies) 4 transport of loopkosten (bron: zelfsturing in de bouw, ST-Groep/RRBouw)

2.3 Informatie in de bouw In de vorige paragraaf is ingegaan op het onderwerp afstemming. Het gaat bij afstemming echter niet alleen om het feitelijk afstemmen van deelprocessen op elkaar, dus bijvoorbeeld qua tijd. Het gaat ook om het afstemmen, of beter nog, het goed uitwisselen van informatie. De moderne opdrachtgever vraagt veel van de bouwwereld. Onder andere veel flexibiliteit. Maar, om te kunnen bouwen moet wel duidelijk zijn wat er gebouwd moet worden. En, hoe dat eruit moet zien. Welke kwaliteitseisen een rol spelen. Die informatie moet niet alleen beschikbaar zijn, deze moet ook op het juiste moment op de juiste plek zijn. Een gevolg van de veelheid van taken en de veelheid van partijen is ook dat het uitwisselen en beschikbaar houden van informatie veel problemen oplevert. Bijvoorbeeld veranderingen in het ontwerp moeten wel op het juiste moment bij alle mensen terecht komen die daar ook iets mee moeten. Als er tekeningen worden gebruikt moeten het wel de laatste, meest actuele versies zijn. Het is in de bouw dagelijkse praktijk dat zaken moeten worden aangepast of worden overgedaan omdat vooraf onvoldoende goede informatie beschikbaar was om deze fouten te voorkomen. Dat kost geld, veel geld. Kortom, het op tijd verkrijgen en op de juiste wijze beheren en distribueren van informatie blijkt in bouwwereld voor verbetering vatbaar te zijn.


2.4 Planning in de bouw Om een bouwwerk goed tot stand te laten komen zal de aansturing van het bouwproces goed moeten zijn. Die aansturing krijgt vorm door vooraf een planning te maken. Die planning beschrijft in detail welke activiteiten op welk moment en in welke volgorde moeten worden uitgevoerd om uiteindelijk het bouwwerk zo efficiënt en goed mogelijk te realiseren. Nadat een planning is gemaakt is het steeds zaak om het werk ook daadwerkelijk volgens deze uit te voeren. De ‘bestuurder’ van het proces zal er voor moeten zorgen dat de regie in eigen handen blijft. Het doel daarbij is steeds de uitvoering op basis van de planning te bewaken en te beheersen. Omdat bouwprojecten doorgaans zo snel mogelijk moeten worden gerealiseerd en omdat de ervaring leert dat er veel verkeerd kan gaan in zo’n proces wordt steeds geprobeerd vooraf en tijdens de uitvoering zoveel mogelijk onzekerheden te minimaliseren. In de praktijk worden projecten op verschillende manieren aangepakt. 4 Als eerste de ‘het oog van de meester’-stijl; de projectleider of bedrijfsleider zit bovenop de verschillende werken (dus meerdere projecten tegelijk) en is in feite een soort superuitvoerder die er alles aan doet om alle projecten binnen de planning te houden. Op deze manier laat hij het werk volledig ‘gecontroleerd’ tot een goed einde komen. Ondanks dat er op elk project een uitvoerder aan het werk is kent hij toch alle details en ‘assisteert’ zo volcontinu de verschillende uitvoerders. Deze superuitvoerder is ‘door de wol geverfd’ en heeft het vak in de praktijk geleerd. 4 De tweede aanpak is de meest gangbare. Elk project heeft daarbij zijn eigen uitvoerder die de hoofdverantwoordelijke is voor de planning van het project. In de praktijk blijkt het voor veel bouwondernemingen lastig te zijn om sterke uitvoerders te vinden. Mensen die in staat zijn daadwerkelijk op de bouwplaats de touwtjes in handen te houden en het overzicht te allen tijde te bewaren. In beide stijlen ligt de nadruk van de aanpak steeds op procesbewaking. 4 De derde aanpak is die van het ‘Integraal Bouwen’. In deze aanpak wordt iedereen die bij het project betrokken is tot op zekere hoogte verantwoordelijk gemaakt voor het welslagen van het werk. Het voordeel van deze aanpak is dat potentiële problemen op deze wijze vroegtijdig aan het licht komen en dus op tijd kunnen worden aangepakt. Overigens wordt deze stijl of aanpak überhaupt nog weinig en met name bij grotere projecten toegepast. In de onderstaande tabel zijn de belangrijkste kenmerken van de stijlen weergegeven. De eerste twee methodes zijn daarbij samengevoegd omdat ze qua kenmerken nagenoeg hetzelfde zijn. Ze zijn weergegeven onder de noemer ‘Procesbewaking’. Projectaanpak Kenmerken Procesbewaking Integraal Bouwen Organisatie: centraal decentraal Verantwoordelijk: hiërarchie allen gezamenlijk Doel: terugbrengen van verstoringen voorkomen van verstoringen Informatie-uitwisseling: hiërarchisch integraal Middel: problemen herkennen en samenwerking versterken, toewijding vragen beantwoorden vergroten en verantwoordelijkheid delen Toepasbaar: alle werken grotere werken Een variant op het Integraal Bouwen is de methode die door één van de geïnterviewde bedrijven voor een aantal van haar projecten hanteert. Daarbij wordt het team dat de bouw uit gaat voeren, vroegtijdig bij elkaar gehaald. Gezamenlijk gaat men de aanpak en planning van het werk vooraf met elkaar uitstippelen en afstemmen. Ook hierbij is al voor uitvoering duidelijk welke afstemmingsvraagstukken tijdens de bouw op zullen treden. Omdat alle betrokken partijen hierbij aanwezig zijn kunnen door goed onderling overleg problemen voorkomen worden. Het grote doel bij deze aanpak is het door het doorlopen van een aantal ‘plansessies’ steeds strakker maken van de planning, een soort samen-korter-aanpak. Omdat er duidelijk overleg tussen de betrokkenen plaatsvindt, kan allerlei ingebouwde reservetijd die iedereen


in de praktijk steeds inbouwt, worden teruggedrongen. Dat kan omdat bijvoorbeeld de aannemer die voor het tegelwerk verantwoordelijk is, direct met de stukadoor kan overleggen over het hoe, wat en wanneer ten aanzien van stucwerk. Zo weet de tegelzetter precies wat hij kan verwachten op het moment dat hij op de bouwplaats verschijnt om zijn werk te doen. Extra tijd om eerst allerlei problemen op te lossen heeft hij dus niet nodig. Omdat de tegelzetter in dit voorbeeld duidelijk met de stukadoor heeft afgestemd weet hij immers nagenoeg zeker dat het zo zal gaan. Een tweede, groot voordeel van deze aanpak is de sociale druk die ontstaat tijdens het toepassen van deze aanpak. De tegelzetter in het voorbeeld hiervoor weet precies wie de stukadoor is, maar niet alleen de tegelzetter weet dat, de hele groep (onder)aannemers weet wie hij is. Er zijn duidelijke, groepsgewijs gemaakte afspraken gemaakt waar men niet zomaar onderuit kan. Bij de samen-korter-aanpak is gebleken dat deze aanpak leidt tot het significant verkorten van de bouwtijd en tevens tot een veel soepeler manier van samenwerken. Omdat alle betrokken partijen commitment aan het project hebben gegeven, en onder de genoemde sociale druk, zal iedereen er alles aan doen om inderdaad precies te doen wat is afgesproken. Als een onderaannemer door vertragingen of iets dergelijks tegelijk op een ander werk moet zijn maar hij heeft de mensen niet, dan zal hij zeer waarschijnlijk kiezen voor het project waar hij die sociale druk voelt. Het blijkt een succesvolle aanpak te zijn die met name op het gebied van onderlinge afstemming heel sterk werkt. De sociale druk is een belangrijke motivatie om afspraken na te komen daarom zal deze aanpak nooit een sectorbrede oplossing kunnen bieden. Als er immers door vertragingen of misschien wel door versnellingen toch op hetzelfde moment dezelfde capaciteit bij twee projecten tegelijk nodig is, dan zal er toch gekozen moeten worden. Eén van de ‘projecten’ zal dan toch teleurgesteld moeten worden. Met andere woorden, door die sociale druk kan een feitelijke planningsafstemming in een breder kader niet worden bereikt. Bij het maken van een planning voor een bouwproject spelen vele onzekerheden een rol. Dit heeft als gevolg dat van alle bouwpartners grote flexibiliteit gevraagd wordt. Meestal maakt de hoofdaannemer een eerste hoofdplanning. Alle (hoofd)activiteiten worden daarbij op volgorde in een balkenschema geplaatst. In eerste instantie maakt de hoofdaannemer aannames over de duur en het moment van de inzet van de betrokken onderaannemers. Wanneer duidelijk is wie daadwerkelijk als onderaannemer betrokken zal zijn worden de gemaakte inschattingen doorgegeven of gezamenlijk doorgenomen.

Als er dus een situatie ontstaat waarin hij eigenlijk op twee werken tegelijk moet zijn, heeft hij in beide wat rek om toch te proberen iedereen tevreden te krijgen/houden. Schematisch ziet dat er als volgt uit:

Project A

Tegelwerk A Buffertijd

Tegelwerk B

Project B

Figuur 1: Ingebouwde buffertijd in de planning van de onderaannemer Er zijn nog meer onzekerheden waar de aannemer en onderaannemer mee te maken krijgen. Zo is er bijvoorbeeld de onzekerheid die wordt veroorzaakt door informatie. Of beter gezegd, door het ontbreken of onjuist zijn ervan. Als we weer de tegelzetter als voorbeeld nemen kun je stellen dat hij voor een goede tijdinschatting moet weten hoe groot het te betegelen oppervlak is. Maar ook op welke ondergrond er betegeld moet worden of het soort tegel (grootte, gewicht). Vaak blijkt deze informatie in het begin van het project nog lang niet éénduidig beschikbaar te zijn. Daar zijn een aantal oorzaken voor. Zo gebeurt het regelmatig dat de opdrachtgever nog geen keuzes heeft gemaakt over hoe het moet worden. Bij de woningbouw gebeurt dat vooral ook omdat de uiteindelijke kopers of gebruikers pas laat bekend zijn. Verder gebeurt het vaak dat de informatie wel ‘ergens’ beschikbaar is, maar dat die informatie niet goed genoeg is vastgelegd en/of niet of onvoldoende goed is gecommuniceerd naar de partijen die de informatie moeten hebben. Omdat de onderaannemer uit ervaring weet dat hij hier waarschijnlijk mee te maken gaat krijgen en omdat dat weer zal leiden tot vertragingen bouwt hij ook hiervoor in zijn planning een strategische buffer in (zie figuur 2).

Tegelwerk B

Taak n+1

Buffertijd

2.5 Het inbouwen van buffers De onderaannemer blijkt echter in de praktijk een zekere mate van strategisch gedrag te vertonen. Als ondernemer probeert hij zijn eigen belang zo goed mogelijk te dienen. Hij wordt echter gedwongen met aantal onzekerheden rekening te houden. De onderaannemer werkt doorgaans niet aan slechts één project tegelijk, maar aan meerdere projecten (zie figuur 1). Dat heeft als gevolg dat soms de gewenste capaciteit groter is dan de beschikbare capaciteit. De mogelijkheden om dit op te lossen zijn natuurlijk afhankelijk van de grootte van de onderneming. Een grotere onderaannemer kan misschien wel meerdere projecten tegelijk bedienen, maar ook bij hem is er een grens. Toch zorgen de talloze verstoringen en dus wijzigingen in de uitvoering voor verschuivingen in de planning. Dit kan als gevolg hebben dat hij dezelfde capaciteit op twee plaatsen tegelijk moet inzetten. Omdat hij met deze onzekerheid te maken heeft, en omdat hij weet dat er gaandeweg de uitvoering nog wel het één en ander zal wijzigen in de planning en informatie zal hij in eerste instantie snel akkoord gaan met het door de hoofdaannemer voorgestelde moment van uitvoering van zijn taken. Bovendien kan het weer de geplande startdatum ook nog beïnvloeden (meer of minder onwerkbaar weer dan gepland). De onderaannemer wil in elk geval liever geen ‘nee’ verkopen. Uiteindelijk heeft dit natuurlijk wel gevolgen voor de betrouwbaarheid van de afspraak die de hoofdaannemer en de onderaannemer gezamenlijk maken voor de uitvoering van de onderaannemerstaken in het betreffende project. Behalve dat de onderaannemer enigszins strategisch omgaat met de afspraken over het moment waarop de werkzaamheden zullen worden uitgevoerd, zal hij ook wat buffertijd inbouwen in de doorlooptijd. Dit gebeurt lang niet altijd bewust. In alle projecten is het steeds weer afwachten hoe het loopt. Door aan te geven dat hij wat meer tijd nodig heeft om de werkzaamheden uit te voeren, zal hij bij de verschillende projecten wat meer speelruimte overhouden.


Figuur 2: Extra ingebouwde buffertijd in de planning van de onderaannemer Zoals hiervoor beschreven zorgt de onderaannemer er in de afspraken met de hoofdaannemer voor dat hij voldoende buffertijd inbouwt voor onzekerheden. Maar met de twee genoemde onzekerheden zijn we er nog niet. Ook de afhankelijkheid van andere bouwpartijen die vóór hem aan de slag zijn gegaan zorgt voor onzekerheden. Is die partij wel op tijd klaar met zijn werk? Met andere woorden, kan hij wel beginnen op het moment dat is afgesproken? En, is de werkplek dan inderdaad geschikt om echt aan de slag te gaan of moet er eerst nog een hoop rommel opgeruimd worden of iets dergelijks? Omdat het in de praktijk voor komt dat hij hier vertragingen door oploopt bouwt hij ook voor die onzekerheid een beetje extra buffertijd in (zie figuur 3). Taak n

Stukadoor Tegelwerk B

Taak n+1

Buffertijd

T

Figuur 3: Buffertijd in het plan van de onderaannemer als reactie op afhankelijkheid van de voorganger


Het beschreven (strategische) gedrag van de onderaannemer is logisch. Het is het gevolg van het bestaan van zoveel onzekerheden. In de praktijk blijkt dan ook dat bijna alle onderaannemers op die wijze te werk gaan. Iedereen bouwt buffers in. In het voorbeeld van de tegelzetter geldt dat dus ook voor de stukadoor (zie figuur 4).

Taak n

Stukadoor Tegelwerk

Taak n+1

Buffertijd

T+

Figuur 4: Buffertijden, ook bij de voorganger van de tegelzetter Samengevat zijn er dus drie belangrijke redenen voor (onder)aannemers om extra tijd in de doorlooptijd van activiteiten mee te nemen in de planning (bewust of onbewust), te weten: 4 onzekerheid in de eigen planning (andere projecten); 4 onzekerheid als gevolg van onvolledige of ontbrekende informatie; 4 onzekerheid als gevolg van afhankelijkheid van de voorganger in het werk. Natuurlijk zal de projectleider, of diegene die uit naam van de hoofdaannemer verantwoordelijk is voor de opzet van het project, in zekere zin ook onderhandelen met de onderaannemers. Soms zal hij zijn eigen inschatting laten prevaleren. Toch is het zo dat de in de bouw gehanteerde planning doorgaans veel ingecalculeerde buffertijd bevat. Dat is dan ook de voornaamste reden dat de meeste projecten toch op tijd gerealiseerd kunnen worden. Natuurlijk moet er soms extra capaciteit worden ingekocht, maar meestal is de ‘rek’ die in de planning zit voldoende om verstoringen toch op te vangen. In het kader van het zoeken naar verbetering ligt het dus voor de hand om te proberen die speelruimte uit de planning te verwijderen. In het beschreven voorbeeld van de samen-korter-aanpak is dat precies wat er gebeurt. De onderaannemers blijken bereid steeds meer buffer in te leveren als de onzekerheden, door onderlinge afstemming en overleg, worden weggenomen. Als vervolgens de uitvoering volgens plan verloopt, is het dus mogelijk om het project in fors minder dagen te realiseren. Bij deze aanpak werd bij een bepaald project in eerste instantie de projectdoorlooptijd verkort van 125 naar 100 dagen. Door nog een keer met de groep een plan- en afstemsessie te doorlopen werd de doorlooptijd verder verkort tot 80 dagen. Uiteindelijk is het project in 83 dagen gerealiseerd.

2.6 Oorzaken en gevolgen Zoals in de inleiding van dit rapport al is gesteld is het doel van het vooronderzoek het duidelijk bepalen wat oorzaken en wat gevolgen zijn. Zo wordt het mogelijk om bij de aanpak van de problemen in de bouw daadwerkelijk oorzaken aan te pakken. Op basis van de interviews en de literatuurstudie is een systeemdynamisch model gemaakt van die belangrijkste oorzaken en gevolgen. Uit het onderzoek is duidelijk gebleken dat met name in de aansturing van het proces problemen ontstaan. Om die reden is de focus van het onderzoek meer en meer komen te liggen op deze aansturing. Met de aansturing wordt in dit kader bedoeld, het benoemen van de noodzakelijke activiteiten om het bouwproject te realiseren, het in een planning onderbrengen van die activiteiten en het tijdens de uitvoering zorgen dat de activiteiten volgens plan (of beter) verlopen. Zoals uit de voorgaande tekst blijkt zijn er in de organisatievorm die het meest gangbaar is in de bouw vaak meerdere verschillende personen betrokken bij die aansturing. Hierbij speelt ook de duidelijke splitsing tussen doeners en denkers een grote rol. Het blijkt in het bouwproces steeds erg lastig te zijn om voldoende goede afstemming tussen de denker(s) en de vele doeners te bereiken. Vaak ook veroorzaakt door het feit dat veel doeners niet binnen het zelfde bedrijf werken, maar als ingehuurde onderaannemer werkzaam zijn. Behalve het operationele afstemmen

10


tussen de partijen is ook de informatie-uitwisseling, de informatiebeschikbaarheid en de eenduidigheid van informatie vaak een probleem. Voor wat betreft het afstemmen tussen partijen en de beschreven informatieproblematiek kan een duidelijke parallel getrokken worden met de logistieke sector in het algemeen en havenlogistiek in het bijzonder. In de havenlogistiek is ook sprake van een veelheid aan partijen die weer door andere partijen worden aangestuurd (doeners en denkers), terwijl er onderling weinig of soms geen afstemming plaatsvindt. De veelheid aan spelers in die sector is er tevens oorzaak van dat de (lading)informatie vaak blijft steken bij één van de spelers. De achterliggende problematiek is in feite exact hetzelfde. Zoals aangegeven zijn de belangrijkste oorzaken en gevolgen in het aansturingproces in een model verzameld. Dit is gedaan om op basis van de dynamiek in het systeem duidelijk te krijgen of vermeende oorzaken ook daadwerkelijk oorzaken zijn of misschien toch eigenlijk gevolgen. Doel bij deze aanpak was dus met name het kunnen aanwijzen van de echte oorzaken van de problemen. Omdat het vooral om de aansturing gaat is het systeemdynamisch model (op de volgende bladwijze weergegeven als figuur 5) dan ook op die aansturing gebaseerd. Bovenin het model is van links naar rechts het proces zichtbaar waar ten behoeve van een nieuw project via de voorbereiding een hoofdplanning voor uitvoering wordt gegenereerd. Op basis van de hoofdplanning wordt voor de eerste 8 weken en detailplanning gemaakt (over het algemeen wordt gekozen voor een periode van 6 tot 8 weken voor de detailplanning; dit gebeurt overigens (twee)wekelijks opnieuw). In het model is dat zichtbaar als projectactiviteiten (meer in detail uitgewerkt dan in de hoofdplanning) die instromen in de detailplanning. Nadat de activiteiten in de detailplanning zijn verzameld gaan ze op een zeker moment over naar de uitvoering. In principe worden ze daar afgewerkt en verdwijnen de taken uit het systeem. Daarmee is de route van projectactiviteiten in feite compleet. Maar het hiervoor, versimpeld, weergegeven proces blijkt in de praktijk vaak te worden verstoord. De eerste opvallende factor die veel verstoringen veroorzaakt of verergert is ‘de mate van onzekerheid ontstaan uit informatie’. Twee zaken die daar een rol in spelen zijn: de kwaliteit van de informatie en de beschikbaarheid van informatie. Wanneer deze twee factoren niet optimaal zijn, geeft dat in het proces verstoringen. Bijvoorbeeld omdat op basis van niet eenduidige informatie of bij het ontbreken van informatie minder goede inschattingen kunnen worden gemaakt. Dit heeft het eerder beschreven ‘spel van het invoegen van buffertijd’ tot gevolg. Maar niet alleen bij het maken van een planning speelt het een grote rol. Juist ook tijdens de uitvoering blijkt die onzekerheid uit informatie steeds een verstorend effect te hebben. Zo leidt het tot wijzigingen bij het uitvoeren van projectactiviteiten. Dit kan vervolgens weer als gevolg hebben dat herplanning nodig is. Concreet kan bijvoorbeeld gedacht worden aan het gebruik van het verkeerde materiaal. De werkelijke wens van de klant is via het informatiekanaal niet op tijd bij de juiste personen terecht gekomen. Gevolg zal zijn dat het werk, met nieuw, juist materiaal opnieuw zal moeten worden uitgevoerd. Dit kost natuurlijk altijd veel tijd en geld. In bijlage 6.1 is een sequentie diagram als illustratie weergegeven. Dit diagram laat zien welke afstemmingen en wijzigingen er al in een normale situatie voorkomen. Daarbovenop komen dus nog eens al de wijzigingen die het gevolg zijn alle onzekerheden in het proces.


11

hoeveelheid wijzigingen projectactiviteiten

mate van onzekerheid ontstaan door planning x

In het systeem dynamisch model op de vorige bladzijde (figuur 5), wordt gebruik gemaakt van een aantal symbolen. Als eerste de stromen. Bijvoorbeeld de ‘stroom van projectactiviteiten’ die gepland moeten worden. Het symbool dat voor stromen wordt gebruikt is hieronder weergegeven.

Het volgende symbool dat in de systeem dynamica wordt toegepast is de voorraad. In het systeemdynamisch model in figuur 5 is bijvoorbeeld de ‘voorraad projectactiviteiten’ weergegeven. Het symbool dat voor een voorraad wordt gebruikt ziet er als volgt uit.

De laatste symbolen die in het model zijn weergegeven zijn de constanten en de hulpvariabelen. Bijvoorbeeld het percentage verkeerde informatie kan als een constante worden gezien. Zeker als er weinig informatie over beschikbaar is. Op dat moment kan uitgegaan worden van een vast percentage. Hulpvariabelen beïnvloeden net als constanten het proces maar zijn variabel. De invloed ervan kan verschillen door omstandigheden. Als daarover informatie beschikbaar is kan dit in het systeemdynamisch model worden verwerkt als hulpvariabele. De ruit als hieronder afgebeeld is het symbool voor een constante, her rondje is het symbool dat voor een hulpvariabele wordt gebruikt.

niet beschikbare info verkeerde info

kwaliteit van informatie x

mate van onzekerheid ontstaan uit informatie x

mate van afhankelijkheid met andere projectactiviteit x

instroom project

Voorbereiding

voorbereiding naar hoofdplanning

Hoofdplanning

van hoofdplanning naar hoofdplanning

nauwkeurigheid in te schatten doorlooptijd uitvoering verantwoordelijke x

instroom projectactiviteiten x

hoeveelheid andere projecten van de verantwoordelijke x

planning projectactiviteiten in detailplanning

strategischafgegeven starttijd en slack verantwoordelijke x

van detailplanning naar uitvoering

laatste eindtijd van de activiteit

uitgevoerde detailprojectactiviteiten

uitvoering detailplanning herplanning van uitvoering wijziging van planning projectactiviteiten aantal projectactiviteiten

Systeem Dynamica symbolen

Figuur 5: Systeemdynamisch model aansturing bouwproces (zie toelichting in de kadertekst op de volgende bladzijde)

12


Zoals eerder al beschreven blijkt de inschatting in doorlooptijd en de afstemming van activiteitmomenten door onderaannemer (onderonderaannemers) niet altijd nauwkeurig. Met nauwkeurig wordt hier overigens bedoeld dat er meer tijd gereserveerd wordt dan werkelijk nodig is, als reactie op de onzekerheden die de onderaannemer tegenkomt of verwacht tegen te komen. Een factor die hier weer veel invloed op heeft blijkt ook de hoeveelheid projecten te zijn waar de onderaannemer bij betrokken is. Hier geldt hoe groter de hoeveelheid, hoe meer strategisch gedrag wordt toegepast. Een andere factor die in de hele projectplanning steeds invloed heeft is het moment waarop de projectactiviteit moet plaatsvinden. Wanneer afspraken worden gemaakt over het startmoment van activiteiten die op korte termijn (dus ook in het begin van het project) moeten plaatsvinden is de betrouwbaarheid van die afspraak doorgaans veel groter dan wanneer de activiteit aan het eind van het project plaatsvindt. Deze factor beïnvloed dus ook het strategische gedrag dat de onderaannemer toepast bij het maken van afspraken. De betrouwbaarheid van de afspraken die men gezamenlijk maakt laat dus regelmatig behoorlijk te wensen over. De genoemde planningsfactoren vormen samen de factor ‘de mate van onzekerheid ontstaan door planning’. Deze factor blijkt een heel belangrijke veroorzaker van verstoringen in de uitvoering van projecten te zijn. Zoals zo vaak hangt in dit systeem ook alles met alles samen. Hiervoor is de mate van onzekerheid ontstaan door de planning weergegeven. Behalve dat deze invloed heeft op het aantal wijzigingen


13

in projectactiviteiten, wordt hij op zichzelf ook beïnvloed door de mate van onzekerheid ontstaan uit informatie. Wanneer deze onzekerheid dus hoog is wordt de mate van onzekerheid ontstaan door planning versterkt.

2.7 Conclusies vooronderzoek In de weergave van het systeemdynamisch model zijn twee bolletjes rood gekleurd, te weten de ‘mate van onzekerheid ontstaan door informatie’ en de ‘mate van onzekerheid ontstaan door planning’. Het zijn die twee factoren waar het overgrote deel van de verstoringen in de uitvoering vandaan komt. Opvallend is dat de mate van onzekerheid ontstaan door informatie dus een versterkend effect heeft op de mate van onzekerheid ontstaan door planning. Let wel, het gaat hier om de oorzaken van verstoringen in de uitvoering, die voortkomen uit de wijze van aansturing van het proces. Hier is wederom een duidelijke parallel te leggen met de (haven)logistieke sector. Daar treedt hetzelfde effect op. Om die reden dan ook erg interessant om een succesvolle aanpak in die sector te beoordelen voor toepassing in de bouwsector.

weet dat bij het maken van de eerste planning voor een project vaak nog niet duidelijk is wie allemaal als onderaannemer betrokken zullen zijn. In de doelstelling van dit project is gesproken over het onderzoeken van de mogelijkheden van gedistribueerde projectplanning en informatievastlegging in de bouwbranche. De elementen uit de samen-korter-aanpak die tot succes hebben geleid, kunnen in een gedistribueerde planningen informatieoplossing worden toegepast. In het volgende hoofdstuk zal worden toegelicht hoe dat mogelijk is.

De hoge faalkosten in de bouw komen dus onder andere voort uit de wijze waarop het proces wordt aangestuurd. In paragraaf 2.1 ‘Organisatie in de bouw’ is toegelicht waarom de bouw is georganiseerd zoals ze is georganiseerd. Gezien de marktontwikkelingen en de ontwikkelingen op de arbeidsmarkt liggen er duidelijke mogelijkheden voor de bouwwereld om op die veranderingen in te springen. Andere organisatievormen bieden grote kansen om efficiënter, betrouwbaarder en daarmee winstgevender te kunnen bouwen. Nieuwe, andere organisatievormen vallen buiten het kader dit project. Binnen dit project ligt de focus op het zoeken naar de mogelijkheden om de huidige, voorlopig meest gangbare, werkwijze in de bouwwereld te verbeteren. Er is hierbij gekozen om de huidige manier van werken, waarin hoge faalkosten eerder regel dan uitzondering zijn, onder de loep te nemen en te zoeken naar mogelijkheden om die huidige werkwijze te verbeteren. Binnen dit kader blijken de grootste kansen te liggen in het toepassen van oplossingen die leiden tot het verlagen van de mate van onzekerheid ontstaan door informatie en het verlagen van de mate van onzekerheid ontstaan door planning. Doel bij het verminderen van de negatieve invloed van die twee factoren is het voorkomen van verstoringen in de uitvoering, maar daarnaast ook het verwijderen van ingebouwde buffertijden. De doorlooptijd van projecten kan korter en de planning kan betrouwbaarder. In het voorbeeld van de samen-korteraanpak bleek het mogelijk te zijn om door gezamenlijke afstemming de projectduur fors in te korten. Tevens bleek het mogelijk te zijn om de betrouwbaarheid van de planning fors te vergroten waardoor de uitvoering nagenoeg volgens de planning werd uitgevoerd. Het is echter de vraag of de wijze waarop dat mooie resultaat tot stand kwam ook geschikt is om algemeen te worden toegepast. De sociale druk die uitgaat van de samen-korter-aanpak zal ongetwijfeld verdwijnen wanneer onderaannemer met meer opdrachtgevers op dezelfde wijze gaan werken. Uiteindelijk moeten dan toch weer keuzes gemaakt worden. De grote bereidheid om er alles aan te doen binnen de planning te blijven zal op een andere wijze bereikt moeten worden. Bovendien is het niet zozeer onwil waarom partijen afspraken regelmatig niet precies na kunnen komen, maar vooral de onbetrouwbaarheid van alle planningen waarmee ze te maken hebben is daar oorzaak van. Beter is het dus om ons te richten op een grotere betrouwbaarheid van de planning, daarmee vervalt immers de noodzaak tot het moeten maken van keuzes bij het samenvallen van werk. Het zal immers netjes opéénvolgend gepland zijn in die ideale situatie. Het voorbeeld van de samen-korter-aanpak leert tevens dat het onderling, bij elkaar in één ruimte zittend, overleggen om zo de onzekerheden weg te nemen goed functioneert. De tegelzetter kan direct met de stukadoor overleggen over hoe hij het werk achter gaat laten. De tegelzetter kan duidelijke afspraken maken over bijvoorbeeld de volgorde van het werk, of over het type stucwerk dat wordt toegepast. Kortom, men zit bij elkaar en kan zekerheden creëren, waardoor het inbouwen van buffertijden niet langer noodzakelijk is. De tegelzetter weet immers precies wat hem te wachten staat als hij op het werk arriveert. Hij kan in principe direct aan de slag. Het is echter de vraag of het praktisch haalbaar is om voor elk project vooraf met elkaar een (paar) plansessie(s) op deze wijze te doorlopen. Zeker als men

14



15

3 Conceptuele oplossing Zoals in de conclusies in het vorige hoofdstuk is aangegeven zijn er twee elementen waarop gefocust moet worden om de prestatie van het bouwproces te verbeteren in zijn huidige organisatievorm. Als eerste, de mate van onzekerheid ontstaan door informatie en als tweede de mate van onzekerheid ontstaan door planning. Het is duidelijk dat het goed onderling afstemmen om de onzekerheid te verminderen goed werkt. Zoals aangegeven is het praktisch lang niet altijd mogelijk om fysiek, zoals bij de samen-korter-aanpak, bij elkaar te zitten om onderling deze zaken af te stemmen. Het zou handig zijn als er van de moderne informatie- en communicatiemiddelen gebruik gemaakt kon worden om toch hetzelfde te doen. Overigens dient hierbij opgemerkt te worden dat bij het invoeren van ICT hulpmiddelen in de huidige processen deze hulpmiddelen het werk van de gebruikers aanzienlijk moeten verbeteren om echt door de markt geadopteerd te worden. Bij de ZZP’ers is die acceptatie van applicaties wat lastiger te bereiken dan bij de wat grotere ondernemingen. Behalve duidelijke verbeteringen zal ook de programma-ergonomie groot moeten zijn.

3.1 Aanpak onzekerheid door informatie Zoals gesteld zijn er twee factoren die aangepakt moeten worden om de prestaties van het bouwproces te verbeteren. Het met elkaar kortsluiten van voorwaarden en wensen rondom de praktisch invulling van de taken en het goed op elkaar laten aansluiten van de werkzaamheden. Omdat de samen-korteraanpak tot zeer goede resultaten heeft geleid was dat reden om nauwkeurig te achterhalen waar dat succes precies vandaan kwam. Zoals gesteld is het voor partijen bij het maken van afspraken over doorlooptijd en startmoment van de activiteiten van belang om zekerheden te hebben. Het is belangrijk om alle wensen, eisen, voorwaarden, en dergelijke, al aan het begin van het project met elkaar uit te wisselen. Op die wijze wordt het mogelijk de juiste voorwaarden te scheppen (meer zekerheid te creëren) over de situatie die de onderaannemer zal aantreffen wanneer het zijn beurt is op de bouwplaats. Ook het vaak voorkomende gebrek aan informatie wordt in deze aanpak al direct geadresseerd. Diegene die verantwoordelijk is voor het leveren van die informatie weet daardoor gelijk welke antwoorden hij zal moeten leveren om de prestaties van de betreffende bouwpartner te kunnen verbeteren. In feite gaat het erom dat de bouwpartners aangeven onder welke voorwaarden zij in staat zijn om de taken het snelst en efficiëntst uit te voeren. Wanneer kan worden gegarandeerd dat aan die voorwaarden wordt voldaan zal hij ook bereid zijn om een afspraak te maken waarbij de kortst mogelijke doorlooptijd in de planning wordt gehanteerd. Hoe kan dat gegarandeerd worden? Als het zo eenvoudig was gebeurde het nu toch ook wel, zou men zeggen. Het probleem zit ‘m in de organisatiestructuur. Informatie wordt op veel plaatsen gecreëerd, ontvangen en bewaard. Het is dus van groot belang dat het op de juiste wijze en op het juiste moment beschikbaar wordt gesteld aan de personen die het nodig hebben. Wat dat betreft gaat er in de praktijk veel mis. Ook wanneer informatie correct wordt doorgegeven is het daarmee nog niet gezegd dat die, correcte, informatie ook zal worden gebruikt op het moment dat het nodig is. Denk maar aan de fax die in de keet na ontvangst in de onderste la wordt bewaard en er bij wijze van spreken nooit meer uitkomt. Het gaat hierbij dus voor een groot deel om de systematiek van werken. Verder is er natuurlijk het ontbreken of verkeerd zijn van informatie. Bij het ontbreken van informatie is vaak het probleem dat vanuit de opdrachtgever simpelweg nog niet over het hoe en wat is gecommuniceerd. Bijvoorbeeld welke plinten moeten er gebruikt worden, of welke kleur tegelwerk gaat er toegepast worden. Door de marktstructuur is het niet eenvoudig die opdrachtgever zo ver te krijgen dat hij in het begin van het project die antwoorden al heeft. Op zich is dat ook niet zo erg, als het antwoord er maar wel is wanneer het nodig is. Met andere woorden, als het tegelwerk moet aanvangen moet het inmiddels wel duidelijk zijn. Beter nog, als er tegels besteld worden, moet het wel duidelijk zijn. Als het gaat om verkeerde informatie kan gedacht worden aan bijvoorbeeld de verkeerde (oude) versies van documenten. De betrokkenen gaan er vaak vanuit over de meest actuele en dus juiste informatie te beschikken. Los daarvan worden er natuurlijk ook ‘gewoon’ fouten gemaakt. Voor het overige is er dus een mechanisme nodig waardoor mensen er aan worden herinnerd dat de informatie toch op het

16


juiste moment beschikbaar is of gaat komen. In de praktijk hebben veel uitvoerders, projectleiders en werkvoorbereiders agenda’s, kalenders of notitieblokjes waarop dit soort zaken worden bijgehouden. Deze aanpak blijkt echter niet feilloos te werken. In het concept dat als oplossing voor dit probleem is ontwikkeld wordt de beschreven uitwisseling van informatie, eisen en wensen of kortweg ‘aandachtspunten’ met software ondersteund. In paragraaf 3.3 ‘Concept oplossing’ wordt dit verder uitgewerkt.

3.2 Aanpak onzekerheid door planning Behalve de problemen als gevolg van onzekerheid door informatie speelt dus ook de planning en de manier waarop deze tot stand komt een belangrijke rol bij het veroorzaken van problemen in de uitvoering van het bouwproces. Zoals al eerder aangegeven speelt de huidige organisatievorm van de bouw daarbij een grote rol. Elke zelfstandige commerciële partij die bij het proces betrokken is streeft het optimaliseren van zijn eigen planning na. Dat is ook logisch, uiteindelijk gaat het om het realiseren van een zo goed mogelijk financieel resultaat voor de aandeelhouder. De projectleider of uitvoerder die voor de hoofdaannemer van een project met de planning werkt, probeert deze planning te optimaliseren. Dat is erg lastig als er geen inzicht is in de planningen en de optimalisatiedoelstellingen van alle betrokkenen. Daarnaast treedt het effect op waarbij iedereen als reactie op de onzekerheden gebruik maakt van buffertijden. Dan is er ook nog het feit dat afspraken over het startmoment van activiteiten enigszins strategisch tot stand komen. Het gevolg zal zijn dat de planning op voorhand al onbetrouwbaar is. Omdat er tijdens de uitvoering nog veel geschoven en opnieuw gepland zal worden lijkt dat in de praktijk niet veel uit te maken. Toch is het zeer de moeite waard om steeds te werken met een echt betrouwbare planning. Dus een planning die in werkelijkheid ook te realiseren is. Voor alle duidelijkheid, het gaat hierbij niet zozeer om de technische invulling van de planning, dus wat moet voor wat gebeuren, maar om de capaciteitsplanning met en van alle betrokkenen. Bij het plannen van tijd gaat het om het startmoment en om de doorlooptijd. Het (strategisch) gedrag rondom de doorlooptijd is uitvoerig beschreven. Het startmoment en vooral het betrouwbaar bepalen van een startmoment is minstens zo belangrijk. In de praktijk wordt er menigmaal makkelijk ‘ja’ gezegd zonder dat de onderaannemer zeker weet dat hij op dat moment ook echt beschikbaar is. Toch weet hij dat het wel ongeveer goed zal komen, alles loopt toch altijd anders dan gepland. En, pas in de detailplanning (6/8 weken vooruit) wordt de echt harde afspraak gemaakt. Toch is het vanaf het eerste moment ook bij het maken van die afspraak van belang om alleen betrouwbare afspraken te maken.

3.3 Concept oplossing Door gebruik te maken van nieuwe technieken zijn er meer mogelijkheden om op een voor iedereen acceptabele wijze te komen tot afstemmingen. Afstemmingen op het gebied van planning, maar ook op het gebied van informatie-uitwisseling. Het beoogde effect is dat alle partijen bij het maken van afspraken geen buffertijden inplannen en betrouwbaar plannen als het gaat om het startmoment van activiteiten. Om de onderaannemer zover te krijgen dat hij bereid is om daadwerkelijk zonder buffertijden afspraken te maken zal hij zijn voorwaarden bij de hoofdaannemer willen neerleggen. Als met al de gestelde zaken rekening gehouden wordt, is hij immers echt in staat om het strakke tijdschema te halen. Op basis van de uitgebreide analyse van de werkwijze en problemen in de aansturing van bouwprojecten is het doel van het te ontwikkelen systeem als volgt geformuleerd. Het te ontwikkelen systeem moet de betrouwbaarheid bij het maken van afspraken over het startmoment van activiteiten vergroten en het systeem moet ingeplande buffertijden bij de inschatting van doorlooptijden voorkomen om zo de


17

doorlooptijd van het gehele project te minimaliseren. Daarnaast moet gezorgd worden dat op het juiste moment de juiste informatie wordt verkregen om zo, op tijd, noodzakelijke acties te kunnen ondernemen, met als achterliggend doel het voorkomen van verstoringen in de uitvoering (faalkosten).

Eisen De betrokken marktpartijen zullen natuurlijk een aantal eisen stellen aan het te ontwikkelen systeem. 4 Natuurlijk zal het gebruiksvriendelijk moeten zijn en het moet niet nodig zijn om dit systeem parallel naast andere systemen te moeten gebruiken ter voorkoming van dubbel werk. 4 Maar belangrijker zijn zaken als regie en transparantie. De doelen die met het systeem bereikt moeten worden hebben alles te maken met het wel of niet in handen hebben van de regie. En, ondanks dat de hoofdaannemer het waarschijnlijk prettig zou vinden om veel controle te hebben op de keuzes die onderaannemers maken ten opzichte van de klanten waar ze voor werken, zullen onderaannemers niet bereid zijn om die regie over hun activiteiten uit handen te geven. 4 Een ander aspect dat hierbij een rol speelt is inzicht in de status van zaken, bijvoorbeeld de planning van de onderaannemer. Dat inzicht, of anders genoemd, die transparantie is echter juist weer een struikelblok. Met transparantie zouden partijen goed kunnen inspelen op de situaties die ontstaan. Ze hebben immers inzicht in wat iedereen doet en nog gaat doen. Onderaannemers zijn echter zelfstandig opererende ondernemingen die dergelijke informatie als commercieel gevoelig en dus vertrouwelijk aanmerken. Ze zullen dus niet bereid zijn om aan die transparantie mee te werken. Dat maakt het meteen lastig. De hoofdaannemer is baas over zijn project en huurt een onderaannemer in. Die onderaannemer moet dan precies doen wat hij zegt, althans dat is het gevoel dat men dan heeft. En juist dat is moeilijk te realiseren in een marktsituatie zoals die van de bouwwereld. 4 Een laatste eis die bij het realiseren van het systeem van belang is, is de toegankelijkheid. Om er voor te zorgen dat iedereen er mee kan werken ligt het voor de hand om het geheel internetgebaseerd te maken. Tegenwoordig hebben ook steeds meer ZZP’ers ook een computer met een internetverbinding. Het moet niet zo zijn dat mensen eerst zelf software moeten installeren om er gebruik van te kunnen maken. Juist omdat er steeds in wisselende samenstellingen wordt gewerkt zou dit het algemeen gebruik in de weg kunnen staan.

3.4 Werkwijze van de oplossing Om de werkwijze van de oplossing goed weer te geven roepen we eerst weer even de werkwijze bij de samen-korter-aanpak op in de herinnering. Daar bleek het mogelijk te zijn om, door goede onderlinge afstemming tussen alle betrokkenen, de doorlooptijden van activiteiten in te korten. Dus, door onderaannemers duidelijk aan te laten geven welke zaken zeker geregeld moesten zijn om er voor te zorgen dat ze bereid waren om de doorlooptijden zo kort mogelijk te laten zijn. Het te ontwikkelen systeem moet in feite datzelfde effect zien te bereiken. Tevens zal het systeem in staat moeten zijn om, rekening houdend met de eis omtrent het niet uit handen geven van regie, te komen tot (steeds opnieuw) afgestemde planningen zodat de planning betrouwbaar en haalbaar blijft. Het systeem is op te delen in twee delen. Als eerste het deel waarin met de aandachtspunten wordt gewerkt, als tweede het planningsdeel.

Aandachtspunten De onderaannemer heeft aangegeven wat voor hem van belang is. Dat kan bijvoorbeeld zijn dat er een bouwlift aanwezig moet zijn, of hij moet van te voren weten hoe bepaalde werkzaamheden moeten worden uitgevoerd. Dat wil hij niet pas horen als hij al klaar staat om te werken. Hij wil niet in de situatie terecht komen waarin eerst weer met de opdrachtgever gecommuniceerd moet worden en er zo vertragingen ontstaan. Hij wil direct aan het werk kunnen. Hij krijgt dan ook met het systeem de mogelijkheid om al die van belangzijnde zaken aan de uitvoerder/projectleider door te geven. Voor alle duidelijkheid, het kan hier om van alles gaan, zaken die met de voorgaande werkzaamheden te maken hebben maar

18


bijvoorbeeld ook een zekere informatiebehoefte. Als daar netjes aan voldaan kan worden is het mogelijk om de doorlooptijd in te korten. In het vooronderzoek is echter al gebleken dat het lang niet altijd mogelijk is om bijvoorbeeld specifieke informatie al in het begin van het traject beschikbaar te krijgen. Dat hoeft geen probleem te vormen, zolang de uitvoerder/projectleider er maar op tijd weer achteraan gaat. In de praktijk zal er een aantekening worden gemaakt in de agenda of op de kalender. In het aandachtspunten deel van het systeem wordt dit echter digitaal. Het wordt mogelijk voor de onderaannemers om hun aandachtspunten digitaal door te geven aan de uitvoerder/projectleider en deze kan ze op zijn beurt heel eenvoudig in het systeem opslaan. Nadat duidelijk is wanneer het aandachtspunt opgepakt moet/ kan worden, zal het systeem er voor zorgen dat hij er op tijd aan wordt herinnerd. Hij krijgt hiermee in feite een digitale actielijst die deels gevoed wordt door de onderaannemers. Omdat hij natuurlijk ook nog taken heeft die hij zelf bedenkt en initieert kan hij die taken ook in hetzelfde systeem onderbrengen. De uitvoerder zal dus op de bouw, in de keet op zijn computerscherm steeds die aandachtspunten in beeld zien die van belang zijn. En dus ook die aandachtspunten waarvan de onderaannemers hebben gezegd dat ze voor hen van belang zijn om de het werk zo efficiënt mogelijk te kunnen doen. Zo heeft de uitvoerder in de keet altijd een actuele lijst van taken die van belang zijn. Behalve dat de aandachtspunten via email worden doorgegeven, kunnen ook bijlagen met de aandachtspunten worden meegezonden. Bijvoorbeeld een digitale tekening, een tekstbestand of welk ander digitaal bestand dan ook. Het systeem zal twee type gebruikers kennen, als eerste de gebruiker aan de kant van de hoofdaannemer, als tweede de gebruiker aan de kant van de onderaannemer(s). Het hiervoor beschreven deel van het systeem zal er voor de onderaannemers anders uitzien dan voor de hoofdaannemer. De hoofdaannemer krijgt alle aandachtspunten op een rij en ziet daarmee alle aandachtspunten van iedereen. Voor de onderaannemers is het echter alleen van belang dat hij al zijn aandachtspunten aan de hoofdaannemer kan doorgeven. Daarna hoeft hij alleen nog maar een duidelijk overzicht te hebben van de aandachtspunten zoals hij ze heeft doorgestuurd. Met de aandachtspunten van andere onderaannemers heeft hij feitelijk niets te maken en om die reden zijn die dan ook niet zichtbaar voor hem (daarmee wordt transparantie op dit vlak voorkomen).

Planning Bij het planningsdeel van het te ontwikkelen systeem ligt echter de grootste uitdaging. De eisen die aan het systeem gesteld worden hebben met name betrekking op de wijze waarop de planning tot stand komt. Net als het aandachtspuntendeel is ook voor het planningsdeel van het systeem een verschil gemaakt tussen het gebruikersdeel van de hoofdaannemer en dat van de onderaannemer(s). Als eerste volgt hier een beschrijving van het deel voor de hoofdaannemer en gaandeweg komt de onderaannemer aan de orde. De hoofdaannemer is degene die de volledige planning voor het bouwproject moet maken, actueel moet houden, detailplanningen moet maken (elke week voor 6 of 8 weken vooruit) en moet zorgen dat de uitvoering volgens die planning plaatsvindt. Met het systeem moet het dan ook mogelijk zijn de gehele planning vanaf het eerste begin met het systeem te maken en te onderhouden. Het is dus mogelijk om activiteiten aan te maken. Dat kan in tekst, maar ook door met de muis activiteiten in het balkenschema te tekenen. Er kunnen meervoudige afhankelijkheden in de planning worden aangebracht en ook dit kan door met de muis al klikkend aan te geven hoe de afhankelijkheden lopen. Kortom, net als in de veelal in gebruik zijnde planningsoftware. Kortom, het maken van een planning (en een detailplanning) gaat net als men gewend is. Echter, het doel was om behalve het voorkomen van buffertijden, ook betrouwbaarder afspraken te maken. Om dit te bereiken zal de hoofdaannemer eerst de activiteit aanmaken in het systeem en waarbij hij een voorlopige doorlooptijd invult. Nadat deze activiteit is aangemaakt en er is een onderaannemer aan gekoppeld (zodra deze al bekend is), dan ontvangt de onderaannemer automatisch een bericht waarin hem de benodigde gegevens worden geboden om op het systeem in te loggen. Daar ziet de onderaannemer vervolgens welke details van de activiteit de hoofdaannemer al heeft aangegeven. In plaats van het opnieuw aangeven van de doorlooptijd geeft de onderaannemer hier aan wat de benodigde werktijd (mandagen) is. Dus de netto werktijd als aan alle voorwaarden is


19

voldaan. Hij heeft daarbij tevens inzage in het personeelsplanningdeel waarin zijn personeelsplanning is weergegeven. Deze personeelsplanning kan hij voor al zijn projecten gebruiken, echter het gaat erom dat hij met deze personeelsplanning aangeeft hoeveel capaciteit hij voor de betreffende activiteit beschikbaar stelt (nodig heeft). Dus hij geeft aan hoelang de netto werktijd is en hij geeft aan hoeveel capaciteit beschikbaar wordt gesteld. Nu kan het systeem vervolgens een nieuwe doorlooptijd bepalen. Dan hoeft er alleen nog een startmoment te worden bepaald. Nadat alle projectpartijen hun details hebben aangegeven in het systeem zijn in feite de nieuwe, werkelijke doorlooptijden bekend. Op basis daarvan en op basis van de relaties tussen de activiteiten is het nu mogelijk om de starttijden door het systeem te laten bepalen. Via het systeem zal, op basis van de personeelsplanning van de onderaannemer de meest passende (optimale) starttijd worden vastgelegd. Tevens zal in de personeelsplanning de benodigde capaciteit vanaf het startmoment worden geblokt. Op die manier wordt een afspraak gemaakt die ook daadwerkelijk haalbaar is en dus betrouwbaar is. De onderaannemer krijgt het resultaat van deze afstemming te zien. Doordat gaandeweg steeds meer onderaannemers worden toegevoegd, die allemaal de ruimte aan het systeem geven om flexibel met de bezetting om te gaan, zal er steeds een nieuwe afstemming plaatsvinden. Het resultaat kan (waarschijnlijk zal) steeds anders zijn. Als daarnaast ook regelmatig de daadwerkelijke stand van het betreffende project in het systeem wordt geregistreerd, zal de waarschijnlijkheid dat de resultaten van de afstemming juist zijn (de betrouwbaarheid dus) steeds verder toenemen. Ter voorkoming van ‘vijf voor twaalf-mutaties’ kunnen partijen de resultaten van de systeemberekening, met name de startdatum, fixeren bijvoorbeeld door er een vinkje bij te plaatsen. Het systeem zal in principe willekeurige medewerkers toedelen aan de projecten. Daarom kan de onderaannemer eventueel nog wisselen in de personeelsbezetting, bijvoorbeeld andere mensen inzetten Hij kan het goedkeuren door een vinkje te plaatsen en zo de hoofdaannemer via het systeem informeren. Eventueel kan hij nog wisselen in de personeelsplanning, bijvoorbeeld andere mensen in zetten. Echter, hij zal wel de toegezegde capaciteit beschikbaar moeten houden. Hetzelfde geldt voor het startmoment, alleen wanneer hij duidelijke redenen heeft om die te wijzigen is er aanleiding opnieuw te plannen, anders is daarmee de planning van de kant van de onderaannemer definitief. Wanneer alle onderaannemers hun planning hebben geaccordeerd (het vinkje hebben gezet), is de definitieve planning bekend. De hoofdaannemer zal dan alle startmomenten van alle activiteiten definitief maken en daarmee staan er harde afspraken. Omdat er, ondanks een betrouwbaar plan, toch nog zaken zullen veranderen door bijvoorbeeld onvoorziene omstandigheden wordt dezelfde systematiek steeds opnieuw toegepast wanneer er nieuwe afspraken gemaakt moeten worden. Omdat planningstechnisch het toewijzen van bouwmedewerkers van onderaannemers en van eigen personeel van de hoofdaannemer geen verschil maakt, kan het systeem ook gebruikt worden voor de personeelsplanning van de hoofdaannemer. Bij het lezen van de voorgaande tekst krijgt u als lezer misschien het gevoel dat nog steeds controle uit handen wordt gegeven. Toch is dat niet zo. Elke speler in het ‘spel’ heeft een stukje van het planningssysteem in handen. Een stukje software dat alleen de belangen dient van zijn eigenaar. Overigens gaat het hierbij om ‘agent technology’ waarbij het zonet genoemde stukje software gezien kan worden als een soort agent. Dit is een soort digitaal assistentje dat alleen voor en in opdracht van de eigenaar werkt. Elke speler in het spel krijgt een eigen digitale agent, dat hij via internet, zoals beschreven kan bedienen. In het geval van de hoofdaannemer zal de agent steeds streven naar een afgestemde planning met een minimale doorlooptijd. Aan de kant van de onderaannemer zal de agent alleen afspraken maken die aan de eisen van de onderaannemer voldoen. De onderaannemer geeft zelf aan hoeveel personeelscapaciteit hij beschikbaar stelt voor het uitvoeren van de werkzaamheden. Hij geeft ook zelf aan wat de werkelijke netto werktijd zal zijn voor de activiteit. Hij bepaalt zelf hoe zijn personeelsplanning eruit ziet. Niemand anders heeft daar invloed op. Alleen, op het moment dat er afspraken gemaakt moeten worden, wordt binnen de grenzen van wat mogelijk is, door zijn stukje van het systeem, zijn agent, een passende afspraak gemaakt. Zijn digitale agent (en alleen zijn agent, niet dus die van anderen) kan in zijn personeelsplanning kijken. Daarin wordt precies de hoeveelheid capaciteit ingepland waarvan hij zelf heeft gezegd dat het beschikbaar is voor het project. Dat gebeurt

20


bovendien op een startmoment dat in de projectplanning past (bij de hoofdaannemer) en dat in de personeelsplanning ook daadwerkelijk past. Dus alleen mensen die nog niet ingepland waren kunnen door het systeem worden ingepland. Uiteindelijk, nadat de afspraken gemaakt zijn is het voor de onderaannemer nog steeds mogelijk om wijzigingen in het personeelsplan aan te brengen. Hij blijft immers de baas. Maar, hij moet wel de toegezegde capaciteit beschikbaar houden. Doet hij dat niet, dan wordt door het systeem aangegeven aan de hoofdaannemer dat nieuwe afspraken noodzakelijk zijn. Voor alle duidelijkheid, niemand heeft inzage in de personeelsplanning (agenda) van de onderaannemer, alleen hijzelf. De hoofdaannemer heeft nog steeds geen idee wat er verder allemaal gebeurt bij deze onderaannemer. Hij weet alleen dat hij op een zeker moment op de bouw zal staan met een aantal mensen zoals afgesproken. Dat is ook het enige waar het de hoofdaannemer om gaat. Verder heeft hij ook niets met de onderaannemer te maken. Op deze manier blijft de regie over eigen werkzaamheden steeds in handen van de partijen zelf. Bovendien is er geen transparantie, men ziet van elkaar niets, alleen dat wat van belang is om met elkaar te delen. Door met deze nieuwe techniek (agent techniek) planningen op een gedistribueerde wijze tot stand te laten komen worden planningen (meer) betrouwbaar. Door tevens in ruil voor het voldoen aan de aandachtspunten niet te plannen op basis van in onderling overleg te bepalen doorlooptijden (als inschatting/onderhandeling), maar uit te gaan van benodigde mandagen en bezetting kan een aanzienlijke verkorting van de totale doorlooptijd op het project worden bereikt. Behalve dat deze aanpak tot veel gemak zal leiden bij het opzetten van de planning is het vooral ook een sterk middel bij het omgaan met verstoringen. Door onwerkbaar weer of een andere vertragende factor, bijvoorbeeld verlate levering door een leverancier, kan de planning nog steeds onder druk komen te staan. Door dan op dezelfde wijze, met het systeem met elkaar betrouwbare nieuwe afspraken te maken, is steeds weer op nieuw de planning als geheel betrouwbaar. Net als in de praktijk maakt dit systeem bij het weergeven van de planning gebruik van drie tijdschalen, te weten de kalenderschaal, de prognoseschaal en de werkbare dagenschaal. Op gezette tijden zal de uitvoerder/projectleider de stand opnemen om een standlijn in de planning te tekenen. Ook die faciliteit is opgenomen in het systeem. Door het ‘rechttrekken van de standlijn’ zullen na doorrekenen van het systeem nieuwe startdata, doorlooptijden en bezettingen gevonden worden, echter zijn deze resultaten betrouwbaarder dan de eerdere. Het feit dat niemand alles kan zien en dat de regie over de werkzaamheden nog steeds gespreid blijft, en dat éénieders belang gediend wordt, maakt het tot een sterke oplossing. Een afgeleid voordeel is het feit dat veel onderaannemers hun personeelsplanning, die meestal in een agenda of excelsheet wordt bijgehouden, nu netjes in het systeem, en overal voor hen alleen bereikbaar (internet) kunnen houden. Daarnaast heeft de uitvoerder nu een steeds actuele en complete actielijst waarop hij heel eenvoudig ook allerlei andere aantekeningen kan bijhouden. Daarnaast is in dezelfde applicatie ook de planning als balkenschema zichtbaar waarop bovendien kan worden in- en uitgezoomd. De planning kan geprint worden en hij kan indien gewenst als email aan partijen worden verzonden. In het systeem is het overigens mogelijk om een in principe onbeperkt aantal projecten tegelijk te laten draaien. Als laatste voordeel van deze gedistribueerde aanpak kan genoemd worden het feit dat het met de te gebruiken techniek heel eenvoudig is om te koppelen met andere, bij (grotere) bedrijven reeds bestaande plansystemen. Er zal dan wel een interface gemaakt moeten worden, maar door de opzet is dat relatief eenvoudig. Dit voorkomt dat bedrijven een grote overstap (in werkwijze) moeten maken om met het systeem te kunnen werken.


21

4 Prototype

5 Conclusies & Aanbevelingen

In het voorgaande hoofdstuk is beschreven wat de concept oplossing kan zijn. Echter, voordat een dergelijke oplossing vertaald is in een systeem dat daadwerkelijk als applicatie in de praktijk kan worden ingezet, is het van belang zeker te weten dat de beschreven werkwijze in de praktijk ook echt kan functioneren. Omdat het bouwen van een complete (foutloos werkende) applicatie een tijdrovende en dus een vrij prijzige aangelegenheid is, is er besloten eerst een prototype te bouwen. Een prototype aan de hand waarvan de potentiële gebruikers kunnen bepalen of de voorgestelde technische oplossing een bruikbare oplossing biedt. Wanneer dat het geval is, kan overgegaan worden tot het bouwen van een daadwerkelijke applicatie die vervolgens in een praktijksituatie uitvoerig getest moet worden. Pas wanneer dat is gedaan en alle bevindingen en eventuele aanpassingen in de applicatie zijn verwerkt is het mogelijk om de applicatie breed in de markt in te zetten.

Gesteld kan worden dat de hoge faalkosten met name voortkomen uit de wijze waarop het bouwproces wordt aangestuurd. Dit komt tot uiting in de veelheid aan onzekerheid die bij de aansturing van het proces een rol speelt. Bij die onderzekerheid kan onderscheid gemaakt worden in onzekerheid ontstaan door informatie (verkeerd, te laat, ontbrekend) en onzekerheid ontstaan door planning (onbetrouwbaarheid van de gemaakte afspraken). De historische organisatievormen die in de bouw gangbaar zijn hebben de wijze van aansturing ontwikkeld tot wat deze nu is. Binnen dit project is bekeken of de huidige organisatie van de bouwwereld door gebruikmaking van slimme technische oplossingen geholpen kan worden om tot betere prestatie te komen. De grootste kansen blijken te liggen in het toepassen van oplossingen die leiden tot het verlagen van de mate van onzekerheid ontstaan door informatie en het verlagen van de mate van onzekerheid ontstaan door planning. Om die reden is gekozen voor het ontwikkelen van een prototype systeem waarmee de informatie-uitwisseling en het afstemmen van planningen op een voor de sector acceptabele wijze mogelijk wordt gemaakt.

4.1 Testen van het prototype Bij aanvang van dit project is in eerste instantie uitgegaan van het bouwen van een simulatiemodel om het prototype te kunnen testen. Om dat zinvol te kunnen doen is er goed vergelijkingsmateriaal nodig aan de hand waarvan uitspraken gedaan kunnen worden over het presteren van planningen gemaakt op de traditionele manier en met het nieuwe systeem. Het gaat daarbij om cijfermatige informatie over prestaties in het bouwproces. Gaandeweg het project werd steeds duidelijker dat die cijfers niet beschikbaar zijn. Het doel van het testen met een simulatiemodel moet zijn het verschaffen van bewijs van het nut en de noodzaak van het systeem. Als niet kan worden beschikt over de gegevens die nodig zijn om de prestatie van het systeem te kunnen meten, heeft het dus geen zin om te gaan simuleren. Het zal in elk geval niet het gewenste inzicht opleveren. Om toch inzicht te krijgen in de mogelijke toegevoegde waarde van het systeem is in overleg met de klankbordgroep besloten om het prototype aan de hand van een praktijk voorbeeld, in de klankbordgroep te testen. Een praktijkvoorbeeld waarbij de werking van het systeem voor de klankbordgroepleden duidelijk werd. Het concept zoals beschreven in het voorgaande hoofdstuk is dan ook uitgewerkt in een prototype. Met dit prototype is het niet mogelijk om de praktijk planningen te maken en te onderhouden. Het geeft weer hoe de applicatie er uit komt te zien en vooral hoe deze zal werken. Aan de hand van een scenario is aan de klankbordgroep getoond hoe het zal functioneren. Doel daarbij was het verkrijgen van feedback over de haalbaarheid en de bruikbaarheid van een dergelijk systeem. En daarnaast natuurlijk het in overleg bepalen van de juiste vervolgstappen. Ter illustratie van het prototype is een DVD bij dit rapport gevoegd met daarop een demonstratiefilm van het prototype. Om uiteindelijk tot het daadwerkelijk in de praktijk testen van het concept te kunnen komen zal in een vervolgtraject het prototype worden uitgewerkt tot een applicatie waarmee wel in de praktijk planningen gemaakt en onderhouden kunnen worden.

De projectgroep is van mening dat het beschreven concept met het bijbehorende prototype een zeer goede kans van slagen heeft als het gaat om het vergroten van de efficiency in het bouwproces met als gevolg het verlagen van de faalkosten. In de laatste klankbordgroepbijeenkomst, waar het prototype is getoond en toegelicht kwamen een aantal opbouwende, kritische noten naar voren, maar bovenal overheerste enthousiasme over de toekomstmogelijkheden van een dergelijke applicatie. Op eigen initiatief is door twee marktpartijen aangeboden om aan het testen van de nog te ontwikkelen applicatie mee te werken. De projectgroep beveelt dan ook van harte aan om een dergelijke praktijktest uit te voeren. De toezeggingen van de marktpartijen zijn daarbij een belangrijk gegeven. Echter, zoals beschreven, zal het prototype, dat reeds een goede basis voor een applicatie vormt, nog wel moeten worden uitontwikkeld tot een volwassen applicatie. Een applicatie die daadwerkelijk in de praktijk getest kan worden. Hierbij kan niet volstaan worden met een ‘houtje-touwtje-oplossing’. Om daadwerkelijk te kunnen testen zullen alle bouwpartners in een project met het systeem moeten gaan werken. De uitvoering zal daarbij voor de planning volledig afhankelijk moeten zijn van dit systeem. Daarbij is dan ook geen ruimte voor fouten beschikbaar. Het is van belang dat, wanneer er daadwerkelijk in de praktijk getest gaat worden, er op tijd door met name Bouwend Nederland wordt begonnen met het communiceren over en promoten van het systeem. Het systeem kan voor de sector veel vooruitgang beteken, echter, dan zal het wel door veel partijen gebruikt moeten worden. Zover komen is geen sinecure, zoals ook in de haven van Rotterdam is gebleken.

5.1 Implementatie Wanneer uit de praktijktest blijkt dat het systeem voldoende goed functioneert, en dat het de voordelen biedt waarvoor het bedoeld is, zal implementatie van het systeem marktbreed moeten worden opgepakt. Omdat de problematiek veel gelijkenis vertoont met de (haven)logistieke sector zijn er lessen te leren van ervaringen in die sector bij de implementatie van de oplossing. Net als in de bouwsector bestaat de havenlogistieke sector uit veel verschillende partijen die in steeds wisselende samenstellingen met elkaar te maken hebben. In de haven van Rotterdam is een systeem ontwikkeld dat anders werkt, maar conceptueel veel wegheeft van het prototype zoals dat nu voor de bouw is ontwikkeld. Bij de implementatie in de haven is gebleken dat het van groot belang is dat een overkoepelende partij zorgt voor een neutrale derde partij voor invoering van het systeem. Het systeem zal, bij gebleken geschiktheid, breed in de sector worden toegepast. Het ligt dan voor de hand dat bijvoorbeeld Bouwend Nederland zorgt voor het aanbieden en het promoten van het product (systeem) en dat er voor de sector aantrekkelijke afspraken over kosten en dergelijke worden gemaakt. Vanzelfsprekend zullen de partijen

22



23

die in de bouw van de applicatie hebben geïnvesteerd hierover gezamenlijk beslissen. Een aanpak waarbij het systeem in een vroeg stadium volledig wordt overgedragen aan een commerciële (software) leverancier leidt zeer waarschijnlijk niet tot het gewenste resultaat. Een ander belangrijk punt waar bij implementatie rekening mee gehouden moet worden is dat bij het invoeren van ICT hulpmiddelen in de huidige processen deze hulpmiddelen het werk van de gebruikers aanzienlijk moeten verbeteren om echt door de markt geadopteerd te worden. Bij de ZZP’ers is die acceptatie van applicaties nog wat lastiger te bereiken dan bij de wat grotere ondernemingen. Behalve duidelijke verbeteringen zal ook de programma-ergonomie groot moeten zijn.

RRB

O U W R A P P O RT 1 2 9

Ge d afs in

eerde u b ri t s i ing m tem e bouw d

24



25

26


Gedistribueerde afstemming in de bouw

Recommend Documents