1 Projectorganisatie en

Transcriptie

1 1 Projectorganisatie en samenwerking R.P. Geraedts 1.1 Inleiding In de Nederlandse bouwwereld zijn de ProjectMatig Werken beheersaspecten Geld, Organisatie, Tijd, Informatie en Kwaliteit (GOTIK), waaraan dan soms het aspect risico wordt toegevoegd, vrij algemeen bekend. Onder beheersaspect wordt de invalshoek verstaan waaronder men naar het project (-resultaat of weg) kan kijken (Wijnen, 1995). De beheersaspecten Kwaliteit, Geld, Tijd en Informatie maken in dit boek onderdeel uit van het inhoudelijke perspectief waarmee in hoofdstuk 2 Bouwmanagement naar de praktijk wordt gekeken. Omdat het aspect organisatie en het daar sterk aan verwant zijnde begrip samenwerking vanuit het vak bouwmanagement zo belangrijk en veelomvattend is, worden deze beheersaspecten in dit hoofdstuk aan de orde gesteld. Een architect of een aannemer werkt zelden alleen aan een project, maar heeft bijna altijd te maken met een groot aantal andere projectpartners, zoals de opdrachtgever, al of niet een projectmanagementbureau, de constructeur, de installatieadviseur, onderaannemers, installateurs en leveranciers. De rollen en verantwoordelijkheden van deze bouwpartners kunnen per project totaal verschillen. Dit vindt zijn neerslag in de verschillende bouworganisatie- en contractmodellen die in ons land worden gehanteerd. Belangrijk werk op dit vlak is verricht door De Koning en Sproncken (2001). De door hen aangegeven hoofdstructuur met betrekking tot de verschillende soorten bouworganisatieen contractmodellen is daarom in dit hoofdstuk aangehouden. Het verschil tussen de modellen komt tot uiting in de diverse karakteristieke taken van de bouwpartners en de verschillende contractuele verhoudingen tussen die bouwpartners. Afhankelijk van de contractvorm kan de rol en verantwoordelijkheid van bijvoorbeeld een architectenbureau per project sterk verschillen. In het ene project kan de architect een 'all engineeringsopdracht' hebben (dat wil zeggen dat hij verantwoordelijk is voor het gehele ontwerp- en engineeringsproces en dat hij binnen zijn eigen contract de overige adviseurs

2 selecteert en contracteert), terwijl hij in het andere project slechts ingehuurd is voor het esthetisch advies. Dit is uiteraard van grote invloed op de managementinspanning die het architectenbureau in een project moet leveren Bouwen is organiseren Zoals in de inleiding is aangegeven, zijn bij een bouwproject doorgaans veel verschillende partijen betrokken in diverse stadia van het ontwikkelings- en uitvoeringsproces. Elk met verschillende taken en verantwoordelijkheden. Het mag duidelijk zijn dat een goede organisatie van dit proces van cruciaal belang is voor de kwaliteit van het uiteindelijke resultaat. Bouwen is organiseren, op een zodanige wijze dat de verschillende partijen op een efficiënte wijze met elkaar samenwerken. Om dit in goede banen te leiden is het eveneens van belang dat de onderlinge relaties tussen de betrokken partijen helder zijn. Wie is verantwoordelijk voor welke activiteiten, welke risico's kunnen er optreden en hoe kan dit vastgelegd worden in contracten? Vanuit dit oogpunt is bouwen niet alleen organiseren, maar ook contracteren. Het organiseren van een bouwproject is gebaseerd op het vaststellen van de functies die in het ontwikkelingsproces een rol van betekenis spelen. Dit zijn bijvoorbeeld de financiering van het project, het ontwikkelen, het ontwerpen, het adviseren, het realiseren, het onderhouden en het exploiteren van het project. Daarbinnen moet vastgesteld worden wie daarbij met welke verantwoordelijkheid welke taken gaat uitvoeren. Het vastleggen van deze taken en hun onderlinge afstemming vindt zijn neerslag in het contractmodel. Na de keuze van het organisatiemodel en het vastleggen van het bijbehorende contractmodel kan het bouwproject of de gevraagde dienst door de opdrachtgever worden aanbesteed. Bij een aanbesteding maakt de opdrachtgever bekend dat hij een opdracht of dienst wil laten uitvoeren en vraagt hij bedrijven hierop in te schrijven. De aanbestedingsfase wordt uiteindelijk afgesloten met het ondertekenen van de contracten door de betrokken partijen Veranderende rolpatronen Door de toenemende complexiteit van bouwprocessen en gebouwen in cultureel-maatschappelijke, functionele, technische, economische en juridische zin, ontstaan er verschuivingen in marktverhoudingen en organisatievormen. De rollen of functies van bijvoorbeeld de opdrachtgever, de architect, de aannemer, de adviseur en de toeleverancier wijzigen en daarmee verandert ook de wijze waarop men zich binnen projectverband organiseert en contractueel met elkaar samenwerkt.

3 3 Hiermee verschuiven de traditionele grenzen tussen de verschillende bouwpartners. Daar waar een aannemer vroeger alleen verantwoordelijk was voor de uitvoering van een project en een architect voor het ontwerp, kan de aannemer nu ook verantwoordelijk zijn voor het ontwerp van een plan. De aannemer wordt architect. De aannemer kan ook zelf het initiatief nemen om een project onder eigen verantwoordelijkheid te ontwikkelen. Men spreekt hier over een voorwaartse integratie in het bouwproces. Er zijn ook voorbeelden van architectenbureaus die niet tevreden zijn over de wijze waarop hun ontwerpen door aannemers gerealiseerd worden. Ze pakken de voorbereiding en de organisatie van de uitvoering daarom maar zelf ter hand. Hier is dus sprake van achterwaartse integratie in het bouwproces. De architect wordt aannemer. In figuur 5.1 is dit nader uitgewerkt. Gekoppeld aan deze veranderende rolpatronen kan een relatie gelegd worden met de verschillende soorten projectorganisatievormen die er mogelijk zijn. Voorwaartse integratie Achterwaartse integratie Financiering Ontwikkeling Ontwerp Uitvoering Onderhoud Exploitatie Design Sloop / hergebruik Figuur 5.1 Veranderende rolpatronen, voor- en achterwaartse integratie in het bouwproces Design & Build Design, Build & Operate Design, Build, Finance, Maintain & Operate In figuur 5.1 zijn horizontaal verschillende procesfuncties genoemd, vanaf financiering en ontwikkeling tot en met hergebruik of sloop van een project. Aan de hand hiervan kan de traditionele projectorganisatie gelokaliseerd worden, waarbij de architect ontwerpt (Design) en de aannemer het project realiseert (Build) na de aanbesteding van het project. Ook kunnen aan de hand hiervan andere en nieuwere projectorganisatievormen gelokaliseerd worden. Bijvoorbeeld Design & Build, waarbij ontwerp en uitvoering in zijn geheel bij de aanbiedende partij liggen. De opdrachtgever besteedt hiermee een deel van zijn traditionele verantwoordelijkheden en daaraan verbonden risico s uit aan de aanbiedende partijen. Bij nog meer geïntegreerde organisatievormen wordt de opdrachtgever ook de exploitatie van een project uit handen genomen. De aanbiedende partijen leveren dan niet alleen het ontwerp (Design) en de uitvoering (Build), maar ook de exploitatie (Operate) van een project, al dan niet inclusief de financiering hiervan (Finance) of het onderhoud (Maintain).

4 Zoals te lezen valt, worden in Nederland in toenemende mate Anglo-Amerikaanse proces- en contractbenamingen toegepast, soms correct, vaak ook incorrect. Meestal worden ze door iedereen anders geïnterpreteerd en vaak voorzien van geheel willekeurige vertalingen. Dit hoofdstuk gaat nader in op de verschillende soorten organisatiemodellen. Deze zijn te onderscheiden op basis van de criteria of contractmodellen er zijn, welke voor- en nadelen deze met zich meebrengen en wat dit betekent voor de verschillende actoren in het bouwproces. 1.2 Bouworganisatiemodellen Een organisatiemodel van een bouwproject is gebaseerd op het vaststellen van de functies die in het ontwikkelingsproces een rol van betekenis spelen. Bijvoorbeeld de financiering van het project, het ontwikkelen, het ontwerpen, het adviseren, het bouwen, het onderhouden en het exploiteren van het project. De keuze voor een bepaald model hangt ook af van de invloed die een opdrachtgever wil uitoefenen op het project en of er bijvoorbeeld sprake is van een scheiding tussen de ontwikkeling en de exploitatie daarvan Kiezen van een organisatiemodel Bij het kiezen van een bepaald bouworganisatiemodel spelen vier factoren een rol van betekenis (De Koning en Sproncken, 2001): invloed door de opdrachtgever scheiding tussen ontwikkeling en exploitatie onafhankelijkheid van beïnvloeding door de markt, politiek of omgeving integreren van de opbrengsten van het project in de aanbesteding Invloed door de opdrachtgever Er bestaan onderling grote verschillen tussen opdrachtgevers. Professionele opdrachtgevers, zoals woningcorporaties, hebben bijvoorbeeld vaker te maken gehad met de ontwikkeling van bouwprojecten. Ze hebben de nodige expertise op dit gebied en beschikken vaak over een eigen organisatie die een rol van betekenis kan spelen in het ontwikkelings- en exploitatieproces. Deze opdrachtgevers willen niet alleen invloed uitoefenen op het eindresultaat, maar ook op het proces. Niet-professionele opdrachtgevers hebben weinig tot geen ervaring met de ontwikkeling van een bouwproject, laten zich graag bijstaan door externe adviseurs en willen eventuele risico's graag neerleggen bij de aanbiedende partijen.

5 5 Scheiding tussen ontwikkeling en exploitatie Zoals eerder aangegeven kan in een bouwproject een aantal functies worden onderscheiden die achtereenvolgens of parallel aan elkaar plaatsvinden om het uiteindelijke bedoelde resultaat te bereiken: Financiering De financiering van een bouwproject heeft betrekking op het verwerven van vermogen om de realisatie van een project mogelijk te maken. Ontwikkeling De functie ontwikkelen betreft in wezen alle initiële en commerciële activiteiten die nodig zijn voor de voorbereiding en de uitvoering van het bouwproject tot aan de exploitatie of verkoop. Ontwerp Het ontwerp omvat alle technische ontwerpactiviteiten - vaak onderverdeeld in structuurontwerp, voorlopig ontwerp en definitief ontwerp - die nodig zijn voor de technische uitwerking van het project (bestek en tekeningen; zie ook hoofdstuk 1, tabel 1.1 Fasering naar NEN 263). Uitvoering De uitvoering behelst het daadwerkelijk realiseren van het bouwproject, inclusief de werkvoorbereiding en de oplevering. Onderhoud Het onderhoud betreft het technisch bruikbaar houden van het bouwproject gedurende de exploitatie- of gebruiksfase. Exploitatie De exploitatie betreft het gebruik en het beheer van het bouwproject na de oplevering. Indien wenselijk kan het gebouw door verbouwing aangepast worden aan een veranderend gebruik. Financiering Ontwikkeling Ontwerp Uitvoering Onderhoud Exploitatie Basiskeuze voor organisatiemodel Bouwproject omvat slechts de uitvoering van het werk Bouwproject omvat zowel ontwerp als uitvoering van het werk Bouwproject omvat naast ontwerp en uitvoering ook ontwikkelingsaspecten Figuur 5.2 Voorbeelden van het combineren van functies bij uitbesteding [bron: De Koning en Sproncken, 2001] Bouwproject omvat gehele levenscyclus incl. exploitatie

6 In figuur 5.2 zijn enkele voorbeelden gegeven van mogelijke combinaties van functies die bepalend kunnen zijn voor de keuze van een organisatiemodel. Zoals eerder beschreven kan de keuze van een opdrachtgever voor een bepaald organisatiemodel mede bepaald worden door de keuze of hij bepaalde functies, zoals de financiering of de exploitatie, mee wil aanbesteden bij de ontwikkeling van het project. Onafhankelijkheid van beïnvloeding door de markt, politiek of omgeving Bij de ontwikkeling van een bouwproject kunnen externe omstandigheden van grote invloed zijn op de financiële haalbaarheid of de mogelijke risico's die tijdens de ontwikkeling of exploitatie kunnen optreden. Een plotselinge wijziging in de studiefinanciering kan de vraag naar studentenwoningen bijvoorbeeld snel doen afnemen waardoor ontwikkelde projecten leeg blijven staan. Complexe grootschalige projecten zoals de aanleg van een nieuwe metrolijn kunnen grote onverwachte risico's met zich meebrengen. Integreren van opbrengsten van het project in de aanbesteding Bij de keuze voor een bepaald organisatiemodel kan het van belang zijn om niet alleen rekening te houden met de kosten van een bouwproject, maar ook met de eventuele inkomsten tijdens de gebruiksfase. Hierbij valt bijvoorbeeld te denken aan inkomsten in de vorm van een tolheffing bij een tunnel of snelweg, aan inkomsten die gebaseerd zijn op de jaarlijkse productie van een afgesproken quotum van producten in een fabriek of aan huurinkomsten bij een kantoorgebouw of winkelcentrum.

7 Overzicht vier organisatiemodellen Samenvattend worden in de vorige paragraaf vier factoren genoemd die van invloed zijn op de keuze van een bepaald organisatiemodel: de invloed door de opdrachtgever op het ontwikkelingsproces de scheiding tussen ontwikkeling en exploitatie de invloed van de markt, de politiek of de omgeving op het project het integreren van de opbrengsten van het project in de aanbesteding Uitgaande van deze vier factoren kan een matrix opgesteld worden, met een indeling in vier verschillende hoofdtypen organisatiemodellen: 1. Organisatiemodel Ontwerp en uitvoering 2. Organisatiemodel Projectontwikkeling of koop 3. Organisatiemodel Totaalontwikkeling 4. Organisatiemodel Strategische samenwerking Figuur 5.3 De vier organisatiemodellen [bron: De Koning en Sproncken, 2001] Afnemende integratie van opbrengsten in de uitbesteding 4 Strategische samenwerking 1 Ontwerp en uitvoering Afnemende beïnvloeding door markt, politiek, omgeving 3 Totaalontwikkeling 2 Projectontwikkeling of koop Afnemende scheiding tussen ontwikkeling en exploitatie Afnemende invloed door opdrachtgever Elk kwadrant in figuur 5.3 heeft betrekking op één van de vier typen organisatiemodellen. Elke van de organisatiemodellen wordt getypeerd door de mate waarin ze betrekking heeft op de vier eerder genoemde factoren

8 1.2.3 Organisatiemodel 1: Ontwerp en Uitvoering Het organisatiemodel Ontwerp en Uitvoering heeft daadwerkelijk alleen betrekking op het ontwerpen en realiseren van een bouwproject. Eventuele extra diensten zoals bijvoorbeeld het onderhoud, worden afzonderlijk aanbesteed. Dit model staat bekend als het traditionele model en komt in Nederland nog steeds het meest voor. De opdrachtnemer, meestal de architect, fungeert in dit model als schakel tussen de opdrachtgever en de aannemer. Bij dit model houdt de opdrachtgever veel invloed op het proces en liggen de risico's van de planontwikkeling en exploitatie geheel bij de opdrachtgever (zie figuur 5.4). Opdrachtgever Opdrachtnemer(s) Financierings-, ontwikkelings- en exploitatierisico s Figuur 5.4 Organisatiemodel 1: Ontwerp en uitvoering Figuur 5.5 Organisatiemodel 2: Projectontwikkeling of koop Organisatiemodel 2: Projectontwikkeling of koop Het organisatiemodel Projectontwikkeling houdt een verdergaande integratie in van ontwerp en uitvoering. De opdrachtgever heeft minder invloed op de planontwikkeling. Het bouwproject wordt vooral bepaald door de aanbiedende partij die ook de belangrijkste risico's draagt. De opdrachtgever is vooral geïnteresseerd in het opgeleverde eindproduct en niet in het ontwikkelingsproces. Met name in de koopsector van de woningbouw komt dit organisatiemodel vaak voor (zie figuur 5.5).

9 Organisatiemodel 3: Totaalontwikkeling Het organisatiemodel Totaalontwikkeling is gebaseerd op het vorige model Projectontwikkeling of koop, maar hierin zijn bovendien alle overige ontwikkelingsfuncties geïntegreerd, zoals de financiering maar ook de exploitatie van het project. De opdrachtgever is in dit geval alleen geïnteresseerd in het gebruik van het gebouw, bijvoorbeeld de mogelijkheid een kantoorhoudende organisatie te huisvesten (kantoorgebouw), om zieken te behandelen en te verplegen (ziekenhuis) of onderwijs te bieden (schoolgebouw). De partij die het bouwproject ontwikkeld heeft blijft eigenaar van het project en blijft tevens ook verantwoordelijk voor de exploitatie van het project. Wanneer bij een totaalontwikkeling een publieke opdrachtgever betrokken is (overheid) dan wordt er gesproken over een concessie. Het gaat hier vaak om langlopende verbintenissen die betrekking kunnen hebben op gebouwen zoals kantoren, gevangenissen of scholen of om infrastructurele projecten. De aanbiedende partij is zowel verantwoordelijk voor de financiering, het ontwerp en de realisatie als de exploitatie, inclusief alle mogelijke risico's die zich daarbij kunnen voordoen (zie figuur 5.6). Figuur 5.6 Organisatiemodel 3: Totaalontwikkeling Opdrachtgever Opdrachtnemer(s) Financierings-, ontwikkelings- en exploitatierisico s Organisatiemodel 4: Strategische Samenwerking Het organisatiemodel Strategische Samenwerking is gebaseerd op een duurzame relatie tussen opdrachtgever en opdrachtnemer. Dat betekent dat ze zoveel mogelijk al in een vroeg stadium samenwerken en hun kennis en expertise delen om daarmee tot een kwalitatief beter en geïntegreerd resultaat te komen. In veel gevallen is deze samenwerking projectoverschrijdend. De betrokken partijen kennen elkaar vanuit eerdere projecten, kennen elkaars expertise, weten inmiddels op welke wijze ze het beste kunnen samenwerken en zijn daarmee in staat een optimale prijs-kwaliteitverhouding te realiseren. Zeer complexe projecten waarbij de omgevingsfactoren als markt en politiek een grote rol kunnen spelen en waarbij de mogelijke risico's moeilijk vooraf zijn in te schatten, lenen zich bij uitstek voor een strategische samenwerking.

10 Figuur 5.7 Organisatiemodel 4: Strategische samenwerking 1.3 Contractmodellen Wanneer door de opdrachtgever of zijn adviseurs bepaald is welk organisatiemodel het meest geschikt is voor het betreffende bouwproject, dient er vervolgens gekeken te worden naar de partijen die er bij betrokken zullen worden en op welke wijze dit zich het beste laat vertalen in een contractmodel. Een contractmodel legt de structuur van contractuele relaties vast: welke partijen met welke verantwoordelijkheid welke taken gaan uitvoeren en op welke wijze risico's verdeeld worden. Binnen de vier belangrijkste organisatiemodellen die in de vorige paragraaf beschreven zijn, kunnen weer verschillende soorten contractmodellen onderscheiden worden. Deze reeks is voorlopig nog niet eindig. Ieder jaar komen er weer nieuwe contractbenamingen op de markt, veelal afgeleid van vergelijkbare ontwikkelingen in het buitenland en gebaseerd op weer een iets andere combinatie van procesfuncties die in een aanbieding meegenomen kunnen worden Kiezen van een contractmodel Bij de keuze van een specifiek contractmodel spelen vier criteria een belangrijke rol: Hoe is de verdeling van de risico s? Hoe liggen de contractuele relaties en rechtsverhoudingen tussen partijen? Wat zijn de functionele verhoudingen tussen partijen? Hoe is de fasering van het bouwproces en het tijdstip waarop de partijen hierin gaan deelnemen? Hoe is de verdeling van de risico s? Een bepaald risico kan het beste bij een partij worden ondergebracht die op grond van zijn expertise in staat moet worden geacht dit risico te beheersen of te beperken. Bovendien heeft risico-allocatie te maken met de financiële draagkracht van de betreffende partij. Geen enkele partij is gebaat bij een tussentijds faillissement van een andere betrokken partij.

11 11 Sommige risico's kunnen beter gedragen worden door meerdere partijen. Dit is bijvoorbeeld het geval bij (project)allianties. Hierbij ontstaat door de gedeelde verantwoordelijkheid een betere samenwerking. Uiteindelijk zijn risico's altijd weer terug te voeren op hun consequenties voor de kwaliteit van het bouwproject, de prijs waarvoor het gerealiseerd wordt of de tijd waarbinnen het tot stand wordt gebracht. Zie voor meer informatie ook hoofdstuk 15: Risico's in de bouw. Figuur 5.8 Voorbeeld contractuele relaties in een traditioneel contractmodel Hoe liggen de contractuele relaties tussen partijen? Een belangrijke basis onder een contractmodel zijn de contractuele relaties tussen de partijen die bij een bouwproject betrokken zijn. En die contractuele relaties starten altijd bij de opdrachtgever. Figuur 5.8 laat een voorbeeld zien van de contractuele relaties in een traditioneel model. De opdrachtgever sluit hierbij afzonderlijke contracten met de architect, de adviseur en de aannemer. Architect Opdrachtgever Adviseur installaties Aannemer Hoe liggen de functionele verhoudingen tussen partijen? Met een functionele relatie wordt de aansturings- en verantwoordingslijn weergegeven zoals die tijdens de ontwikkeling van een project bestaat. In figuur 5.9 wordt een voorbeeld gegeven van de functionele relaties tussen de partijen waarvan in figuur 5.8 het traditionele contractmodel is gegeven. De opdrachtgever stuurt in dit geval rechtstreeks de architect aan, maar niet de aannemer: dat doet de architect. Naast de aannemer stuurt de architect ook de installatie-adviseur aan, die op zijn beurt weer de (onder)aannemer van de installaties aanstuurt. Figuur 5.9 Voorbeeld van de functionele relaties in een traditioneel contractmodel Opdrachtgever Architect Bouwkundig aannemer Adviseur installaties Aannemer installaties

12 Hoe is de fasering van het bouwproces en het tijdstip van deelname? Naast de hiervoor besproken contractuele en functionele relaties die er tussen partijen kunnen bestaan, is ook het tijdstip in het proces van belang waarop deze relaties worden aangegaan. Zo wordt een installatie-adviseur in de regel later in het proces ingeschakeld dan de architect. Hetzelfde geldt voor een leverancier. Het element tijd speelt hier dus een rol van betekenis (zie figuur 5.10). Figuur 5.10 Voorbeeld van een fasering en de deelname van partijen daarin [bron: De Koning en Sproncken, 2001] Financiering Ontwikkeling Ontwerp Uitvoering Onderhoud Exploitatie Deelnemende partij Architect Adviseur Aannemer Leverancier Projectontwikkelaar

13 De verschillende contractmodellen Op basis van de vier eerder geïntroduceerde organisatiemodellen (Ontwerp en Uitvoering, Projectontwikkeling, Totaalontwikkeling en Strategische Samenwerking), kunnen veel contractmodellen die in de huidige bouwpraktijk gebruikt worden gepositioneerd worden. Een voorbeeldinvulling is te zien in figuur Afnemende integratie van opbrengsten in de uitbesteding 4 Strategische samenwerking PPS 1 Ontwerp en uitvoering Afnemende beïnvloeding door markt, politiek, omgeving Alliantie Partnering Constr. Mgmt. Design & Build Bouwteam Traditioneel 3 Totaalontwikkeling PFI DBFMO BOT 2 Projectontwikkeling/koop Turnkey Brochureplan Afnemende scheiding tussen ontwikkeling en exploitatie Figuur 5.11 Enkele voorbeelden van contractmodellen die horen bij een van de vier organisatiemodellen [naar: De Koning en Sproncken, 2001] Afnemende invloed door opdrachtgever 1.4 Contractmodellen voor Ontwerp en Uitvoering Veel van de in Nederland gebruikte contractmodellen horen bij het organisatiemodel Ontwerp en Uitvoering. Enkele voorbeelden hiervan zijn: Het Traditionele contractmodel Het Bouwteam contractmodel Het Design & Build contractmodel Het Management Contracting contractmodel Het Construction Management contractmodel

14 De onderlinge verschillen tussen deze contractmodellen hebben vooral te maken met de mate waarin de opdrachtgever zijn eisen heeft geformuleerd en de ontwerpen heeft uitgewerkt, de invloed die de opdrachtgever op het ontwikkelingsproces wil hebben, een gescheiden of meer integrale aanpak van ontwerp en uitvoering en de scheiding tussen planontwikkeling enerzijds en de exploitatie van het bouwproject anderzijds Het Traditionele contractmodel Het Traditionele contractmodel heet ook wel het klassieke contract ofwel de klassieke driehoek tussen opdrachtgever, architect en aannemer. Oorspronkelijk waren dat overigens nog maar twee partijen: de bouwheer (opdrachtgever) en de bouwmeester (architect). Aan de top van de driehoek staat de opdrachtgever. Aan de basis staan respectievelijk de architect en de aannemer. De opdrachtgever heeft in dit model een grote betrokkenheid bij het hele proces. Hij contracteert de architect voor het ontwerp en de aannemer voor de uitvoering. Hij is ook verantwoordelijk voor de directievoering, maar kan dat indien gewenst uitbesteden aan de architect of een andere adviseur. De ontwerpfase omvat het maken van een Voorlopig Ontwerp (VO), Definitief Ontwerp (DO) en het voorbereiden van de definitieve bouw (bestek en tekeningen). Vervolgens vindt de aanbesteding plaats. De bouwer die de beste aanbieding doet mag het werk maken. Een variant van het traditionele model is het werken onder regie. De opdrachtgever is daarbij verantwoordelijk voor het ontwerp en schakelt daar in de regel een architect voor in. De aannemer wordt ingeschakeld op uurbasis. Voorbeelden van deze contracten zijn bijvoorbeeld General Contracting (waarbij er sprake is van hoofdaanneming) of Subcontracting (waarbij er sprake is van onderaanneming) door samenwerkende of ondergeschikte specialistische bedrijven of toeleveranciers. Figuur 5.12 Voorbeeld van de contractuele relaties bij een traditioneel model Architect Opdrachtgever Adviseur installaties Aannemer Onderaannemer Onderaannemer Het Bouwteam contractmodel Het Bouwteam contractmodel is een variant op het hiervoor beschreven traditionele contractmodel. Het betreft een tijdelijke vorm van samenwerking

15 15 (op projectbasis) waarbij de opdrachtgever geadviseerd wordt door zowel architect als aannemer in een vroeg stadium van de planontwikkeling (ontwerpfase). Op deze wijze kan bijvoorbeeld uitvoeringsexpertise van de aannemer al vroeg in de ontwerpfase geïntegreerd worden door de architect. Doel van een bouwteammodel is dus om met behoud van de individuele zelfstandigheid en verantwoordelijkheid samen aan de voorbereiding van een project te werken, waarbij ieder zijn eigen deskundigheid en ervaring zo goed mogelijk gebruikt. De taak van de bouwteamaannemer in de ontwerpfase is slechts adviserend. Het staat immers nog geenszins vast of hij het bouwproject daadwerkelijk na de aanbesteding ook zal uitvoeren. De architect vertaalt de vraag van de opdrachtgever, met ondersteuning van adviseurs, naar een VO, een DO en bestek en tekeningen. De geselecteerde bouwer maakt deel uit van het team en adviseert over uitvoeringszaken en kosten. Na de aanbesteding wordt een nieuw contract met deze aannemer of met een andere geselecteerde aannemer gesloten voor de realisatie van het project. Het bouwteammodel is met name geschikt voor utiliteitsprojecten die in zeer korte tijd moeten worden ontwikkeld of een hoge graad van specialistische uitvoering vereisen. Voorwaarde is wel dat de aannemer dan ook over een goed bedrijfsbureau beschikt, dat daadwerkelijk in staat is actief en constructief mee te werken aan de ontwikkeling van het plan. Voordelen Door middel van goede basisafspraken, gemaakt over eenheidsprijzen, bouwplaatskosten, uurlonen en opslagpercentages, kan in een vroeg stadium in overleg met de aannemer worden gebudgetteerd. Door de aannemer mede verantwoordelijk te stellen voor het budget, kan bij een goed omlijnd Definitief Ontwerp sturend worden opgetreden in de bestekfase. De specifieke uitvoeringskennis van de aannemer wordt in een vroeg stadium ingebracht bij het uitwerken van het plan. Nadelen Indien nog ingrijpende wijzigingen in het ontwerp c.q. de constructies zijn te verwachten, vervalt de kracht van de afspraken over eenheidsprijzen en de eerder ingebrachte specialistische uitvoeringskennis. Slechts weinig aannemers beschikken over een daadwerkelijk goed bedrijfsbureau, waardoor slechts zelden een optimale uitvoerings- en prijzenkennis wordt ingebracht. Doordat de aannemer tijdens het ontwikkelingsproces doorgaans toch op de hoogte raakt van vertrouwelijke informatie, zal zijn prijsopgave niet

16 gespeend zijn van politieke invloeden. Hij kan een meer reële prijs offreren dan wanneer hij in concurrentie met andere aannemers moet aanbieden. Dit speelt met name een rol bij opdrachtgevers met voldoende eigen vermogen. Afhankelijk van de aanbesteding heeft de opdrachtgever wel of geen profijt van prijsconcurrentie tussen verschillende aannemers. Wel profijt heeft hij als er na de bouwteamontwikkeling opnieuw een aanbesteding plaatsvindt met meerdere aannemers, waarbij de aannemer uit het bouwteam ook weer kan meebieden. Figuur 5.13 Voorbeeld van de contractuele relaties bij een bouwteammodel Het Design & Build contractmodel Bij het Design & Build contractmodel (ook wel geïntegreerd model genoemd) liggen het ontwerp en de uitvoering in één en dezelfde hand. In de praktijk is dit vaak de uitvoerende partij, maar dat hoeft niet noodzakelijkerwijs het geval te zijn. Ook architectenbureaus en ingenieursbureaus kunnen - al dan niet in combinatie met elkaar - naast het ontwerp ook de uitvoering verzorgen. Partijen bieden een concept aan (ontwerp én uitvoering) voor een vaste prijs. Ontwerprisico s liggen bij de aanbieder, exploitatierisico s bij de klant. Bij Design & Build heeft de opdrachtgever een semi-actieve rol. Hij toetst namelijk een aantal vooraf benoemde tussentijdse projectresultaten. De opdrachtnemer mag pas verder wanneer de opdrachtgever zijn fiat heeft gegeven. Er kunnen behalve het ontwerp en de uitvoering nog meer functies in de aanbieding naar de opdrachtgever meegenomen worden, bijvoorbeeld de financiering (Finance) of het onderhoud (Maintenance). Ook in dit geval is er sprake van geïntegreerde contractmodellen. Voordelen De kosten voor projectmanagement, architect en adviseurs kunnen relatief laag zijn, omdat de aannemer zijn inkooptechnieken op deze partijen zal toepassen.

17 17 Er ontstaat een grote betrokkenheid van de aannemer bij de ontwikkeling van het plan, waardoor mogelijke kostenbeperkende alternatieven in een vroeg stadium worden onderkend. Door de aannemer verantwoordelijk te stellen voor het budget is hij gebonden een haalbaar plan te produceren. De opdrachtgever heeft zekerheid ten aanzien van de realisatie en loopt weinig risico. Nadelen De opdrachtgever dient de eisen zeer compleet en nauwkeurig te formuleren. Er is geen of onvoldoende inzicht in de relatie tussen kosten en kwaliteit. Deze methode is alleen wenselijk wanneer de aannemer ook daadwerkelijk deelneemt in het risicodragend kapitaal en daarom het meest voor de hand liggend voor opdrachtgevers met een beperkt eigen vermogen. Opdrachtgevers die van deze methode gebruik maken, zullen een goed tegenwicht moeten bieden. De prijsvorming zal 5 tot 10% hoger zijn ten opzichte van de in de markt haalbare aanneemsom. Daarentegen is er wel het voordeel van een vaste prijs voor de opdrachtgever en het ontbreken van risico's. Bij deze methode zal de opdrachtgever een goede adviseur moeten hebben die het Programma van Eisen opstelt en nauwgezet de kwaliteit bewaakt. Figuur 5.14 Voorbeeld van de contractuele relaties bij een Design & Build model Management Contracting en Engineering Contracting Bij Management Contracting, waaronder de architecten-, advies-, management-, consulting- en engineerscontracten vallen, is er een specialist of een specialistische manager voor de verschillende taken in het bouwproces. Deze werkt op basis van een adviesdienst. Er gelden bij deze contractvorm dan ook sterk opgedeelde advies- en realiseringsopdrachten. Voorbeelden zijn de architect, de constructeur, de gespecialiseerde adviseur, de consultant, de

18 projectmanager, de design manager, de construction manager en de facilty manager. Engineering Contracting gaat uit van de adviesdiensten van architecten, adviseurs en/of consulting engineers, waarbij meer taken in het bouwproces betrokken kunnen worden om zodoende een meer geïntegreerd proces te krijgen. Dit noemt men ook wel de achterwaartse integratie van deze adviseurs. Voorbeelden zijn Total Engineering of General Contracting. General Contracting lijkt op de Turnkey-overeenkomst (zie ook paragraaf 5.5.1). Toch is er verschil. De Turnkey-aanbieder werkt op basis van een door de opdrachtgever opgesteld Programma van Eisen (PvE). De General Contractor echter helpt de opdrachtgever juist ook in de programmafase en stelt samen met de opdrachtgever het PvE op. Het is denkbaar dat de General Contractor eerst een haalbaarheidsstudie uitvoert. De General Contractor ziet zichzelf dan ook als een echte adviseur van de opdrachtgever. Hij kan zelf weer afzonderlijke overeenkomsten afsluiten met verschillende andere partijen ten behoeve van het ontwerp- en uitvoeringsproces. Figuur 5.15 Voorbeeld van contractuele relaties bij Engineering Contracting Engineering Contractor Opdrachtgever Aannemer Adviseur installaties Architect Onderaannemer Construction Management Construction Management is als contractmodel oorspronkelijk afkomstig uit Amerika en Engeland. Bij dit model coördineert de bouwmanager als adviseur voor de opdrachtgever het gehele ontwerp- en uitvoeringsproces, inclusief de directievoering. Construction Manager Opdrachtgever Architect/ adviseurs Aannemer Figuur 5.16 Voorbeeld van de contractuele relaties bij Construction Management

19 Contractmodellen voor Projectontwikkeling of koop Een beperkt aantal contractmodellen behoort bij het organisatiemodel Projectontwikkeling of koop. Enkele voorbeelden hiervan zijn Turnkey en het Brochureplan. In alle voorbeelden van dergelijke contractmodellen is sprake van levering of koop. De opdrachtgever en de projectontwikkelaar komen in een vroeg stadium een totaalprogramma overeen, meestal inclusief de projectfinanciering. De opdrachtgever loopt hierbij nauwelijks risico en beperkt zich tijdens de realisatie hooguit tot het controleren van de gemaakte afspraken Het Turnkey contractmodel Turnkey is een verzamelnaam voor contracten waarbij de verantwoordelijkheid voor ontwerp, uitvoering en in sommige gevallen ook de financiering bij één opdrachtnemende partij ligt. In het Turnkey-model wordt de opdrachtgever wel geïnformeerd, maar is er van tussentijds toetsen van zijn kant geen sprake. In de meest extreme vorm beperkt de opdrachtgever zich bij Turnkey tot het formuleren van zijn bouwbehoefte. Wanneer de Turnkey-aanbieder een aannemer is, dan is ook hier sprake van zogenaamde voorwaartse integratie in het proces (zie ook figuur 5.1). Van de traditionele uitvoerder van bestek en tekeningen is hij nu de totaalaanbieder geworden. Opdrachtgever Turnkey-aanbieder Figuur 5.17 Voorbeeld van de contractuele relaties bij het Turnkey contractmodel Architect (Onder)aannemer Adviseur installaties Als bekend voorbeeld in Nederland kan het bouwbedrijf Pellikaan genoemd worden, dat zich als leverancier van sporthallen ontwikkeld heeft tot totaalaanbieder van scholen, zwembaden, sportaccommodaties, kantoren en hotels Het Brochureplan contractmodel Het brochureplan wordt vooral toegepast in de particuliere woningbouwsector. De opdrachtgever of koper kan alleen vooraf via reeds door de aanbieder bepaalde keuze-opties zijn wensen kenbaar maken voor het volume, de inrichting en de afwerking van het project in relatie tot het beschikbare budget.

20 De koper ziet al vooraf wat hij uiteindelijk geleverd krijgt. De koper heeft buiten de te maken afspraken over de te leveren kwaliteit en het tijdspad waarbinnen het project wordt opgeleverd geen enkele invloed op het ontwerpen uitvoeringsproces. Er zijn varianten van dit contractmodel waarbij het onderhoud over een bepaalde periode eveneens wordt meegenomen in de aanbieding. Figuur 5.18 Voorbeeld van de contractuele relaties bij het brochureplan contractmodel Opdrachtgever Brochureplanaanbieder Architect (Onder)aannemer Adviseur(s) 1.6 Contractmodellen voor Totaalontwikkeling Bij het organisatiemodel Totaalontwikkeling worden naast de planontwikkeling ook de andere noodzakelijke procesfuncties integraal in het aanbod van de aanbiedende partijen meegenomen. De opdrachtgever stelt zich hier bij het opgeleverde bouwproject hetzelfde op als bijvoorbeeld wanneer hij een auto zou leasen. Hij betaalt voor gebruik, service en onderhoud een vast bedrag over een vastgestelde periode. In de aanbieding kunnen de volgende procesfuncties een plaats krijgen: de financiering (F - finance), het ontwerp (D - design), de uitvoering (B - build), het onderhoud (M - maintain) en de exploitatie (O - operate). Na afloop van de contractperiode waarin het gebouw geleased wordt, kan het project uiteindelijk ook overgedragen worden aan de gebruiker (T - transfer) Het BOT contractmodel Kenmerkend voor het BOT contractmodel (de combinatie van Build, Operate en Transfer) is het feit dat alle in het ontwikkelings- en exploitatieproces voorkomende functies in één totaalpakket aan de opdrachtgever worden aangeboden door de ontwikkelende partij. Dit pakket behelst dus alle functies vanaf initiëring en financiering tot en met beheer, onderhoud en uiteindelijk ook de overdracht na afloop van de exploitatieperiode,. De aanbiedende partij bestaat vaak uit meerdere deelnemers die gespecialiseerd zijn in één of meer van de procesfuncties die aangeboden worden. Zo maken banken hiervan soms ook deel uit in verband met het financieringsaspect in de aanbieding.

21 21 Bij BOT bestaat het ontwikkelen van het project uit het ontwerpen en bouwen van het project (Build) en het beheren en exploiteren van de voorziening (Operate) voor een afgesproken periode (concessie) waarbinnen de concessiehouder het geïnvesteerde vermogen kan terugverdienen uit de opbrengsten van het gebruik. Voorbeelden hiervan zijn het heffen van tol voor het gebruik van de voorziening (tunnel, brug) of een gebruiksvergoeding bij gebouwen. Aan het einde van de concessieperiode (bijvoorbeeld 30 jaar) draagt de concessiehouder het project doorgaans zonder kosten over aan de opdrachtgever (Transfer). Bij de BOT-benadering vraagt de opdrachtgever om de levering van een totaalproduct; niet alleen het ontwerp en de realisatie, maar ook het beheer, onderhoud en facilitymanagement: Total Product Delivery. Kenmerkend voor het BOT-model is dat dit vooral een vorm van financieren is door het verlenen van een concessie aan een private partij. Vooral overheden hebben hier in het verleden gebruik van gemaakt om daarmee financierings- en exploitatieproblemen bij private partijen neer te leggen. Veel complexe infrastructurele werken zijn op deze wijze gerealiseerd (o.a. de Kanaaltunnel, de Velsertunnel in Nederland en diverse wegen). Leveranciers Overheid BOT-aanbieder concessiecontract Gebruikers Figuur 5.19 Voorbeeld van de contractuele relaties bij een BOT contractmodel Banken Consortium Exploitant Investeerders Aannemers 1.7 Contractmodellen voor Strategische Samenwerking Enkele voorbeelden van contractmodellen binnen het organisatiemodel Strategische samenwerking zijn: de publiek-private samenwerking (PPS) de alliantie partnering

22 De belangrijkste onderlinge verschillen tussen deze contractmodellen hebben onder meer te maken met de vraag of de overheid al dan niet betrokken is of betrokken moet blijven bij de ontwikkeling en exploitatie van het project (PPS), of vragende en aanbiedende partijen samen een project willen ontwikkelen met werkelijk gedeelde risico's en mogelijke winsten (alliantie) of dat opdrachtnemende en opdrachtgevende partijen langdurig en projectongebonden afspraken willen maken over de manier van samenwerken, de kosten en de te leveren kwaliteit (partnering). Met name in de Anglo-Amerikaanse landen is nogal wat ervaring opgebouwd met partnering. Mede als gevolg van de parlementaire enquête naar de bouwfraude in Nederland in 2002 wordt partnering ook in een negatief daglicht geplaatst in relatie tot verboden prijsafspraken en een beperking van de vrije marktwerking Het PPS contractmodel Publiek-private samenwerking (PPS) is een verzamelbegrip en behelst verschillende mogelijkheden voor de samenwerking tussen publieke partijen (lokale, regionale of landelijke overheden) en private partijen (marktpartijen zoals ontwikkelaars, financiers of bouwbedrijven). Zowel in het buitenland als in Nederland is PPS vooral bekend geworden van projecten die te maken hebben met gebiedsontwikkeling. De laatste jaren wordt in Nederland ook met deze contractvorm geëxperimenteerd bij projecten op objectniveau, zoals bruggen, tunnels, ziekenhuizen en scholen. Enkele voorbeelden zijn: Ontwerp, bouw en onderhoud van de HSL-Zuid voor een periode van 30 jaar door Infraspeed en een exploitatie voor een periode van 15 jaar door High Speed Alliance. Financiering, ontwerp, aanleg en beheer van de A59 tussen Oss en 's- Hertogenbosch voor een periode van 18 jaar. Ontwerp, bouw, financiering, onderhoud en exploitatie van het renovatieproject voor het kantoorgebouw van het ministerie van Financiën op het Korte Voorhout in Den Haag. Ontwerp, aanleg, financiering en onderhoud van de Tweede Coentunnel bij Amsterdam. Verschillende definities Wanneer de verschillende mogelijke definities van PPS die in de praktijk gebruikt worden naast elkaar worden gelegd, rest slechts één conclusie: PPS blijft een containerbegrip. Wel kunnen bepaalde aspecten genoemd worden die steeds terugkomen en typerend zijn voor deze contractvorm. Het betreft in alle gevallen samenwerking tussen publieke en private partijen op basis van een gemeenschappelijke scope en dezelfde doelstellingen

23 23 in alle fasen van een project waarin verschillende partijen deelnemen (consortium) gericht op het creëren van een win-winsituatie met mogelijkheden voor een goede balans met mogelijkheden voor het genereren van cash-flows die de basis vormt van een financiële risicoverdeling die de basis vormt voor de verdeling van de opbrengsten in een gemeenschappelijke verantwoordelijkheid op basis van gelijkwaardigheid met behoud van eigen identiteit Voordelen PPS De voordelen van PPS omvatten in het kort de volgende aspecten: de kerntaak van de publieke instelling (overheid) blijft gewaarborgd er vindt vroegtijdig informatie-uitwisseling plaats een hoger rendement door inruil van prestaties er is wederzijds commitment en er zijn wederzijdse belangen er vindt een betere risicoverdeling plaats Publieke instelling concentreert zich op haar kerntaak Doordat de verantwoordelijkheid voor het transportvraagstuk of het integrale huisvestingsvraagstuk wordt overgedragen aan de markt, ligt daar ook de beheerslast c.q. het regelen van de verschillende contracten voor de realisatie en het beheer van het project. De publieke instelling kan zich op deze manier meer richten op de kwaliteit van de eigen core business, bijvoorbeeld het geven van onderwijs of het verzorgen van zieken. Kwaliteit omhoog door vroegtijdige informatie-uitwisseling Bij PPS maken de betrokken partijen een gezamenlijk plan. Daartoe wisselen ze al in een vroegtijdig stadium informatie uit over hun plannen. De kwaliteit van de resulterende plannen en daarmee het rendement van het project kan hierdoor hoger komen te liggen. Hoger rendement door inruil van prestaties Bij zogenaamde combinatieprojecten, bijvoorbeeld bij gebiedsontwikkeling, worden vaak meerdere functies ontwikkeld (station openbaar vervoer, woningen, kantoren, openbare ruimte). Door gezamenlijk een integraal plan op te stellen kunnen deze functies beter in ruimte en tijd ontwikkeld worden. Het rendement van projectonderdelen kan worden vergroot door het zogenaamde inruilen van prestaties. De betere integratie van private en publieke planonderdelen, zoals de ligging en vorm van een kantoor bij een plein, kan bijvoorbeeld de ruimtelijke kwaliteit verbeteren. Verhuuropbrengsten van

24 kantoorruimte kunnen toenemen, omdat huurders bereid zijn om te betalen voor investeringen in de openbare ruimte die de aantrekkelijkheid van het hele gebied verhogen. Commitment en wederzijds belang Door PPS ontstaat draagvlak voor ontwikkelingen bij meerdere partijen in het te ontwikkelen project. Dat kan in een groter commitment resulteren. Commitment van betrokken partijen is belangrijk aangezien het meestal gaat om lange termijnprojecten waarbij partijen zeker willen weten dat ze van elkaar op aan kunnen. Betere risicoverdeling Bij PPS kan door het verdelen van taken en belangen een betere verdeling van risico's ontstaan. Effecten van een betere risicoverdeling zijn de grotere mogelijkheden en prikkels tot besparing op de uitvoeringskosten. Figuur 5.20 Voorbeeld van de contractuele relaties bij een PPS contractmodel Publieke partij (bv. gemeente) Private partij (bv. belegger) Opdrachtgever - PPS Private partij (bv. ontwikkelaar) Adviseurs Architect Aannemer(s) Onderaannemer Onderaannemer Het Alliantie contractmodel De alliantie kan gezien worden als een contractmodel waarmee de strikte scheiding tussen verantwoordelijkheden en daaruit voortkomende - vaak tegenstrijdige - belangen van verschillende partijen gelijkgericht kunnen worden. De partners in een alliantie streven dezelfde doelen na. De winst van partijen wordt afhankelijk gemaakt van de randvoorwaarden die de opdrachtgever stelt (Koolwijk en Geraedts, 2006). Alle partners in de alliantie delen gezamenlijk naar rato de volledige risico s die zich bij projecten kunnen voordoen. Dat betekent ook dat wanneer er zich onverhoopt problemen tijdens het project voordoen, alle partners gezamenlijk zullen gaan zoeken naar de beste oplossing. Immers, een probleem kan de gezamenlijke winst drukken, dus ook de winst van iedere partner afzonderlijk. Op deze manier is het in het belang van iedere partner

25 25 dezelfde doelen na te streven in het project. Samenwerken aan de ideale oplossing is dus het bindende advies. Een begrip dat vaak in relatie met alliantie gebruikt wordt is de joint venture. Een joint venture is een zakelijk samenwerkingsverband tussen twee of meer partijen om samen één economische activiteit te ondernemen. De partijen spreken af om zowel winst als verlies te delen. Ook bij een joint venture blijven alle partners in het samenwerkingsverband geheel zelfstandig. Een joint venture wordt vaak opgezet voor een speciaal project. Het is geen langdurig zakelijke verbinding tussen twee of meer partijen (strategische alliantie). Hierdoor is een joint venture relatief gevoeliger voor conflicten tussen de achterliggende partijen. Het eerste internationale voorbeeld in de utiliteitsbouw van een projectalliantie is het National Museum of Australia ( ) in Canberra (Koolwijk en Geraedts, 2006). De Waardse Alliantie ( ) is in Nederland het eerste voorbeeld van een projectalliantie toegepast in de civiele bouw. De Waardse Alliantie vormt een onderdeel van de Betuweroute, het tracédeel Sliedrecht Gorinchem met een lengte van 22 kilometer. Voor dit deel is een alliantiecontract gesloten en uitgevoerd door ProRail en de aannemerscombinatie HBSC. Een innovatie op het gebied van ontwerp en realisatie van infrastructuur in Nederland (Buck, 2005). Voordelen alliantie De voordelen van het alliantie contractmodel worden hier kort op een rij gezet: Integratie van ontwerp en uitvoering Projectbelang op de eerste plaats door het gezamenlijk delen van winst en verlies Gezamenlijke verantwoordelijkheid deelnemende partijen Hoge betrokkenheid en motivatie deelnemende partijen Kostenverlaging en tijdreductie door optimale afstemming van ontwerp en uitvoering Spreiding van risico s over de alliantiepartners Open communicatie tussen partners; in vroeg stadium mogelijkheden tot bijsturing, minder geschillen Nadelen alliantie Cultuuromslag; de openheid tussen partners vergt van alle betrokkenen een andere denk- en werkwijze dan gebruikelijk; in de huidige cultuur staan partijen meer tegenover elkaar Tijdrovend in beginfase; het opstarten van een alliantie vereist intensieve betrokkenheid van de deelnemers

26 Afhankelijkheid van andere partners; een financiële tegenvaller voor één partij is een tegenvaller voor alle partijen Een kijkje in de keuken van de ander; de vereiste openheid tussen partijen maakt dat de ene partij wel op een heel letterlijke manier in de boeken van de ander kan kijken Investeren in overleg; er moet veel in overleg geïnvesteerd worden en dat is niet alleen tijdrovend, maar ook kostbaar door verschillende opstartsessies en workshops Juridische onvolwassenheid; de alliantie is een betrekkelijk nieuw begrip in de bouw; de juridische omgeving staat wat dat betreft nog in de kinderschoenen Figuur 5.21 Voorbeeld van de contractuele relaties bij een alliantie contractmodel Opdrachtgever Aannemer Architect Opdrachtgever - Alliantie Adviseurs Leveranciers Onderaannemer Het Partnering contractmodel Partnering is een gestructureerde managementbenadering om samenwerking te bevorderen over de contractuele grenzen heen. De fundamentele elementen zijn geformaliseerde gemeenschappelijke doelen, een afgesproken manier om problemen op te lossen en een actief zoeken naar voortdurend meetbare verbeteringen. Partnering is gebaseerd op het principe van supply chain management en vooral toepasbaar in projecten waarbij sprake is van een vaste keten van leveranciers (ketenintegratie). Voorbeelden hiervan zijn te vinden in projecten die gerealiseerd worden door ketens als Albert Heijn en McDonalds. Het principe berust op een win-winsituatie voor zowel opdrachtgever als opdrachtnemer(s) op basis van een continuïteit in de samenwerking die moet leiden tot standaardisatie en kwaliteitsgarantie van producten en kostenbesparingen ten gevolge van schaalvoordelen (afzet- en omzetgaranties). Een voorbeeld in de Nederlandse woningbouw is de vereniging Esprithuis. Al sinds 1997 vormt deze vereniging een platform voor spelers in de woningbouw zoals toeleveranciers, projectontwikkelaars, installatiebedrijven en ontwerpers. Esprithuis richt zich op het beter bedienen van de eindgebruiker van woningbouw (consumentgericht bouwen), met meer keuzevrijheid voor de bewoner in ontwerp en uitrusting van een woning en meer gebruiksflexibiliteit

27 27 voor de bewoner. Doel is om van de woningbouw een echte industrie te maken met een kwaliteitsniveau dat vergelijkbaar is met andere industrieën. In mei 2006 is dit platform gestart met het Mass Customisation EspritHuis Project. Hierbij wordt een methode ontwikkeld om aan eindgebruikers keuzevrijheid te bieden door aan hem vooraf geformuleerde en beprijsde keuzepakketten aan te bieden. In die methode krijgen toeleveranciers betere mogelijkheden om hun (innovatieve) producten direct bij de eindgebruiker te brengen, zonder dat de moeizame besluitvoming in de bouwkolom daarvoor drempels opwerpt. In dit project is het niet langer het bestek waarop toeleveranciers - meestal op basis van de laagste prijs - hun aanbieding doen. De toeleveranciers bepalen samen met de projectontwikkelaar de specificatie en de kopers-opties van de woning. Figuur 5.22 Voorbeeld van de contractuele relaties bij een partnering contractmodel Producenten Leveranciers Partneringovereenkomst (Onder)aannemers Gebruikers Architect(en) Opdrachtgever Partnering tracht in principe hetzelfde te bewerkstelligen als een alliantie. Partijen streven dezelfde doelen na. Het grote verschil tussen beide contractmodellen is het feit dat partnering gebaseerd is op een traditionele samenwerking waar risico s, winsten en verliezen verdeeld worden tussen de partijen in plaats van gedeeld. Bij partnering kent men daarom ook niet de gezamenlijke (financiële) stimuli die een alliantie wel kent. 1.8 Samenwerken Samenwerken: waarom? Eerder in de hoofdstuk is gezegd dat bouwen organiseren is. Bouwen is echter ook samenwerken. De praktijk laat zien dat samenwerken aan een bouwproject lang niet altijd betekent dat die samenwerking ook goed verloopt. Oorzaken hiervoor zijn vaak de niet samenvallende of soms tegenstrijdige belangen van opdrachtgever en opdrachtnemers. Soms vertrouwen ze elkaar niet volledig.