Handboek SE 9-11-2009-2

Systems Engineering in Projecten van VolkerInfraHandreiking voor het gebruik van Systems Engineering in projectorganisaties, in 3 delen: I Waarom Systems Engineering? II Wat is Systems Engineering? III Werken volgens Systems Engineering & Project Management

Document HistorieRevisie 0.4 1.0 2.0 Omschrijving/belangrijkste wijzigingen. Eerste uitgave onder documentnummer 3453-SE-001, ter review Commentaar reviewers verwerkt Commentaar reviewers verwerkt Datum 23-10-08 10-07-09 17-09-09

Ten geleide bij versie 2.0Vanwege de groeiende behoefte naar kennis en kunde met betrekking tot Systems Engineering (SE), die we kunnen toepassen binnen de projecten en binnen VolkerInfra, bieden wij u Systems Engineering in projecten van VolkerInfra aan.

Dit document is de basis voor de ontwikkeling van onze organisatie op weg naar een betere beheersing van projecten, door Systems Engineering en Projectmanagement methoden en technieken. Dit document ondersteunen wij in de vorm van presentaties, cursussen en workshops.

Namens de vakgroep Systems Engineering,

Marco Vos & Tufail Ghauharali

Vianen, November 2009

Project Documentnaam Documentnummer Revisie Status

: : : : :

Vakgroep Systems Engineering Systems Engineering in projecten van VI 8057-RAP-001 2.0 Definitief

VoorwoordAl geruime tijd verschuiven rollen en verantwoordelijkheden in de Nederlandse bouwsector. Opdrachtgevende partijen doen een stap terug en richten zich op hun kerntaak: het zorgen voor infrastructuurvoorzieningen die op de wensen van de samenleving en op elkaar zijn afgestemd. Opdrachtnemende partijen krijgen steeds meer verantwoordelijkheid in het totale proces, van initiatief tot sloop van bouwwerken. Deze tendens leidt tot gentegreerde contracten, waarin men niet alleen de bouw als technisch proces aan de marktpartijen vraagt, maar ook ontwerp, onderhoud en soms zelfs sloop.

Voor beheersing van de technische processen in een gentegreerd contract zijn nieuwe methoden nodig. Systems Engineering is als methode door opdrachtgevers gentroduceerd om integratieprocessen te kunnen beheersen. SE is een methode om een probleem gestructureerd aan te pakken en op te lossen binnen de gestelde termijn en het budget. In de zoektocht naar de meest optimale beheersing van gentegreerde contracten onderkent VolkerInfra het belang hiervan en verwoordt in dit document de basis van het werken met SE.

In dit document beschrijven we de manier waarop VolkerInfra de primaire processen in gentegreerde contracten beheerst. Afhankelijk van de contractvorm vallen ontwerp, realisatie, beheer en onderhoud en sloop in de primaire processen. We richten ons op een redelijk brede doelgroep. Iedereen die met een gentegreerd contract werkt, krijgt te maken met facetten van SE die beschreven worden in dit document.

Het document geeft geen gerichte oplossingen. Het is een handreiking om een beter inzicht te krijgen in hoe SE zich nu en de komende jaren ontwikkelt. Iedereen die deze handreiking volgt, draagt bij aan het verder ontwikkelen van SE als projectmanagementmethode binnen de bouwsector. Door het volgen van deze handreiking ontwikkelt men vanuit SE standpunt binnen de bouwsector een projectmanagement methode.

Ruud van Wijk

directeur VolkerInfra

Pag. 3 van 173


: : : : :


ColofonDit document kwam tot stand binnen de vakgroep Systems Engineering. Jan Bouwman (Volker Wessels Innovatie Management) leverde eveneens een waardevolle bijdrage door ons telkens te motiveren met zijn positief gestemde en opbouwende kritiek.

De vakgroep Systems Engineering bestaat uit de volgende personen:

ir. R. (Rob) Bender ir. T.G.F. (Tufail) Ghauharali ir. M.L. (Maarten) Stoutenbeek ir. J. (Johan) van den Tillaart ing. J.B. (Jasper) Plantinga ing. B. (Benjamin) Plante ing. R. (Remco) van Vliet ing. M.C. (Marco) Vos

De volgende personen hielpen mee aan dit document:

ir. R. (Rene) Beurze ing. J. (Jaap) Boneveld ir. H.A (Hermen) Breunissen ing. C.M. (Esther) van Eijk ing. J.S. (Jorik) Freeke, MSc. ing. G.L.J. (Edwin) de Graaf ir. J.S. (Jan Simon) de Koning ir. J. (Jeroen) Huiskamp ir. M.(Maarten) Voet ing. R. (Ruud) van Wijk

Pag. 4 van 173


: : : : :


Management SamenvattingIn dit document beschrijven we hoe de principes van Systems Engineering (SE) te verenigen zijn met de projectmanagement aanpak van VolkerInfra (VI). SE zorgt voor de beste kwaliteit, terwijl het bij projectmanagement vooral gaat om het beheersen van risicos, tijd, geld, informatie en organisatie. SE pakt een probleem van belanghebbenden integraal en methodisch aan. Dit leidt tot een duurzame, maatschappelijk verantwoorde oplossing, in de vorm van een systeem dat voldoet aan de verwachtingen en blijft functioneren. Inleidend op toepassingen van SE, lichten we kort de aanleiding voor het werken met SE in de grond-, wegen waterbouw (GWW) (deel I), en de achtergrond van SE (deel II) toe.

Dit document bestaat uit drie delen. In deel I gaan we in op de vraag waarom de bouwsector SE toepast en de visie van VI hierop. SE wordt toegepast zodra er een verschuiving van rollen en verantwoordelijkheden plaatsvindt. Opdrachtgevers doen een stap terug en specificeren hun vraag zo functioneel mogelijk. Opdrachtnemers krijgen door deze vraagstelling meer verantwoordelijkheid in het totale proces: van initiatief nemen tot en met de bouw en soms ook onderhoud. Door deze verschuiving van verantwoordelijkheden hebben de OG en de ON behoefte aan een eenduidige beheersmethode van de huidige projecten. Typerend voor de verschuiving is de integratie van ontwerpen realisatieprocessen enerzijds en het integrale karakter van de projecten anderzijds. Het integrale karakter kenmerkt zich door de samenwerking tussen de disciplines: wegen, spoorwegen, betonwerken en technische installaties. Door de verschuiving ontstaat een nieuwe uitdaging in de vorm van gentegreerde contracten voor zowel de ON als de OG in de bouwsector. SE beheerst de gentegreerde contracten.

In deel II beschrijven we de achtergrond van SE en de begrippen die van belang zijn om een goed beeld van SE te ontwikkelen. Het is een probleemoplosmethode, gebaseerd op het systeemdenken. Het systeemdenken gaat er vanuit dat een systeem bestaat uit een verzameling elementen en een verzameling relaties tussen de elementen. (Deel II, hoofdstuk 4).

In de huidige bouw richt men zich vaak alleen op de elementen (zoals vakdisciplines) en vergeet men de relaties bijna. Het gaat mis als de elementen niet samenwerken en de prestaties van het systeem als geheel niet meer te overzien zijn. Veel van de huidige problematiek in de bouwsector heeft met dit probleem te maken. Dit komt voort uit het gebrek aan inzicht in het systeemdenken.

Pag. 5 van 173


: : : : :


Als afgeleide van het systeemdenken gaat SE in op de processen die men doorloopt tijdens de ontwikkeling van een systeem. Dit zijn bijvoorbeeld het proces functionele-analyse, het verificatieproces of de stakeholdersanalyse. Hierbij definiren we de activiteiten binnen een proces en de overgangen tussen de processen. We beschrijven deze processen zo precies mogelijk, door de definitie, het doel, de relatie met andere processen en veel voorkomende problemen toe te lichten. SE gaat dus vooral in op de wat-vraag: Wat moet er gebeuren om een systeem succesvol te ontwikkelen, te beheren, te onderhouden en zelfs te slopen? Het integrale ontwerpproces geeft antwoord op de hoe-vraag, met als hoofddoel het ontwerpen van een effectief en duurzaam systeem, dat blijft voldoen aan de behoeften van de veranderende wereld. Dit onderdeel is summier beschreven. Het ontwerpproces is een vak op zich en valt buiten de kaders van dit document. Belangrijk is dat men in de ontwerpfase verschillende processen doorloopt, die een relatie hebben met SE. Deze processen worden beschreven in dit document.

Deel III beschrijft SE in relatie tot projectmanagement. Belangrijke aandachtspunten zijn de verschillende fasen van een project, van projectaanpak tot projectafsluiting. We zetten voor de verschillende fasen uiteen welke activiteiten er in relatie tot SE in een project noodzakelijk zijn. Door het noteren van noodzakelijke activiteiten is meteen het verband tussen SE en de overige processen in een project duidelijk. Denk aan planning, risicobeheersing, kostenbeheersing, maar ook ontwerp, realisatie, onderhoud en sloop. De beschreven aanpak vormt hierdoor input voor de bedrijfsvoeringsystemen van de betrokken werkmaatschappijen van de infrabedrijven VolkerWessels.

Pag. 6 van 173


: : : : :


InhoudsopgaveVOORWOORD ________________________________________________________________ 3

MANAGEMENT SAMENVATTING ____________________________________________________ 5

DEEL I 1. 1.1 1.2. 1.3. 2. 2.1 2.2 2.3 2.4 3. 3.1 3.2

WAAROM SYSTEMS ENGINEERING? _______________________________________ 9 SYSTEMS ENGINEERING IN DE BOUWSECTOR VOOR VOLKERINFRA__________ 10 Inleiding ________________________________________________________________ 10 Kaderstelling ____________________________________________________________ 11 Leeswijzer ______________________________________________________________ 12 VERANDERINGEN IN DE BOUWSECTOR ___________________________________ 13 De periode tot 1990: het RAW bestek _________________________________________ Omstreeks 1993: de kwaliteitsnorm ISO 9001___________________________________ Rond het jaar 2000: het prestatiebestek _______________________________________ De situatie vanaf 2004: het gentegreerd prestatiecontract _________________________ 13 14 15 17

TOEKOMSTVISIE BOUWSECTOR _________________________________________ 19 Van aannemer naar (bouw)partner ___________________________________________ 19 VolkerInfra als bouwpartner _________________________________________________ 22

DEEL II 4. 4.1 4.2 4.3 4.4 5. 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 5.15 5.16 5.17 5.18

WAT IS SYSTEMS ENGINEERING? ________________________________________ 24 INLEIDING TOT SYSTEMS ENGINEERING IN DE BOUWSECTOR _______________ 25 Systeemdenken __________________________________________________________ Systems Engineering ______________________________________________________ Integraal ontwerpen _______________________________________________________ Expliciet werken __________________________________________________________ Configuratiebeheer________________________________________________________ Complexiteit _____________________________________________________________ Decompositie ____________________________________________________________ Raakvlakanalyse en -beheersing _____________________________________________ Aspectsystemen__________________________________________________________ Stakeholdersanalyse ______________________________________________________ Procesanalyse ___________________________________________________________ Functie analyse __________________________________________________________ Programma van Eisen (PvE) ________________________________________________ Eisenanalyse (groei van het PvE) ____________________________________________ Objectenstructuur (SBS) ___________________________________________________ Basis Objecten Bibliotheek (BOB) ____________________________________________ BAB (Basis Activiteiten Bibliotheek)___________________________________________ Het Project Activiteitenmodel (PAM) __________________________________________ De WBS (Work Breakdown Structure) _________________________________________ Organisatiestructuur (OBS) _________________________________________________ Verificatie _______________________________________________________________ Validatie ________________________________________________________________ 25 28 31 36 39 42 45 47 50 52 54 56 58 61 64 68 70 72 74 80 82 84

ALGEMEEN BEGRIPPENKADER SYSTEMS ENGINEERING ____________________ 38

Pag. 7 van 173

Project Documentnaam Documentnummer Revisie Status DEEL III

: : : : :


WERKEN VOLGENS SYSTEMS ENGINEERING & PROJECTMANAGEMENT ______ 86

ONDERDEEL A. OPSTARTEN ____________________________________________________ 90 6. 7. 8. 9. 10. PROBLEEMANALYSE ___________________________________________________ 94 STAKEHOLDERS ANALYSE ______________________________________________ 96 PROJECTINITIATIE ____________________________________________________ 100 PLANNEN MAKEN _____________________________________________________ 101 DOCUMENTENMANAGEMENT___________________________________________ 102

ONDERDEEL B. REALISEREN___________________________________________________ 104 11 12. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. ANALYSE WERKPAKKET _______________________________________________ 107 VERIFICATIEPLANNEN OPSTELLEN ______________________________________ 110 UITVOEREN WERKPAKKET _____________________________________________ 113 FUNCTIONEEL ONTWERP ______________________________________________ 114 RUIMTELIJK ONTWERP ________________________________________________ 119 CONSTRUCTIEF ONTWERP_____________________________________________ 124 REALISATIE __________________________________________________________ 127 BEHEER EN ONDERHOUD ______________________________________________ 130 SLOOP ______________________________________________________________ 132 VERIFICATIERAPPORTEN OPSTELLEN ___________________________________ 134 ASPECT MANAGEMENT ________________________________________________ 136 RISICOMANAGEMENT _________________________________________________ 138 TIJDMANAGEMENT ____________________________________________________ 139 KOSTENMANAGEMENT ________________________________________________ 140 WIJZIGINGENMANAGEMENT ____________________________________________ 141

ONDERDEEL C. AFRONDEN ____________________________________________________ 142 27. 28. AFLEVERPAKKET _____________________________________________________ 144 OPLEVERDOSSIER ____________________________________________________ 145

LITERATUURLIJST______________________________________________________________ 146 BEGRIPPENLIJST ______________________________________________________________ 147 BIJLAGE 1 PROCESSCHEMAS____________________________________________________ 154 BIJLAGE 2 CONTRACTVORMEN___________________________________________________ 167

Pag. 8 van 173


: : : : :


DEEL I

WAAROM SYSTEMS ENGINEERING?

Pag. 9 van 173


: : : : :


1.1.1

Systems Engineering in de bouwsector voor VolkerInfraInleiding

De Nederlandse bouwsector was tot begin deze eeuw gewend te werken met gescheiden disciplines, gericht op realisatie van bouwwerken. Van oudsher zijn projecten in andere sectoren altijd integraal en multidisciplinair. Door een verschuiving van rollen en verantwoordelijkheden, kwam er een eind aan het monodisciplinair werken aan n fase van een project. Deze verschuiving wordt gekenmerkt door integratie van processen als ontwerp en realisatie enerzijds en het integrale karakter van de projecten anderzijds. Het integrale karakter blijkt uit de samenwerking tussen de disciplines: wegenbouw, civiele werken en technische installaties. Hierdoor ontstond een nieuwe uitdaging voor zowel de ON als de OG in de bouwsector, in de vorm van gentegreerde contracten. Het werken met een gentegreerd contract kenmerkt zich door een uitvraag, waarbij meerdere processen en disciplines gentegreerd zijn in n contract. Om de processen (onder andere ontwerp, voorbereiding, realisatie en beheer en onderhoud) in n gentegreerd contract te beheersen, heeft de OG en de ON behoefte aan een eenduidige methode. De OG heeft de methode SE aangedragen om de processen in n gentegreerd contract te beheersen. In het kort is de methode SE een systematische manier om op een bestuurbare wijze oplossingen te creren die functioneren, voldoen aan de eisen en wensen van de klant en binnen de gestelde tijd en het budget gerealiseerd zijn.

VI past een aansluitende manier van werken toe, waarbij structurering en beheersing van informatie en werkmethoden van groot belang is. De manier van werken is gericht op de gentegreerde contractvorming De wijze waarop men projectinformatie zoals eisen, objecten, risicos et cetera beheerst, bepaalt in grote mate het slagen van een project (zie Figuur 1).

Figuur 1 SE samenhang

Pag. 10 van 173


: : : : :


Naast het structureren, beheersen en onderkennen van onderlinge afhankelijkheden van die informatie, gaat het om de wijze waarop men deze informatie communiceert. Communicatie is een van de moeilijkste aspecten binnen een project. Voor daadwerkelijke integratie tussen verschillende disciplines, is intensieve samenwerking in plaats van zogenaamde eilandwerken en bijbehorende eilanddenken noodzakelijk.

In dit document zetten we een doelmatige aanpak en werkwijze volgens de SE methode neer, met als doel gentegreerde processen, integratie van disciplines en hiermee gentegreerde contracten beter te sturen en beheersen.

1.2.

Kaderstelling

Een organisatie kent verschillende besturingsniveaus, waarbinnen een voorgestelde verandering plaatsvindt. Als het om een raamwerk gaat over verandering van werken, gericht op een gentegreerde procesketen, is aandacht voor elk niveau van belang. Vul het raamwerk daarom volledig en eenduidig in. Dit document staat derhalve niet op zichzelf.

De behoefte aan een gentegreerde projectaanpak blijkt uit de visie en strategie. In de visie en strategie besteden we aandacht aan vragen als, wat moeten we intern doen om de nieuwe externe richting te bepalen?, Welk soort mensen hebben we nodig?, Welke nieuwe middelen hebben we nodig en hoe moeten we de structuur en cultuur aanpassen?

Een niveau lager, ook wel het tactisch niveau (gericht op de nabije toekomst) genoemd, vullen we de plannen in en wijzen we mensen en middelen toe aan organisatiedelen, die een bepaalde resultaatverplichting hebben. Verder sturen we de activiteiten aan, door deze verder uit te werken en in een kader te plaatsen. Dit document is gericht op dit niveau.

Onder het tactisch niveau bevindt zich het operationele niveau, gericht op kunde en operationeel handelen. Op dit niveau worden de beschreven activiteiten in dit document uitgevoerd en gevalueerd. De lijst met veel voorkomende problemen (opgenomen in elk hoofdstuk van deel II) toetsen we en vullen we aan. We geven zo goed mogelijk antwoorden op praktische vragen en werken we n of meerdere SE praktijkvoorbeelden van projecten uit.

Op het laatste niveau, kennis en institutioneel handelen genoemd, borgen we de kennis van het werken met gentegreerde contracten en ontwikkelen we deze kennis in de organisatie. De vereiste kennis behandelen we in latere revisies van dit document. Daarnaast nemen we de integrale werkwijze op in het bedrijfsvoeringssysteem (BVS-systeem) van VI. Pag. 11 van 173


: : : : :


1.3.

Leeswijzer

Dit document bestaat uit drie delen, elk met een specifiek doel.

Deel I

Waarom SE?

Geeft een algemeen beeld van de aanleiding voor SE in de bouw en de voortvloeiende veranderingen van de gebruikelijke werkwijze. Hiernaast staan we stil bij de visie van VI op gentegreerde contracten.

Deel II

Wat is SE?

Geeft aandacht voor begripsvorming en is gericht op de beginnende lezer, met interesse in SE. We geven een korte introductie van het begrip SE binnen de bouw, inclusief het doel, nut en de noodzaak ervan. Binnen deze context definiren we de relevante begrippen.

Deel III

Werken volgens SE en PM Bestemd voor de projectmedewerker en gericht op het toespitsen van SE op het werk in de projecten. We leggen bijvoorbeeld uit welke rol SE binnen een project speelt en met welke activiteiten we deze rol invullen.

Pag. 12 van 173


: : : : :


2.

Veranderingen in de bouwsector

In dit hoofdstuk lichten we de aanleiding voor de verandering van rollen in de bouwsector toe. 2.1 De periode tot 1990: het RAW bestek

Tot 1990 leverde de Opdrachtgever (OG) in de bouw een RAW bestek en tekeningen aan. Het bestek is een nauwkeurige technische omschrijving van het uit te voeren werk, inclusief de bijbehorende administratieve en juridische bepalingen (standaard UAV). Het beschrijft de eisen van het te realiseren bouwwerk. Tevens zijn er tekeningen gekoppeld aan het bestek, de zogenaamde bestektekeningen.

De OG verzorgde het gehele voortraject (vergunningen, kostenramingen, ontwerp et cetera) en vertaalde dit in bestekken en een bestektekening die gereed voor uitvoering was. De Opdrachtnemer (ON) voerde zijn werkzaamheden uit onder toezicht van de OG, geheel conform het bestek en de tekeningen. De ON voerde alleen uit wat de OG bedacht en uitgewerkt had. Het werk was doorgaans opgedeeld in drie disciplines (civiele werken, wegenbouw en technische installaties), die elk conform een eigen bestek werkten. Het was tot 1990 normaal dat er aan n project minimaal drie aannemers (n per discipline) werkten.

Pag. 13 van 173


: : : : :


2.2

Omstreeks 1993: de kwaliteitsnorm ISO 9001

Omstreeks 1993 werd de kwaliteitsnorm NEN/EN/ISO 9001 gentroduceerd in de bouw. Dit is een serie standaarden van het ISO instituut waarin vastgelegd was hoe een organisatie de kwaliteit kon waarborgen. De ON voerde zijn werk nog steeds conform bestek en tekeningen uit, maar eiste dat de kwaliteit van het werk voldeed aan de volgens de norm gestelde eisen. Dit betekende dat kwaliteitsen keuringsplannen opgesteld en nageleefd werden.

Figuur 2 geeft de situatie omstreeks 1993 grafisch weer. De driehoek stelt het te ontwikkelen product voor, dat opgedeeld kan worden in verschillende niveaus van systeem tot element. We zien in de RAW bestekken dat het contractniveau (het niveau waarop de eisen worden gesteld) en het standaardisatieniveau (het niveau waarop producten gestandaardiseerd worden) op het laagste niveau is. Het product is al top-down ontwikkeld en gespecificeerd, de ON bouwt alleen. Met top down bedoelen we van boven naar beneden. Men start met een algemeen principe (doel, functie, systeem). Dit systeem deelt men vervolgens op in delen, uitgewerkt tot het niveau waarop men de bijbehorende producten bouwt. Er is geen ruimte voor standaardproducten. Elk product is tot op elementniveau gespecificeerd. De ON maakt bij elk project unieke producten.

Figuur 2 Top-down RAW bestek

Pag. 14 van 173


: : : : :


2.3

Rond het jaar 2000: het prestatiebestek

Het prestatiebestek, of beeldbestek, vervangt aan OGs zijde langzaam het traditionele RAW bestek. Hierin staan technische, functionele en cosmetische eisen en tekeningen.

De algemene definitie van prestatiebestek luidt: Een prestatiebestek is een bestek waarin de opdrachtgever voor een uit te voeren werk de beginsituatie en de gewenste eindsituatie beschrijft, met behulp van zogenaamde prestatie-eisen. Hij vermeldt daarbij de administratieve en juridische voorwaarden en overige (rand)voorwaarden die hij in acht hoort te nemen .1

Een prestatiebestek beschrijft niet de activiteiten die ON moet verrichten en vermeldt geen hoeveelheden. Dit is anders dan het RAW bestek. In deel III Technische bepalingen beschrijft het RAW bestek het realisatieproces. De ON bepaalt dus zelf, met inachtneming van de gestelde (rand)voorwaarden, de te verrichten activiteiten, de frequentie en tijdstippen waarop die activiteiten plaatsvinden en de hoeveelheden van benodigde bouwstoffen en dergelijke om de gewenste eindsituatie te bereiken.

Figuur 3 geeft de gedachte achter het prestatiebestek grafisch weer. Op elementniveau (bijvoorbeeld heipalen) is standaardisatie mogelijk, omdat het contract de vrijheid biedt om op dat niveau zelf specificaties en detailtekeningen op te stellen.

Hoofdwegennet

systeem

Weg

subsysteem

Verharding Standaardisatieniveau

component Contract

Deklaag

element

Top-down Prestatiebestek Figuur 3 Top-down prestatiebestek

1 RWS (2004), Handreiking bij het model Prestatiebestek onderhoud droog versie 3. Pag. 15 van 173


: : : : :


In 2000 doet ook de Externe Kwaliteitsborging (EKB) aan ONs kant op verzoek van de OG zijn intrede. De Onafhankelijk Functionaris Aannemer (OFA) is verantwoordelijk voor een onafhankelijke: controle van tekeningen, berekeningen en constructies van de ON; inspectie met betrekking tot uitvoering en veiligheid, alsmede rapportage hiervan.

De EKB toont aan de hand van kwaliteitsen keuringsplannen op systematische en beheerste wijze aan dat de te bouwen producten voldoen aan de daarvoor gestelde eisen. De ON stelt zelf specificaties en detailtekeningen op en kwantificeert en beperkt de risicos (en eventuele schade die uit deze risicos voortvloeit).

Pag. 16 van 173


: : : : :


2.4

De situatie vanaf 2004: het gentegreerd prestatiecontract

Vanaf 2004 vervangt het prestatiecontract het prestatiebestek aan OGs zijde (consumentenzijde). Het werken met het prestatiecontract stelt eisen op wisselende niveaus (zie contractniveau Figuur 4). De bijbehorende gentegreerde contractvormen zijn onder andere: D&C (Design & Construct), E&C (Engineering & Construct) en DBFMO (Design, Build, Finance, Maintain, Operate). Hierbij voert de ON (de producent) zowel de ontwerp- als de realisatiewerkzaamheden uit.

Figuur 4 Top-down DBFM(O)

Figuur 4 geeft de gedachte achter het gentegreerde contract weer. Aan de zaagtand die het eisniveau in het contract voorstelt, zien we dat het eisniveau per discipline varieert. De disciplines staan in het figuur loodrecht op het eisniveau. Op verschillende niveaus moeten de te ontwikkelen objecten voldoen aan eisen.

Het standaardisatieniveau is nog steeds op elementniveau en de vraag is nog steeds top down gestuurd. Om het complexer te maken, bevatten de eisen in het contract vaak ook al oplossingen.

Pag. 17 van 173


: : : : :


Deze situatie gebruiken we als vertrekpunt voor dit document. Het beschrijft een werkwijze waarmee men in huidige en toekomstige situaties projecten beheerst. Sinds de invoering van dit document gebruiken we systeemgerichte contractbeheersing (SCB) voor het beheersen van gentegreerde contracten. De OG gebruikt het kwaliteitsmanagementsysteem van de ON om de ontwikkeling van de oplossing te toetsen en de oplossing zelf te beheersen. In het kort is SCB gebaseerd op de volgende uitgangspunten: 1. De verantwoordelijkheid voor het voldoen aan de eisen, zoals opgenomen in de overeenkomst ligt bij de ON; 2. OG kiest bewust voor een rol op afstand. Er is minimale bemoeienis met de invulling van het projectmanagement en kwaliteitsmanagement door de ON; 3. ON toetst het naleven van de contractuele verplichting door het uitvoeren van een geplande mix van systeem-, proces- en producttoetsen.

De ON is verantwoordelijk voor het: Verder uitwerken van de eisen, indien nodig; Traceerbaar en objectief aantoonbaar ontwikkelen van een oplossing, waarbij de ON rekening houdt met interne en externe randvoorwaarden (respectievelijk raakvlakken binnen het systeem, tussen disciplines en met de omgeving).

Dit betekent dat bij de ON veel verantwoordelijkheden liggen. In de huidige contracten is de oplossing vaak al in de eisen opgenomen, waardoor het voor de ON lastig is om die verantwoordelijkheid over te nemen. Dit is vanuit het RAW denken een logisch gevolg. Bij een gentegreerd contract kan de ON niet verantwoordelijk zijn voor een oplossing die door een ander is bedacht.

Door het hebben van een gentegreerd contract etaleert de ON weinig van zijn toe te voegen waarde en blijft de ON zich alleen richten op het bedenken van slimme realisatieoplossingen. De branche blijft door deze beperking achter met het standaardiseren van objecten. Men pakt ieder project als prototype aan, waardoor de transactiekosten hoog blijven.

De bouwsector groeit naar een situatie, die vergelijkbaar is met de normale consumentenmarkt. In deze consumentenmarkt presenteert de ON eigen oplossingen, standaardiseert oplossingen en innoveert om de problemen op te lossen, die de consument ervaart en benoemt. Het afleggen van deze weg gaat gepaard met vallen en opstaan.

Pag. 18 van 173


: : : : :


3.

Toekomstvisie bouwsector

In dit hoofdstuk schetst VI haar toekomstvisie op de veranderende bouwsector en kijkt door de ogen van de ON en de OG naar de groei van ambtelijke bouwer naar betrouwbare bouwpartner.

3.1

Van aannemer naar (bouw)partner

We belichten drie aspecten van de groei naar bouwpartner: 1. de vraag van de OG die is vastgelegd in een probleembeschrijving, oplossingsruimte (ontwerpruimte) en een wensenpakket; 2. 3. bottom-up productontwikkeling door de ON; werken met multidisciplinaire werkpakketten door de ON.

3.1.1 Probleembeschrijving, oplossingsruimte en wensenpakket Aspect 1 beschrijft het probleem van de OG met een oplossingsruimte en een pakket wensen. De OG moet het probleem of de ongewenste situatie vertalen naar een doelstelling. Deze doelstelling omvat de oplossing of gewenste situatie, uitgedrukt in waarden in het systeem dat door de ON ontwikkeld en geleverd wordt. Deze waarden zijn bijvoorbeeld gericht op: de functies die vervuld moeten worden (bijvoorbeeld transportcapaciteit); het uiterlijk (esthetica) (bijvoorbeeld afwerkingswaarde); het technisch functioneren (bijvoorbeeld energiegebruik).

De OG moet deze waarden vertalen naar eisen, randvoorwaarden en wensen. Ze zijn uitgezet op de verticale as van Figuur 5. De OG geeft ook de minimale kosten (om prijsduikers te voorkomen) voor het project en het budget (de plafondprijs). Dit is op de horizontale as opgenomen. De opgespannen ruimte tussen minimale eisen en randvoorwaarden enerzijds en minimale kosten en budget anderzijds noemen we de oplossingsruimte . Binnen deze ruimte ontwikkelen aanbieders/ONs een oplossing. waarde randvoorwaarde2

minimale eis kosten minimale kostenFiguur 5 De oplossingsruimte

budget

2 De Ridder, H.A.J. (2007); Living building concept for adding value in an unpredictable future Pag. 19 van 173


: : : : :


Het voordeel van een vraagspecificatie door middel van wensen en oplossingsruimte, is dat ON de ruimte krijgt een oplossing te zoeken voor het probleem. Hij specificeert deze oplossing zelf, in plaats van dat hij een vooraf volledig gespecificeerde oplossing uitwerkt. Het zoeken van de juiste oplossing voor een specifiek probleem voeren we uit volgens de principes van SE. Deze principes behandelen we in Deel II. 3.1.2 Bottom-up productontwikkeling Het tweede aspect van de groei naar bouwpartner is bottom-up productontwikkeling. Dit is het tegenovergestelde van top-down. Top-down houdt in dat van algemeen naar specifiek gewerkt wordt. Dit betekent dat men bij elk project de ontwikkeling van het systeem volledig van boven naar beneden doorloopt. Bottom-up ontwikkeling start onderaan, met de standaardproducten die men al jaren bouwt. Deze producten brengt men vervolgens samen tot een systeem dat specifiek wordt gemaakt voor het projectdoel. Hierbij past men de kracht van innovatie en verbetering toe, om de meest effectieve oplossing voor het probleem te vinden en te realiseren. De werkwijze is veranderd.

Gentegreerde contracten met een oplossingsruimte zorgen voor een normale situatie in de bouw. Dit is mogelijk als de ON de vrijheid krijgt om zijn producten bottom-up te ontwikkelen, te standaardiseren en vervolgens met relatief weinig inspanning specifiek kan maken voor het project. De voordelen hiervan zijn: betere en goedkopere oplossingen, omdat de ON het geleverde product ontwikkelt, test en gebruikt. De ON bezit dus alle benodigde kennis van het product om het aan te bieden; de ON krijgt de kans aan productontwikkeling en innovatie te doen. Normaal gesproken maakt de ON voor elk project unieke producten. Productontwikkeling en innovatie leidt tot lagere transactiekosten.

Figuur 6 geeft de toekomstvisie grafisch weer.

Figuur 6 Toekomstvisie vanuit een bottom-up gestuurde vraag

Pag. 20 van 173


: : : : :


3.1.3 Multidisciplinaire werkpakketten Aspect drie van de toekomstvisie bundelt het werk van verschillende disciplines en minimaliseert de raakvlakken. Op dit moment zijn de disciplines in de bouw gescheiden in specialistische werkmaatschappijen of bedrijven. Bij een gentegreerd contract knipt de ON het contract op en verdeelt hij de werkzaamheden over de benodigde disciplines. Deze disciplines zijn vervolgens middels raakvlakkenbeheer aan elkaar verbonden. Dit is geen ideale oplossing, aangezien raakvlakken in een project zoveel mogelijk geminimaliseerd moeten worden. Een raakvlak is volgens velen de plek waar het mis gaat. Elke discipline werkt met een eigen fasering. Een eigen fasering veroorzaakt aantoonbare problemen binnen een project. Ontwerpen die qua uitwerkingsniveau niet op elkaar aansluiten en geen uniform gebruik van maatvoering hebben, leiden tot serieuze problemen in projecten.

Om dit te voorkomen werkt men met werkpakketten werken die multidisciplinair van opzet zijn. Een werkpakket is een bundeling van activiteiten, met een gedefinieerde input en output. Door met werkpakketten te werken, regelt men een aantal zaken: men creert zo min mogelijk raakvlakken in het project, omdat men bij de bundeling uitgaat van zo min mogelijk raakvlakken met andere werkpakketten; faseringsproblemen komen explicieter aan de orde in een werkpakket en worden eenvoudiger opgelost daardoor; een werkpakketeigenaar is verantwoordelijk voor de voortgang, in termen van tijd en geld, voor het werkpakket.

Pag. 21 van 173


: : : : :


3.2

VolkerInfra als bouwpartner

Om het tweede aspect van de toekomstvisie (bottom-up productontwikkeling bij de ON) verder vorm te geven, staan we in deze paragraaf stil bij de ontwikkeling van VI als bouwpartner.

VI verwacht dat in de toekomst steeds vaker zelfstandig oplossingen worden ontwikkeld, gespecificeerd en gegarandeerd voor de problemen die de OG aandraagt.

De ontwikkeling van de branche, vanuit het RAW denken, naar het beantwoorden van een functioneel gespecificeerde vraag, kan worden beschreven met groeimodellen. Een vaak gebruikt model is de CMMI (Capability Maturity Model Integration) .Tabel 1 geeft de verschillende niveaus in een organisatie/project aan, binnen projectbeheersing. De focus ligt nu op niveau 2: basisprojectbeheersingsvaardigheden. Zaken als eisenbeheersing, configuratiebeheersing (ook wel scopebeheersing genoemd) en (sub)contractbeheersing komen hier aan de orde. Voor VI en de OG ligt de uiteindelijke focus op continue procesverbetering, aangestuurd door procesmanagement.3

Tabel 1 Ontwikkelingscurve voor projectbeheersing Niveau 5 Focus Continue proces verbetering 4 Kwantitatief Management Procesgebieden Proceswijzigings management Voorkomen van defects Technologischwijzigingsmanagement Kwantitatief projectmanagement Systeem Kwaliteit Management Performance van de organisatieprocessen 3 Proces Standaardisatie Verificatie, Validatie Risicomanagement Eisen ontwikkeling, en ontwerp afwegingen 2 Basis project Management (sub)contractmanagement Configuratiemanagement Eisenmanagement 1 Initieel

3; Carnegie Mellon Software Engineering Institute (2002), Capability Maturity Model Integration. Pag. 22 van 173


: : : : :


De CMMI methode helpt organisaties die actief invulling willen geven aan continue prestatieverbetering door middel van procesverbetering. CMMI bevat een set van eisen, afgeleid uit succesvolle praktijkervaringen. Aan de hand van deze eisen professionaliseren organisaties hun processen stapsgewijs. Een groot aantal organisaties implementeerde wereldwijd met veel succes het CMMI en bracht significante prestatieverbeteringen tot stand.

Figuur 7 CMMI niveaus

Het basisconcept van CMMI is dat organisaties hun processen verbeteren volgens een groeimodel. CMMI kent vijf niveaus (zie Figuur 7). Het laagste niveau stelt geen eisen. De processen zijn ongestructureerd en verlopen chaotisch. Succes is daardoor grotendeels afhankelijk van individuen. Op niveau 2 wordt de basisbeheersing van processen en projecten ingericht.

De processen bij de ON in de bouwsector verlopen over het algemeen op het eerste en tweede niveau. De vroegere primaire processen, ontwerp of voorbereiding en realisatie, zijn per discipline wel op orde. Wat nog wel te wensen overlaat is de integratie met enerzijds de nieuwe processen als stakeholders analyse, integraal ontwerpen, beheer en onderhoud en anderzijds de overige disciplines.

Niveau 3 definieert en onderhoudt de processen organisatiebreed. Projectprocessen worden op een gestructureerde en consistente manier afgeleid van de organisatiebrede standaardprocessen. Dit is het niveau waar VI met dit document naar toe wil: het standaardiseren van processen en vervolgens ook van producten.

Niveau 4 bestuurt processen op basis van kwantitatieve gegevens.

Op niveau 5 verbetert de organisatie haar processen continu. Op basis van de gebruikservaring met de standaardprocessen en -producten, worden de processen continu verder geoptimaliseerd. Door technisch en marktonderzoek profileert VI zich als professionele partner in het bouwproces.

Door te voldoen aan de CMMI-criteria tot en met niveau 5 verbetert VI haar procesvaardigheid. Hierdoor verbetert het bedrijfsresultaat: we leveren een hogere kwaliteit en lagere kosten met kortere doorlooptijden en hogere voorspelbaarheid. Pag. 23 van 173


: : : : :


DEEL II

WAT IS SYSTEMS ENGINEERING?

Pag. 24 van 173


: : : : :


4.

Inleiding tot Systems Engineering in de bouwsector

Dit hoofdstuk geeft een algemene inleiding tot Systems Engineering (SE) in de bouw. Eerst leggen we het systeemdenken uit. Daarna gaan we in op SE als werkwijze voor procesbeheersing en overgang en vervolgens beschrijven we het integrale ontwerpproces.

4.1

Systeemdenken

n van de grondbeginselen van SE is de toepassing van het systeemdenken. Dit systeemdenken gaat uit van het zogenaamde holisme. Het Engelse woord whole betekent geheel of eenheid Een systeem is een verzameling elementen en een verzameling relaties tussen de elementen. De relaties tussen de elementen staan centraal, omdat het functioneren van het systeem niet terug te brengen is naar de elementen. Het functioneren van het systeem is wel terug te brengen naar de relatie. De relatie is de manier waarop de elementen met elkaar samenwerken. Vanuit deze gedachte is een systeem per definitie niet decomponeerbaar, omdat de relaties doorsneden worden. In de praktijk worden systemen wel gedecomponeerd, maar met voldoende aandacht voor de relaties.

Systeemdenken is een manier van denken, een manier van kijken naar dingen. Systeemdenken op zichzelf lost geen enkel probleem op. Het is een hulpmiddel, waarbij alle bestaande disciplines hun eigen deelbijdrage moeten blijven leveren in het geheel voor de oplossing van een probleem. 4.1.1 Systemen De elementen en relaties hebben een gezamenlijk doel en soms relaties met andere elementen uit de totale werkelijkheid.

Een systeem stelt VI voor als: iets interns (bijvoorbeeld de projectorganisatie); iets externs, het bouwwerk zelf (bijvoorbeeld een wegenknooppunt, het spoorwegnet in Nederland, de brug in gemeente X); een soort metasysteem: namelijk de levensloop van het bouwwerk, ongeacht het doel.

Let wel: alle drie interpretaties voldoen aan de definitie. Er is dus geen sprake van goed of fout. Toch kan de driedeling een bron van verwarring zijn. Wat is bijvoorbeeld SE in deze drie gevallen?

Pag. 25 van 173


: : : : :


SE is in het eerste geval een methode om gentegreerde contracten te ontwikkelen en te beheersen. Bij SE staat de organisatie van het project centraal. In het tweede en derde geval is het de ontwikkeling van een bouwwerk dat (blijvend) aan de behoefte van de klant voldoet. In het vervolg van dit document hanteren we de derde voorstelling van systeem: het systeem staat voor en metasysteem, de levensloop van het bouwwerk. 4.1.2 Systeembegrippen Om een goed begrip van systemen en SE te krijgen, beschrijft deze paragraaf enkele basis systeembegrippen (bron: In t Veld, 2002). Elementen

Dit zijn de kleinste delen van het bouwwerk. Deze zijn van belang voor het project. Hierachisch gezien bestaat een systeem uit subsystemen. De subsystemen bestaan uit componenten en de componenten bestaan uit elementen. Dat betekent dat zowel een systeem, als een subsysteem, als een component verzamelingen van elementen zijn. Als een weg van A naar B een systeem is, zijn bijvoorbeeld de kunstwerken subsystemen, het brugdek van een kunstwerk is een component en een element is de ligger in een brugdek.

Let op! Deze niveaus zijn niet absoluut, maar gelden als richtlijn. Het gaat om hirarchie en niet om de benamingen. Het komt voor dat niveaus andere benamingen hebben. In dit document kiezen we voor de volgende benamingen van niveaus en hirarchie (zie Figuur 8).

Figuur 8 Systeembegrippen

Pag. 26 van 173


: : : : :


Eigenschappen

Elk element heeft bepaalde eigenschappen, zoals fysische, geometrische, esthetische et cetera. De ligger van een brugdek heeft bijvoorbeeld een bepaalde vorm en afwerking en een bepaalde lengte, breedte, hoogte en gewicht. Relaties

Tussen de elementen bestaan relaties. In een weg van A naar B is een wisselwerking of interactie tussen de elementen. Ze benvloeden elkaar. Als een ligger in een brugdek zwaarder wordt, heeft dat effect op bijvoorbeeld het element heipaal. De heipaal draagt dan een groter gewicht af. Complexiteit

Complexiteit is het tegenovergestelde van onafhankelijk. Het gedrag van een complex systeem wordt onder andere gekenmerkt door de afhankelijkheid tussen de elementen. Hoe meer elementen van elkaar afhankelijk zijn, hoe complexer het systeem. Doel

Het doel is hetgeen we willen bereiken met een systeem. Bijvoorbeeld afname van filedruk. Functie

De functie van een element is datgene wat dat element teweeg brengt. Een element is geen functie, maar heeft een functie. De functie van een weg is bijvoorbeeld het ondersteunen en geleiden van het verkeer. Proces

Een proces wordt gekenmerkt door input, output en uit te voeren activiteiten. In een systeem onderscheiden we drie soorten processen: bewerkende processen dragen direct bij aan de invoer, aan de transformaties tijdens de doorvoer en aan de uitvoer (bijvoorbeeld: ontwerpen, realiseren en onderhouden). Denk aan de totstandkoming van een bouwwerk, vanaf papier of bits and bytes tot het fysieke bouwwerk zelf; ondersteunende processen houden de middelenstromen in stand. Denk bijvoorbeeld aan documentmanagement; regelende processen stemmen de activiteiten in de bewerkende processen onderling op elkaar af. Regelende processen stemmen ook de ondersteunende processen af op de bewerkende processen en de interne processen op de omgeving. Hier vallen bijvoorbeeld calculatie en planning onder. Systeemgrens

Het trekken van een denkbeeldige grens zodat de elementen van het te beschouwen systeem te onderscheiden zijn van de omgeving. Het enige wat door de grens gaat zijn in- en uitvoer. Denk aan een wegverbreding op een bepaald wegtrac. De fysieke wegverbreding is in dit geval het systeem en de systeemgrens is de aansluiting met de bestaande weg. Pag. 27 van 173


: : : : :


4.2

Systems Engineering

Deze paragraaf geeft een korte schets van de geschiedenis van SE en een eerste verkenning van de toepassing in de bouwsector. 4.2.1 Een korte geschiedenis SE werd ongeveer 70 jaar geleden voor het eerst bekend. Het is door niemand uitgevonden, maar verschillende aspecten zijn door velen gepromoot. Essentieel voor SE is het systeemdenken: het met een totale blik kijken naar het proces van probleem naar oplossing. In het systeemdenken wordt net zoveel aandacht gegeven aan de relaties tussen de elementen, als aan de elementen zelf. De aloude waarheid, het geheel is meer dan de som der delen, is van toepassing op het systeemdenken.

De ontwikkeling van SE gaat gepaard met de ontwikkeling van complexe systemen per decennium. Hieronder een korte opsomming: de jaren 40 van de vorige eeuw zien we als de start van SE, tijdens de ontwikkeling van communicatiesystemen gedurende de Tweede Wereldoorlog; SE wordt verder ontwikkeld en gebruikt in de jaren 50, door de ontwikkeling van militaire systemen voor de koude oorlog; in de jaren 60 gebruikt men SE voornamelijk bij militaire en ruimtevaartprogrammas. Dit leidt tot de ontwikkeling van de eerste SE norm, de MIL-STD-499; gedurende de jaren 70 neemt het gebruik van SE af. De meeste gebruikers denken dat het niets meer is dan logisch nadenken. Het wordt vaker gebruikt bij extreem complexe projecten, zoals het US Navys AEGIS programma; ernstig publiek falen zorgt in de jaren 80 voor een wederopleving van SE in militaire systemen. De opkomst van de computers zorgt ervoor dat eisenbeheersing vaker wordt toegepast; complexe softwareontwikkeling zorgt in de jaren 90 voor toename van het gebruik van SE. Door het intensieve gebruik van ICT wordt SE goed gedocumenteerd en vastgelegd in standaarden en modellen.

Pag. 28 van 173


: : : : :


4.2.2 Een eerste verkenning Een belangrijke term in het begrip SE is het woord Engineering. Engineering omvat meer dan men vaak onder de term verstaat. Naast het materialiseren en dimensioneren van elementen omvat dit begrip het gehele traject, vanaf probleemanalyse tot ontwerp, realisatie, beheer en onderhoud en tenslotte sloop van het bouwwerk. Engineering houdt in onze optiek het ontwikkelen en in stand houden van de oplossing (bijvoorbeeld een bouwwerk) in.

Om dieper in te gaan op SE schetsen we hieronder het traject van probleem tot oplossing.

Het hele (bouw)traject begint met een probleem. Iemand ervaart een ongewenste situatie. Die persoon of instantie wil die ongewenste situatie omvormen naar een gewenste situatie. Willen we dit goed doen, dan bepalen we eerst hoe we de ongewenste situatie ongedaan kunnen maken. De persoon of instantie die het probleem heeft en die zelf gebaat is bij de oplossing (de belanghebbende) verricht vaak deze activiteiten. Vaak wordt de term opdrachtgever gebruikt. Van een opdrachtgever is echter pas sprake als er een opdracht is gegeven, en dat is in het begin van het traject niet het geval.

De belanghebbende is verantwoordelijk voor de uitvoering van een proces waarvan de voortgang wordt belemmerd (= een ongewenste situatie) en heeft daarmee dus een groot belang bij de oplossing ervan. Kortom, de belanghebbende is in staat het probleem te beschrijven en de doelen te formuleren, waaraan de oplossing moet voldoen. Hij heeft kennis van het (primaire) proces, waarin de oplossing moet passen. Hij heeft inzicht in de vrijheden (en beperkingen) die hij heeft en de oplossingsrichtingen die al dan niet tot de mogelijkheden behoren. In praktijk betekent dit dat de belanghebbende de eisen van het gebruik van het bouwwerk kent. De randvoorwaarden zijn bekend en worden gesteld door de omgeving of het netwerk waarin het bouwwerk past. Verder weet de belanghebbende welk budget beschikbaar is voor de oplossing van het probleem.

Aan de hand van bovenstaande gegevens kiest hij een oplossingsrichting. Vervolgens formuleert hij waar een geschikte oplossing aan moet voldoen. Kortom, hij formuleert gewenste functionaliteit, de bijbehorende eisen, de randvoorwaarden en het budget. Hij houdt zoveel mogelijk wet- en regelgeving in het oog, maar ook standaarden vanuit zijn primaire proces en de mogelijke locaties van uitvoering. Dit is de oplossingsruimte van het probleem, die al eerder in Deel I naar voren kwam.

Pag. 29 van 173


: : : : :


De belanghebbende heeft meestal geen verstand van het ontwerpen en vervaardigen van het voor hem noodzakelijke systeem (in ons geval vaak een bouwwerk). Om deze reden wordt een andere belangrijke rol in dit proces beschouwd: de bouwwerk leverende. De bouwwerk leverende wordt ook wel de opdrachtnemer genoemd. Ook hier geldt weer dat deze term pas van toepassing is wanneer er sprake is van een opdracht. Een bouwwerk is een oplossing van een probleem. Algemener gezegd, een bouwwerk is een deel van het systeem van de belanghebbende waarmee zijn primaire proces wordt uitgevoerd.

Het hoofddoel van een bouwwerk wordt altijd geformuleerd in termen van het primaire proces van de eindgebruiker, inclusief de randvoorwaarden vanuit de omgeving of het netwerk. Bij bouwwerken gaat het om de waarde van een bouwwerk, tegenover de kosten die daarvoor nodig zijn (zie Figuur 9). De waarde komt uit het systeem en betekent een lust of een last voor verschillende belanghebbenden, die iets met het systeem te maken hebben. Dit kan belevingswaarde (vorm, kleur, afwerking), functionele waarde (bijvoorbeeld capaciteit) of technische waarde (bijvoorbeeld beschikbaarheid en energiegebruik) zijn. De kosten zijn nodig om het systeem te ontwikkelen, te onderhouden en te exploiteren.4

Figuur 9 Waarde en kosten van een systeem

SE maakt de onderlinge relaties tussen de waarde en de kosten bekend en beheersbaar. De kern van SE is dat het gedrag van een systeem bekend is op elk schaalniveau en op elk moment in de ontwerplevensduur. Met gedrag wordt bedoeld: de te leveren dienst, de uit te voeren functie, de werking van het systeem et cetera. Door middel van de grootheden waarde en kosten beschrijven we het gedrag. Het beschrijven is lastig, er zijn immers veel objecten in een systeem met verschillende onderlinge relaties.

Dit is een van de kenmerken van complexiteit waar we in hoofdstuk 5 dieper op ingaan. Door het gebruik van SE kan VI in de projecten op elk moment de actuele staat van alle elementen samenbrengen tot de topinformatie ten aanzien van de waarde van het systeem versus de kosten. We kunnen vragen beantwoorden als: Halen we de betrouwbaarheid nog? en Voldoen we nog aan de veiligheidseisen? De waarde en kosten worden als aspectsystemen gedefinieerd. Deze term werken we in deel III verder uit. 4 De Ridder, H.A.J. (2007), Living building concept for adding value in an unpredictable future Pag. 30 van 173


: : : : :


4.3

Integraal ontwerpen

Door een uniform proces te definiren, inclusief bijbehorende procedures en activiteiten, legt SE de basis voor het ontwikkelen van systemen. Tijdens het integrale ontwerpproces gaan we vervolgens in op de inhoud. Deze paragraaf beschrijft dit proces in het kort, omdat het proces onlosmakelijk is verbonden met SE in de grond-, wegen waterbouw (GWW).

De integraal ontwerper is gespecialiseerd in het integreren van bijdragen uit verschillende disciplines en aspecten. Door te integreren komt hij tot een systeem in een gecompliceerde omgeving (zie Figuur 10). Integraal ontwerpen wordt steeds belangrijker, omdat de realisatie van effectieve oplossingen steeds moeilijker wordt in een wereld die sneller en sneller verandert.

Figuur 10 Integraal ontwerpen

Pag. 31 van 173


: : : : :


4.3.1 Het integrale ontwerpproces We kiezen voor integraal werken omdat complexe projecten snel qua kosten en planning uitlopen en soms totaal mislukken. Complexe projecten zijn moeilijk decomponeerbaar, omdat de afhankelijkheden in een project niet of nauwelijks bekend zijn. De complexiteit van projecten in de bouw kenmerkt zich door onder andere: de betrokkenheid van veel stakeholders, zoals ministeries, gemeenten, waterschappen, provincies, actiegroepen, burgers, et cetera; de betrokkenheid van veel disciplines tijdens de verschillende fasen van het werk: civieltechnici, bodemdeskundigen, verkeerstechnici, landschapsarchitecten, MER-deskundigen, juristen, geluidsdeskundigen et cetera; de veelheid aan eisen die in het contract voorkomen in verschillende fasen van het project en op verschillende abstractieniveaus. Het integraal ontwerp gaat uit van een integratie van5: fasen (ontwerp, uitvoering, onderhoud, beheer); spelers (stedebouwkundigen, architecten, constructeurs, installateurs, leveranciers); disciplines (civiel, water, weg, installaties); objecten (verlichting, wegdek, damwand et cetera); aspecten (capaciteit, energiegebruik, emissies, hergebruik); processen (planproces, ontwikkelingsproces).

Denk bij het integraal ontwerpen na over de volgende vragen: 1. Hoe ontwerpen we integraal, als de aspecten realiseerbaarheid en onderhoudbaarheid, milieu, veiligheid en klimaat niet in het contract staan?; 2. Welke effecten heeft het bouwwerk op de omgeving? Zijn er neveneffecten die niet in het contract staan, maar wel de scope van de werkzaamheden kunnen benvloeden?; 3. Welk effect heeft de omgeving en de opgelegde randvoorwaarden op het bouwwerk? Is er een oplossing op een abstract niveau mogelijk? Denk aan tracbesluiten, milieubesluiten et cetera, die niet definitief zijn, waarvan het risico bij de opdrachtnemende partij ligt.

5

De Ridder, H.A.J. 2009. Memo Integraal Ontwerpen

Pag. 32 van 173


: : : : :


4.3.2 Functioneel, ruimtelijk en constructief ontwerp Beheshti, R. (1999) verdeelt het integraal ontwerpen onder in een functioneel, ruimtelijk en constructief ontwerp. Deze ontwerpstappen zijn niet lineair, maar iteratief (herhaald doorlopen ). Het ontwerpproces is een vertaalslag van initiatief naar bouwrijpe informatie. Om deze vertaalslag te beheersen en te verantwoorden, rondt VI elke ontwerpfase af met een rapportage en een beslissing. De schriftelijke rapportages noemen we ook wel producten of fasedocumenten.

Ontwerpproducten zijn een voorbereiding voor de verantwoording aan de OG. De ontwerper presenteert en beargumenteert de invulling van de varianten. Hij verstrekt informatie en toont de haalbaarheid. Op basis van deze informatie besluit de OG hoe verder te gaan. In de huidige gentegreerde contracten ondervangt het verificatieproces dit. Dit proces verloopt niet als gewenst, omdat de OGs relatief veel eisen opnemen in de contracten met betrekking tot de invulling van het ontwerp. Daarom is de invulling van het ontwerp al gegeven in de vorm van eisen. De ontwerper dient door middel van verificaties te laten zien dat zijn ontwerp(varianten) voldoen aan de eisen in het contract. Dit is een onnatuurlijk proces, dat het ontwerpproces verstoort.

Het is beter topeisen te stellen en ervoor te zorgen dat de ontwerpers met ontwerpen komen die hieraan voldoen. Indien specifieke zaken verlangd worden binnen een ontwerp, is het beter deze zaken te specificeren door middel van tekeningen, berekeningen en eisen. Op deze manier sluiten de ontwerpers aan op de zaken. In een ideaal ontwerpproces bekijken de ontwerpers op een creatieve manier het brede palet aan oplossingen en beoordelen zij deze oplossingen op nut, financierbaarheid en levensvatbaarheid. Ons bedrijf divergeert op basis van de ontwerpaspecten functie en omgeving (functioneel en ruimtelijk ontwerp). Vervolgens convergeert men naar twee drie voorstellen. Tijdens dit convergeren, komen de ontwerpaspecten techniek, en onderhoud naar voren (constructief ontwerp) en vermindert de aandacht voor functie en omgeving. Dit principe is in Figuur 11 weergegeven en werken we uit in deel III.

Figuur 11 Functioneel, ruimtelijk en constructief ontwerp

Pag. 33 van 173


: : : : :


De onderlinge samenhang tussen functioneel, ruimtelijk en constructief ontwerpen lichten we toe aan de hand van het ontwerp van een brug: het functioneel ontwerp resulteert onder andere in de capaciteitsbepaling, de eisen ten aanzien van de verkeersafwikkeling en de veiligheid. De input voor het ruimtelijk werk komt vanuit het functioneel ontwerp. We stellen de volgende aspecten vast: het aantal rijstroken, de behoefte aan eventuele inspectie-, fiets- of voetgangerspaden, de doorrij- en doorvaarthoogte, de toelaatbare hellingen et cetera; het ruimtelijk ontwerp resulteert in de plaatsbepaling, inpassing in de omgeving, de ruimtelijke vormgeving van de draagconstructie, de vaststelling van het dwars- en lengteprofiel et cetera; het constructief ontwerp resulteert in het vaststellen van de overspanning en plaatsing van steunpunten, de constructieve vormgeving, dimensionering en detaillering van de draag- en afbouwconstructie et cetera.

In de huidige gentegreerde contracten vertalen we het constructieve ontwerp vaak in eisen. Dit betekent dat er al een functioneel, ruimtelijk en tot op zekere hoogte constructief ontwerp gemaakt is. Van de ON wordt verwacht dit ontwerp af te maken, zonder inzage in de reeds gemaakte ontwerpen, op basis van gestelde eisen op systeem-, subsysteem-, componenten elementniveau. De ON kijkt bij het afmaken van het ontwerp niet naar reeds gemaakte ontwerpen, Met de huidige gentegreerde contracten hebben de ontwerpers bijna geen oplossingsruimte en dienen ze iets te ontwerpen dat precies voldoet aan alle gestelde eisen. De eigen inbreng in het proces is minimaal. Door deze gang van zaken wordt het ontwerpproces niet optimaal uitgevoerd. Deel III beschrijft het ontwerpproces op hoofdlijnen. 4.3.3 Het te ontwikkelen systeem maakt deel uit van een groter geheel Figuur 10 toont dat het probleem onderdeel uitmaakt van een omgeving. In bijna alle gevallen van integrale projecten gaat het om bouwwerken die onderdeel uitmaken van een systeem of netwerk van civieltechnische en bouwkundige producten/objecten (vaak aangeduid als infrastructuurnetwerk of systeem). De bouwwerken zijn op zichzelf te beschouwen als een systeem. Niet alleen de afzonderlijke producten/objecten vragen om een ontwerp, ook de systemen of netwerken vragen om een totaalontwerp. Bij het totaalontwerp gaat het in mindere mate om de constructieve ontwerpproblematiek en meer om het planologische ontwerp van civieltechnische en bouwkundige werken. Veel van de problemen in de huidige bouwpraktijk, hebben te maken met het isoleren van de objecten in een netwerk. Het risico van het isoleren is dat het systeem (de omgeving en het netwerk) op de achtergrond raakt en de ingreep een doel op zich wordt. Om dit te voorkomen is het belangrijk dat we het systeem dat ontworpen wordt, bezien in het grotere geheel (systeemdenken).

Pag. 34 van 173


: : : : :


Tijdens de eerste stap in het ontwerpproces bepalen we het te ontwerpen systeem en het daarbij behorende doel. Behandel bij de bepaling vragen als: Wat willen we? (kijkend naar de minimum eisen en wensen uit de stakeholders analyse) en Wat mogen we? (kijkend naar de omgeving voor de gestelde randvoorwaarden). Elk systeem vervult een functie in een hoger systeem (de omgeving). Dit hogere systeem bepaalt de randvoorwaarden die gelden voor het te ontwerpen systeem. Zonder de randvoorwaarden is niet bekend of het te ontwerpen systeem zal functioneren in de omgeving en het netwerk.

De vraagspecificaties dienen alleen minimumeisen, randvoorwaarden en eventueel wensen te bevatten. Rijkswaterstaat en ProRail gebruiken de term vraagspecificaties voor documenten waarin zij hun vraag naar de markt specificeren. Naast de vraagspecificatie dient een minimumprijs en een budget gegeven te zijn.

Werk niet met gedetailleerdere eisen voor componenten of elementen. Gedetailleerdere eisen beperken de oplossingsruimte en maken daardoor het ontwerpproces lastiger. Gedetailleerde eisen leiden er ook toe dat de verantwoordelijkheid voor het functioneren van het systeem terug wordt gelegd bij de OG. Door eisen te stellen ten aanzien van de technische invulling begeeft de OG zich namelijk op het terrein van de aanbieder.

We gaan weer terug naar de omgeving die de randvoorwaarden stelt aan het te ontwerpen systeem. De omgeving vervult een aantal functies. n of meerdere functies moeten worden uitgevoerd door het te ontwerpen systeem. Aan de uitvoering van deze functie(s) worden eisen gesteld in de vorm van de minimumeisen en randvoorwaarden (deze zijn eerder in deze paragraaf behandeld). De kostencomponent mag ook niet uit het oog worden verloren.

Het is goed om de andere functies die de omgeving en het netwerk vervullen te onderzoeken, (voor zover dat niet tijdens de stakeholdersanalyse is gebeurd). Ook de aspecten (zoals capaciteit, doorstroming en veiligheid) die onderdeel uitmaken van de omgeving en waarop de functies worden uitgevoerd, dienen onderzocht te worden. Dit leidt tot extra randvoorwaarden waaraan het te ontwerpen systeem moet voldoen. Deel III van dit document gaat hier verder op in.

Pag. 35 van 173


: : : : :


4.4

Expliciet werken

In deze paragraaf wordt de term expliciet werken uitgelegd. Expliciet werken betekent het waarborgen van informatieoverdracht, met behoud van volledigheid, traceerbaarheid, ondubbelzinnigheid en consistentie.

Het toepassen van SE en het uitvoeren van het integrale ontwerpproces gebeurt op basis van expliciet werken. Via systematisch werken wordt kennis expliciet op papier gezet, zodanig dat geen verschillende interpretaties mogelijk zijn. Hiermee bedoelen we dat alle relevante projectinformatie helder, eenduidig en logisch vastgelegd wordt. Informatie is snel en trefzeker op te zoeken en te vinden.

Projectbeheersing gaat over de beheersing van informatie. Alle benodigde informatie dient gestructureerd en vastgelegd te worden. Alleen dan is de benodigde informatie altijd terug te vinden. De beheersing van deze informatie bepaalt in grote mate het slagen van een project. Naast het ordenen, beheersen en onderkennen van onderlinge afhankelijkheden van die informatie, gaat het om de wijze waarop we deze informatie delen.

Het is belangrijk om expliciet te werken wanneer we binnen een gentegreerd contract werken. Expliciet werken is onnatuurlijk. Als je elkaar niet goed kent of niet veel kennis deelt, moet je extra expliciet zijn om onbegrip en misverstand te voorkomen. Voor samenwerking in complexe projecten is vakdeskundigheid alleen onvoldoende. Impliciete communicatie kan alleen worden gebruikt als degenen die samenwerking elkaar en de materie zo goed kennen dat halve woorden voldoende zijn. Om expliciet te communiceren is het belangrijk om het zender-ontvanger principe toe te passen: de zender moet zich inleven in de behoefte van de ontvanger.

Expliciete communicatie is belangrijk wanneer we grote hoeveelheden gegevens moeten verwerken, zoals je vaak ziet bij complexe projecten. Als de hoeveelheid informatie zo groot is dat het overzicht verdwijnt, ontstaat de behoefte aan ordening. Wanneer bijvoorbeeld het aantal eisen in de duizenden loopt, geldt dat ook voor het aantal werkzaamheden en kostenposten. Dat is lastig, want ordening van eisen, werkzaamheden en kosten moet men op elkaar afstemmen, anders zijn de relaties hiertussen onbeheersbaar. Wat kost bijvoorbeeld de wijziging van een eis en hoe vertaalt een dergelijke wijziging zich in extra werkzaamheden?

Pag. 36 van 173


: : : : :


Recht toe recht aan-ordeningen, zoals alfabetische ordeningen of ordeningen op datum voldoen niet. Men moet veel meer kijken naar betekenisvolle groeperingen, zoals een hirarchische ordening (de boomstructuur). Het voordeel van een hirarchische ordening is dat deze recursief (zichzelf herhalend) is. Een hirarchische ordening is zinvol bij een grote verzameling informatie (bijvoorbeeld objecten). In principe eindigt een recursief proces nooit, maar een momentopname van de stand van zaken is altijd mogelijk.

De verzameling informatie gaat bijvoorbeeld over e-mailberichten waarin gemaakte afspraken staan, mondeling overleg met de OGs of zelfs mondeling gemaakte afspraken binnen de verschillende teams. Deze informatie moet terug te vinden zijn onder een uniek identificatienummer, gerelateerd aan projectspecifieke informatie waar de informatie op van toepassing is. Als twee disciplineleiders bijvoorbeeld in een telefoongesprek vaststellen wie verantwoordelijk is voor een bepaald raakvlak, dan dient dit schriftelijk vastgelegd te worden en terugvindbaar te zijn.

SE wordt toegepast om een probleem op te lossen. De technisch-inhoudelijke invulling laat men aan de vakdisciplines over. Het beheersen van de processen ten aanzien van de invulling en ontwikkeling van de oplossing doet VI met behulp van SE, door eenduidig, transparant, traceerbaar en aantoonbaar te communiceren (expliciet werken).

Bij eenduidigheid gaat het om het vastleggen van objecten of aspecten, zoals eisen, vergunningen, functies et cetera, zodat deze objecten of aspecten voor n uitleg vatbaar zijn. Bij transparantie is belangrijk dat we elke genomen stap en bijbehorende beslissing (zoals eisen afleiden, alternatieven kwantificeren) vast leggen. Als het gaat om traceerbaarheid moet de waarom vraag gesteld worden. Op deze manier herleidt men de oplossing aantoonbaar naar de oorspronkelijke vraagstelling.

Pag. 37 van 173


: : : : :


5.

Algemeen begrippenkader Systems Engineering

Dit hoofdstuk beschrijft veel voorkomende begrippen in het kader van SE (in de bouw). Dit kader is bedoeld om relevante begrippen te definiren, zodat er geen spraakverwarring ontstaat en de kern van de zaak belicht wordt.

Deel III gebruikt deze begrippen bij de invulling van het werken met SE in de projecten. De lijst met omschreven begrippen is niet uitputtend en breiden we (inhoudelijk) uit zodra de ervaring met SE in de bouw toeneemt.

In de eerste paragraaf gaan we in op configuratiebeheer, omdat dit proces de basis legt voor de terugvindbaarheid van projectinformatie. Dit proces dient men als n van de eerste zaken op een project te regelen. De drie paragrafen daarna gaan in op de manier waarop men een complex project kan decomponeren en sturen door middel van raakvlakbeheersing en aspectbeheersing. Decomponeren is na configuratiebeheer belangrijk, omdat we hierin de meest geschikte opdeling van het project beschrijven.

De paragrafen 5.6 tot en met 5.11 kennen een chronologische volgorde die overeenkomt met het uitvoeren van een project van behoefte tot en met ontwerp. De paragrafen 5.12 en 5.13 beschrijven een deel van de toekomstvisie van VI, verankerd in de BOB (Basis Objecten Bibliotheek) en de BAB (Basis Activiteiten Bibliotheek).

De paragrafen 5.14 en 5.15 gaan over het gebruik van de Work Breakdown Structure (WBS) en het Project Activiteiten Model (PAM). De WBS geeft het werk weer dat moet worden verricht om het project op te leveren. De PAM geeft de activiteiten weer die nodig zijn voor de totstandkoming van het eindresultaat. Deze paragrafen sluiten aan op het begin van dit hoofdstuk.

Paragraaf 5.16 gaat in op de organisatiestructuur. Paragraaf 5.17 en 5.18 beschrijven de controleprocessen verificatie en validatie.

Pag. 38 van 173


: : : : :


5.1

Configuratiebeheer

Bij configuratiebeheer gaat het om: het terugvinden van systeeminformatie, zoals eisen, randvoorwaarden, risicos; het bevriezen van informatie die dient als referentie voor verdere werkzaamheden (configuratie baseline).

Figuurlijk gezien maken we een momentopname van de projectinformatie. Het is van belang voor de projecten/of ontwerpleider om continue de onderlinge verhouding van de elementen met hun toestanden, karakteristieken en eigenschappen te controleren. Door de vastlegging van projectinformatie is inzichtelijk welke gegevens wanneer gebruikt zijn, wanneer welke gegevens of situaties zijn gewijzigd en welke gevolgen dat had voor de elementen. 5.1.1 Definitie Het vastleggen en beheersen van relevante projectinformatie, zijnde de configuratie van het systeem in de tijd

Hiermee bedoelen we dat alle relevante gegevens op georganiseerde wijze worden benoemd, opgeslagen en bijgehouden gedurende de totale levensduur van het project. 5.1.2 Doel Het doel van configuratiebeheer is traceerbaarheid van informatie en beslissingen, inclusief de bijbehorende status van de configuratie. Doordat alle informatie en beslissingen traceerbaar zijn, werkt iedereen met de juiste uitgangspunten en gegevens en verloopt een wijziging van deze uitgangspunten via beheerste procedures. Het vaststellen van een bevriesmoment (configuratie baseline) op specifieke punten van de fasen en het gestructureerd bijhouden van veranderingen zijn belangrijke aspecten in configuratiebeheer.

Pag. 39 van 173


: : : : :


De kern van configuratiebeheer is : Het identificeren van de configuratie Welke informatie (ook wel configuratieobjecten genoemd) moet men onderwerpen aan configuratiebeheer? Om deze vraag te kunnen beantwoorden, moeten we eerst beslissen welke informatie traceerbaar moet zijn. Dit zijn bijvoorbeeld minimaal de eisen en de objecten. Het wijzigingsproces In dit proces houdt men bij welke wijzigingen het configuratieobject doorloopt, zodat men deze beheerst en vastlegt. Bedenk dat een wijziging pas een wijziging is als het een wijziging van de configuratie baseline is. Dit betekent bijvoorbeeld dat het tijdens het ontwerpproces niet de bedoeling is dat men elke wijziging vastlegt. Het ontwerpproces is per definitie een wijzigingsproces. Pas als er een configuratie baseline is, start het wijzigingsproces. Het bijhouden van de documentatie van de configuratie Men legt vast op welke momenten de configuratie baseline is vastgesteld, oftewel de informatie bevriest. Door middel van periodieke rapportage biedt men vervolgens inzicht in de status van de informatie. Door het documenteren van de configuratie maakt men het verschil tussen de vastgelegde baseline (foto) en de actuele status expliciet. Het auditeren van de configuratie Periodiek auditeert men of men de activiteiten ten behoeve van configuratiebeheer ook werkelijk volgt.

6

6 NEN-ISO 10007 (1995), Configuration Management Pag. 40 van 173


: : : : :


5.1.3 Relatie met andere structuren Configuratiebeheer is van belang voor relevante projectinformatie. Ten aanzien van de informatie is bekend wat de status en de laatste versie is. Configuratiebeheer is het meest gerelateerd aan documentmanagement. Documentmanagement is de wijze waarop bepaalde informatie wordt beheerst. Documentmanagement betreft documentsoorten, -benaming, -nummering, -distributie en beheer, terwijl configuratiemanagement over de inhoud van aangewezen documenten gaat (zie Figuur 12).

Figuur 12 Het verschil tussen documentmanagement en configuratiemanagement

5.1.4 Veel voorkomende problemen We zijn gewend de inhoud (eisen, randvoorwaarden, uitgangspunten et cetera) in ons eigen document te stoppen, zonder dat de informatie expliciet wordt vastgelegd. Het is niet voor iedereen duidelijk wat configuratiebeheer is. Men denkt vaak dat configuratiebeheer hetzelfde is als documentenmanagement. Er zijn vooraf geen duidelijke coderingsafspraken gemaakt. We onderschatten het belang van configuratiebeheer.

Pag. 41 van 173


: : : : :


5.2

Complexiteit

In eerdere hoofdstukken kwam al naar voren dat bouwwerken vaak complex zijn. Met complex bedoelen we moeilijk decomponeerbaar. Decomponeren is het opdelen in stukken. In deze paragraaf behandelen we het onderwerp complexiteit.

Complexiteit is het tegenovergestelde van decompositie. Het ontwikkelingsproces van een bouwwerk is complex, omdat: het systeem verschillende vormen van waarde kent. Bijvoorbeeld belevingswaarde (vorm, kleur en afwerking), functionele waarde (capaciteit) of technische waarde (beschikbaarheid en energiegebruik); het systeem uit diverse en ingewikkelde elementen en relaties bestaat; het proces een Programma van Eisen (PvE) met diverse ingewikkelde eisen en/of relaties met zich meebrengt; een conceptoplossing wordt gegeven in de vraag van de OG. Deze oplossing bestaat uit vele diverse ingewikkelde elementen en/of ingewikkelde relaties; de kosten van het systeem zijn opgebouwd uit vele posten met diverse relaties.

Figuur 13 De waarde en kosten van een systeem

Figuur 13 is een grafische weergave van de waarde, het bijbehorende programma van eisen (PvE), de conceptoplossing en de kosten van een systeem. Tijdens het integrale ontwerp dient er een dynamische koppeling te zijn tussen deze vier eenheden.

Met meerdere mensen (disciplines) werken aan de totstandkoming van een bouwwerk is moeilijk. Het belangrijkste probleem is de wijze waarop we een cyclisch proces (het ontwerp) opdelen in een aantal parallelle cyclische deelprocessen. Met andere woorden: Hoe zorgen we ervoor dat een aantal mensen werkt aan een gemeenschappelijk doel en er genoeg ruimte is om te zoeken naar de optimale oplossing? Kunnen mensen voldoende communiceren en veranderingen aanbrengen, zonder het doel in gevaar te brengen?

Pag. 42 van 173


: : : : :


Vooral het laatste is in strijd met wat er vaak in groepswerk wordt gedaan. Regelmatig worden afspraken gemaakt, waaraan iedereen zich houdt. Dit uit zich in het opsplitsen in vakdisciplines en daarna het geheel aan elkaar plakken door middel van een planning (de bekende vertical split methode). Tijdens het ontwerp is het toepassen van de vertical split methode onmogelijk, omdat er moeilijk afspraken te maken zijn over zaken die nog niet zijn uitgezocht. Denk maar aan communicatieproblemen tussen disciplines die met verschillende ontwerpcycli werken.

Het ontwerpen binnen een gentegreerd contract is lastig, omdat het te realiseren systeem uit verschillende elementen bestaat. Denk aan wegen, kunstwerken, duikers, kabels, leidingen et cetera. Al deze elementen dienen aan een groot aantal eisen te voldoen. Mensen realiseren zich te weinig dat een systeem nooit voldoet aan ALLE gestelde eisen. Ontwerpen is het proberen om aan zoveel mogelijk eisen te voldoen. Omdat een ontwerper nooit alleen en tegelijk aan alle elementen kan werken, verdeelt VI het werk in multidisciplinaire werkpakketten.

Wanneer een ontwerper concludeert dat zijn element moet veranderen omdat hij anders niet kan voldoen aan een gestelde eis, begint hij vaak opnieuw. Dit brengt het vak met zich mee; het is een iteratief proces. Wanneer het element ook relaties heeft met andere ontwerpen, zijn de eerste raakvlakken een feit. 5.2.1 Definitie Complexiteit heeft te maken met de volgende zaken: 1. in de bouw is weinig sprake van complexiteit van de elementen. Elementen als heipalen en brugliggers zijn niet complex en vervaardigen we al jaren; 2. in de bouw is met name bij het gebruik van gentegreerde contracten sprake van verscheidenheid in elementen. De elementen van de disciplines wegenbouw, civiele werken en installatietechniek verschillen nogal van elkaar; 3. in een multidisciplinair project is sprake van verscheidenheid in relaties en complexiteit van relaties, doordat de verschillende elementen verschillende relaties met elkaar hebben. Een brugligger dient niet alleen voor krachtsafdracht, maar levert tegelijkertijd een bijdrage aan de stabiliteit van het kunstwerk; 4. het feit dat een object meerdere functies in een systeem vervult. De functies zijn niet of moeilijk te scheiden en benvloeden elkaar.

Pag. 43 van 173


: : : : :


In gentegreerde contracten spelen vaak veel belangen en factoren een rol. Deze factoren en belangen leiden soms tot heroverwegingen. Hoe groter en complexer het project, hoe moeilijker het is om tot een gedragen eindresultaat te komen. Bij grote en complexe producten zijn er vaker twijfels over gemaakte keuzes. Die twijfels leiden tot heroverwegingen en wijzigingen. Die wijzigingen leiden tot meer complexiteit, wat een zelfversterkend effect heeft. In die omstandigheden is het een wonder dat projecten regelmatig tot aanvaardbare eindresultaten leiden. Het veelvuldig heroverwegen van eerder genomen besluiten verhoogt de complexiteit van een project.

Complexiteit in projecten is niet goed, maar ook niet slecht. Soms moet men zaken breder trekken, oftewel de scope van een project oprekken. Andersom moeten zaken soms versimpeld worden om verder te komen in processen. 5.2.2 Doel Complexiteit dient geen doel, maar ontstaat door de veelheid aan afhankelijkheden in het ontwikkelingsproces van een bouwwerk. 5.2.3 Veel voorkomende problemen Zo snel mogelijk in stukken knippen (vertical split) en daardoor geen oog hebben voor cyclische ontwerpprocessen; Het aantal betrokkenen maximaliseren; Teveel besturen en te weinig vrijheid voor de ontwerpers genereren.

Pag. 44 van 173


: : : : :


5.3

Decompositie

Decompositie is het tegenovergestelde van complexiteit en betekent het opdelen van een systeem in delen met behoud van onderlinge relaties. Deze opdeling vindt bijvoorbeeld plaats naar: subsystemen (System Breakdown Structure (SBS), ook wel objectenstructuur genoemd); werkpakketten (Work Breakdown Structure (WBS); aspectsystemen (veiligheid, duurzaamheid).

De eerste vorm van decompositie richt zich op het systeem en komt tijdens het ontwerp tot stand in de objectenstructuur. Tijdens de bouw komt de eerste vorm van decompositie tot stand in de fysieke structuur. De tweede vorm van decompositie is het organiseren van SE en richt zich op het project management proces. De derde vorm van decompositie is in de bouw nooit volledig toegepast en praktisch uitgewerkt. Deze decompositie baseert men op het sturen door middel van aspecten (bijvoorbeeld veiligheid, CO 2 uitstoot en doorstroming). Bij de derde vorm kan waarde uiteenvallen in belevingswaarde, gebruikswaarde en technische waarde. Kosten onderscheidt men in ontwikkelingskosten, onderhoudskosten en beheerkosten. Deel III beschrijft deze vorm.

Bij de beheersing van een project maakt men gebruik van de eerste twee genoemde decomposities. In de nieuwe contracten zien we dat de OG zich richt op decompositie in aspectsystemen.

Een ontwerpopgave is meestal complex, omdat men aan onderling gekoppelde of zelfs conflicterende eisen en randvoorwaarden moet voldoen. Een Programma van Eisen waaraan VI moet voldoen bestaat uit meer dan 2000 eisen. Door een ontwerpproces te decomponeren, tracht men het ontwerpproces beheersbaar te maken. Decomponeren is het opdelen van een ontwerpproces in overzienbare delen en de deeloplossingen weer aan elkaar plakken. Het gaat bij decomponeren in eerste instantie om de uiteenrafeling van een project. Hoe beter dat gebeurt, hoe minder problemen voorkomen met de integratie van de stukken tot een geheel. 5.3.1 Definitie Het idee om te decomponeren ontstond vanuit het besef dat een mens niet alle noodzakelijke handelingen gelijktijdig uit kan voeren om een bepaald doel te bereiken. Een gangbare definitie voor decompositie is: het opdelen van een systeem in minder complexe delen, zodanig dat cordinatie van die delen mogelijk is.

Pag. 45 van 173


: : : : :


5.3.2 Doel Het doel van een decompositie is het verminderen van de complexiteit door het probleem op te splitsen in deelproblemen. Met decomponeren kan men tijd besparen door parallel aan de verschillende deelproblemen te werken. Andere doelen zijn het werk verdelen in de organisatie, het werk plannen en de werkzaamheden definiren. Deze doelen gaan samen met het formeren van werkpakketten, waar we verderop in dit document op terugkomen.

In simpele taal komt het doel op het volgende neer: We zijn genteresseerd in het gedrag en eigenschappen (aspecten) van het systeem in de omgeving. Om dit gewenste gedrag te bereiken hebben we een ding' nodig (het object). Om dit 'ding' te maken zijn mensen/productiemiddelen (disciplines) nodig. Om de juiste oplossing te bieden, brengen we de aspecten samen, oftewel we maken een goede 'mix' van aspecten. Daarvoor moeten de elementen van het systeem goed met elkaar samenwerken en op elkaar aansluiten. Niet alleen aandacht besteden aan de objecten, maar ook aandacht hebben voor de relaties. De disciplines moeten dus goed samenwerken (multidisciplinaire teams). 5.3.3 Veel voorkomende problemen Te ver decomponeren, zonder dat het in de betreffende fase noodzakelijk is. Het decomponeren tot op bout en moer niveau binnen een organisatie, bij gebrek aan standaarden. Decomponeren naar werkpakketten met veel onderlinge raakvlakken, omdat bijvoorbeeld vanuit machtsposities de werkpakketten al zijn verdeeld.

Pag. 46 van 173


: : : : :


5.4

Raakvlakanalyse en -beheersing

De essentie van het decomponeren is het minimaliseren van doorsnijding van relaties en het minimaliseren van raakvlakken. Hoe men ook decomponeert of organiseert, de organisatie krijgt altijd te maken met allerlei raakvlakken. Er zijn verschillende soorten raakvlakken: tussen objecten; tussen activiteiten; tussen werkpakketten; tussen eisen.

Om een project goed te beheersen is het belangrijk de scope zodanig op te splitsen (te decomponeren) dat er goed beheersbare delen (werkpakketten) ontstaan. Als praktische regel geldt: maximaal het aantal raakvlakken binnen een werkpakket en minimaal het aantal raakvlakken tussen werkpakketten . 5.4.1 Definitie Een raakvlak is een omstandigheid, manier of plaats waar zaken samen komen en elkaar benvloeden. Een raakvlak wordt ook wel een afspraak op de grens van twee zaken genoemd. Interne raakvlakken bevinden zich binnen de systeemgrenzen. Externe raakvlakken worden gedefinieerd als invloeden van het systeem op de omgeving en andersom. 5.4.2 Doel Het doel van raakvlakbeheersing is het beheersen van het systeem door de interne en externe relaties te borgen in lijn met decompositie. Een voorbeeld van slim decomponeren met een minimaal aantal raakvlakken creren is in Figuur 14 weergegeven. Praktische uitspraken in relatie tot het voorkomen van raakvlakken is de volgende: Wie splijt krijgt spijt en Wie knipt, moet ook plakken. Waarmee bedoeld wordt: als men een element (object, activiteit, et cetera) in tween deelt, ontstaan n of meerdere raakvlakken die men moet beheersen en voor extra werk zorgen.7

Figuur 14 Raakvlakken minimaliseren

7 Simon, H.A. (1969), The architecture of complexity. In: The sciences of the artificial, Cambridge. Pag. 47 van 173


: : : : :


Tabel 2 geeft in twee matrices een fictief systeem weer. De enen geven de relaties tussen de elementen weer. Om te beginnen heeft elk element een relatie met zichzelf. Sommige elementen hebben een tweezijdige relatie en sommige elementen hebben een eenzijdige relatie. Door de elementen te herschikken en te groeperen, vormt men werkpakketten. Binnen werkpakketten moeten de relaties tussen elemen

Handboek SE 9-11-2009-2

Documents

Transcript of Handboek SE 9-11-2009-2