Effectieve informatie-uitwisseling binnen Nederlandse DBFM weginfrastructuurprojecten

Effectieve informatie-uitwisseling binnen Nederlandse DBFM weginfrastructuurprojecten

Op weg naar Life Cycle Based afwegingen in de ontwerpfase

Jeremy de Bruijn

Thesis Jeremy de Bruijn_5-12-2013 2

Colofon Effectieve informatie-uitwisseling binnen Nederlandse DBFM weginfrastructuurprojecten Op weg naar Life Cycle Based afwegingen in de ontwerpfase

Personalia Student: Student ID: Studie: Faculteit: Master: Telefoon: Email:

M.A.M. (Martinus Antonius Michael) de Bruijn 4050320 Technische Universiteit Delft Civiele Techniek en Geowetenschappen Construction Management and Engineering 06-51366358 [email protected]

(TUD) (CEG) (CME)

Afstudeercommissie TU Delft: Voorzitter: Commissielid: Commissielid:

Prof dr. ir. M.J.C.M. (Marcel) Hertogh Ir. L.S.W. (Leonie) Koops Ir. drs. J.G. (Jules) Verlaan

Iter Fidelis: Commissielid:

Ir. L. (Leon) de Jonge

(CEG) (TPM) (CEG)

Disclaimer Dit rapport betreft het afsluitend onderzoek voor de Master Construction Management & Engineering op de TU Delft. Dit onderzoek is uitgevoerd door M.A.M. de Bruijn in samenwerking met Iter Fidelis. Het onderzoek bevat bevindingen op basis van zowel primaire als secundaire bronnen. De informatie in dit onderzoek is niet volledig openbaar. Het deel dat openbaar is, kan vrij gebruikt worden. Ondersteuning bedrijf Naam: Adres: Plaats: Telefoon:

Iter Fidelis B.V. Computerweg 2 Utrecht 0346 28 3090

Lay-out Versie: Datum:

V42 5-12-2013



Voorwoord Dit document betreft de rapportage van mijn thesisonderzoek voor de Master Construction Management & Engineering (CME). Het rapport is geschreven in samenwerking met het bedrijf Iter Fidelis. Iter Fidelis is een consultancy bedrijf en dit onderzoek is geschreven in het kader van een intern onderzoek van Iter Fidelis. Dit is de ontwikkeling van een kennisdatabase voor informatie die in een project tot stand komt. De titel van dit onderzoek is: “Effectieve informatie-uitwisseling binnen Nederlandse DBFM weginfrastructuurprojecten”. Informatie uitwisselen is de normaalste zaak van de wereld, maar effectieve informatie-uitwisseling niet. Als men onder tijdsdruk werkt en beperkte middelen voorhanden zijn is de informatie dan wel effectief uit te wisselen? Of zorgen we ervoor dat het eigen deel van het werk binnen een project is geregeld en wordt de informatie over de schutting gegooid naar de volgende partij? Dit onderzoek kan een bijdrage leveren voor opdrachtnemers (marktpartijen) in de Grond, - Weg, - en Waterbouwsector, die informatie effectiever willen uitwisselen. Informatie-uitwisseling is echter niet alleen een uitdaging voor opdrachtnemers, maar is een uitdaging voor iedereen die informatie effectief wil uitwisselen. Om de overzichtelijkheid te bevorderen is dit document opgedeeld in vijf delen. Elk onderzoeksdeel heeft één of meer hoofdstukken. Op de volgende pagina is in de structuurbeschrijving van dit onderzoek te zien. Voorafgaand aan het inhoudelijke deel van dit document wil ik iedereen bedanken die een bijdrage heeft geleverd aan het tot stand komen van dit rapport. Om te beginnen gaat mijn dank uit naar mijn afstudeerbegeleiders van de Technische Universiteit Delft. Leonie Koops, Marcel Hertogh en Jules Verlaan. Ik bedank jullie voor het scherpe, omvangrijke commentaar en jullie hulp om de rode draad erin te krijgen. Vervolgens wil ik Iter Fidelis bedanken voor de samenwerking in dit onderzoek en het verbreden van mijn horizon. Leon de Jonge en Iter Fidelis collega’s, bedankt dat jullie mij buiten de gebaande wegen hebben geleid! Verder vormt dit document in haar fysieke vorm de afronding van fase in mijn leven. Een fase die niet mogelijk was geweest zonder steun van mijn vriendin, familie en vrienden. Zoals altijd hebben jullie ook tijdens dit afstudeertraject onvoorwaardelijk achter mij gestaan. Bedankt voor het geduld dat jullie met mij hebben gehad. Hiervoor mijn eeuwige dank. Als laatst hoop ik vurig dat dit document bijdraagt aan een effectievere manier van informatieuitwisseling bij de in de civiele sector actieve partijen. Ik wens u dan ook veel leesplezier. Jeremy de Bruijn Nootdorp, december 2013


Structuurbeschrijving Dit rapport bestaat uit vijf onderzoeksdelen. De onderzoeksdelen zijn opgenomen in een onderzoeksmodel (structuurbeschrijving). In figuur 1 is de structuurbeschrijving te zien. Deel A Opzet

Deel B Theorie

Systems Engineering (SE)

Theoretisch (1) model Systems Engineering

Inleiding en ontwerp onderzoek

Deel C Resultaten

Deel D Discussie

Eisen DBFM contracten

(4)

interviewvragen Levenscycluskosten (LCC) analyses

Voorwaarden (2) voor effectieve informatieuitwisseling

Deel Evaluatie

Veldonderzoek

Verschillenanalyse theorie en praktijk

Conclusies en Reflectie aanbevelingen

(3) Bevindingen uit de praktijk

LEGENDA Theorie

Empirie

Producten

(1)

Relatie tot onderzoeksvragen

Figuur 1 Structuurbeschrijving van het onderzoek.

Het onderzoeksmodel geeft visueel weer welke stappen worden doorlopen in ieder onderzoeksdeel. De onderzoeksdelen zijn de opzet, theorie, resultaten, discussie en evaluatie. Deze worden hieronder uiteengezet:  Deel A bestaat uit de opzet van het onderzoek. De introductie is opgenomen in hoofdstuk 1. In hoofdstuk 2 is de onderzoeksopzet te vinden;  Deel B bestaat uit de theorie. Dit deel is opgedeeld in twee hoofdstukken. Hoofdstuk 3 beschrijft de theorie over Systems Engineering (SE). Hieruit volgt een theoretisch model (product 1). Hoofdstuk 4 is een verdieping in Levenscycluskosten (LCC) analyses. Hieruit volgen voorwaarden voor effectieve informatie-uitwisseling (product 2);  Deel C bestaat uit de resultaten uit de praktijk. Dit deel bestaat uit twee hoofdstukken. In hoofdstuk 5 worden product 1 en 2 gecombineerd met de eisen van de contractvorm Design (D), Built (B), Finance (F) en Maintenance (M). Hieruit volgen interviewvragen voor het veldonderzoek. Hoofdstuk 6 zijn de resultaten van de interviews. Uit deze resultaten volgen de bevindingen uit de praktijk (product 3);  Deel D is de discussie. In het eerste deel van hoofdstuk 7 een reflectie op de interviewresultaten worden gegeven voor de generalisatie van de casus. Vervolgens volgt in het tweede deel van hoofdstuk 7 de verschillenanalyse (product 4);  Deel E is de evaluatie. De evaluatie bestaat uit drie hoofdstukken. In hoofdstuk 8 zijn de conclusies te vinden. In hoofdstuk 9 worden aanbevelingen gedaan. Tot slot wordt in hoofdstuk 10 een reflectie op de werkwijze in het onderzoek gegeven en wordt een reflectie op de resultaten van het onderzoek gegeven. Voor definities in dit onderzoek verwijs ik u naar bijlage 1. Bijlagen 2 tot en met 5 zijn achtergrondinformatie van SE en LCC. In bijlage 6 is de totstandkoming van de vragenlijst te vinden. De resultaten van de interviews zijn opgenomen in bijlage 7 en één op één interview is opgenomen in bijlage 8. Elk deel in dit onderzoek begint met de structuurbeschrijving.


Samenvatting Sinds tien jaar hebben opdrachtnemers in de GWW sector te maken gekregen met een andere uitvraag vorm van publieke opdrachtgevers (Rijkswaterstaat, Prorail). Deze vraag is in de vorm van geïntegreerde contracten, waarin activiteiten voor ontwerp, bouw en/of onderhoud zijn gebundeld. In projecten waarin sprake is van vergaande bundeling van activiteiten worden projecten aanbesteed met de contractvorm Design (D), Built (B), Finance (F) en Maintain (M). Op dit moment zijn binnen Nederland meerdere DBFM weginfrastructuurprojecten in voorbereiding of in uitvoering. De overheid heeft de intentie om de komende jaren meer projecten met de contractvorm DBFM aan te besteden. In DBFM projecten is een consortium (opdrachtnemer) verantwoordelijk voor het ontwerp, de bouw en het onderhoud. Daarnaast verzorgt de opdrachtnemer de voorfinanciering. Deze marktbenadering leidt ten eerste tot meer vrijheid in het ontwerp om Life Cycle Based (LCB) afwegingen te maken door opdrachtnemers. LCB afwegingen zijn afwegingen waarin tijdens het ontwerp componenten van bouw en onderhoud worden meegenomen. Ten tweede worden opdrachtnemers verantwoordelijk voor het leveren van prestaties tijdens bouw en onderhoud. Onderzoek van SBR (2013) geeft aan dat de bouwsector hoge faalkosten kent met 8-10% faalkosten van de totale bouwsom. Onderzoek van USP Marketing (2011) geeft aan dat 21% van de faalkosten ontstaan door gebrekkige informatie-uitwisseling. Daarmee heeft informatie-uitwisseling het grootste aandeel in de faalkosten. In totaal 2% faalkosten van de totale bouwsom. De probleemstelling van dit onderzoek is gebaseerd op de problemen bij het maken van LCB afwegingen. In de praktijk is geconstateerd dat te weinig gebruik wordt gemaakt van informatie van verschillende informatie dragers die bepalend is voor de levenscycluskosten. Deze informatie is binnen de Organisatie beschikbaar, maar informatie over systeemkenmerken en gedragingen wordt onvoldoende uitgewisseld tussen de verschillende teams, namelijk het ontwerpteam en de informatiedragers, tijdens de ontwerpfase. Het doel van dit onderzoek is om te bepalen of effectieve informatie-uitwisseling plaatsvindt bij het maken van ontwerpkeuzes en aanbevelingen te doen voor het verbeteren hiervan. Hiertoe is zowel literatuuronderzoek uitgevoerd, als praktijkonderzoek. Het praktijkgedeelte bestaat uit een aantal uitgevoerde interviews met kennisdragers uit de markt bij de aannemende partijen in de DBFM contractvormen. Uit het uitgevoerde onderzoek blijkt dat binnen Nederlandse DBFM weginfrastructuurprojecten nauwelijks sprake is van effectieve informatie-uitwisseling (1). Als gevolg daarvan bestaat veel ontwikkelpotentieel om tot effectievere informatie-uitwisseling te komen (2). In dit onderzoek zijn op basis van de problemen bij LCC analyses voorwaarden gesteld om te spreken van effectieve informatie-uitwisseling. Er wordt gesproken van effectieve informatie-uitwisseling als informatie relevant (1a), aanwezig (1b), tijdig beschikbaar (2), expliciet (3) en traceerbaar (4) is. De voorwaarden 1a en 1b hebben betrekking op de kennis van een projectmedewerker. De voorwaarden 2,3 en 4 hebben betrekking op de kwaliteit van informatie. Om de voorwaarden voor effectieve informatie-uitwisseling in de praktijk te toetsen zijn de voorwaarden verwerkt tot vragen voor de interviews.


Binnen een DBFM contract worden in het eisen gesteld. Deze eisen moeten centraal staan in het project, dus voor meerdere teams van een opdrachtnemer. In Nederlandse DBFM weginfrastructuurprojecten is contractueel vastgelegd dat opdrachtnemers werken conform Systems Engineering (SE). SE is een benadering, waarbij informatie wordt gegenereerd en gestructureerd door middel van het doorlopen van processen. Het volgen van SE processen leidt tot informatie die in Structuren kan worden vastgelegd. Tussen Structuren bestaan relaties. Om informatie-uitwisseling te toetsen zijn relaties tussen Eisen met andere Elementen geïdentificeerd. Dit zijn relaties tussen Eisen en Functies (a), Eisen en Organisaties (b), Eisen en Locaties (c), Eisen en Fasen (d), Eisen en Objecten (e) en Eisen en Risico’s (f) getoetst. In de praktijk zijn verschillen in effectieve informatie-uitwisseling getoetst tussen relaties. Een relatie is de relatie tussen bijvoorbeeld Eis en Locatie, zoals de beschikbaarheideisen. Uit de resultaten blijkt dat alleen bij de relatie tussen Eis en Organisatie (b) aan alle vijf de voorwaarden wordt voldaan volgens meer dan 50% van de respondenten. De relatie is echter discutabel als beperkt relaties gelegd worden tussen eisen en andere Structuren, want de informatie context en samenhang mist. Uit het onderzoek blijkt dat vaak niet aan één of meer van de gestelde voorwaarden (1a, 1b, 2, 3 of 4) wordt voldaan. Daarbij is een trend zichtbaar naarmate wordt doorgevraagd naar de kwaliteit van informatie (3 en 4). In de meeste gevallen wordt de informatie relevant gevonden, maar blijkt de informatie niet aanwezig te zijn binnen het project. Als de informatie aanwezig is, dan is deze vaak niet expliciet en niet traceerbaar. Op basis van de bevindingen van de verschillen tussen praktijk en theorie worden aanbevelingen gedaan voor effectievere informatie-uitwisseling. In tabel 1 zijn deze weergegeven. Tabel 1 Lijst met bevindingen en aanbevelingen

Bevindingen en aanbevelingen Bevindingen

Nr.

Aanbeveling

REL-1: Zowel de praktijk als de theorie geeft aan dat informatie meegenomen moet worden AANW-1: Een opdrachtnemer redeneert niet opnieuw vanuit de functies, waardoor een deel van het SE proces niet doorlopen wordt

-

Geen aanbeveling

TV-1

Werkwijze van opdrachtnemers veranderen richting MBSE

TV-3

Aantal relaties bepalen tussen Structuren en binnen Structuren van SE

AANW-2: Verschillen in teams, interpretatie en budgetten leidt tot verschillende informatie-uitwisseling TIJ-1: Onderscheid tussen verschillende Structuren

ON-1 IF-3

Investeren in één centraal informatie management systeem. Reserveer een geldbedrag voor het organiseren van de informatie. Informatie management – blinde vlek binnen projecten

TIJ-2: Het eisen analyse proces wordt niet herhaald

ON-2

Meerdere malen doorlopen processen (o.a. eisen analyse proces)

TIJ-3: In de praktijk ligt de focus op de eisen van het ontwerp en de uitvoeringsfase en niet op het onderhoud. EXP-1: Het eisen analyse proces wordt niet voor alle eisen doorlopen, omdat niet alle eisen worden afgeleid. TRAC-1: Door de beperkte relaties tussen eisen en Structuren mist de informatie context. Dit beperkt de samenhang en context van informatie.

-

Geen aanbeveling voor informatie-uitwisseling. Vergroot kennis van Maintenance Engineering

ON-3

afspraken maken over de interpretatie van ISO 15288 en werken op hetzelfde detailniveau Vanaf de start van een project Structuren opzetten en aan elkaar te relateren om informatie vast te leggen in een System Design

ON-4 TV-2

Onderzoek naar optimale verhouding van Structuren en relaties om informatie in vast te leggen

IF-1

Theoretisch model adopteren en concretiseren

IF-2

Onderzoek doen naar de programmatuur voor een database


De belangrijkste bevinding ligt in het onderkennen dat informatie cruciaal is voor de sturing van processen. Het verdient dan ook de aanbeveling om de informatie-uitwisseling centraal aan te sturen. Als advies wordt één centraal informatie management systeem voorgesteld dat aansluit op de SE processen (ON-1). Een tweede bevinding is de werkwijze van opdrachtnemers. SE wordt voor opdrachtnemers contractueel verplicht door een opdrachtgever en op die wijze als verplichting ervaren. Het gevolg hiervan is dat, generiek gesteld, SE niet gedragen en adequaat wordt toegepast door de aannemende partijen in de markt. Hierdoor vallen gaten in het structureren en borgen van informatie, wat vervolgens leidt tot hogere faalkosten doordat informatie niet tijdig en/of niet volledig ontsloten wordt voor relevante partijen. De auteur adviseert opdrachtnemers om SE meer te gaan beschouwen als een kans. SE kan gebruikt worden als hulpmiddel voor effectieve informatie-uitwisseling tussen teams. Dit is mogelijk door het inrichten en doorlopen van de processen (ON-2), afstemmen van de verschillende interpretaties van de ISO15288 (ON-3) en het vastleggen van gegenereerde informatie in Structuren (ON-4). Met deze veranderingen kan effectievere informatie-uitwisseling plaatsvinden, doordat meer gebruik kan worden gemaakt van informatie die beschikbaar is. Hiermee kunnen zij betere invulling geven aan de vrijheid en verantwoordelijkheid, wat kan leiden een afname van de faalkosten. Dit is een gewenste situatie, zowel voor opdrachtnemers als opdrachtgevers.



Abstract Since ten years contractors receive another question of public clients (government, local authorities) in the Dutch Civil Engineering sector. This question is in the form of integrated contracts, in which design, construction and/or maintenance are clustered. In projects contracted with the contract form Design (D), Built (B), Finance (F) and Maintain (M) the contractor is responsible for the design, construction and maintenance of the asset in question. This market approach results to freedom and responsibility for contractors. Firstly, a contractor has the freedom to make LCB considerations. Secondly, contractors become responsible for the delivery of performance during construction and maintenance. Currently, several Dutch DBFM infrastructure projects are in the pipeline. The government intends to spend the upcoming years more money on projects with the contract form DBFM. The construction has high failure costs with costs are 8-10% of the total contract value (SBR, 2013). A study by USP Marketing (2011) indicates that the failure costs consist in 21% by limited exchange of information. The information exchange is with 2% of the total contract value the biggest factor for failure costs. There is a freedom to make LCB considerations and responsibility for the provision of services for new contractors. This includes the exchange of information in order to make and give meaning to the agreed performance. How do contractors organize the exchange of information with freedom they get for LCB considerations and responsibility for delivering performance? The core issue in this research is that contractors make limited use of information for LCB considerations from various information carriers in practice which determine the life cycle costs. This information is available within the organization, but information on system characteristics and behavior are insufficient exchanged between the design team and the carriers during the design phase. The purpose of this study is to determine whether effective exchanges of information takes place when making design choices and to do recommendations for effective information exchange. The conclusion is that there is insufficient effective exchange of information (1) within Dutch DBFM infrastructure projects. Therefore there is enough untapped potential (2) for a more effective exchange of information. Contractors in Dutch DBFM infrastructure projects do not work according to Systems Engineering (SE) as ideally prescribed by literature. SE is an approach in which information is created by through processes. Following the SE standard leads to Structures in which information can be recorded, stored, shared and recalled Information is structured data that can be recorded on a computer. (Examples are) such as functions, risks, requirements and objects. To determine whether this information exchange is effective, there are conditions established where information must meet. In this study the conditions are based on the problems of LCC analyses. This study defines effective information exchange when information is relevant (1a), available (1b), punctual (2), explicit (3) and traceable (4).


To test the conditions for effective exchange of information in practice, the conditions are processed into questions. These questions are part of interviews. Another part of the interviews are the DBFM contract requirements. Within a DBFM contract the requirements should be central to several teams of a contractor. For the interviews are relationships between Requirements and Functions (a), Requirements and Organizations (b), Requirements and Locations (c), Requirements and Stages (d), Requirements and Objects (e) and Requirements and Risks (f) tested. The results show the candidates find information relevant, but the information is not always available. In addition the information available is not on time, not explicitly or not traceable. The differences between theory and practice in information exchange have been identified for five of the six tested relationships. Only the relationships between the Requirements and Organizations (b) are in accordance with the criteria that more than 50% of the respondents are satisfied with all conditions. This relation satisfies the conditions for effective exchange of information, but is debatable. This is debatable, since this relation is the only satisfied relationships between requirements and other Structures. Therefore there is missing information for context and coherence. Contractors think that by allocating requirements on parts of the organization is sufficient for working with SE. Contractors experience SE in practice as a form of managing the requirements, imposed by public clients. In addition, in practice, the focus is located on the requirements of the design and the construction and not in the maintenance. This does not in accordance for LCB considerations. The main recommendation is to send in information exchange, whereby one central information management system (ON-1) is needed that addresses the processes of employees in the project. A second recommendation is a change of working and vision of contractors. SE is contractually obliged for contractors by a client. A contractor should see SE more as a chance. SE can be used as a tool for information exchange. A contractor should do SE as an opportunity. To take this opportunity the different recommendations need to be done for effective exchange of information: execute the processes (ON-2), interpret the ISO15288 together (ON-3) and capture the generated information in Structures (ON-4). Then information can become more timely, explicit and traceable. With these changes effective information exchange can take place and contractors can make LCB considerations according to the agreed performance. Upholding the freedom and responsibility can lead to a reduction in failure costs through more effective information exchange.


Inhoudsopgave DEEL A OPZET .......................................................................................................................................................19 1

2

INTRODUCTIE...............................................................................................................................................21 1.1

VERANDERINGEN VOOR OPDRACHTNEMERS .....................................................................................................22

1.2

AFBAKENING ONDERZOEK ...........................................................................................................................29

CONCEPTUEEL ONTWERP ONDERZOEK ........................................................................................................31 2.1

AANLEIDING ............................................................................................................................................31

2.2

DOELSTELLING .........................................................................................................................................34

DEEL B THEORIE....................................................................................................................................................39 3

4

SYSTEMS ENGINEERING ...............................................................................................................................41 3.1

SYSTEMEN...............................................................................................................................................41

3.2

SE PROCES ..............................................................................................................................................44

3.3

VASTLEGGEN VAN INFORMATIE IN STRUCTUREN VOLGENS SE ...............................................................................49

3.4

PRODUCT 1: THEORETISCH MODEL SYSTEMS ENGINEERING .................................................................................53

3.5

BEANTWOORDING DEELVRAAG 1 ..................................................................................................................54

LIFE CYCLE BASED AFWEGINGEN ..................................................................................................................55 4.1

LCC ANALYSES .........................................................................................................................................55

4.2

PROBLEMEN BIJ LCC ANALYSES.....................................................................................................................57

4.3

PRODUCT 2: VOORWAARDEN VOOR EFFECTIEVE INFORMATIE-UITWISSELING ............................................................59

4.4


DEEL C RESULTATEN .............................................................................................................................................61 5

6

INTERVIEWPROTOCOL .................................................................................................................................63 5.1

EISEN DBFM CONTRACT ............................................................................................................................63

5.2

RESPONDENTEN .......................................................................................................................................65

RESULTATEN PRAKTIJK.................................................................................................................................67


6.1

DATA ANALYSE INTERVIEWS .........................................................................................................................67

6.2

PRODUCT 3: RESULTATEN UIT DE PRAKTIJK ......................................................................................................84

6.3


DEEL D DISCUSSIE .................................................................................................................................................87 7

VERSCHILLEN EN OVEREENKOMSTEN ..........................................................................................................89 7.1

ANDERE RESULTATEN UIT DE PRAKTIJK ............................................................................................................89

7.2

GENERALISEERBAARHEID VAN DE CASUS VOEGOVERGANGEN ................................................................................91

7.3

VERSCHILLEN EN OVEREENKOMSTEN THEORIE EN PRAKTIJK...................................................................................94

7.4

PRODUCT 4: VERSCHILLEN ANALYSE THEORIE EN PRAKTIJK ................................................................................. 100

7.5

BEANTWOORDING DEELVRAAG 4 ................................................................................................................ 101

DEEL E EVALUATIE ..............................................................................................................................................103 8

CONCLUSIES ...............................................................................................................................................105

9

AANBEVELINGEN .......................................................................................................................................107 9.1

AANBEVELINGEN VOOR THEORIEVORMEND ONDERZOEK .................................................................................... 107

9.2

AANBEVELINGEN VOOR OPDRACHTNEMERS ................................................................................................... 108

9.3

AANBEVELINGEN DATABASE ITER FIDELIS....................................................................................................... 110

10

REFLECTIE ..................................................................................................................................................113

11

BRONNENLIJST ...........................................................................................................................................115 11.1

BOEKEN................................................................................................................................................ 115

11.2

TIJDSCHRIFTARTIKELEN ............................................................................................................................. 115

11.3

INTERNET BRONNEN ................................................................................................................................ 116

11.4

INTERVIEWS........................................................................................................................................... 118


Lijst met figuren Figuur 1 Structuurbeschrijving van het onderzoek. .................................................................................. 6 Figuur 2 oude situatie en nieuwe situatie (in het geval van een DBFM contract) ....................................21 Figuur 3 Publieke en private partij (actoren) binnen een DBFM weginfrastructuurproject, aangepast van (De Wit, 2013) .......................................................................................................................................22 Figuur 4 Life Cycle systeem, aangepast van (Taylor, 1981) ......................................................................23 Figuur 5 Schematische representatie van de werking van een DBFM contract (PPS netwerk, 2013) .......24 Figuur 6 Informatie-uitwisseling tussen teams van Ontwerp, Bouw en Onderhoud (nieuwe situatie) .....25 Figuur 7 Oude versus nieuwe situatie bij projecten ................................................................................26 Figuur 8 Informatie-uitwisseling tussen disciplines en teams van Ontwerp, Bouw en Onderhoud in de nieuwe situatie ......................................................................................................................................26 Figuur 9 Informatie-uitwisseling tussen disciplines en teams van Ontwerp, Bouw en Onderhoud in de nieuwe situatie ......................................................................................................................................28 Figuur 10 Systeemgrens van de actoren in dit onderzoek binnen een DBFM weginfrastructuurproject ..30 Figuur 11 Dimensies voor informatie-uitwisseling in dit onderzoek ........................................................30 Figuur 12 V-model, aangepast van (Werkgroep leidraad SE, 2009) .........................................................43 Figuur 13 Generieke werkwijze tijdens de ontwerpfase, geïnterpreteerd van Martin (1997) ..................44 Figuur 14 SE Proces, aangepast van Department of Defense (2001) .......................................................46 Figuur 15 Meerdere iteratieslagen in de ontwerpfase (Werkgroep leidraad SE, 2009) ............................47 Figuur 16 Voorbeeld van contracteisen en afgeleide eisen bij het project N35 Nijverdal (Berg, 2010) .....48 Figuur 17 Specificeren en ontwerpen, aangepast van (BAM, 2008) ........................................................48 Figuur 18 geschaald en opvolgend decomponeren, aangepast van (Oostinga, 2011) ..............................50 Figuur 19 Theoretisch model ..................................................................................................................53 Figuur 20 Afhankelijkheid van de voorwaarden onderling ......................................................................59 Figuur 21 Overzicht opbouw deel 2 en deel 3 programma van eisen in DBFM contracten (Rijkswaterstaat, 2012) ..........................................................................................................................64


Figuur 22 verzamelde data over relatie tussen Eis en Functie .................................................................68 Figuur 23 verzamelde data over relatie Eis Organisatie verantwoordelijk voor eisen ..............................69 Figuur 24 verzamelde data verantwoordelijkheid per onderdeel ............................................................70 Figuur 25 verzamelde data over beschikbaarheid eisen per Locatie .......................................................72 Figuur 26 verzamelde data over Locatie eisen van kunstwerken ............................................................73 Figuur 27 Verzamelde data van eisen over de onderhoudsstrategie .......................................................75 Figuur 28 Verzamelde data van eisen per Fase .......................................................................................76 Figuur 29 Verzamelde data eisen uit kunstwerken .................................................................................78 Figuur 30 Verzamelde data eisen vanuit asfalt .......................................................................................79 Figuur 31 Verzamelde data eisen en Risico’s ..........................................................................................81 Figuur 32 Andere ontwerpkeuzes waarbij beschikbaarheid een rol speelt ..............................................91 Figuur 33 Visualisatie per voorwaarde ...................................................................................................94 Figuur 34 Informatie is relevant bij relaties a t/m f .................................................................................95 Figuur 35 Informatie is aanwezig bij relaties b t/m f ...............................................................................95 Figuur 36 Informatie is beschikbaar bij relaties b t/m e ..........................................................................97 Figuur 37 Informatie is expliciet bij relatie b ...........................................................................................98 Figuur 38 Informatie is traceerbaar bij relatie b......................................................................................99


Lijst met tabellen Tabel 1 Lijst met bevindingen en aanbevelingen ..................................................................................... 8 Tabel 2 Lijst met termen en afkortingen en introductie binnen onderzoek .............................................18 Tabel 3 Oorzaken faalkosten in projecten (Hull, 2005)............................................................................31 Tabel 4 Overzicht werkwijze onderzoek .................................................................................................36 Tabel 5 Lijst met belangrijkste Structuren, geïnterpreteerd van Oostinga (2011) ....................................52 Tabel 6 Allocatie problemen op voorwaarden voor effectieve informatie-uitwisseling ...........................58 Tabel 7 Voorwaarden voor effectieve informatie-uitwisseling ................................................................59 Tabel 8 Overzicht opbouw programma van eisen DBFM contracten (Rijkswaterstaat, 2012) ..................63 Tabel 9 Lijst met geanonimiseerde respondenten en projecten .............................................................66 Tabel 10 Kruistabel met percentages per voorwaarde voor effectieve informatie-uitwisseling ...............82 Tabel 11 Resultaten effectieve informatie-uitwisseling bij de casus voegovergangen per relatie ............84 Tabel 12 Problemen bij LCC analyses in de theorie en afspiegeling van de praktijk .................................89 Tabel 13 Succesfactoren voor informatie-uitwisseling als afspiegeling van de interviews .......................90 Tabel 14 Verschillenanalyse theorie en praktijk ....................................................................................100 Tabel 15 Samenvatting bevindingen op basis van verschillen en overeenkomsten. ..............................101 Tabel 16 Samenvatting conclusies en aanbevelingen............................................................................111


Afkortingen en termen Tabel 2 Lijst met termen en afkortingen en introductie binnen onderzoek

Afkorting

Engelse term

Nederlandse term

Geïntroduceerd in:

DBFM

Design, Build, Finance & Maintain

Ontwerp, bouw, financiering en onderhoud Definitief Ontwerp

0

FBS FMECA GIS LCB LCC LBS MBSE OBS OBBS PBS PROBS RAMS

Functional Breakdown Structuur Failure Mode and Effects and Criticality Analyses Geographical Information System Life Cycle Based Life Cycle Costs Location Breakdown Structuur Model Based Systems Engineering Organization Breakdown Structuur Objective Breakdown Structuur Phase Breakdown Structuur Process Breakdown Structuur Reliability, Availability, Maintainability and Safety

0 2 0

RBS

Requirement Breakdown Structuur

Functie Structuur Faalmode, effect en kritieke analyse Geografisch Informatie Systeem Life Cycle based Levenscycluskosten Ruimtelijke Structuur Model Based Systems Engineering Organisatie Structuur Doelen Structuur Fasen Structuur Processen Structuur Betrouwbaarheid, beschikbaarheid, onderhoudbaarheid en veiligheid Eisen Structuur

RIBS RWS

Risk Breakdown Structuur -

SBS SD SE SEP SO SOI VO WBS UO

System Breakdown Structuur System Design Systems Engineering Systems Engineering Process

Hoofdstuk

DO

System Of Interest Work Breakdown Structuur -

Risico Structuur Organisatie: Rijkswaterstaat (publieke opdrachtgever) Objecten (systemen) Structuur System Design Systems Engineering proces Schetsontwerp Systeem binnen (beperkt) belang Voorlopig Ontwerp Werkpakketten Structuur Uitvoerings Ontwerp

3

0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 3 0 3 0 3

De definities zijn in bijlage 1 te vinden.


Deel A Opzet

Deel A Opzet

Deel B Theorie




Deel C Resultaten

Deel D Discussie


(4)



Deel Evaluatie

Veldonderzoek




LEGENDA Theorie

Empirie

Producten

(1)




1 Introductie Tot tien jaar geleden besteedde de overheid in de bouwsector het ontwerp, de bouw en het onderhoud in aparte contracten aan. Dit noemt men het traditionele bouwproces. Sinds 2004 werkt Rijkswaterstaat (RWS) binnen de Grond-, Weg-, en Waterbouw (GWW) sector met het principe “de markt, tenzij”. Het principe 'de markt, tenzij' betekent dat taken die RWS traditioneel zelf uitvoerde op het gebied van aanleg, beheer en onderhoud van wegen en waterwegen, worden overgedragen aan de markt (opdrachtnemers). RWS beschrijft welke functies de te bouwen, ontwerpen en/of te onderhouden infrastructuurmoet vervullen, maar laat het ontwerp en de daadwerkelijke oplossing over aan marktpartijen (opdrachtnemers). RWS geeft daarbij invulling aan de trend van de overheid om zich terug te trekken en meer aan de markt over te laten (Rijksoverheid, 2012). Het middel dat wordt gebruikt door opdrachtgevers om de activiteiten in verschillende fasen van het bouwproces te bundelen zijn geïntegreerde contractvormen (Lenferink, 2012). Een van de redenen voor de bundeling is dat het bouwproces ingewikkelder wordt doordat steeds meer partijen betrokken zijn. Een tweede reden voor deze bundeling door opdrachtgevers is dat de markt activiteiten in verschillende fasen van het bouwproces beter kan managen en beheersen en de risico’s bij de partij liggen die hem het beste kan beheersen. Opdrachtgevers hebben verschillende mogelijkheden in contractvormen om de markt te benaderen. Zij kunnen ontwerp en de bouw gezamenlijk (D&C) aanbesteden, maar ook ontwerp, bouw, onderhoud en financiering (DBFM) gezamenlijk aanbesteden (Lenferink, 2012). RWS lijkt van deze werkwijze haar vruchten te plukken. Zij geven aan tot op een contractwaarde van 6 miljard euro een financiële meerwaarde van 700 miljoen gecreëerd te hebben tot 2012 (Rijksoverheid, 2012). De algemene rekenkamer geeft een genuanceerder beeld van deze meerwaarde, maar geeft bevestigd dat de DBFM contracten meerwaarde bieden (Algemene rekenkamer, 2013). De overheid heeft de intentie om de komende jaren meer projecten aan te besteden waarin het ontwerp, de bouw en het onderhoud in één contract te bundelen. Het DBFM contract is daarom de standaard voor complexe weginfrastructuurprojecten binnen Nederland (Ministerie van Financiën, 2012). Toelichting DBFM Met een DBFM contract ontwerpt (Design), bouwt (Build), financiert (Finance) en onderhoudt (Maintain) de markt de infrastructuur en krijgt de markt betaald voor geleverde prestaties. Geleverde prestaties betreft in DBFM weginfrastructuurprojecten de beschikbaarheid van de infrastructuur en het niveau van de dienstverlening. Typische doorlooptijden van DBFM contracten die op dit moment worden gerealiseerd zijn 25 tot 30 jaar (PPS netwerk, 2013).

In de toelichting wordt gesproken over ontwerpen, bouwen en onderhouden. Figuur 2 geeft de fasen en de rol van het DBFM contract weer in de oude en nieuwe situatie voor opdrachtnemers. Oude situatie (traditioneel) Idee

Ontwerp

Bouw

Beheer en onderhoud

Nieuwe situatie (DBFM contract) Publieke sector

Idee

Contracten

DBFM Contract

Ontwerp

Bouw

Beheer en onderhoud Contracten

Private sector Private sector

Figuur 2 oude situatie en nieuwe situatie (in het geval van een DBFM contract)


In het voorbeeld zijn twee veranderingen gevisualiseerd. Het onderscheid zit tussen de publieke en private sector. De eerste verandering is dat de opdrachtgever één contractuele relatie heeft met de opdrachtnemer (DBFM contract). Ten tweede vraagt de overheid niet om een product, maar om een dienst in de vorm van een prestatie, namelijk een beschikbare weginfrastructuur voor de doorlooptijd van het contract. Deze weginfrastructuur moet voldoen aan de eisen in het DBFM contract. Met deze veranderingen ontstaat contractueel één schakel tussen de opdrachtgever (onderdeel van de publieke sector) en de opdrachtnemers (onderdeel van de private sector) van het project, zoals in figuur 3 te zien is. Publieke opdrachtgever Publieke sector

DBFM contract Private sector

Financiers

DBFM consortium

Aandeelhouders

Onderaannemers

Figuur 3 Publieke en private partij (actoren) binnen een DBFM weginfrastructuurproject, aangepast van (De Wit, 2013)

Het DBFM contract vormt de schakel tussen de publieke sector en de private sector (markt). De markt bestaat uit private partijen (consorten) die zich in een consortium als één projectorganisatie (PPS Netwerk, 2013). De projectorganisatie huurt onderaannemers in, zorgt voor de financiering van het project en heeft de verantwoordelijkheid naar haar aandeelhouders. De marktbenadering van RWS resulteert in meer vrijheid, maar ook in meer verantwoordelijkheid voor opdrachtnemers. In de volgende paragraaf worden de veranderingen voor opdrachtnemers in de private sector (markt) en de gevolgen van deze veranderingen uiteengezet.

1.1 Veranderingen voor opdrachtnemers De veranderingen in vrijheid en verantwoordelijkheid, die contractueel worden vastgelegd tussen opdrachtgever en opdrachtnemer, leiden voor een opdrachtnemer onder andere tot twee belangrijke veranderingen in haar werkwijze (PPS netwerk, 2013): 1. Een opdrachtnemer heeft de ontwerpvrijheid om de beste keuzes te maken over de gehele contractduur, de zogenoemde Life Cycle Based (LCB) afwegingen. Een afweging is Life Cycle Based, omdat de gestelde eisen voor ontwerp, realisatie en onderhoud uit het contract de basis vormen voor een keuze. Een LCB afweging maakt het mogelijk voor opdrachtnemers om keuzes te maken die niet alleen gebaseerd zijn op bouwkosten, maar ook op onderhoudskosten; 2. Een opdrachtnemer is verantwoordelijk voor het leveren van prestaties die in het contract zijn opgenomen. Dat betekent dat de duur van de Life Cycle gebaseerd moet zijn op het contract en de contractduur van het project. Deze twee veranderingen voor de opdrachtnemer worden kort toegelicht in de onderstaande subparagrafen. Thesis Jeremy de Bruijn_5-12-2013 22

1.1.1

Life Cycle Based afwegingen

Een LCB afweging betekent voor opdrachtnemers dat zij in het ontwerp de afweging moeten maken tussen investeren tijdens de bouwfase of later investeren tijdens de onderhoudsfase. De essentie van LCB afwegingen is dat gestuurd wordt op de laagste kosten gedurende de hele levenscyclus. Meer of minder investeren in eerdere fasen betekent dat er in latere fasen meer of minder kosten gemaakt worden. Dat kan leiden tot een besparing op het gehele project(Taylor, 1981). Daarom bestaat er een relatie tussen de ontwerpkeuzes die gemaakt moeten worden in de ontwerpfase met de kosten voor bouw (realisatie), onderhoud en sloop. De ontwerpfase, bouwfase, onderhoudsfase en sloopfase worden de Life Cycle genoemd. Figuur 4 geeft het Life Cycle systeem weer met de kosten inter-relaties.

Kosten inter-relaties

Plannen

Identificeer eisen

Voorspellen

Ontwerp (ontwikkel)

Bouw (installeer)

Monitoren

Onderhoud en beheer

Sloop

Feedback

Figuur 4 Life Cycle systeem, aangepast van (Taylor, 1981)

In het Life Cycle systeem zijn de kostenrelaties tussen verschillende fasen te zien. Uit onderzoek (Taylor, 1981) blijkt dat 65% van de kosten wordt bepaald door het ontwerp en dat na oplevering 90% van het kostenpatroon in een project vast ligt voor de toekomst. Opdrachtnemers moeten daarom afwegingen maken in de ontwerpfase die het kostenpatroon voor een groot deel van het project vastleggen. In het onderstaande voorbeeld zijn dilemma’s bij LCB afwegingen weergegeven. Voorbeeld: dilemma’s bij afwegingen Meer investeren in de realisatie door duurdere materialen te kiezen kan goedkoper onderhoud opleveren, maar waar is de grens? Dilemma’s in LCB afwegingen zijn (Taylor, 1981):  Korte termijn versus lange termijn;  Preventief onderhoud versus correctief onderhoud;  Bouwkosten versus onderhoudskosten;  Kosten versus zekerheid van prestaties.

Opdrachtgevers betalen naar het functioneren van de weginfrastructuur in DBFM projecten (PPS netwerk, 2013). De benoemde dilemma’s hebben dus betrekking op zowel de kosten als de opbrengsten (zekerheid van opbrengsten) voor een opdrachtnemer.


De betalingen van opdrachtgevers zijn in de vorm van beschikbaarheid vergoedingen, opgedeeld in tijdseenheden en locaties van de infrastructuur (Rijkswaterstaat, 2012; Koster, et al., 2008). In figuur 5 is de werking van een DBFM contract te zien.

Figuur 5 Schematische representatie van de werking van een DBFM contract (PPS netwerk, 2013)

Onder de dikke streep zijn in het oranje de voorbereidingskosten te zien en in het rood de bouwkosten. In het blauw zijn de kosten voor de financiering te zien en in het lichtblauw de kosten voor extra onderhoud. In elke fase zijn kosten, maar dit geldt niet voor de opbrengsten (Koster, et al., 2008). Boven de streep zijn in het groen de standaard betalingen (opbrengsten) te zien die een opdrachtnemer krijgt als de weginfrastructuur beschikbaar is. Een opdrachtnemer krijgt een eenmalige betaling na voltooiing van het project en vervolgens standaard betalingen tijdens de onderhoudsfase (Koster, et al., 2008). Hieruit blijkt dat een opdrachtnemer rekening moet houden met de onzekerheid van opbrengsten. De onzekerheid wordt bepaald door het product en de prestatie eisen die contractueel zijn vastgelegd (PPS Netwerk, 2013). LCB afwegingen vragen aldus om een zorgvuldige afweging tussen eisen (afgesproken prestaties), risico's en investeringen gedurende de levenscyclus van een project. Voor een opdrachtnemer betekent dit dat zij de LCB afwegingen moeten maken op basis van de kosten tijdens het project en de zekerheid van de opbrengsten van de infrastructuur, in dit onderzoek de levenscycluskosten. Om levenscycluskosten te bepalen kan gebruik worden gemaakt van levenscycluskosten (LCC) analyses (Department of Defense, 2001; Jonge, 2010). Het doel van een LCC analyse is het in beeld brengen van de invloed van eisen (afgesproken prestaties) op de levenscycluskosten om zo een LCB afweging te kunnen onderbouwen. Om een LCB afweging te kunnen maken zullen verschillende criteria meegenomen moeten worden. In onderstaand voorbeeld is het project A15 Maasvlakte-Vaanplein te zien (A-Lanes A15, 2012). Daarin is naast de omvang van het project te zien. In het voorbeeld van de A15 Maasvlakte-Vaanplein zijn bij de omvang van de ontwerpopdracht van een opdrachtnemer de criteria te zien.


Voorbeeld van A15: omvang ontwerpopdracht DBFM project en criteria voor afwegingen (A-Lanes A15, 2012) Omvang project   

Criteria

37 kilometer wegverbreding; Bouw 12 nieuwe kunstwerken Handhaven 36 kunstwerken.

      

Integraliteit; Vergunningen; Uitvoerbaarheid Onderhoudbaarheid; Risico management; Kostenaspecten; Planning.

De bovenstaande criteria voor afwegingen zijn bij een project. Een project is gedefinieerd als een unieke en tijdelijke onderneming om een uniek product of service te verlenen. Tijdelijk betekent dat elk project een duidelijk begin en een duidelijk eind heeft. Een projectteam is gedefinieerd als het team dat verantwoordelijk is voor het uitvoeren van activiteiten om het project te voltooien. Een projectorganisatie heeft een eigen identiteit, zodat zij samen kunnen werken met een gemeenschappelijk set van waarden en normen om de projectdoelstellingen van het project te behalen (Verbraeck, 2012). Teams hebben dus in projecten met verschillende criteria te maken die relevant zijn voor afwegingen. Voor het maken van LCB afwegingen moeten verschillende teams met elkaar informatie uitwisselen die betrekking hebben op de criteria. Dit betreft de organisatieonderdelen (teams) die verantwoordelijk zijn voor Ontwerp, Bouw en Onderhoud. In figuur 6 is informatie uitwisseling tussen deze teams in de nieuwe situatie geschetst. Publieke sector

Idee

Publieke sector

DBFM Contract

Ontwerp

Bouw

Beheer en onderhoud Contracten


Legenda Informatie-uitwisseling (opdrachtgever) Informatie-uitwisseling (opdrachtnemers)

Figuur 6 Informatie-uitwisseling tussen teams van Ontwerp, Bouw en Onderhoud (nieuwe situatie)

De nieuwe situatie biedt kansen voor opdrachtnemers om optimalisaties voor bouw en onderhoud op te nemen in het ontwerp, kortom een LCB afweging maken. Zij moeten dan de informatie met elkaar uitwisselen. Dit betreft niet alleen de teams die verantwoordelijk zijn voor Ontwerp, Bouw en Onderhoud, maar ook de combinatie van de disciplines Wegen, Kunstwerken en Installaties. Figuur 7 geeft de oude en nieuwe situatie weer met betrekking tot disciplines.


Oude situatie (traditioneel)

Nieuwe situatie (DBFM contract)

WEGEN (ASFALT) Idee RWS

Ontwerp RWS

Bouw

Beheer en onderhoud

Opdrachtnemer

RWS

Financiering: RWS

KUNSTWERKEN (BETON) Idee RWS

Ontwerp RWS

Bouw

WEGEN, KUNSTWERKEN EN INSTALLATIES

Opdrachtnemer

Ontwerp

Idee

Beheer en onderhoud

RWS

RWS

Bouw

Beheer en onderhoud

Opdrachtnemer Opdrachtnemer

Financiering: RWS

Opdrachtnemer

Financiering: Opdrachtnemer

INSTALLATIES Idee RWS

Ontwerp

Bouw

RWS

Opdrachtnemer

Beheer en onderhoud RWS

Financiering: RWS

Figuur 7 Oude versus nieuwe situatie bij projecten

In de afbeelding is geredeneerd vanuit het perspectief van aannemers van de bouw (Werkgroep leidraad SE, 2009). Voor het maken van LCB afwegingen kan dus ook informatie tussen de disciplines wegen, kunstwerken en installaties uitgewisseld worden. Figuur 8 geeft deze situatie weer.

Publieke sector

Idee

Publieke sector

DBFM Contract

Ontwerp Wegen, Kunstwerken, Installaties

Bouw

Beheer en onderhoud

Wegen, Kunstwerken, Installaties


Contracten


Legenda Informatie-uitwisseling (opdrachtgever) Informatie-uitwisseling (opdrachtnemers) Figuur 8 Informatie-uitwisseling tussen disciplines en teams van Ontwerp, Bouw en Onderhoud in de nieuwe situatie

De opdrachtnemer krijgt de kans om fasen én disciplines op elkaar af te stemmen in de LCB afwegingen. De kans is nieuw, omdat in het verleden een de disciplines bij opdrachtnemers gescheiden waren. Met vrijheid komt een verantwoordelijkheid. In de volgende subparagraaf komt de verantwoordelijkheid voor de opdrachtnemer aan bod.


1.1.2

Verantwoordelijk voor prestaties binnen projecten

De tweede verandering in de werkwijze van de opdrachtnemers is de verantwoordelijkheid die opdrachtnemers krijgen. Opdrachtnemers worden verantwoordelijk voor het leveren van de gevraagde prestaties in het contract. Dat betekent dat de duur van de Life Cycle voor een opdrachtnemer is gebaseerd op het contract en de contractduur van het project. In een DBFM contract wordt de levenscyclus van Ontwerp, Bouw en Onderhoud van een project beschouwd. Om als opdrachtnemer LCB afwegingen te kunnen maken is het aldus van belang om te weten wat in het contract uitgevraagd wordt aan prestaties in een contract. Om te voldoen aan de eisen, zoals de prestatie eisen, zal een opdrachtnemer informatie-uitwisseling zelf moeten organiseren binnen een project. Kortom, een opdrachtnemer moet de interne projectomgeving managen. De interne projectomgeving is een gedefinieerde hoeveelheid activiteiten, die eenmalig in een bepaalde tijd voor een vastgesteld bedrag moet worden gerealiseerd. Daarbij moet uit de informatie van verrichte activiteiten informatie-uitwisseling plaatsvinden. In vorige subparagraaf is geconstateerd dat binnen projecten door verschillende teams wordt gewerkt. Deze teams verrichten activiteiten binnen een project waar informatie uit voortkomt. In het voorbeeld op de volgende pagina is de interne projectomgeving van een opdrachtnemer te zien bij het project A15 Maasvlakte-Vaanplein.

Voorbeeld van omvang project, criteria en ontwerpopdracht in DBFM project (A-Lanes A15, 2012) Omvang project   

37 kilometer wegverbreding; Bouw 12 nieuwe kunstwerken; Handhaven 36 kunstwerken.

Criteria       

Integraliteit; Vergunningen; Uitvoerbaarheid Onderhoudbaarheid; Risico management; Kostenaspecten; Planning.

Wat betekent dit aan activiteiten en informatie?      

Uitvoering start na 1 jaar ontwerp; > 4000 tekeningen >1000 rapporten/ nota’s; >4500 eisen verifiëren; In circa 3 jaar ontwerptijd; Circa. 120 medewerkers.

In het voorbeeld zijn in kolom drie de informatie karakteristieken in tijd, omvang en complexiteit te zien waar een opdrachtnemer voor staat. In drie jaar tijd moeten dus 4000 tekeningen, 1000 rapporten en 4500 eisen geverifieerd worden met een team van 120 medewerkers. De hoeveelheid informatie die tot stand komt en uitgewisseld moet worden binnen een project is dus groot. Dat zijn niet alleen de activiteiten binnen DBFM project, maar tevens de informatie die geproduceerd, verwerkt, afgeleid en uitgewisseld moet worden. Informatie is data die door een computer begrepen kan worden (Dale, 2013). Denk bijvoorbeeld aan de eisen van een project die vastgelegd worden in een database. Daarmee wordt informatie gecategoriseerd en gestructureerd. Complexiteit in Nederlandse weginfrastructuurprojecten betreft niet alleen de omvang van een project, maar betreft ook meerdere dimensies van een project, zoals techniek, Organisatie en omgeving (BoschRekveldt, Jongkind, Mooi, Bakker, & Verbraeck, 2009). RWS geeft aan dat Nederlandse weginfrastructuurprojecten complex zijn en een resultaat is van een intensieve samenwerking tussen Thesis Jeremy de Bruijn_5-12-2013 27

verschillende partijen (Rijksoverheid, 2012). In de theorie over complexiteit van ontwerpprocessen zijn verschillende vormen van complexiteit te onderscheiden, zoals de externe projectomgeving, interne projectomgeving en het sociale netwerk (Van Esch, 2007). Dit onderzoek heeft betrekking op de projectomgeving van een opdrachtnemer en wordt daarbinnen complex genoemd. Informatieuitwisseling tussen teams lijkt eenvoudig, maar gezien de complexiteit van weginfrastructuurprojecten wordt een LCB afweging ingewikkeld. Daardoor bestaat de behoefte van opdrachtnemers om deze informatie te managen en te Structureren om zo tot LCB afwegingen te komen. Binnen Nederlandse DBFM weginfrastructuurprojecten wordt informatie door opdrachtgevers gestructureerd volgens SE Life Cycle processen (Rijkswaterstaat, 2012). De SE Life Cycle processen zijn processen om een systeem te ontwikkelen volgens de ISO15288 (Nederlands Normalisatie Instituut, 2008). In de ISO15288 zijn processen voorgeschreven (Nederlands Normalisatie Instituut, 2008). In deze norm is beschreven op welke wijze de processen worden opgesteld. SE is een interdisciplinaire benadering, die bijdraagt aan het ontwikkelen en realiseren van succesvolle systemen (Leidraad SE voor de GWW- sector, 2009). SE is een benadering, waarbij informatie gegenereerd en gestructureerd wordt door middel van het doorlopen van processen. Dit betekent dat SE zorgt voor gestructureerd werken volgens gedefinieerde processen. Een opdrachtnemer wordt contractueel verplicht om volgens de ISO15288 haar processen in te richten. In figuur 9 is te zien hoe vanuit de gedachte van SE de teams van ontwerp, realisatie en onderhoud worden verbonden en de disciplines wegen, kunstwerken en installaties worden geïntegreerd.

Publieke sector

Idee

Publieke sector

DBFM Contract

Ontwerp

Bouw


SE

Beheer en onderhoud


SE

SE

SE


SE


Legenda Informatie-uitwisseling (opdrachtgever) Informatie-uitwisseling (opdrachtnemers) SE

Systems Engineering

Figuur 9 Informatie-uitwisseling tussen disciplines en teams van Ontwerp, Bouw en Onderhoud in de nieuwe situatie

In dit onderzoek staat informatie-uitwisseling centraal, waarbij informatie volgens de procesbenadering SE tot stand komt. Systems Engineering is een verzameling processen en dus een procesbenadering. De informatie die tot stand komt wordt vastgelegd in Structuren die in een database worden opgenomen. Voorbeelden zijn eisen en objecten (Werkgroep leidraad SE, 2009)


1.2 Afbakening onderzoek In deze paragraaf zal de systeemgrens van het onderzoek worden toegelicht. Dat gebeurt door enkele afbakeningen te maken naar aanleiding van wat in de voorgaande paragraaf uiteengezet is. 1. Nederlandse DBFM weginfrastructuurprojecten. In dit onderzoek is gekeken naar effectieve informatie-uitwisseling bij Nederlandse weginfrastructuurprojecten die aanbesteed zijn met de contractvorm DBFM. Daarbij wordt beperkt tot de informatie-uitwisseling binnen DBFM projecten. 2. Opdrachtnemer (consortium) DBFM project. Dit onderzoek gaat over informatie-uitwisseling binnen de interne projectomgeving van de opdrachtnemer. In dit onderzoek wordt de informatie-uitwisseling tussen opdrachtgever en opdrachtnemer buiten beschouwing gelaten. Daarom vallen de dialoogfasen en wijzigingen van de opdrachtgever buiten de scope van dit onderzoek. 3. Actoren binnen DBFM project. In dit onderzoek gaat het om het maken van LCB afwegingen in de ontwerpfase. Daarbij wordt gekeken naar informatie-uitwisseling binnen het DBFM consortium als eindverantwoordelijke voor de afstemming van informatie-uitwisseling van informatie in het project. In dit onderzoek wordt dus geen aandacht besteed aan de financiering. Daarom worden banken en aandeelhouders niet in dit onderzoek meegenomen. 4. Wijze van organiseren en verscheidenheid bedrijven. Een DBFM consortium is vaak een combinatie van bedrijven (consorten). Dit kan van invloed zijn op de wijze waarop een opdrachtnemer is georganiseerd. In dit onderzoek wordt geen onderscheid gemaakt in de wijze van organiseren van een opdrachtnemer, noch de verschillende bedrijven die werkzaam zijn binnen een consortium. 5. Teams (Organisatie onderdelen). Bij het maken van ontwerpkeuzes vindt informatieuitwisseling plaats tussen verschillende teams van een opdrachtnemer. In dit onderzoek wordt beperkt het team dat het systeem (project) ontwerpt, het team dat het systeem bouwt (realiseert) en het team dat het systeem gaat onderhouden. Het ontwerpteam maakt de ontwerpkeuze en wordt tijdens het ontwerpproces geadviseerd door het realisatieteam en het onderhoudsteam. Het realisatieteam en onderhoudsteam worden informatiedragers genoemd. 6. Disciplines. Binnen weginfrastructuurprojecten wordt traditioneel een verdeling gemaakt naar de disciplines wegen, kunstwerken en installaties. Binnen dit onderzoek worden in een casus civiele ontwerpkeuzes van een weginfrastructuurproject onderzocht en daarom worden alleen de disciplines kunstwerken en wegen meegenomen. 7. Ontwerpfase. In elk project zijn rollen gedefinieerd die vervuld worden in meerdere fasen van een project. Dit onderzoek beperkt zich tot de ontwerpfase. De ontwerpfase voor een opdrachtnemer bestaat uit de tenderfase en de fase na gunning. 8. Systems Engineering is de wijze waarop informatie gegenereerd en gestructureerd wordt. Met deze benadering komt informatie voort uit processen en wordt informatie op die manier gegenereerd en gestructureerd. In figuur 10 en figuur 11 zijn deze afbakeningen gevisualiseerd. Thesis Jeremy de Bruijn_5-12-2013 29

Publieke opdrachtgever Publieke sector

DBFM contract Private sector

Financiers

DBFM consortium

Aandeelhouders

Onderaannemers

Figuur 10 Systeemgrens van de actoren in dit onderzoek binnen een DBFM weginfrastructuurproject

Het figuur geeft het speelveld tussen actoren bij een DBFM project aan binnen Nederlandse weginfrastructuurprojecten (afbakening nr. 1). Het blauwe vlak geeft de afbakening aan waarbinnen zich binnen dit onderzoek informatie-uitwisseling tussen plaatsvindt (afbakening nr. 2 en 3). Binnen een DBFM consortium is onderzoek naar informatie-uitwisseling afgebakend tot de teams van het ontwerp, bouw en onderhoud binnen het DBFM consortium (afbakening nr. 5 en 6). In figuur 11 is de afbakening van teams binnen dit onderzoek te zien.

Informatie-uitwisseling in de ontwerpfase OntwerpTender

Verantwoordelijke teams per fase Ontwerp

Ontwerp Na gunning

Per discipline

Bouw Kunstwerken

Wegen

Onderhoud

Figuur 11 Dimensies voor informatie-uitwisseling in dit onderzoek

In het volgende hoofdstuk wordt het conceptueel ontwerp van het onderzoek uiteengezet.


2 Conceptueel ontwerp onderzoek 2.1 Aanleiding Zoals in de introductie is beschreven zijn er veranderingen op gang in de Nederlandse GWW sector. Deze veranderingen creëren de mogelijkheid om LCB afwegingen te maken (PPS netwerk, 2013). Opdrachtnemers moeten hiervoor informatie-uitwisselingen gaan organiseren binnen een project. In de volgende subparagrafen wordt daarom ingegaan op de achtergrond van informatie-uitwisseling binnen projecten. Van daaruit wordt een probleemstelling gedefinieerd waarop dit onderzoek zich zal richten. Ook zal worden uitgelicht wat het belang van dit probleem is. De volgende subparagraaf gaat in op de achtergrond van faalkosten. 2.1.1

De achtergrond

De overheid heeft met haar benadering van de markt gezorgd dat opdrachtnemers de mogelijkheid krijgen om LCB afwegingen te maken. De opdrachtnemers moeten zelf de informatie uitwisselen om LCB afwegingen te kunnen maken. Uit onderzoek is gebleken dat gebrekkige informatie-uitwisseling in het verleden één van de belangrijkste oorzaken van faalkosten was. Faalkosten zijn alle kosten die voor het eindproduct zijn gemaakt, ontstaan door vermijdbaar tekortschieten (SBR, 2013). Faalkosten in de bouwsector zijn 8-10% van de totale bouwkosten (SBR, 2013). Uit internationaal onderzoek van NIST (2002) “Cost Analysis of Inadequate Interoperability in the U.S. Capital Facilities Industrie” blijkt dat interoperabiliteit (communicatie tussen systemen, apparaten of organisaties) voor 2% inkomstenverlies zorgt bij projecten in de Verenigde Staten. In een weginfrastructuurproject van 100 miljoen euro betekent dit dat gemiddeld 2 miljoen euro aan faalkosten worden gemaakt. In tabel 3 is een overzicht te zien van oorzaken van deze faalkosten, waarbij gebrekkige informatie-uitwisseling zelfs op nummer 1 staat. Tabel 3 Oorzaken faalkosten in projecten (Hull, 2005)

Oorzaken faalkosten Gebrekkige (gegevens) uitwisseling en communicatie

21,0%

Tijdens ontwerpfase onvoldoende aandacht voor uitvoerbaarheid

20,0%

Leveren van de kwaliteit aan eindgebruiker staat niet centraal

10,0%

Het Programma van Eisen is van onvoldoende kwaliteit: tijdens het bouwproces zijn veel aanpassingen

9,0%

Informatie-uitwisseling is met 21% de grootste oorzaak van faalkosten (Hull, 2005; USP Marketing consultancy, 2011). Van de faalkosten ontstaat daarbij 25% gedurende de ontwerpfase van een systeem (Hull, 2005). Een opdrachtgever geeft aan dat zij miljoenen euro’s meerwaarde creëerden met de nieuwe vorm van uitvragen. Maar welke gevolgen heeft dit voor opdrachtnemers? Werkt de nieuwe vorm van uitvragen of werkt deze wijze mogelijk averechts voor opdrachtnemers, gezien de karakteristieken van een DBFM project en de kenmerken van de markt zelf? Kortom, nemen de faalkosten of nemen deze mogelijk toe voor een opdrachtnemer?


DBFM projecten binnen Nederland worden gekarakteriseerd door een groot aantal betrokkenen, een grote projectomvang en grote projectteams (Bosch-Rekveldta, Jongkindb, Mooia, Bakker, & Verbraeck, 2011). Binnen de interne projectomgeving bestaat het groot aantal betrokkenen uit verschillende teams. De teams binnen een opdrachtnemer zijn echter van oorsprong gefragmenteerd binnen de GWW sector (BIR, 2012). Optimalisaties in kosten werden doorgaans in één fase van de levenscyclus gemaakt door de in de GWW sector (Werkgroep leidraad SE, 2009). In het onderstaande voorbeeld is de gefragmenteerde input van de markt weergegeven.

Toelichting van de gefragmenteerde input in de GWW sector Publieke opdrachtgever (Overheid)

Marktpartijen

De overheid gebruikt advies van de markt; De overheid huurt capaciteit ingenieurs in;

De overheid zet de capaciteit van bouwbedrijven in; De overheid besteed onderhoud uit.

Interne informatie-uitwisseling

In de toelichting is de gefragmenteerde input van de marktpartijen te zien. De traditionele verdeling is een karakteristiek van de markt. De oranje hokjes in de toelichting komen overeen met de grijze hokjes in figuur 2. De karakteristieken van de markt in relatie tot de karakteristieken van DBFM projecten lijken een invloed te hebben op effectieve informatie-uitwisseling. Dit leidt tot de probleemstelling in de volgende subparagraaf.


2.1.2

Probleemstelling

De intentie van RWS is om faalkosten te verminderen door de markt in te schakelen. De markt krijgt een nieuwe rol en kan faalkosten verkleinen doordat opdrachtnemers de mogelijkheid krijgen om LCB afwegingen kunnen maken. Een ontwerpteam moet componenten van bouw en onderhoud meenemen in het ontwerp om de LCB afweging te kunnen maken. Deze mogelijkheid bestaat doordat het realisatieteam en onderhoudsteam informatie aandragen over deze componenten. Faalkosten worden voor meer dan 20% veroorzaakt door ineffectieve informatie-uitwisseling tussen partijen (teams). De karakteristieken van DBFM projecten met de van oorsprong gefragmenteerde teams kunnen leiden ertoe dat informatie wel aanwezig is binnen een project, maar niet gebruikt wordt bij LCB afwegingen. Hiermee wordt de kans op het verminderen van faalkosten een het risico op hogere faalkosten. Op basis hiervan is de volgende probleemstelling gesteld: Bij het maken van Life Cycle Based afwegingen wordt in de praktijk te weinig gebruik gemaakt van informatie van verschillende informatie dragers die bepalend is voor de levenscycluskosten. Deze informatie is binnen de Organisatie beschikbaar, maar informatie over systeemkenmerken en gedragingen wordt onvoldoende uitgewisseld tussen het ontwerpteam en de informatiedragers tijdens de ontwerpfase.

De volgende subparagraaf gaat over het belang van dit onderzoek. 2.1.3

Belang van het onderzoek

Het consultancy bedrijf Iter Fidelis ziet kansen in de veranderende ontwikkelingen in de GWW sector. Iter Fidelis is een bedrijf dat werkzaam is als consultant voor opdrachtnemers. Zij spelen in op de veranderingen in de contractduur, de focus van de aansturing en de steeds groter wordende ruimte en verantwoordelijkheden die opdrachtnemers krijgen (Iter Fidelis, 2013). Iter Fidelis ziet de centrale rol van informatie als belangrijke ontwikkeling binnen het de sector (Iter Fidelis, 2013), maar ook binnen haar eigen bedrijf. Daarbij wordt gezocht naar mogelijkheden om met behulp van software een kennisdatabase op te zetten. Daarbij zien zie mogelijkheden om informatie van DBFM weginfrastructuurprojecten vast te leggen in verschillende Structuren om deze in vervolgprojecten te kunnen hergebruiken. Dit onderzoek is onderdeel van een eerste verkenning naar een dergelijke database. (Iter Fidelis, 2013). De rol die Iter Fidelis binnen het afstudeeronderzoek heeft is het voorzien in een onderzoeksomgeving. Deze onderzoeksomgeving betreft de dagelijkse begeleiding op de werklocatie en het beschikbaar stellen van haar netwerk. In de achtergrond is geconstateerd dat 21% van de faalkosten ontstaat door gebrekkige informatieuitwisseling. De opdrachtnemer moet veel meer informatie managen en uitwisselen dan in het verleden. Hier is nog weinig onderzoek naar gedaan binnen Nederlandse DBFM weginfrastructuurprojecten. Dit maakt het wetenschappelijk van belang, omdat in het vervolg onderzoek kan doen naar het optimaliseren van informatie-uitwisseling binnen projecten van een dergelijke omvang. Op basis van de probleemstelling wordt in de volgende paragraaf geeft het doel van dit onderzoek besproken.


2.2 Doelstelling Om een oplossing voor dit probleem te maken is het van belang te bepalen in hoeverre informatie tussen ontwerpteam en informatie dragers is uitgewisseld om aanbevelingen te kunnen geven. Op basis van de probleemstelling is de volgende doelstelling gesteld: Het doel van dit onderzoek is om te bepalen of effectieve informatie-uitwisseling plaatsvindt bij het maken van ontwerpkeuzes en aanbevelingen te doen voor effectievere informatie-uitwisseling.

Dit doel wordt bereikt door ten eerste het definiëren van wat er onder effectieve informatie uitwisseling verstaan kan worden; ten tweede het inventariseren in welke mate er volgens deze definitie effectieve informatie-uitwisseling plaatsvindt binnen DBFM projecten. Als laatste door het onderzoeken van handreikingen uit de praktijk en theorie ter bevordering van de effectiviteit van deze informatieuitwisseling. In de volgende subparagraaf worden de onderzoeksvragen uiteengezet. 2.2.1

Onderzoeksvragen

Op basis van de doelstelling is de volgende onderzoeksvraag met daarbij behorende deelvragen opgesteld. Deze deelvragen geven elk antwoord op een onderdeel van de hoofdvraag.

Hoofdvraag: Vindt effectieve informatie-uitwisseling plaats tussen teams van opdrachtnemers binnen Nederlandse DBFM weginfrastructuurprojecten? En kan deze uitwisseling effectiever uitgevoerd worden? Q1. Hoe moet informatie volgens de uitgangspunten van Systems Engineering gestructureerd worden binnen Nederlandse DBFM weginfrastructuurprojecten? Q2. Welke voorwaarden worden aan informatie-uitwisseling gesteld om Life Cycle Based afwegingen te kunnen maken op basis van LCC analyses in de ontwerpfase? Q3. Welke informatie over eisen is wel en welke informatie over eisen is niet effectief uitgewisseld bij de ontwerpkeuze van voegovergangen in Nederlandse DBFM weginfrastructuurprojecten? Q4. Welke verschillen en overeenkomsten zijn te onderkennen tussen de praktijk en de theorie bij ontwerpkeuzes betreffende de informatie-uitwisseling binnen Nederlandse DBFM weginfrastructuurprojecten?


De hoofdvraag is tweeledig. Ten eerste wordt er gevraagd of effectieve informatie-uitwisseling plaatsvindt. Ten tweede wordt er gevraagd of de uitwisseling nog effectiever kan worden uitgevoerd om daarmee aanbevelingen te geven voor opdrachtnemers van DBFM projecten en Iter Fidelis. De volgende vragen geven elk een deel van het antwoord op de hoofdvraag. Deelvraag 1 en 2 zijn theoretisch van aard. Om te bepalen over welke informatie-uitwisseling gesproken kan worden moet duidelijk worden welke informatie wordt gegenereerd en gestructureerd. Binnen de Nederlandse weginfrastructuurprojecten komt informatie tot stand door de processen van SE te volgen. Deze informatie kan vastgelegd worden in Structuren. Om te bepalen of informatie effectief uitgewisseld kan worden, wordt bij deelvraag 1 inzichtelijk gemaakt welke informatie in projecten tot stand komt. De tweede deelvraag geeft antwoord op de vraag wanneer informatie-uitwisseling effectief is. In dit onderzoek is informatie-uitwisseling effectief als voldoen wordt aan verschillende voorwaarden voor informatie-uitwisseling. Deelvraag 2 richt zich op het opstellen van deze voorwaarden. Deelvraag 3 gaat in op de praktijk. In de introductie is geconstateerd dat men in Nederlandse weginfrastructuurprojecten op een andere wijze uitvraagt dan in traditionele verdeling in het bouwproces. Om die reden worden in deelvraag 3 de relaties tussen eisen met andere Elementen getoetst aan de voorwaarden voor effectieve informatie-uitwisseling. Daarbij wordt gekeken naar een ontwerpkeuze die kritiek kan zijn voor het systeem. De keuze voor de casus van een bepaalde ontwerpkeuze volgt daarom uit een analyse van een groot weginfrastructuurproject, waarbij een Faalmode, Effect en Kritieke Analyse is uitgevoerd. Uit deze FMECA volgt dat de voegovergangen één van de meest kritieke onderdelen van het systeem is (A-Lanes A15, 2012). Deelvraag 4 gaat over de verschillen en overeenkomsten tussen de praktijk en de theorie. Deze vraag is noodzakelijk om aanbevelingen te kunnen doen op basis van de verschillen en overeenkomsten tussen praktijk en theorie. In de volgende subparagraaf wordt de werkwijze in dit onderzoek uiteengezet.


2.2.2

Werkwijze van het onderzoek

Om de hoofdvraag en deelvragen (onderzoeksvragen) te beantwoorden zijn onderzoeksstrategieën geformuleerd. Deze gelden als basis van het onderzoeksontwerp (Verschuren & Doorewaard, 2007). Deze verschillende onderzoeksstrategieën zijn verkennend, beschrijvend of vergelijkend en worden elk in een deel van het onderzoek gebruikt. De aansluiting tussen de onderzoeksdelen, onderzoeksvragen, wijze van data verzameling en de producten zijn te vinden in tabel 4. Tabel 4 Overzicht werkwijze onderzoek

Werkwijze van het onderzoek Probleem

Doel

Bij het maken van Life Cycle Based afwegingen wordt in de praktijk te weinig gebruik gemaakt van informatie van verschillende informatie dragers die bepalend is voor de levenscycluskosten. Deze informatie is echter wel binnen de Organisatie beschikbaar. Informatie over systeemkenmerken en gedragingen wordt onvoldoende uitgewisseld tussen het ontwerpteam en de informatiedragers tijdens het ontwerpproces. Het doel van dit onderzoek is om te bepalen of effectieve informatie-uitwisseling plaatsvindt bij het maken van ontwerpkeuzes en aanbevelingen te doen voor effectievere informatie-uitwisseling.

Hoofdvraag

Vindt effectieve informatie-uitwisseling plaats tussen teams van opdrachtnemers binnen Nederlandse DBFM weginfrastructuurprojecten? En kan deze uitwisseling effectiever uitgevoerd worden?

Deel van het onderzoek

Beantwoording vraag

Wijze van dataverzameling

Uitkomst

Onderzoeksvraag1

Proposal problematisering, Literatuuronderzoek

Onderzoeksvraag 2

Literatuuronderzoek

Deel C, Beschrijvend onderzoek

Onderzoeksvraag 3

Interviews Likertschaal

Aanpak, verwacht resultaat, doel van het onderzoek en de onderzoeksopzet Theoretisch model Bepalen wat voor informatie een rol speelt volgens SE, in de vorm van Theoretisch model, bestaande uit Elementen en relaties Voorwaarden voor effectieve informatie-uitwisseling Lijst met voorwaarden voor effectieve informatieuitwisseling Bevindingen huidige informatie-uitwisseling in de praktijk Inzicht in de effectieve informatie-uitwisseling bij de ontwerpkeuze van voegovergangen in de praktijk

Deel D, Vergelijkend onderzoek

Onderzoeksvraag 4

Verschillen analyse

Verschillenanalyse tussen de theorie en de praktijk Verschillen tussen praktijk en theorie

Deel E

Hoofdvraag

Evaluatie

Conclusies, aanbevelingen en reflectie

Deel A Deel B, verkennend onderzoek

De tabel geeft de relatie aan tussen de onderzoeksdelen, de deelvragen en de producten. Deel A en B komen voort uit literatuur- en documentenonderzoek. In deel C worden interviews gehouden. In deel C wordt de mate van effectieve informatie-uitwisseling getoetst. Effectieve informatieuitwisseling is niet eenvoudig te meten. Informatie kan helemaal niet, of voor een deel uitgewisseld worden. Informatie-uitwisseling is dus moeilijk te kwantificeren. Om informatie-uitwisseling te meten wordt gebruik gemaakt van de Likertschaal. De manier waarop wordt gemeten is bepalend voor het niveau van de variabele. De Likertschaal geeft gegevens op ordinaal niveau. Door te werken met een Likertschaal betekent dat de resultaten alleen geordend kunnen worden naar de opinie van de respondent. Bij een ordinale schaal zijn de antwoorden niet relatief van elkaar. De antwoorden kunnen


dus alleen op zichzelf geanalyseerd worden. De antwoorden van de respondenten geven een beeld van effectieve informatie-uitwisseling in de verschillende projecten waarin de case voegovergangen getoetst. Om conclusies te trekken wordt bepaald in hoeverre men in de praktijk invulling geeft aan de voorwaarden voor effectieve informatie-uitwisseling. Om te spreken van effectieve informatieuitwisseling bij een voorwaarde dient minimaal de helft van de respondenten volledig eens te zijn met alle voorwaarden die bij iedere stelling gevraagd worden. De stelling wordt vergeleken met de andere stelling die over vergelijkbare relatie gaat. Indien beide stellingen van één relatie boven 50% uitkomen, kan gesproken worden van effectieve informatie-uitwisseling. In het geval dat personen een beeld schetsen dat compleet anders is dan dat van alle andere respondenten van hetzelfde project, dan is er binnen het project bekeken wat de achtergrond van de respondent is geweest. In de volgende subparagraaf worden de uitgangspunten besproken die binnen dit onderzoek aangehouden worden om het doel te kunnen bereiken. 2.2.3

Uitgangspunten

Om het doel te bereiken zijn een aantal uitgangspunten gedefinieerd waar in de rest van het onderzoek vanuit zal worden gegaan. De uitgangspunten zijn: 1. De ontwerpfase van een opdrachtnemer is te onderscheiden in een aanbestedingsfase en een fase na aanbesteding. De aanbestedingsfase wordt tenderfase genoemd en de fase na aanbesteding wordt de fase na gunning genoemd. In het voortraject van een project heeft een opdrachtgever een deel van het ontwerpproces uitgevoerd volgens SE. Vanaf het moment van aanbesteden zal een opdrachtnemer het ontwerpproces moeten inrichten. Het startpunt om te ontwerpen is voor een opdrachtnemer het DBFM contract; 2. Met twaalf respondenten kan een kwalitatief onderzoek gedaan worden. Op dit moment is een beperkt aantal projecten volgens DBFM aanbesteed, waarbij een beperkt aantal respondenten betrokken is geweest bij specifieke ontwerpkeuzes; 3. In de tenderfase is een ander projectteam bezig dan in de fase na gunning. In beide fasen moet informatie-uitwisseling georganiseerd worden, dus is binnen dit onderzoek geen onderscheid gemaakt tussen de actoren in beide fasen; 4. In projecten wordt door opdrachtnemers gewerkt volgens SE; 5. Levenscyclus (LCC) analyses vormen de basis voor het maken LCB afwegingen; 6. In verband met de grootte van weginfrastructuurprojecten worden deze projecten doorgaans uitgevoerd door meerdere bedrijven in een samenwerkingsverband. Dit soort samenwerkingsverbanden wordt een consortium genoemd. In dit onderzoek wordt uitgegaan dat tussen de bedrijven werkzaam zijn binnen het consortium onderling geen grote verschillen zijn; 7. Er wordt geen onderscheid gemaakt tussen verschillende consorten binnen een consortium; 8. Effectieve informatie uitwisseling wordt benoemd als per stelling 50% van alle voorwaarden van effectieve informatie-uitwisseling voldaan wordt.



Deel B Theorie

Deel A Opzet

Deel B Theorie




Deel C Resultaten

Deel D Discussie


(4)



Deel Evaluatie

Veldonderzoek




LEGENDA Theorie

Empirie

Producten

(1)




3 Systems Engineering In de volgende paragrafen word de werking van SE uiteengezet. Daarbij geeft paragraaf 3.1 een beschrijving van systemen en is paragraaf 3.2 een beschrijving van het proces voor de totstandkoming van informatie. De Structuren waar informatie in vastgelegd kan worden, zijn in paragraaf 3.3 uitgelegd en de relaties tussen deze Structuren worden in paragraaf 0 Vastgelegd als product 1. Tot slot kan dan met de informatie in paragraaf 3.1 tot en met 3.4 de deelvraag in paragraaf 3.5 worden beantwoord.

3.1 Systemen In de systeembenadering wordt de werkelijkheid beschouwd als een systeem. Het uitgangspunt van een systeem is dat het geheel meer is dan de "som" der delen (Veeke, Ottjes, & Lodewijks, 2008). Bij de systeemtheorie staan Elementen (entiteiten), relaties tussen Elementen en attributen (eigenschappen) centraal (In 't Veld, 2002). In onderstaand overzicht zijn de grondbeginselen van SE weergegeven in een figuur.

Uitgangspunten SE: Basisbegrippen systeem Een systeem kan omschreven worden als een verzameling gerelateerde onderdelen die een interdisciplinair geheel vormen binnen een omgeving. In het onderstaande figuur zijn de belangrijkste begrippen weergegeven (In 't Veld, 2002). Systeem = binnen dikke cirkel Grens = dikke cirkel Omgeving = buiten dikke cirkel Entiteit = kleine cirkels Relaties tussen: entiteiten entiteit en omgeving Systemen en omgeving

De uitgangspunten van systemen vormen de basis voor de theorie over SE in dit onderzoek. Elementen en relaties vormen Structuren. In dit onderzoek wordt onderscheid gemaakt naar Structuren, Elementen en relaties. Voor de verduidelijking wordt gesproken over Structuren en Elementen in dit onderzoek. Bij het systeemdenken is het van belang te onderkennen dat iedereen zijn eigen System of Interest (SoI) heeft (INCOSE, 2013). Een SoI is gedefinieerd als het belang van een actor, omkaderd in een systeem. Zo is het SoI van RWS het netwerk van snelwegen, terwijl het SoI van een opdrachtnemer een project is (INCOSE, 2013). Binnen een opdrachtnemer hebben verschillende teams elk een eigen SoI. Een systeem lijkt met deze benadering beheersbaar te zijn door het te verdelen in behapbare delen (Werkgroep leidraad SE, 2009), zogenaamde subsystemen. In de praktijk blijken echter ook problemen te ontstaan bij het opdelen van een systeem. Het voorbeeld van de installaties van een tunnel in de A73 laat dit zien.


Voorbeeld De installaties van de tunnels in de A73 bij Roermond bevatten 56 onderdelen die als apart onderdeel zijn getest. Bij de ingebruikname in januari 2008 bleek echter dat de afstemming tussen de onderdelen problematisch verliep. Tot eind 2009 hebben geregeld afsluitingen plaatsgevonden om maatregelen te treffen om het totale systeem te laten functioneren (Rijksoverheid, 2008).

Het voorbeeld van de installaties in de A73 laat de relevantie zien van het beschouwen van het systeem in zijn geheel, evenals het individueel beschouwen (in dit geval testen) van het systeem. Kortom, men moet optimaliseren binnen subsystemen, maar tevens het grotere geheel in beschouwing blijven houden. Samenvattend, met complexiteit van een systeem wordt een eigenschap van een complex systeem of model bedoeld die niet is af te leiden uit elk van de afzonderlijke componenten maar alleen uit het systeem of model als geheel (In 't Veld, 2002). De reden voor publieke opdrachtgevers (RWS, Prorail) om volgens SE te werken heeft te maken met goede ervaringen in andere branches om de complexiteit te beheersen. SE kan immers zorgen voor een systematische vastlegging van informatie. SE wordt in andere branches zoals in de ruimtevaart, defensie en luchtvaartindustrie, al jaren toegepast (Incose, 2013). Bij deze industrieën zijn betrouwbaarheid en ontwikkeltijd van complexe systemen zeer belangrijk (INCOSE, 2013). In bijlage 2 is een theoretische en praktische invulling van SE te zien. Nederlandse weginfrastructuurprojecten zijn in hoofdstuk 1 bestempeld als complex. Het systeem is complex wanneer het systeem meerdere functies moet vervullen en binnen het systeem, of tussen de verschillende (sub)systemen, onderlinge interactie plaatsvindt. Daarnaast is een systeem complex wanneer het onderhevig is aan verandering (dynamisch) (In 't Veld, 2002). Binnen de interne projectomgeving van een opdrachtnemer is één van de complexe onderdelen het beslissingsproces (Decision Making Process). Het Decision Making Proces binnen SE is het proces dat leidt tot het afleiden van informatie. Het is van belang om het totale systeem te beschouwen waarin informatie wordt gegenereerd en gestructureerd. In de Nederlandse theorie van SE (Werkgroep leidraad SE, 2009) wordt een onderscheid gemaakt in vijf fasen. Dit zijn de conceptfase, de ontwikkelfase, de realisatiefase, de onderhoudsfase en de sloopfase. Volgens het systeemdenken staan de verschillende levenscyclusfasen met elkaar in verbinding (Martin, 1997; INCOSE, 2013; Werkgroep leidraad SE, 2009). Dit sluit aan op de inter-relaties van de kosten van verschillende fasen in figuur 4. Daarmee sluit de procesbenadering aan op LCB afwegingen die een opdrachtnemer moet maken.


De levenscyclusfasen in SE komen overeen met de traditionele verdeling van ontwerp, bouw (realisatie) en onderhoud. Daarbij is de levenscyclusfase ontwikkeling van het systeem in overeenstemming met de ontwerpfase van een project (Werkgroep leidraad SE, 2009). In dit onderzoek wordt de term Ontwerp gebruikt om de fase van ontwikkeling binnen SE aan te duiden. In de Nederlandse GWW sector is het Vmodel de meest gebruikte visualisatie van de levenscyclusfasen (Werkgroep leidraad SE, 2009). In Figuur 12 is het V- model te zien.

Idee DBFM Contract

Ontwerp

em

er

Beheer en onderhoud

Onderhoud g re

po

Uitvoering

ne re

Int e

m

re n

rac

rac co

n

Definitief ontwerp (DO)

Op d

Op d

De

Voorlopig ontwerp (VO)

htg

Schetsontwerp (SO)

htn

ev

er

Bouw

Uitvoeringsontwerp (UO)

Werkvoorbereiding

Figuur 12 V-model, aangepast van (Werkgroep leidraad SE, 2009)

Het V-model gaat ervan uit dat in de ontwerpfase steeds verder gedetailleerd wordt. Daarbij is in het figuur te zien dat in de ontwerpfase een knip zit tussen de opdrachtgever en opdrachtnemer. Een opdrachtgever ontwerpt tot een bepaald detailniveau, het voorlopig ontwerp (VO). Vervolgens gaat een opdrachtnemer het ontwerp verder detailleren binnen de vrijheid die een ontwerper heeft. De vrijheid die een ontwerper heeft wordt bepaald door het VO en de eisen die in een DBFM contract gesteld worden. De eisen uit het contract zijn het startpunt voor het ontwerpteam om van het VO een definitief ontwerp (DO) te ontwikkelen en vervolgens tot een uitvoeringsontwerp (UO) uit te werken. Het deel van de ontwerpfase van een opdrachtnemer is dikgedrukt. Een opdrachtnemer gaat van het VO een DO en Een opdrachtnemer wordt betaald binnen DBFM weginfrastructuurprojecten volgens een betalingsmechanisme, dat gerelateerd is aan de afgesproken prestatie eisen. UO uitwerken. De keuzes die men maakt in de ontwerpfase leiden dus tot detaillering van het systeem. Het ontwerpproces in de ontwerpfase kent daarbij een aantal stappen. In de volgende paragraaf worden de stappen uiteengezet binnen het SE proces.


3.2 SE proces Het SE Proces (SEP) wordt een iteratief en recursief oplossingsproces genoemd (Coins, 2013). Recursief omdat bij iedere iteratieslag in het ontwerpproces eenzelfde proces wordt doorlopen. Iteratief omdat elke iteratieslag een verdiepingsslag in detailniveau is, waardoor het ontwerp van grof naar fijn verloopt. Een oplossingsproces, omdat bij iedere stap keuzes worden gemaakt. Generiek kunnen drie stappen in de ontwerpfase worden onderscheiden bij elk proces (Martin, 1997; Werkgroep leidraad SE, 2009; BAM, 2008): 1. Analyseren; 2. Structureren en Alloceren; 3. Ontwerpen.

Ontwerpen

Specificatie

Analyseren

OUTPUT

Specificeren

INPUT

Specificatie

In figuur 13 zijn de drie stappen weergegeven.

Analyseren

Structureren en alloceren

…..

Figuur 13 Generieke werkwijze tijdens de ontwerpfase, geïnterpreteerd van Martin (1997)

Binnen iedere processtap wordt de informatie vastgelegd. Vastleggen van informatie uit de drie stappen wordt een specificatie genoemd. Dit is van belang om te onderkennen, omdat de informatie dus in Structuren kan worden vastgelegd. In de volgende subparagraaf volgt de toelichting van de verschillende processtappen. Uiteindelijk worden deze processtappen toegepast in het iteratieve proces van het SEP. 3.2.1

Analyseren, Structuren & Alloceren en Ontwerpen

Ieder proces kent drie processtappen. Dit zijn Analyseren, Structureren & Alloceren en Ontwerpen. Analyseren (1) betreft het ontleden van eisen en typeren van de eisen (Martin, 1997). In deze stap wordt de input van het proces aan de hand van de probleemanalyse, doelstellingen, scope en eisen afgeleid tot wat het systeem concreet moet doen en in welke mate. Dit is een iteratief proces. In een specificatie kan dit door de opdrachtnemer verder uitgewerkt worden, waarbij de eerste stap analyseren is. Structureren en Alloceren (2) betekent het creëren van overzicht (Martin, 1997). Structureren en Alloceren zijn stappen bedoeld om een (complex) project deelbaar te maken. Een DBFM weginfrastructuurproject is in hoofdstuk 1 complex genoemd. Daarnaast vragen dergelijke projecten een bijdrage van meerdere disciplines. Door te Structureren en te Alloceren wordt een systeem opgedeeld in deelsystemen en systeemelementen en wordt complexiteit beheerst. Daarbij wordt Thesis Jeremy de Bruijn_5-12-2013 44

gebruik gemaakt van de Objecten Structuur (System Breakdown Structuur, SBS). De SBS is een Structuur die alle objecten indeelt. De eisen die geanalyseerd zijn in de eisenanalyse kunnen vervolgens worden gekoppeld aan het systeem en de deelsystemen. Het is mogelijk zowel eisen als functies te Alloceren aan objecten. Een systeem bestaat hierbij uit meerdere objecten. Hierbij kunnen op verschillende niveaus eisen en objecten gekoppeld worden. De stap Ontwerpen (3) bestaat uit het vastleggen van keuzes (Martin, 1997). Tijdens het ontwerpen wordt naar de oplossing toegewerkt. In dit proces worden oplossingen geverifieerd door een opdrachtnemer. Dit kan leiden tot aanpassing van ontwerp, maar ook tot een aanpassing van de eisen. In deze stap kunnen opdrachtgevers eisen valideren, wat de opdrachtgever mogelijkheid geeft om controles uit te voeren (Werkgroep leidraad SE, 2009). Dit betreft geen informatie-uitwisseling binnen de interne projectomgeving van een opdrachtnemer en valt daarom buiten dit onderzoek. De afstemming van het ontwerp met de overige onderdelen van het systeem is wel onderdeel van dit onderzoek. Dit is de Systeem Analyse en Controle. In de volgende subparagraaf wordt Systeem Analyse en Controle behandeld.


3.2.2

Systeem Analyse en Controle

Een onderdeel dat niet in het generieke SE proces wordt genoemd, maar bij iedere processtap doorlopen moet worden is de Systeem Analyse en Controle (Department of Defense, 2001). In figuur 14 is de het SE proces van Department of Defense (2001) te zien, waarbij elke stap een reflectie op de Systeem Analyse en Controle kent. Process input * Customer Needs/Objectives/Requirements - Missions - Measures of Effectiveness - Environments - Constraints * Technology Base * Output Requirements from Prior Development Effort * Program Decision Requirements * Requirements Applied Through Specifications and Standards System Analysis and Control (Balance)

1) Requirements Analysis * Analyze Missions and Environments * Identify Functional Requirements * Define/ refine Performance and Design Constraint Requirements

Requirements loop 2) Functional Analysis/ Allocation * Decompose to Lower-level Functions * Allocate Performance and Other Limiting Requirements to All Functional Levels * Define/ Refine Functional Interfaces (Internal/External) * Define/Refine/Integrate Functional Architecture

* Trade-Off Studies * Effectiveness Analyses * Risk Management * Configuration Management * Data management * Performance Measurement - SEMS - TPM - Technical Reviews

Design loop 3) Synthesis

Verification

* Transform Architectures (Functional to Physical) * Define Alternative System Concepts, Configuration Items and System Elements * Select Preferred Product and Process Solutions * Define/Refine Physical Interfaces (Internal/External)

Related Terms Costumer = Organizations responsible for Primary Functions Primary Functions = Development, Production/Construction, Verification, Deployment, Operations, Support, Training, Disposal Systems Elements = Hardware, Software, Personnel, Facilities, Data, Material, Services, Techniques

Process output * Development Level Dependent - Decision Database - System/Configuration Item Architecture - Specifications and Baselines

Figuur 14 SE Proces, aangepast van Department of Defense (2001)

De Systeem Analyse en Controle wordt bij elke stap uitgevoerd en zorgt dat het totaalplaatje in beeld blijft (Department of Defense, 2001). Uit het figuur zijn de drie stappen van Martin (1997) te herkennen. De stap Analyse komt overeen met de stap Requirements Analysis. De stap Structureren en Alloceren komt hier overeen met Functional Analysis/ Allocation en de stap Ontwerpen komt overeen met de stap Synthesis. Binnen dit onderzoek is de eerste input van informatie voor het SE proces het DBFM contract van een opdrachtgever (hoofdstuk 1). Daarbij moet een analyse voor doelen, identificeren van functionele eisen als het verfijnen van prestatie eisen en afbakenen van randvoorwaarden plaatsvinden.


Het tweede deel van de input voor SE processen is informatie uit de iteratieslagen. Iteratieslagen moeten door opdrachtnemers uitgevoerd worden in de ontwerpfase om het project gedetailleerder te ontwerpen. Hierdoor wordt informatie gegenereerd. Deze informatie kan worden gestructureerd en daarbij wordt de informatie aan elkaar gerelateerd. Zo wordt in de Functie analyse nieuwe eisen afgeleid en deze gerelateerd aan andere informatie uit SE processen. Tot slot volgt in de synthese het ontwerp en de terugkoppeling naar de eerdere twee stappen. Dit wordt uitgevoerd met interactie van Systeem Analyse en controle. Binnen dit onderdeel vallen onder andere de trade-offs en risico management (Department of Defense, 2001). Daarmee zijn bij de trade-offs van ontwerpkeuzes al deze stappen van belang. 3.2.3

Iteratief proces

De processtappen worden ingezet tijdens elke iteratieslag van het totale System Engineering Proces (SEP). In dit figuur zijn de drie stappen Analyseren, Structuren met Alloceren en Ontwerpen te zien. Bij elke iteratieslag hebben de processtappen een input en een output. SEP is een herhalend proces van analyseren, Structuren en Alloceren en Ontwerpen, waarbij men bij elke stap het systeem verder detailleert (Werkgroep leidraad SE, 2009). Als de iteratieslagen op het SEP van Martin (1997) en Department of Defense (2001) plaatst, dan zorgt elk proces bij een iteratieslag voor afgeleide informatie. In figuur 15 is een overzicht te zien van enkele Structuren van informatie als meerdere iteratieslagen worden uitgevoerd tijdens de ontwerpfase. Idee DBFM Contract

Ontwerp er

re n g re

Uitvoering

ne re

Int e

po SBS

em

ev m

RBS

htn

rac co

n

Definitief ontwerp (DO)

FBS

Onderhoud

rac

SBS

Op d

RBS

Op d

FBS

De

Voorlopig ontwerp (VO)

htg

Schetsontwerp (SO)

Beheer en onderhoud

er

Bouw

Werkvoorbereiding Uitvoeringsontwerp (UO)

FBS

RBS

SBS

Figuur 15 Meerdere iteratieslagen in de ontwerpfase (Werkgroep leidraad SE, 2009)

Zoals in dit figuur te zien is ontstaat bij elke iteratieslag meer informatie uit de SE processen. Deze informatie wordt vastgelegd in Structuren. In het figuur worden deze aangeduid met rondjes, die terugkomen in elke ontwerpslag. Meer over deze structuren volgt in paragraaf 3.3 en 3.4. Eén onderdeel waar meer informatie over ontstaat, zijn de eisen. De eisen zijn een zeer belangrijke Structuur, omdat in DBFM contracten andere type eisen worden gesteld dan in traditioneel contractvormen. Dit verschil in type eisen wordt in hoofdstuk 5 verder behandeld. Dit is nodig voor het veldonderzoek voor deel C. In figuur 16 is een voorbeeld gegeven met het contracteisen en het afleiden van eisen in het project N35 Nijverdal (Berg, 2010).


Opdrachtgever Opdrachtnemer

Oplossingen (SBS)

Eisen (RBS)

Figuur 16 Voorbeeld van contracteisen en afgeleide eisen bij het project N35 Nijverdal (Berg, 2010) Figuur 17 Specificeren en ontwerpen, aangepast van (BAM, 2008)

Uit de 2500 contracteisen zijn later circa 4000 afgeleide eisen ontstaan. Dit betekent dus bijna een factor twee in het aantal eisen dat ontwikkeld wordt door de opdrachtnemer. De eisen die worden gesteld zijn niet allen op hetzelfde niveau binnen een Structuur. In het figuur zie je dit aan de puntige delen die meer in het grijze gebied vallen dan de andere delen. Deze eisen zijn al ver door gespecificeerd door de opdrachtgever en opgenomen in het contract. De eisen ontstaan dus tijdens het doorlopen van het specificatie- ontwerpproces. In deze werkwijze sluit het specificeren en ontwerpen één op één op elkaar, zoals in figuur 17 te zien is. In de linker Structuur is de ontwikkeling van de eisen te zien en in de rechter Structuur de ontwikkeling van de oplossingen, kortom het ontwerp. In het figuur zijn slechts twee Structureren weergegeven. Het doorlopen van de processen creëert de totstandkoming van meer informatie. In de volgende paragraaf wordt ingegaan op verschillende Structuren voor het vastleggen van informatie binnen SE.


3.3 Vastleggen van informatie in Structuren volgens SE Naast het procesmatig doorlopen van SE processen is de andere zijde van SE het vastleggen en uitwisselen van informatie. Hoeber (2012) noemt als grootste problemen de validatie, configuratiemanagement, raakvlakbeheer en traceerbaarheid van informatie bij SE. Dit heeft veel te maken met het onderdeel “Systeem Analyse en controle”. Het oogpunt waaruit Hoeber (2012) zijn onderzoek heeft geschreven is vanuit een ontwerpteam dat een ontwerp moet maken voor een opdrachtgever, zoals RWS of Prorail. De oplossing die hij aandraagt is het werken met een Bouw Informatie Model (BIM) in combinatie met SE. Werken met een BIM kan meerwaarde bieden, maar in zijn onderzoek komt naar voren dat slechts kleine verbeteringen bij configuratiemanagement mogelijk worden (Hoeber, 2012). Dit zijn kritieke Elementen voor een opdrachtnemer, omdat daarmee inzichtelijk wordt in hoeverre de informatie van realisatie en beheer en onderhoud meegenomen is. Voor het koppelen van informatie bestaan verschillende programma's. Huidige hulpmiddelen die ondersteuning bieden zijn bijvoorbeeld Bouw Informatie Model (BIM), relationele databases (zoals Relatics) en Geographic Information System (zoals ArcGis) (Visser, 2013; BIR, 2012; Bouwend Nederland, 2012). Kenmerkend bij iedere tool zijn relaties die gemaakt worden tussen verschillende Structuren waarin informatie wordt vastgelegd. In de context van SE is het logisch dat informatie modellen in opkomst zijn die de verschillende informatie koppelen (Visser, 2013). Binnen de Nederlandse GWW sector wordt hierin onderzoek gedaan (Ruijven, 2013) en praktische invulling aan gegeven (Oostinga, 2011) binnen Nederlandse weginfrastructuurprojecten. In de volgende subparagraaf wordt bekeken welke taal aansluit op het vastleggen van informatie in SE. 3.3.1

Systeemtheorie en semantische manier van werken

Voor het maken van informatie modellen is een “taal” nodig om informatie te koppelen. Met deze taal kan een relatie betekenis krijgen, zodat bijvoorbeeld een database op basis van semantiek kan worden opgezet. Semantiek betekent dat relaties een betekenis krijgen. De systeemtheorie gebaseerd op Elementen, relaties tussen Elementen en attributen (Veeke, Ottjes, & Lodewijks, 2008). Deze basis geldt ook voor semantische databases (wikixl, 2013). Het gebruik van semantische databases is al enige tijd in opkomst bij DBFM projecten (Iter Fidelis, 2013). Andere partijen volgen de ontwikkeling met informatiemodellen ook. Enkele partijen hebben informatie modellen opgesteld (Ruijven, 2013; Oostinga, 2011). Men noemt dit Model Based SE (MBSE), waarbij het model centraal staat. De partijen die werken met informatiemodellen bouwen een System Design (SD). Een SD is het te ontwerpen systeem in de vorm van Structuren (Werkgroep leidraad SE, 2009). Om gebruik te maken van semantische databases dient “zuiver” gewerkt te worden in het SD (Oostinga, 2011; Werkgroep leidraad SE, 2009). Zuiver betekent dat bijvoorbeeld een decompositie van een Objectenstructuur bestaat uit Elementen en één Element een onderverdeling kent van andere Elementen, in dit geval objecten (Werkgroep leidraad SE, 2009). Zuiver betekent naast een pure onderverdeling binnen Structuren ook de relaties tussen Structuren één betekenis moet krijgen. In dit onderzoek wordt beperkt tot relaties die voor kunnen komen tussen Structuren. Daarbij wordt geen aandacht besteed aan de regels voor semantiek binnen de relaties, maar is vastgesteld dat de gedefinieerde relatie moet bestaan.


In de volgende subparagraaf worden verschillende Structuren in SE besproken worden waar informatie in moet worden vastgelegd. 3.3.2

Zuivere Structuren en Structuren voor informatie

Decomposities, of Structuren, binnen SE bestaan volgens de Systeemtheorie (In 't Veld, 2002) uit Elementen en relaties. In dit onderzoek wordt verder elke een decompositie een Structuur genoemd. Een Structuur is een manier waarop een samengesteld geheel is opgebouwd met een logisch verband. Oostinga (2011) geeft aan dat om informatie vast te leggen als Elementen en relaties twee abstractieniveaus nodig zijn. Dit zijn een abstracte en concrete laag. Abstracte Elementen zijn denkbeeldig, omdat ze niet aanwijsbaar zijn (Oostinga, 2011). Concrete Elementen zijn de werkelijke Elementen, ofwel de Elementen die we kunnen aanraken en aanwijzen. Onderscheid maken tussen deze twee abstractie niveaus is van belang voor het maken van een database, maar niet voor dit onderzoek. Het doel van dit deel in het onderzoek is om inzicht te verkrijgen in effectiviteit van informatieuitwisseling. Structuren om informatie in vast te leggen zijn daarbij van belang, maar hierbij hoeft geen invulling te worden geven of een Structuur abstract of concreet is. Om die reden is in dit onderzoek geen onderscheid gemaakt naar abstracte en concrete Elementen. Voor de aanbevelingen in het kader van een database is het wel noodzakelijk dit onderscheid aan te geven. De volgende paragrafen zijn een beschrijving van verschillende Structuren waarin informatie vastgelegd kan worden. De wijze van Structureren is zeer belangrijk bij het SD. Om informatie overzichtelijk te maken wordt de informatie vastgelegd in Structuren, ofwel decomposities. Bij decomponeren kan onderscheid worden gemaakt naar volgordelijke decomposities en geschaalde decomposities. In figuur 18 zijn de verschillen tussen deze decomposities te zien. Structuur SBS

Structuur FBS

Geschaald

Opvolgend

Geschaald

Figuur 18 geschaald en opvolgend decomponeren, aangepast van (Oostinga, 2011)

Om een SD vanaf het begin neer te zetten en informatie af te leiden volgens het SE proces moeten volgordelijke decomposities plaatsvinden (Oostinga, 2011). Een volgordelijke decompositie is de wijze waarop een systeem tot stand komt. Een voorbeeld van een volgordelijke decompositie is de relatie tussen de Functie Structuur (FBS) en Objectenstructuur (SBS) (BAM, 2008; Werkgroep leidraad SE, 2009). Een voorbeeld van volgordelijke decompositie zijn: is gelokaliseerd in, is Locatie voor, is een soort voor, is gegroepeerd in. In paragraaf 3.2 is zijn de SE processen beschreven, waarbij informatie wordt gegenereerd. Door het SE proces te doorlopen zal een systeem ontworpen worden in Structuren die steeds gedetailleerder worden.


Een Structuur ontleden in onderdelen wordt een geschaalde decompositie genoemd. Deze decompositie kent één Structuur. Een voorbeeld is van groot naar klein of van grof naar fijn. Belangrijk bij een geschaalde decompositie is dat geen sprake mag zijn van een andere soort structuur zoals een indeling op groepen, typen, soorten of Locatie (Oostinga, 2011). In het SD komen de verschillen Structuren waarin informatie wordt vastgelegd samen. Binnen dit onderzoek wordt daarom beperkt tot Structuren en relaties tussen Structuren, kortom de volgordelijke decomposities. Volgens In ’t Veld (2002) begint men met het definiëren van wat men wil bereiken met het project en pas later benoemt men welke middelen en eigenschappen van middelen worden ingezet. Bij een volgordelijke decompositie kunnen daarom verschillende niveaus onderscheiden worden (Oostinga, 2011). Dit zijn: - Doelen, ofwel de situaties waar men naar streeft; - Functies, ofwel de activiteiten die door een fysiek Object worden uitgevoerd; - Fysieke objecten, ofwel de middelen waaruit het systeem bestaat. Doelen, functies en fysieke objecten worden als volgt in Structuren opgezet en vastgelegd: - Doelen Structuur (OBBS): een doel wordt gerealiseerd door een Functie uit de FBS; - Functie Structuur (FBS): een Functie wordt uitgevoerd (vervuld) door een fysiek Object uit de SBS. Een goed SD is van belang om onderscheid in verschillende Structuren te kunnen maken. In de theorie zijn verschillende Structuren te vinden. Zo worden op verschillende niveaus doelen, functies en Object afgeleid. In bijlage 3 zijn deze Structuren in een tabel opgenomen. De Structuren die door de meeste theorie invulling krijgen zijn functies, eisen, objecten/ systemen, werkpakketten en Organisatie. Andere informatie, zoals risico’s worden apart gedocumenteerd. Dit is in de vorm van lijsten en niet in een Structuur. Deze wijze kan gezien worden als document based. Nieuwe ontwikkelingen, waarbij model based ontworpen wordt geven echter handvatten voor invulling voor meer Structuren (INCOSE, 2013). Oostinga (2011) noemt bijvoorbeeld acht belangrijke Structuren die van belang zijn voor een SD. Dit zijn doelen, functies, objecten, specificaties, locaties, processen, activiteiten en organisaties. Een reden voor een uitbreiding van de huidige Structuren is om zuiver te werken. Voor alle andere Structuren zou al zuiver moeten worden gewerkt (Werkgroep leidraad SE, 2009), maar in de praktijk worden nog weleens Structuren door elkaar gebruikt (How2SE, 2012; Oostinga, 2011). Op die manier ontstaan hybride Structuren, zoals objecten Structuren waar locaties in de Structuur van objecten verweven zitten (Visser, 2013). Tot dit punt zijn verschillende Structuren van Elementen en relaties genoemd uit de theorie die veel voor komen. Deze bronnen leggen relaties tussen deze Structuren (BAM, 2008; Werkgroep leidraad SE, 2009; Kluis, 2012). Verder zijn in deze paragraaf doelen, locaties, processen en fasen benoemt. Deze worden in veel bronnen niet in een Structuur geplaatst. Als dit wel het geval is, dan is de relatie zeer beperkt tussen deze Structuren met de andere Structuren. In MBSE worden deze koppelingen met andere Structuren wel gelegd (INCOSE, 2013). Dit sluit aan op het systeemdenken uit paragraaf 3.1 (In 't Veld, 2002; Incose, 2013). In tabel 5 is een overzicht te vinden van de verschillende Structuren.


Tabel 5 Lijst met belangrijkste Structuren, geïnterpreteerd van Oostinga (2011)

Vraag

Structuur (Engelse term)

Bestaat uit

1

Welke situatie is gewenst?

Doelen Structuur (Objective Breakdown Structure)

Doelen bij activiteiten

2

hoe gaan we dat bereiken?

Functie Structuur (Functional Breakdown Structure)

Functies van het systeem

3

Welke systemen doen dat?

Objecten Structuur (System Breakdown Structure)

Fysieke objecten in systemen

4

Waar bevinden de systemen zich? Op welke wijze krijgen we die systemen? Wie gaat dat uitvoeren?

Ruimte Structuur (Location Breakdown Structure)

Geometrische afbakeningen

Werkpakketten Structuur (Work Breakdown Structure)

Werkpakkett en om werk te clusteren

Organisatie Structuur (Organisation Breakdown Structure) Eisen Structuur (Requirement Breakdown Structure)

Activiteiten door personen Stukjes tekst

5

6

7

Volgens welke specificaties?

8

Welke risico's zijn van toepassing op systemen? Wanneer ontstaan systemen?

Risico Structuur (Risk Breakdown Structure)

Risico's

Fasen Structuur (Phase Breakdown Structure)

Tijdspad

Volgens welke processen?

Processen Structuur (Process Breakdown Structure)

Generieke activiteiten

9

10

Afkorting Objective Breakdown Structure (OBBS)

Functional Breakdown Structure (FBS) System Breakdown Structure (SBS) Locational Breakdown Structure (LBS)

Work Breakdown Structure (WBS)

Organizational Breakdown Structure (OBS) Requirement Breakdown Structure (RBS)

Risk Breakdown Structure (RIBS)

Phase Breakdown Structure (PBS)

Process Breakdown Structure (PROBS)

Voorbeelden Duurzame infrastructuur, weinig onderhoud, veilig vervoersysteem Verplaatsen water, verbinden weg, tunnel, voegovergang Perceel, wegvak, sub tracé

Kunstwerken 4 ontwerpen

Organisaties, afdeling, personen, functies capaciteit: 4m3/uur, geluidsreductie: 6 dB (A), levensduur: 40 jaar Systeem falen bij niet functioneren voegovergang (door bijvoorbeeld falen) Definitief Ontwerp (DO), Uitvoeringsontwerp (UO) Ontwerpen, bouwen en onderbouwen

Elke Structuur geeft antwoord op een vraagstuk binnen een project. Daarmee wordt de relevantie van een Structuur aangegeven. Verder is in de tabel de afkorting te vinden en zijn voorbeelden gegeven die in een Structuur voor komen. De Structuren vormen input voor product 1, het Theoretisch model.


3.4 Product 1: Theoretisch model Systems Engineering Op basis van de geïdentificeerde Structuren is een Theoretisch model opgezet. Het Theoretisch model bestaat uit Structuren en relaties tussen de Structuren binnen SE. In figuur 19 is het model op basis van systeemtheorie uit paragraaf 3.2 opgebouwd. Relatie systeem – informatie structuren Wordt gerechtvaardigd door

Objectives Breakdown Structure (OBBS)

Heeft betrekking op


Bedreigt

Bedreigt

Genereert

Wordt gerealiseerd door

Wordt beheerst door Functional Breakdown Structure (FBS)

Is afgeleidt in (prestatie)

Requirement Breakdown Structure (RBS)

Is verantwoordelijkheid van

Vindt plaats in Genereert Wordt vervuld door

Hebben betrekking op Moet voldoen aan

Moet voldoen aan

Is verantwoordelijk van

Genereert

Locational Breakdown Structure (LBS)

Bevindt zich op

Is bepalend voor System Breakdown Structure (SBS)


Realiseert


Wordt uitgevoerd in

Van toepassing in

Heeft betrekking op

Verantwoordelijk voor


Organizational Breakdown Structure (OBS)

Verantwoordelijk voor

Wordt uitgevoerd tijdens

Wordt uitgevoerd door

Hebben belang bij

Legenda Objective Breakdown Structure (OBBS)

Functional Breakdown Structure (FBS)

Doelen structuur

Functie structuur

System Breakdown Structure (SBS)


Objecten structuur

Ruimtelijke structuur



Werkpakketten structuur

Organisatie structuur


Eisen structuur



Risico structuur


Fasen structuur

Processen structuur

Interne structuur

Figuur 19 Theoretisch model

In het overzicht zijn de belangrijkste Structuren opgenomen die worden onderscheiden. De afkortingen en kleuren van de verschillende Structuren van tabel 5 komen overeen met het Theoretisch model. Voor meer informatie over de Structuren is in bijlage 3 een overzicht van verschillende Structuren te zien die in de literatuur voorkomen. In de werkelijkheid zijn nog meer Structuren te verzinnen, zoals betaling Structuur en contracten Structuur (How2SE, 2012). Een Betalingen Structuur is van belang bij de financiering. Een Contracten Structuur is van belang voor het managen van onderaannemers. Beide Structuren zijn echter niet van belang voor een LCB afweging. De tien Structuren die wel van belang zijn binnen dit onderzoek mogen niet los van elkaar gezien worden. Kortom, de relaties tussen Structuren zijn van belang. Op basis van paragraaf 3.1 tot en met 3.4 kan antwoord worden gegeven op deelvraag 1.


3.5 Beantwoording deelvraag 1 In dit hoofdstuk wordt antwoord gegeven op deelvraag 1:“Hoe moet informatie volgens de uitgangspunten van Systems Engineering gestructureerd worden binnen Nederlandse DBFM weginfrastructuurprojecten?” Op basis van de voorgaande paragrafen kan geconcludeerd worden dat informatie in tien Structuren kan worden vastgelegd om daarmee “zuiver” te Structureren. Een “zuivere” Structuur is bijvoorbeeld dat in de Objecten Structuur enkel objecten opgenomen worden en niet naar Locatie wordt opgedeeld (Oostinga, 2011). Dit maakt het noodzakelijk om informatie te ontsluiten door gebruik te maken van verschillende Structuren en relaties tussen deze Structuren. Op basis van de uitgangspunten van SE zijn de volgende Structuren geïdentificeerd waar informatie in gestructureerd moet worden: 1. Doelen; 2. Functies; 3. Objecten; 4. Eisen; 5. Organisaties; 6. Locaties; 7. Risico’s; 8. Fasen; 9. Werkpakketten; 10. Processen. De bovenstaande Structuren zijn opgenomen in het Theoretisch model van figuur 19. Andere Structuren zijn mogelijk, maar zijn niet van belang voor een LCB afweging. De Structuren staan in relatie met elkaar. De relaties zijn in figuur 19 gedefinieerd. De Structuren mogen niet los van elkaar gezien worden. Voor het veldonderzoek zal het Theoretisch model gebruikt worden om relaties tussen Structuren te toetsen. Een Structuur bestaat uit Elementen en voor de toets zal daarom de relaties tussen twee Elementen getoetst worden. De Structuren en Relaties zullen getoetst worden in het veldonderzoek in deel C. In eerste instantie zal in hoofdstuk 5 de afbakening tot één Element en relatie met andere Structuren worden gemaakt. Om te bepalen wanneer sprake is van effectieve informatie-uitwisseling wordt in hoofdstuk 4 gedefinieerd wat effectieve informatie-uitwisseling is. In dit onderzoek staan het beslissingsproces centraal en daarom zal in het volgende hoofdstuk LCB afwegingen centraal staan.


4 Life Cycle Based afwegingen Dit hoofdstuk zal antwoord geven op de vraag welke voorwaarden gelden voor effectieve informatieuitwisseling om LCB afwegingen te kunnen maken in de ontwerpfase. Paragraaf 4.1 beschrijft LCC analyses voor het maken van LCB afwegingen. In paragraaf 4.2 worden de problemen bij deze afwegingsmethodiek beschreven. In paragraaf 4.3 volgen de criteria voor effectieve informatie-uitwisseling. Tevens worden in paragraaf 4.4 is de voorwaarden benoemd als product 2 en de beantwoording van de hoofdvraag gegeven.

4.1 LCC analyses Een opdrachtnemer wil een LCB afweging maken om een positieve balans tussen kosten (investering) en opbrengsten (baten) te verkrijgen, ofwel de levenscycluskosten. Om de levenscycluskosten te bepalen kan men levenscycluskosten (LCC) analyses uitvoeren (Werkgroep leidraad SE, 2009). LCC analyses kunnen in de ontwerpfase ondersteuning bieden om de juiste afwegingen te maken voor optimalisatie van het systeem over de gehele levenscyclus (Werkgroep leidraad SE, 2009). Dit draagt bij aan het doel van SE, namelijk het optimaliseren van systemen gedurende de levenscyclus door te sturen op de waarde van de systemen en de functies (Werkgroep leidraad SE, 2009). Om helder te krijgen wat de invloed van toegevoegde functionaliteiten en eisen is op de levenscycluskosten en te ontdekken welke varianten interessant zijn, is in dit onderzoek gekozen voor de LCC analyse. De LCC analyse is geen eenmalige actie, maar een continu proces. Om LCC analyses uit te voeren dient men kennis te nemen van de eisen. In deze paragraaf zal beperkt aandacht worden gegeven aan deze eisen, omdat in hoofdstuk 5 dieper wordt ingegaan op de eisen voor DBFM contracten. In deze paragraaf worden wel de prestatie eisen (RAMS eisen) benoemd, die centraal staan in DBFM projecten.

Voorbeeld RAMS eisen De Opdrachtgevers willen bij DBFM projecten dat het systeem op een bepaald prestatieniveau wordt gehouden (Breemer, Al-Jibouri, Veenvliet, & Heijmans, 2009). Presteren van een systeem wordt bepaald op basis van verschillende aspecten. Deze aspecten worden door RWS RAMS aspecten genoemd, waarbij RAMS staat voor Reliability, Availability, Maintainability and Safety (Rijkswaterstaat, 2011). Analyse methodieken zoals FMECA, FTA en RCA kunnen ingezet worden om te bepalen welke prestaties geleverd worden op de aspecten betrouwbaarheid, beschikbaarheid, onderhoudbaarheid en veiligheid (Markeset & Kumar, 2003). De aspecteisen zijn door opdrachtgevers afgeleid tot prestatie eisen op systeemniveau.

De aspecteisen zijn dus criteria en gelden als input voor het ontwerp in de ontwerpfase om te zorgen dat het systeem de prestaties gaat leveren die gewenst zijn (Markeset & Kumar, 2003). Deze eisen zullen in een LCC analyse meegenomen moeten worden, maar gelden dus niet voor een object, maar een systeem. Dit is belangrijk om te onderkennen, omdat meerdere onderdelen van een project met deze eisen rekening moeten houden.


Naast de levenscycluskosten dienen bij een LCC analyse de gemiste opbrengsten meegenomen te worden. Opdrachtnemers worden betaald naar de beschikbaarheid van de weginfrastructuur voor een langere termijn (Rijkswaterstaat, 2012). De prestatie eisen zijn contractueel vastgelegd. De informatie die beschikbaar is voor een LCB afweging wordt bepaald door eisen in het contract en het afleiden van eisen door een opdrachtnemer naarmate men verder in de ontwerpfase komt (Werkgroep leidraad SE, 2009). Het onderzoek van de Jonge (2010) volgt de procesbenadering SE en geldt daarom als input voor dit onderzoek. De Jonge heeft een vijftal Elementen aangehouden om LCC analyses uit te voeren, waarbij in het onderzoek de context van SE en informatie die daarmee tot stand komt meegenomen. Daarmee is het procesmodel geschikt voor beperkt gebruik in een eenvoudige context. Het LCC procesmodel van De Jonge (2010) geeft aan dat juiste uitvoering van SE een van de randvoorwaarden is voor afwegingen bij ontwerpkeuzes. De Jonge (2010) gaat in zijn onderzoek er vanuit dat men het SE proces doorloopt en opdrachtnemers aan de voorwaarden voor informatie-uitwisseling invulling geven. In paragraaf 3.2 zijn drie stappen benoemd in het SE proces die doorlopen moeten worden. Door het doorlopen van deze stappen komt informatie tot stand. In paragraaf 3.4 zijn Structuren te vinden waar informatie in gestructureerd kan worden tijdens het doorlopen van het SE proces. Deze informatie kan dus gebruikt om voorwaarden voor effectieve informatie-uitwisseling te bepalen om LCC analyses te kunnen maken. Deze voorwaarden identificeren is nodig, omdat tijdens het maken van LCC analyses een aantal problemen aanwezig zijn. In de volgende komen de problemen aan de orde.


4.2 Problemen bij LCC analyses Verschillende onderzoeken zijn gewijd aan hoe levenscycluskosten (LCC) analyses gemaakt moet worden. Toch wordt niet veel gewerkt met LCC analyses. Wubbenhorst (1986) en Ellram (1994) hebben de problemen bij het maken van LCC analyses in vier categorieën verdeeld. Dit zijn: 1. Informatie; 2. Configuratiemanagement; 3. Kosten; 4. Cultuur en onwetendheid. De effectiviteit van informatie-uitwisseling bij LCB afwegingen wordt bedreigd door deze potentiële problemen. Om effectieve informatie-uitwisseling bij LCB afwegingen te kunnen toetsen dienen de problemen geconcretiseerd te worden naar meetbare variabelen. In de volgende paragraaf worden de problemen van LCC analyses gerelateerd aan voorwaarden voor effectieve informatie-uitwisseling. In de volgende alinea’s worden deze problemen concreet gemaakt naar het definiëren van voorwaarden voor effectieve informatie-uitwisseling. Daarbij wordt per probleem een voorwaarde gedefinieerd. 4.2.1

Informatie

Het probleem bij informatie is dat men pas verder in traject meer zekerheid krijgt. In dit onderzoek is uitgegaan dat informatie-uitwisseling mogelijk is als de informatie tijdig beschikbaar is. De Structuren zijn echter het resultaat van het beslissingsproces. Dit betekent dat de wijze van vastlegging essentieel is om verder op door te bouwen. Daarmee zal de informatie uit het beslissingsproces zich tegelijk moeten ontwikkelen met andere vastgelegde informatie en iteratief van grof naar fijn worden opgebouwd. De potentie voor LCC vermindert en de kosten voor aanpassingen vergroten naarmate het ontwerp ontwikkelt. De grootste kansen liggen dus in de beginfase, maar informatie in de ontwerpfase is vaak nog niet ver genoeg uitgekristalliseerd (Clift, 2003). Hierdoor is weinig zeker, maar LCB afwegingen moeten al gemaakt worden. Eén van de problemen bij LCC analyses is dus dat later in het traject zekerheid ontstaat over de informatie (Woodward, 1997). Niet alle informatie is dus beschikbaar. Met de integratie van de verschillende disciplines kan informatie eerder beschikbaar komen binnen het project. Om LCB afweging te kunnen maken moet de juiste informatie daarbij tijdig beschikbaar zijn vanuit verschillende bronnen en verschillende partijen (Ozbay, Jawad, Parker, & Hussain, 2004). 4.2.2

Configuratiemanagement

Configuratiemanagement is de wijze waarop veranderingen in informatie worden beheerd en doorgevoerd. Het probleem van configuratiemanagement is dat veranderingen vaak andere kostenstructuren brengen. De samenhang van informatie is vaak beperkt waardoor niet duidelijk en traceerbaar is hoe de projectdoelen bereikt worden met de oplossing (Ozkaya & Akin, 2006). Het verband tussen functies, eisen, objecten en het ontwerp is dan niet duidelijk (Hull, 2005). De traceerbaarheid is belangrijk, zodat het resultaat navolgbaar is. Dit is een belangrijk doel van SE. Zowel de decompositie Structuren, het ontwerp als de overige informatie in SE een goede traceerbaarheid moet hebben (Nederlands Normalisatie Instituut, 2008). Dit sluit aan bij het probleem met configuratiemanagement in LCC analyses (Wübbenhorst, 1986; Ellram, 1994). Voor de ontwerpkeuzes is een correcte, volledige en duidelijke overdracht van informatie erg belangrijk. Dit sluit aan op Woodward (1997) dat informatie traceerbaar moet zijn om de LCB afwegingen te kunnen onderbouwen.


4.2.3

Kosten

Het probleem van kosten is dat een beslissing in de ontwerpfase maatgevend is voor de kosten bij realisatie en onderhoud (Taylor, 1981). Om de kosten in te kunnen schatten moet de informatie van ontwerp, realisatie en onderhoud duidelijk vastgelegd zijn. In hoofdstuk 3 is beschreven dat SE uitgaat van een duidelijke, expliciete manier van werken. Met deze werkwijze kan helder inzicht verschaft worden in de opbouw van het systeem (CROW, 2011). Door expliciet te werken kan later ook herleidbaar worden gemaakt op welke wijze eerdere keuzes in het decomponeren en ontwerpen gemaakt zijn. Dit sluit daarmee aan op de geïdentificeerde problemen van veranderingen in kostenstructuren (Wübbenhorst, 1986). De methode van expliciet werken biedt dus een Structuur waarin kan worden aangegeven wat op een bepaald moment over een bouwwerk bekend is. Informatie moet daarom expliciet zijn om informatie uit te wisselen (Werkgroep leidraad SE, 2009). 4.2.4

Cultuur en onwetendheid

Opdrachtnemers concurreerden in het verleden op kosten voor realisatie of onderhoud en niet op levenscycluskosten (BIR, 2012). Dit is een cultuurverandering voor opdrachtnemers, omdat zij kosten van meerdere levenscyclusfasen mee moeten nemen. Een voorbeeld is een ontwerpteam dat wel de eisen van uitvoerbaarheid meeneemt in haar afweging, maar niet de beschikbaarheideisen van het systeem op een specifieke Locatie. Om deze reden is het noodzakelijk om te toetsen of actoren deze informatie relevant vinden. Om informatie beschikbaar te krijgen op korte termijn moet aangeleverde informatie relevant gevonden worden door projectmedewerkers en teams die met informatie moeten werken of de informatie moeten uitwisselen (Werkgroep leidraad SE, 2009). Het probleem van onwetendheid is dat men denkt vaak dat het berekenen van levenscycluskosten erg moeilijk is en extra hulpmiddelen nodig zijn om tot resultaten te komen (Woodward, 1997). Met deze constatering bestaat de kans dat niet alle informatie meegenomen wordt in de ontwerpkeuzes, omdat niet bekend is welke informatie noodzakelijk is voor verschillende actoren binnen een project. Dit sluit aan op de onwetendheid of de informatie binnen een project aanwezig is. Dit probleem is samengevoegd met het culturele probleem, omdat beide voorwaarden bepalend zijn voor de andere voorwaarden voor effectieve informatie-uitwisseling. Op basis van het bovenstaande is een kader gevormd waarbinnen problemen van LCC analyses in relatie staan met informatieuitwisseling. De relatie tussen problemen en voorwaarden is in tabel 6 te vinden. Tabel 6 Allocatie problemen op voorwaarden voor effectieve informatie-uitwisseling

Relatie tussen problemen bij LCC analyses en informatie Voorwaarden voor effectieve informatie-uitwisseling Traceerbaar

Problemen bij LCC analyses

1.

Informatie

2.


3.

Kosten

4.

Cultuur en onwetendheid

Tijdig beschikbaar

Expliciet

Relevant

aanwezig

X X X X

X

De allocatie van de problemen aan voorwaarden is de input voor product 2.


4.3 Product 2: Voorwaarden voor effectieve informatie-uitwisseling Op basis van de allocatie van de voorwaarden op de problemen bij LCB afwegingen is een lijst ontstaan met voorwaarden voor effectieve informatie-uitwisseling. De voorwaarden zijn onderling afhankelijk van elkaar. Daarom zijn de voorwaarden in logische volgorde een lijst geplaatst. Figuur 20 geeft de volgorde van de vragen weer. Oorzaak en gevolg diagram

1. (a) Relevant?

2. Tijdig beschikbaar?

4. Traceerbaar?

Effectieve informatie-uitwisseling

1. (b) Aanwezig?

3. Expliciet?

Figuur 20 Afhankelijkheid van de voorwaarden onderling

De volgorde is als volgt bepaald: als respondenten informatie niet relevant vinden, dan is geen sprake van effectieve informatie-uitwisseling. Als respondenten informatie niet traceerbaar vinden, dan is geen sprake van effectieve informatie-uitwisseling. Alleen als informatie relevant, aanwezig, tijdig beschikbaar, expliciet en traceerbaar is, spreekt men van effectieve informatie-uitwisseling. Relevant en aanwezig hebben betrekking op de kennis van een projectmedewerker. Tijdig beschikbaar, expliciet en traceerbaar hebben betrekking op de kwaliteit van informatie. De indeling met 1(a) en 1(b) geeft de afhankelijkheid weer van vraag 1 op de andere vragen. Als informatie namelijk niet relevant of aanwezig is binnen een project, dan is het onnodig om door te vragen op andere voorwaarden. Alleen als alle voorwaarden gelden is immers sprake van effectieve informatie-uitwisseling. De voorwaarden stellen product 4 voor in tabel 7. Tabel 7 Voorwaarden voor effectieve informatie-uitwisseling

1. (a) (b) 2.

Voorwaarden voor effectieve informatie-uitwisseling Om informatie voor LCB afwegingen te kunnen gebruiken moet informatie relevant gevonden worden. Om informatie voor LCB afwegingen te kunnen gebruiken moet informatie aanwezig zijn. Om informatie voor LCB afwegingen te kunnen gebruiken moet informatie tijdig beschikbaar zijn.

3. 4.

Om informatie voor LCB afwegingen te kunnen gebruiken moet informatie expliciet zijn. Om informatie voor LCB afwegingen te kunnen onderbouwen moet informatie traceerbaar zijn.

De vijf voorwaarden voor effectieve informatie-uitwisseling ingedeeld. Op basis van hoofdstuk 4 kan antwoord worden gegeven op deelvraag 2.


4.4 Beantwoording deelvraag 2 Ter voorbereiding op de dataverzameling is het noodzakelijk om te weten welke voorwaarden aan informatie-uitwisseling worden gesteld. Deze paragraaf geeft antwoord op de vraag “Welke voorwaarden worden aan informatie-uitwisseling gesteld om Life Cycle Based afwegingen te kunnen maken op basis van LCC analyses in de ontwerpfase?” Om te bepalen of de informatie-uitwisseling in de praktijk overeen komt met de theorie, zijn op basis van de problemen uit de theorie over LCC analyses voorwaarden bepaald voor LCB afwegingen te maken. De voorwaarden zijn opgesteld op basis van de allocatie van problemen aan informatie in tabel 6. Er wordt voldaan aan voorwaarden voor effectieve informatie-uitwisseling als: 1. (a) Informatie relevant is; (b) Informatie aanwezig is; 2. Informatie tijdig beschikbaar is; 3. Informatie expliciet is; 4. Informatie traceerbaar is. De voorwaarden voor effectieve informatie-uitwisseling staan in tabel 7. Deze dienen als toetsingskader voor het bepalen van effectieve informatie-uitwisseling om LCB afwegingen te maken. Elke voorwaarde is bij een stelling over de relaties opgenomen als vraag. Bij elke stelling worden dus vergelijkbare vragen gesteld. In hoofdstuk 5 wordt dit als input voor het interviewprotocol gebruikt. De voorwaarden voor informatie-uitwisseling sluiten aan op SE. Een toegevoegde waarde van SE is dat dit niet impliciet, maar expliciet, weloverwogen en naspeurbaar gebeurt. Het ''waarom'' van afwijkingen van de oorspronkelijke vraagstelling moet naderhand altijd herleidbaar zijn. Daarmee dekt het de verschillende problemen van LCB afwegingen af door informatie expliciet en traceerbaar te maken. In dit onderzoek is aangehouden dat de ene voorwaarde afhankelijk is van een andere voorwaarde. De afhankelijkheid is in figuur 20 weergegeven. In het geval dat respondenten informatie vinden dat informatie totaal niet tijdig beschikbaar is, dan zal de informatie ook niet aan de voorwaarden voldoen die daarna volgen. De ene voorwaarde kan dus uitsluiten dat aan andere voorwaarden wel wordt voldaan. Met deze werkwijze zal men rekening moeten houden bij de interpretatie van de resultaten van het veldonderzoek in deel C. In hoofdstuk 5 worden de voorwaarden voor effectieve informatie-uitwisseling gebruikt als input voor het interviewprotocol.


Deel C Resultaten

Deel A Opzet

Deel B Theorie




Deel C Resultaten

Deel D Discussie


(4)



Deel Evaluatie

Veldonderzoek




LEGENDA Theorie

Empirie

Producten

(1)




5

Interviewprotocol

Het veldonderzoek wordt uitgevoerd door interviews te houden onder verscheidene werkvoorbereiders of projectleiders die werkzaam zijn in een DBFM weginfrastructuurproject. De resultaten van deze interviews worden uiteengezet in hoofdstuk 6. De interviews kunnen echter pas worden uitgevoerd als de eisen die in een DBFM contract staan worden gekoppeld met het gerelateerde Element. Daarbij is gebruik gemaakt van product 1 en 2; het Theoretisch model en de voorwaarden voor effectieve informatie uitwisseling. In hoofdstuk 5 wordt de combinatie gemaakt van product 1 en 2 en eisen in de contractvorm Design (D), Built (B), Finance (F) en Maintenance (M). Hieruit volgen interviewvragen voor het veldonderzoek. Hoofdstuk 6 zijn de resultaten van de interviews. De medewerkers die in hun rol betrokken zijn dienen aan vijf kenmerken te voldoen. De kenmerken zijn: 1) 2) 3) 4) 5)

Werkzaam zijn in een DBFM weginfrastructuurproject; Werkzaam binnen het team van Ontwerp, Realisatie of Onderhoud; Werkzaam binnen de disciplines Wegen of Kunstwerken; Werkzaam in de rol van werkvoorbereider/ projectleider van een team; Betrokken zijn bij de ontwerpkeuzes voor voegovergangen.

In de volgende paragraaf volgt een uiteenzetting van de eisen in een DBFM contract.

5.1 Eisen DBFM contract Een opdrachtnemer krijgt betaald naar de beschikbaarheid van de weg (systeem). De betalingen zijn daarbij afhankelijk van de eisen die in het contract gesteld zijn (Rijkswaterstaat, 2012). Een opdrachtgever betaalt dus naar de prestatie van opdrachtnemers op basis van de gestelde eisen uit het contract. Bij een opdrachtnemer staan de eisen centraal. De eisen gelden voor meerdere teams van de opdrachtnemer die werkzaam zijn binnen het project. De eisen van de opdrachtgever zijn geformuleerd in het programma van eisen van de DBFM contracten. Dit programma van eisen bestaat uit vijf delen, zoals weergegeven in tabel 8 (Rijkswaterstaat, 2012). Tabel 8 Overzicht opbouw programma van eisen DBFM contracten (Rijkswaterstaat, 2012) Deel

Toelichting

Deel 1: systeemdefinities Deel 2: outputspecificaties

In de systeemdefinitie staat weergegeven op welke wijze het systeem is opgebouwd. In dit deel staat aangegeven aan welke eisen het systeem, het subsysteem en de objecten moeten voldoen. Hierin staat aangegeven welke eisen aan het management gesteld worden.

Deel 3: managementspecificaties Deel 4: certificatenplan

Deel 5: Afspraken belanghebbenden

Een overzicht van welke certificaten er zijn en wanneer deze verkregen kunnen worden. Aan deze certificaten hangt een eenmalige betaling of een verandering van de hoogte van de beschikbaarheidvergoeding. De koppeling naar de voorgaande twee delen is aanwezig omdat het vervullen van deze eisen bepalen wanneer een certificaat verkregen wordt. Overzicht van de afspraken die de opdrachtgever met de belanghebbenden van het project gemaakt heeft.


In deel 2 en deel 3 staan de daadwerkelijke eisen (Rijkswaterstaat, 2012). Deze zijn in figuur 21 opgenomen. Deel 2: Outputspecificatie

Deel 3: Managementspecificatie

Subsysteem vraagspecificaties    

Functionele eisen Aspect eisen Externe raakvlakeisen Interne raakvlakeisen Object Object vraagspecificaties vraagspecificaties  Functionele  Functionele eisen eisen  Aspect eisen  Aspect eisen  Externe  Externe raakvlakeisen raakvlakeisen  Interne  Interne raakvlakeisen raakvlakeisen

Technische processen

Functionele eisen Aspect eisen Externe raakvlakeisen Interne raakvlakeisen Object Object vraagspecificaties vraagspecificaties  Functionele  Functionele eisen eisen  Aspect eisen  Aspect eisen  Externe  Externe raakvlakeisen raakvlakeisen  Interne  Interne raakvlakeisen raakvlakeisen

Externe raakvlak eisen Interne raakvlak eisen

Project processen

Subsysteem vraagspecificaties    

 

Functionele eisen Aspect eisen

Context processen

 

Project ondersteunende processen

Systeem vraagspecificaties

Figuur 21 Overzicht opbouw deel 2 en deel 3 programma van eisen in DBFM contracten (Rijkswaterstaat, 2012)

Op basis van de eisen in deel 2 en deel 3 in het DBFM contract zijn stellingen opgesteld. Elke stelling stelt een relatie tussen twee Structuren voor. De lijst met stellingen is in bijlage 6 te vinden. Elke Structuur bestaat uit Elementen en relaties tussen Elementen. Om effectieve informatieuitwisseling te bepalen moet vanuit één van de Structuren worden geredeneerd. In dit onderzoek is geredeneerd vanuit de eisen in relatie tot andere Elementen. Figuur 19 is het Theoretisch model. In dit model zijn de relatie van de eisen met andere Structuren te zien. In figuur 19 zijn zes relaties te zien tussen een Eis en een ander Element. Dit zijn de volgende relaties: a) Relatie tussen Eis en Functie; b) Relatie tussen Eis en Organisatie; c) Relatie tussen Eis en Locatie; d) Relatie tussen Eis en Fase; e) Relatie tussen Eis en Object; f) Relatie tussen Eis en Risico. Voor elke relatie van een Eis met een ander Element wordt minimaal één stelling opgenomen in het interview. In dit hoofdstuk is bepaald welke informatie van de eisen uitgewisseld is bij de ontwerpkeuze voor voegovergangen. Om dit te bepalen is per stelling gevraagd in hoeverre invulling wordt gegeven aan de voorwaarden voor effectieve informatie-uitwisseling. Het interviewprotocol is in bijlage 6 opgenomen. De ruwe data van de interviews is in bijlage 7 opgenomen. In de volgende paragraaf wordt een toelichting op de respondenten gegeven.


5.2 Respondenten Deze paragraaf gaat over respondenten om bij de casus voegovergangen te onderzoeken en de toegepaste onderzoeksstrategieën. In de volgende subparagraaf worden de kenmerken van respondenten weergegeven. 5.2.1

Kenmerken

De medewerkers die in hun rol betrokken zijn dienen aan vijf kenmerken te voldoen. De kenmerken zijn: 6) Werkzaam zijn in een DBFM weginfrastructuurproject; 7) Werkzaam binnen het team van Ontwerp, Realisatie of Onderhoud; 8) Werkzaam binnen de disciplines Wegen of Kunstwerken; 9) Werkzaam in de rol van werkvoorbereider/ projectleider van een team; 10) Betrokken zijn bij de ontwerpkeuzes voor voegovergangen. Binnen de Organisatie van een project werken meerdere teams samen. Om LCB afwegingen te maken dient binnen een project informatie uitgewisseld te worden tussen de verschillende teams. Deze teams zijn te onderscheiden in een ontwerpteam, realisatieteam en onderhoudsteam en in disciplines Wegen en Kunstwerken. De teams worden aangestuurd door projectleiders. Elke projectleider is verantwoordelijk voor een deel van ofwel het ontwerp, ofwel de realisatie, ofwel het onderhoud. De projectleider ontwerp maakt de ontwerpkeuzes. De projectleiders realisatie en onderhoud adviseren in de ontwerpfase de ontwerpende partij. Voor de interviews zullen daarom actoren die de rol van projectleider hebben binnen een DBFM weginfrastructuurproject worden geïnterviewd. Actoren in de rol van projectleiders zijn eindverantwoordelijke binnen een team. Zij hebben overzicht op raakvlakken met andere projectleiders en zijn betrokken bij ontwerpkeuzes. De projectleiders zijn ervaringsdeskundigen in projecten waar het ontwerp, de realisatie en het onderhoud onder de verantwoordelijkheid van een opdrachtnemer vallen. Binnen DBFM weginfrastructuurprojecten worden meer rollen vervuld dan de betrokken rollen binnen dit onderzoek. In bijlage 6 zijn verschillende rollen benoemd die vervuld worden binnen deze projecten. Projectmanagers worden niet betrokken in dit onderzoek, zij niet betrokken zijn bij LCB afwegingen voor ontwerpkeuzes. Leveranciers en onderaannemers worden niet betrokken in dit onderzoek, omdat zij in onderaanneming werken en niet behoren tot het DBFM consortium. In het geval dat een respondent op een andere wijze betrokken is geweest bij ontwerpkeuzes, is de mogelijkheid gegeven om dit in te vullen. Deze mogelijkheid is een extra kolom in de interviewlijst geworden. Naast de codering per fase en discipline is een onderscheid gemaakt naar de fase waarin de respondent betrokken is geweest. Dit betreft dit de tenderfase en de fase na gunning. Dit onderscheid is gemaakt om eventueel een verklaring te kunnen geven bij verschillende antwoorden. In de antwoorden van de respondenten zal alleen een verklaring worden gezocht als geen duidelijk beeld naar voren komt van de antwoorden. De volgende subparagraaf gaat over de strategie om respondenten te benaderen.


5.2.2

Strategie

Op basis van bovenstaande doelgroep zijn bij dit onderzoek twee strategieën gebruikt om de respondenten te vinden. Door gebruik van maken van een doelgerichte steekproef en door de sneeuwbalsteekproef. De strategie van de doelgerichte steekproef, waarbij de groep uit de populatie vooraf geselecteerd is op bepaalde kenmerken die als karakteristiek worden beschouwd voor de hele groep, zijn tien respondenten gevonden. Gezien het beperkte aantal actoren die in de rol van projectleider zowel bij voegovergangen betrokken is binnen de context van DBFM projecten is daarom als tweede strategie het sneeuwbaleffect ingezet. Hierbij zijn op aangeven van geïnterviewde personen nieuwe personen naar voren gekomen, die voldeden aan de gestelde kenmerken. Dit heeft ertoe geleidt dat twee extra respondenten naar voren zijn gekomen. In tabel 9 is de lijst met geanonimiseerde respondenten opgenomen. Tabel 9 Lijst met geanonimiseerde respondenten en projecten Nr.

Rol

Discipline

Fase

Codering

1 2 3 4 5 6 7 8 9 10 11 12

Projectleider ontwerp

Kunstwerken

Ontwerp na gunning

OK1

Projectleider realisatie

Kunstwerken

Ontwerp tender en ontwerp na gunning

PK1


Kunstwerken


OK2


Wegen

Ontwerp na gunning

OW1

Projectleider onderhoud

Wegen en kunstwerken


PO1


Realisatie Wegen

Ontwerp na gunning

OW2


Wegen

Ontwerp tender

PW1



Ontwerp tender

PO2


Wegen

Ontwerp na gunning

PW2



Ontwerp na gunning

PO3



Ontwerp tender

PO4


Wegen

Ontwerp na gunning

PK2

Voor de casus voegovergangen zijn respondenten van verschillende Nederlandse DBFM weginfrastructuurprojecten geïnterviewd. De respondenten zijn gecodeerd. De codering is aan de rechterzijde te zien. In de codering is het onderscheid naar Ontwerpleider Kunstwerken (OK), Projectleider Kunstwerken (PK), Ontwerpleider Wegen (OW), Projectleider Wegen (PW) en Projectleider Onderhoud (PO) gemaakt. Indien respondenten een quote geven zal deze codering gebruikt worden om aan te duiden welke respondent wat gezegd heeft. Aan de codering zie je direct de rol en discipline van de desbetreffende respondent. De bovenstaande lijst van geanonimiseerde betrokkenen zijn werkzaam bij verschillende bedrijven met elk haar eigen bedrijfscultuur. Dit komt de representativiteit ten goede, omdat niet tot één bedrijfscultuur beperkt wordt (Baarda & Goede, 2012). Het volgende hoofdstuk geeft de resultaten van de praktijk weer van de casus voegovergangen.


6 Resultaten praktijk 6.1 Data analyse interviews Dit hoofdstuk geeft antwoord op de vraag welke informatie over eisen wel en welke informatie niet effectief is uitgewisseld bij de ontwerpkeuze van voegovergangen in Nederlandse DBFM weginfrastructuurprojecten. De input voor het interviews zijn product 1, product 2 en de eisen uit een standaard DBFM contract geweest. De relaties die getest zijn betreft Elementen die gerelateerd zijn aan de eisen. Dit leidde in hoofdstuk 5 tot de thematisering van relatie tussen twee Elementen. De relaties komen voort uit het Theoretisch model van deelvraag 1. Voor de casus ontwerpkeuze voegovergangen zijn de volgende zes relaties getest: a) Relatie tussen Eis en Functie; b) Relatie tussen Eis en Organisatie; c) Relatie tussen Eis en Locatie; d) Relatie tussen Eis en Fase; e) Relatie tussen Eis en Object; f) Relatie tussen Eis en Risico. In de volgende subparagrafen volgt per relatie tussen Eis en Element de uitwerking van de interviews. De volgende subparagrafen komen overeen met de zes getoetste relaties (a t/m f). Deze uitwerking is een samenvatting van de interviewresultaten. De informatie per respondent is te vinden in bijlage 7.


6.1.1

Relatie tussen Eis en Functie

De relatie tussen Eis en Functie (a) betreft het afleiden van de functies in eisen. In figuur 22 is de stelling bij deze relatie te zien met de resultaten.

Figuur 22 verzamelde data over relatie tussen Eis en Functie

Uit de resultaten blijkt dat 100% van de respondenten de relatie tussen Eis en Functie door het afleiden van eisen gewenst vindt binnen projecten (figuur 22). Van deze respondenten geeft slechts 33% aan eens of deels mee eens te zijn, waarvan 25% volledig mee eens te zijn dat de relatie tussen Functie en Eis is gelegd in het project. Van de respondenten is 17% eens of deels mee eens dat de informatie tijdig beschikbaar is, waarvan slechts 8% het volledig eens is dat informatie over de functies tijdig beschikbaar is. Opvallend uit de resultaten is dat de informatie over de functies door 17% van de respondenten expliciet en traceerbaar wordt gevonden.


6.1.2

Relatie tussen Eis en Organisatie

De relatie tussen Eis en Organisatie (b) betreft de relatie van verantwoordelijkheid tussen de Elementen Eis en Organisatie. Deze relatie is getoetst bij de verantwoordelijkheid per Eis en de verantwoordelijkheid per onderdeel. In figuur 23 is de stelling over verantwoordelijkheid per Eis te zien met de resultaten.

Figuur 23 verzamelde data over relatie Eis Organisatie verantwoordelijk voor eisen

Uit de resultaten blijkt dat 100% van de respondenten de relatie tussen Eis en Organisatie door de verantwoordelijkheid vast te leggen gewenst vindt binnen projecten (figuur 23). Alle respondenten geven aan mee eens of deels mee eens te zijn dat een relatie op deze wijze is gelegd in het project. Daarvan is 92% volledig mee eens is. Van de respondenten geeft echter slechts 58% van de respondenten aan mee eens of deels mee eens te zijn. Daarvan geeft 42% van de respondenten aan volledig mee eens te zijn dat de informatie over verantwoordelijkheden tijdig beschikbaar is. Opvallend uit de resultaten is dat 50% van de respondenten de informatie expliciet en traceerbaar vindt.


In figuur 24 is de stelling over verantwoordelijkheid per onderdeel te zien met de resultaten.

Figuur 24 verzamelde data verantwoordelijkheid per onderdeel

Uit de resultaten blijkt dat 100% van de respondenten de relatie tussen Eis en Organisatie gewenst vindt (figuur 24). 92% van de respondenten geeft aan mee eens te zijn dat deze relatie is gelegd in het project. Daarvan is 83% van de respondenten volledig mee eens is dat de relatie op deze wijze is gelegd in het project en deze informatie tijdig beschikbaar is. Van de respondenten geeft verder 50% van de respondenten aan volledig mee eens dat de verantwoordelijkheid expliciet en traceerbaar is. Eén respondent (PW2) geeft aan dat de werkpakketten niet centraal stonden. Dit wordt bevestigd door andere respondenten (PO2 en PO4). Zij geven aan dat werkpakketten niet aanwezig zijn of zweven. Daardoor is onduidelijk wie verantwoordelijk is voor welk deel van het werk (scope). Voorbeeld van prioriteiten “Ik ben vanuit de rol als projectleider onderhoud afhankelijk wat het ontwerpteam uitgezocht willen hebben. Kortom, ik ben afhankelijk van de prioriteiten die het ontwerpteam stelt. Een voegovergang stelde het ontwerpteam in dit project niet als prioriteit” (PO2).


Een van de respondenten (PO2) geeft aan dat de focus tijdens het ontwerp nog erg ligt op de uitvoeringsfase. Een van de respondenten geeft een schatting van 95% medewerkers die focussen op de uitvoering versus 5% medewerkers die het totaalbeeld voor zich zien (PO3). De respondenten geven ook een ander probleem aan: veel informatie blijft zweven (PK1, PO2, PW1 en PW2). Kortom, de informatie wordt niet vastgelegd. Dit geldt bijvoorbeeld voor de werkpakketten (PO2). Een andere respondent geeft aan dat keuzes vaak worden gemaakt tijdens 1-2 gesprekken (PW1). Tussen betrokkenen is de informatie dan bekend, maar vervolgens wordt enkel de keuze (Object) vastgelegd en niet het proces en afwegingen daarbinnen expliciet vastgelegd. Het volgende voorbeeld: Voorbeeld van het vastleggen van het ontwerpproces “Het ontwerpproces om van fluistervoeg (goedkope, stille voeg) naar Maurervoeg (dure, stalen voeg) over te gaan was niet expliciet vastgelegd. Hoe kunnen we nu na de gunning dan achterhalen waarom we overal deze dure voeg toepassen?” (PK1)

Een andere respondent onderkent dit en vraagt zich af wanneer het nog nodig is om “De Rolls Royce” onder voegovergangen te kiezen (OK1)? Uit antwoorden van respondenten (PW1, PK1, PO2 en PW2) blijkt dat het lang duurt voordat men informatie expliciet maakt en vastlegt. De respondenten geven aan dat dit negatieve consequenties heeft. Een voorbeeld is project A: “Bij het project duurde het lang voordat informatie expliciet beschikbaar is. Doordat informatie niet expliciet gemaakt was ontstonden hierdoor interpretatie verschillen bij partijen/ actoren (PW1)”. Een voorbeeld zijn de werkpakketten die niet duidelijk gedefinieerd waren. Daardoor is het werk (de scope) moeilijk af te bakenen. Eén respondent (PO2) refereert hierbij aan de safari metafoor van Mintzberg over strategie (Jacobs, 2013). Drie mensen gaan op safari. “De één ziet een oor, de ander een slurf en de derde een poot. Allen zien zij een stukje van het systeem, maar allen hebben slechts een deel van het geheel in beeld: de olifant! Dit is een bepalend voorbeeld voor dit immense project, waarbij de olifant niet in beeld was” (PO2). De verantwoordelijkheid per Eis en verantwoordelijkheid per onderdeel geven beiden een overeenkomstig beeld. Zowel de verantwoordelijkheid per Eis als de verantwoordelijkheid per onderdeel wordt in de praktijk dus erkend en gebruikt.


6.1.3

Relatie tussen Eis en Locatie

De relatie tussen Eis en Locatie (c) is onder te verdelen naar de beschikbaarheideisen per Locatie en de Locatie eisen van een kunstwerk. In figuur 25 is de stelling over beschikbaarheideisen per Locatie te zien met de resultaten.

Figuur 25 verzamelde data over beschikbaarheid eisen per Locatie

Uit de resultaten blijkt dat 100% van de respondenten de relatie tussen Eis en Locatie legt in projecten (figuur 25). Alle respondenten geven aan dat deze relatie in meer of mindere mate mee eens dat deze relatie gelegd is in het project. Daarvan is 92% van de respondenten volledig mee eens is dat de relatie op deze wijze is gelegd in het project. 75% van de respondenten is het eens of deels mee eens met de tijdige beschikbaarheid, waarbij 50% volledig mee eens is over de beschikbaarheideisen. 58% van de respondenten is volledig mee eens dat deze informatie expliciet en traceerbaar is. De respondenten geven aan dat contracteisen wel beschikbaar zijn, maar geen afleiding van de eisen plaatsvindt. Ofwel, de beschikbaarheideisen zijn onder andere niet opgedeeld naar locaties. Meerdere respondenten geven aan het minder eens te zijn met de mate waarin eisen expliciet zijn, omdat de contracteisen niet afgeleid worden. Andere respondenten geven aan dat de informatie wel beschikbaar is, maar beperkt beschikbaar. Een voorbeeld is de eisen analyse bij één van de projecten. “De hoofdaannemer moest de vraagspecificatie uit elkaar halen om te kunnen verdelen, maar de eisen Thesis Jeremy de Bruijn_5-12-2013 72

bleven op contract niveau”. Daarmee was het onduidelijk of eisen aangetoond konden worden voor partijen. De respondenten geven allen aan deels mee eens of deels niet mee eens te zijn verschillen bij deze stelling. Dit gaat van projectleider ontwerp kunstwerken, tot projectleider realisatie wegen, zowel in tender als tijdens gunning. De meningen zijn verdeeld tot welk detail niveau de informatie over beschikbaarheideisen afgeleid moet worden om te kunnen gebruiken voor ontwerpkeuzes (in dit geval voor voegovergangen). In figuur 25 is te zien dat de helft van de informatie pas laat in het traject beschikbaar wordt gemaakt. In figuur 26 is de stelling over Locatie eisen van kunstwerken te zien met de resultaten.

Figuur 26 verzamelde data over Locatie eisen van kunstwerken

Uit de resultaten blijkt dat 100% van de respondenten de relatie tussen Eis en Locatie legt in projecten (figuur 26). Van de respondenten geeft 83% aan dat deze relatie in meer of mindere mate mee eens dat deze relatie gelegd is in het project, waarvan 67% volledig mee eens is dat de relatie is gelegd. 50% van de respondenten is eens of deels mee eens dat informatie tijdig beschikbaar is. Slechts 33% van de respondenten is het volledig eens dat de informatie tijdig beschikbaar is. Van de respondenten geeft slechts 25% van de respondenten aan volledig mee eens te zijn dat de informatie expliciet en traceerbaar is.


Twee respondenten (OK1 en OW2) geven aan dat de locatie specifieke eisen van kunstwerken niet gebruikt zijn voor zover zij weten voor de ontwerpkeuze voor voegovergangen. Beiden geven aan dat hen niet bekend is of gebruik is gemaakt van locatie specifieke eisen. Enkele respondenten hebben aangegeven in de fase na gunning opnieuw analyses doen, omdat informatie tijdens de tender helemaal niet of niet expliciet is vastgelegd. Eén respondent (PO3) geeft aan dat hij het zeer wenselijk zou vinden als de locatie specifieke eisen bekend waren geweest. Deze respondent geeft met een voorbeeld waarom dit van belang is met een voorbeeld van eisen met betrekking tot geluid. Voorbeeld van een locatie specifieke eis ”Bij één kunstwerk heeft geluid een rol gespeeld. Rijkswaterstaat had een probleem met een bewoner over geluid. Hem was een stille voegovergang beloofd. In dit voorbeeld was (net als de andere kunstwerken) staal zonder sinusvoeg gekozen. Bitumineus was in ieder geval geen optie in verband met het vele onderhoud (1x per 3 jaar) in vergelijking met andere voegovergangen. In dit geval werd de verkeerde voeg geplaatst, waardoor niet aan de geluidseisen werd voldaan. De desbetreffende Eis was pas laat gezien door het consortium, maar blijkbaar was de Eis niet van toepassing op dat desbetreffende deel van de weg (onjuiste relatie)”. (PO3)


6.1.4

Relatie tussen Eis en Fase

De relatie tussen Eis en Fase (d) is onderverdeeld naar een stelling over eisen van de onderhoudsstrategie en de eisen opdeling per Fase. In figuur 27 zijn de resultaten van de eerste stelling, over de eisen uit de onderhoudsstrategie te zien.

Figuur 27 Verzamelde data van eisen over de onderhoudsstrategie

Uit de resultaten blijkt dat 100% van de respondenten de relatie tussen Eis en Fase legt in projecten (Figuur 27). Van de respondenten geeft 75% aan dat deze relatie in meer of mindere mate mee eens dat deze relatie gelegd is in het project, waarvan 67% volledig mee eens is dat de relatie is gelegd. Slechts 25% van de respondenten is het eens dat de informatie tijdig beschikbaar is. Van de respondenten geeft verder 17% van de respondenten aan volledig mee eens te zijn dat de informatie expliciet en traceerbaar is. Alle respondenten geven aan dat uit de onderhoudsstrategie eisen moeten volgen voor ontwerpkeuze van voegovergangen. Meer dan de helft van de respondenten geeft aan dat eisen zijn gesteld uit de onderhoudsstrategie. Twee respondenten (PO3 en PO4) die echter verantwoordelijk zijn voor het onderhoud geven aan dat dit niet gebeurd was. Dit strookt niet met de antwoorden van de andere respondenten die in hetzelfde project betrokken waren. Een andere verklaring is dat men ogenschijnlijk eisen voor ogen had, zoals “zo onderhoudsvrij mogelijk te ontwerpen", maar zonder exacte invulling van Thesis Jeremy de Bruijn_5-12-2013 75

deze term te geven en dit daarmee geïnterpreteerd werd als Eis. Dit sluit aan op de volgende vraag, omdat de informatie over de eisen vanuit de onderhoudsstrategie pas heel laat beschikbaar kwamen volgens de helft van de respondenten. De factor tijd heeft hier dus een zeer belangrijke rol gespeeld. Dit sluit aan op de eerder benoemde onderhoudseisen die pas laat in het traject beschikbaar kwamen. Meerdere respondenten (OK1, OW1, PW2 en PK2) geven aan dat de onderhoudsstrategie niet tijdig beschikbaar is, wat opmerkelijk aangezien zij betrokken zijn bij het ontwerp na gunning. De tweede stelling gaat over de opdeling van eisen per Fase. In figuur 28 zijn de resultaten van de stelling over de eisen per Fase te zien.

Figuur 28 Verzamelde data van eisen per Fase

Uit de resultaten blijkt dat 100% van de respondenten de relatie tussen Eis en Fase legt in projecten (figuur 28). Van de respondenten geeft 82% aan dat deze relatie in meer of mindere mate mee eens dat deze relatie gelegd is in het project, waarvan 75% volledig mee eens is dat de relatie is gelegd. 58% van de respondenten is het eens dat de informatie tijdig beschikbaar is, waarvan slechts 42% aangeeft volledig mee eens te zijn. Van de respondenten geeft verder 33% aan dat de informatie expliciet is, waarvan 25% volledig mee eens is dat de informatie expliciet is. 25% van de informatie vinden te respondenten traceerbaar. Daarvan geeft slechts 17% van de respondenten aan hiermee volledig mee eens te zijn.


De betrokkenen geven allen aan dat het wenselijk is een onderscheid naar eisen per Fase te maken en dat dit op deze wijze gebeurd is. Echter, het grote onderscheid zit in de tijdigheid van de informatie. Pas laat in het traject wordt duidelijk welke eisen voor welke Fase van toepassing zijn. Dit wordt door verschillende respondenten in verschillende rollen benoemd. Aangezien in het project verschillende rollen verantwoordelijk zijn voor verschillende fasen is het noodzakelijk het onderscheid in eisen per Fase vroegtijdig in kaart te brengen en eisen te Alloceren in de juiste Fase bij de juiste persoon. Voorbeeld van geen eisen opleggen “ Van oorsprong stelde Rijkswaterstaat verschillende eisen per fase op. Een voorbeeld zijn de eisen voor de onderhoudsfase. In ons project komt het onderhoudsteam met veel input over onderhoudbaarheid van het systeem of objecten daarbinnen, maar daar blijft het bij. De medewerkers van het onderhoudsteam leggen geen eisen op waar informatie aan moet voldoen, waar voorheen Rijkswaterstaat wel stellend in was.” (OW2)

Het onderscheid in de antwoorden van de respondenten zit in de tijdigheid van de informatie. Pas laat in het traject wordt duidelijk welke eisen voor welke Fase van toepassing zijn. Dit wordt door verschillende rollen, zowel in tender als na gunning benoemd. Aangezien in het project verschillende rollen verantwoordelijk zijn voor verschillende fasen is het noodzakelijk dit vroegtijdig in kaart te brengen en eisen toe te wijzen in de juiste Fase bij de juiste persoon. De eisen uit onderhoudsstrategie en de eisen per Fase geven beiden een overeenkomstig beeld. De informatie is wel relevant, maar is niet tijdig beschikbaar. Als de informatie tijdig beschikbaar is dan is in de helft van de gevallen de informatie expliciet en traceerbaar.


6.1.5

Relatie tussen Eis en Object

De relatie tussen Eis en Object (e) is getoetst bij een stelling over eisen die uit ontwerpkeuzes voor kunstwerken voortkomen en een stelling over eisen die uit ontwerpkeuzes voor asfalt voortkomen. In figuur 29 zijn de resultaten van de eerste stelling te zien, betreffende eisen die vanuit kunstwerken komen.

Figuur 29 Verzamelde data eisen uit kunstwerken

Uit de resultaten blijkt dat 100% van de respondenten de relatie tussen Eis en Object legt in projecten (figuur 29). Van de respondenten geeft 83% aan dat deze relatie in het project is gelegd. Slechts 42% van de respondenten is het eens dat de informatie tijdig beschikbaar is. Van de respondenten geeft verder 50% van de respondenten aan volledig mee eens te zijn dat de informatie expliciet en traceerbaar is.


De tweede stelling gaat over de eisen die voortvloeien uit ontwerpkeuzes voor het asfalt. In figuur 28 zijn de resultaten van de stelling over de eisen per Fase te zien. In figuur 30 zijn de resultaten bij deze stelling te zien.

Figuur 30 Verzamelde data eisen vanuit asfalt

Uit de resultaten blijkt dat 100% van de respondenten de relatie tussen Eis en Object legt in projecten (figuur 29 en figuur 30). Van de respondenten geeft 67% aan dat deze relatie in het project is gelegd. Slechts 42% van de respondenten is het eens of deels mee eens dat de informatie tijdig beschikbaar is. Daarvan is 33% volledig mee eens dat de informatie tijdig beschikbaar is. Van de respondenten geeft slechts 25% van de respondenten aan volledig mee eens te zijn dat de informatie expliciet en traceerbaar is. De praktijk wijst uit dat informatie van asfalt pas laat in het traject beschikbaar komt en (later) niet meer afgestemd is met voegovergangen. Kortom, de informatie wordt niet expliciet gemaakt en daardoor moeilijk te vergelijken als wijzigingen plaats vinden. Het onderstaande voorbeeld geeft dit goed weer.


Voorbeeld van vastleggen raakvlakken “De raakvlakken van het onderhoud van de objecten zijn niet expliciet. Een voorbeeld is het raakvlak in onderhoud van een voegovergang (10 jaar) en asfalt (7 jaar). Deze afstemming gebeurd tijdens overleggen, maar wordt niet expliciet vastgelegd. Als één van de twee veranderd dan veranderd het andere niet direct mee als deze niet is vastgelegd" (PO3).

Een andere respondent geeft aan dat raakvlakken en risico’s en beïnvloeden keuzes voor de onderhoudsstrategie. Een andere respondent zegt: “Als projectleider onderhoud moet je bewustzijn van andere onderhoudskeuzes.” Daarbij maakt hij een doorkijk naar de raakvlakken in tijd. Niet alleen de fysieke raakvlakken, zoals aansluiting asfalt op voegovergang is van belang, maar tevens andere dimensie raakvlakken, zoals wanneer onderhoud nodig is. Opmerkelijk is dat bij deze relatie dat een groot onderscheid tussen eisen vanuit kunstwerken en asfalt is (figuur 30). De informatie van de kunstwerken in de meeste gevallen wel tijdig beschikbaar, expliciet en traceerbaar. Terwijl de informatie-uitwisseling van asfalt beduidend later beschikbaar komt en zeer beperkt expliciet en traceerbaar is.


6.1.6

Relatie tussen Eis en Risico

De relatie tussen Eis en Risico (f) is één stelling. In figuur 31 zijn de resultaten van deze stelling, over risico’s op niet-beschikbaarheid te vinden.

Figuur 31 Verzamelde data eisen en Risico’s

Uit de resultaten blijkt dat 100% van de respondenten de relatie tussen Eis en Object legt in projecten (figuur 31). Van de respondenten geeft 83% aan eens of deels mee eens te zijn dat deze relatie in het project is gelegd. Daarvan is 75% volledig mee eens dat deze relatie in het project is gelegd. 58% van de respondenten is het eens of deels mee eens dat de informatie tijdig beschikbaar is. Daarvan is slechts 25% volledig mee eens dat de informatie tijdig beschikbaar is. Van de respondenten geeft verder 25% van de respondenten aan volledig mee eens te zijn dat de informatie expliciet is en 33% van de respondenten dat de informatie traceerbaar is. Verschillende respondenten geven aan dat risico’s niet expliciet gemaakt zijn. Het belang van het goed in kaart brengen van de risico’s voor de onderhoudsfase wordt door verschillende respondenten benadrukt. Zo geeft een respondent aan dat “de risico's tijdens onderhoudsfase 20x hoger zijn dan de realisatiefase”. Een andere respondent geeft aan dat “eigenlijk alles waar beschikbaarheid eisen of boetepunten van toepassing zijn veel pijn kunnen doen. De analyse van deze eisen in relatie tot risico’s gebeurt nu vaak impliciet ” (PO4).


Op basis van de verschillende resultaten per relatie en per stelling is in tabel 10 een overzicht gemaakt. Tabel 10 Kruistabel met percentages per voorwaarde voor effectieve informatie-uitwisseling

Voorwaarden voor effectieve informatie-uitwisseling

1a Relaties

a

b

c

d

e

f

Relatie tussen Eis en Functie

Relatie tussen Eis en Organisatie

Relatie tussen Eis en Locatie

Relatie tussen Eis en Fase

Relatie tussen Eis en Object

Relatie tussen Eis en Risico

Meningen Mee eens

1b

2

3

4

Gewenst Aanwezig Tijdig beschikbaar Expliciet Traceerbaar 100%

25%

8%

17%

17%

Deels mee eens

0%

8%

8%

0%

0%

Overig Mee eens

0%

67%

83%

83%

83%

100%

92%

42%

50%

50%

Deels mee eens

0%

8%

17%

17%

0%

Overig Mee eens

0%

0%

33%

50%

50%

100%

83%

83%

58%

58%

Deels mee eens

0%

8%

0%

8%

8%

Overig Mee eens

0%

8%

17%

33%

33%

100%

92%

50%

58%

58%

Deels mee eens

0%

8%

25%

17%

8%

Overig Mee eens

0%

0%

25%

25%

33%

100%

67%

33%

25%

25%

Deels mee eens

0%

17%

17%

0%

0%

Overig Mee eens

0%

17%

42%

75%

75%

100%

67%

25%

17%

17%

Deels mee eens

0%

8%

0%

0%

0%

Overig Mee eens

0%

17%

75%

83%

83%

100%

75%

42%

25%

17%

Deels mee eens

0%

8%

17%

8%

8%

Overig Mee eens

0%

17%

42%

67%

75%

100%

83%

42%

50%

50%

Deels mee eens

0%

0%

0%

0%

0%

Overig Mee eens

0%

17%

58%

50%

50%

100%

67%

33%

25%

25%

Deels mee eens

0%

0%

8%

8%

0%

Overig Mee eens

0%

33%

58%

67%

75%

100%

75%

25%

25%

33%

0% 0%

8% 17%

33% 33%

25% 59%

25% 42%

Deels mee eens Overig

In het overzicht zijn bij elke stelling drie opinies weergegeven. In dit onderzoek wordt voldaan aan een voorwaarde van effectieve informatie-uitwisseling als meer dan 50% van de respondenten met een vraag eens is. In het groen zijn resultaten te vinden die 50% of meer van de respondenten


vertegenwoordigd die volledig eens is met de stelling. In rood zijn respondenten te vinden die minder dan 50% van de respondenten vertegenwoordigen die volledig eens waren met de stelling. Hieruit blijkt dat alleen bij de relaties tussen Eis en Organisatie effectieve informatie-uitwisseling plaats vindt. Dit betekent dat bij het toetsen van de relaties alleen bij beide stellingen van deze relatie 50% van de respondenten het eens zijn met de voorwaarden. Uit de vijf andere getoetste relaties blijkt elke relatie wel relevant gevonden te worden, maar wordt niet voldaan aan één van de voorwaarden. Op basis van de antwoorden van paragraaf 6.1 worden de bevindingen uit de praktijk samengevat. De bevindingen hebben in enkele gevallen enige nuancering. Deze nuanceringen zijn in hoofdstuk 7 opgenomen. Op basis van het bovenstaande resultaten komt product 3 tot stand.


6.2 Product 3: Resultaten uit de praktijk In tabel 10 zijn de resultaten van de data verzameling te vinden. Daarbij is opgenomen van welke stellingen de voorwaarden wel of niet voldoen aan het 50% criterium. De resultaten per relatie en stelling uit paragraaf 6.1 In tabel 11 is een samenvatting van de bevindingen te zien. Tabel 11 Resultaten effectieve informatie-uitwisseling bij de casus voegovergangen per relatie

Uitkomsten van voorwaarden per stelling Iedere relatie voldoet aan de voorwaarde voor effectieve informatie-uitwisseling wat betreft de voorwaarde aan relevantie (figuren 17 t/m 26) a) Relatie tussen Eis en Functie Stelling 1: De relatie tussen Eis en Functie zijn volgens minder dan 50% van de respondenten gelegd in projecten (figuur 17) b) Relatie tussen Eis en Organisatie Stelling 1: Meer dan 50% van de respondenten is het eens dat verantwoordelijkheid per Eis aanwezig, tijdig beschikbaar, expliciet en traceerbaar is (figuur 18) Stelling 2: Meer dan 50% van de respondenten is het eens dat verantwoordelijkheid per onderdeel aanwezig, tijdig beschikbaar, expliciet en traceerbaar is (figuur 19) c) Relatie tussen Eis en Locatie Stelling 1: Meer dan 50% van de respondenten is het eens dat beschikbaarheideisen per Locatie aanwezig, tijdig beschikbaar, expliciet en traceerbaar zijn (figuur 20) Stelling 2: De Locatie eisen van kunstwerken zijn volgens meer dan 50% van de respondenten beschikbaar in projecten. De Locatie eisen van kunstwerken zijn volgens minder dan 50% van de respondenten tijdig beschikbaar, expliciet en traceerbaar gemaakt in het project (figuur 21) d) Relatie tussen Eis en Fase Stelling 1: De eisen uit de onderhoudsstrategie zijn volgens meer dan 50% van de respondenten beschikbaar in projecten. De afgeleide eisen van de onderhoudsstrategie zijn volgens minder dan 50% van de respondenten tijdig beschikbaar, expliciet en traceerbaar gemaakt in het project (figuur 22) Stelling 2: De eisen per Fase zijn volgens meer dan 50% van de respondenten beschikbaar in projecten. De afgeleide eisen van de onderhoudsstrategie zijn volgens minder dan 50% van de respondenten tijdig beschikbaar, expliciet en traceerbaar gemaakt in het project (figuur 23) e) Relatie tussen Eis en Object Stelling 1: De afgeleide eisen van kunstwerken zijn volgens meer dan 50% van de respondenten beschikbaar in projecten. De afgeleide eisen van kunstwerken zijn volgens minder dan 50% van de respondenten tijdig beschikbaar. Meer dan 50% van de respondenten geeft echter wel aan dat deze eisen expliciet en traceerbaar zijn gemaakt in het project (figuur 24) Stelling 2: De afgeleide eisen van asfalt zijn volgens meer dan 50% van de respondenten beschikbaar in projecten. De afgeleide eisen van asfalt zijn volgens minder dan 50% van de respondenten tijdig beschikbaar, expliciet en traceerbaar gemaakt in het project (figuur 25) f) Relatie tussen Eis en Risico Stelling 1: De relatie tussen eisen en Risico is volgens meer dan 50% van de respondenten beschikbaar in projecten. De eisen zijn volgens minder dan 50% van de respondenten tijdig beschikbaar, expliciet en traceerbaar gemaakt in het project (figuur 26)

Bevinding over relatie Bij elke relatie wordt voldaan aan voorwaarde voor relevantie. Deze relatie tussen Eis en Functie voldoet niet aan de voorwaarden voor effectieve informatie-uitwisseling Deze relatie tussen Eis en Organisatie voldoet aan de voorwaarden voor effectieve informatie-uitwisseling

De relatie tussen Eis en Locatie voldoet niet aan de voorwaarden voor effectieve informatie-uitwisseling

De relatie tussen Eis en Fase voldoet niet aan de voorwaarden voor effectieve informatie-uitwisseling

De relatie tussen Eis en Object voldoet niet aan de voorwaarden voor effectieve informatie-uitwisseling

De relatie tussen Eis en Risico voldoet niet aan de voorwaarden voor effectieve informatie-uitwisseling

Het overzicht geeft aan op basis waarvan een bevinding gedaan is. Daarbij is het criterium dat nok beide stellingen de relatie tussen Eis en Structuur voldoet aan de 50% regel. In het overzicht blijkt dat vijf van de zes relaties niet voldoen aan de alle voorwaarden voor effectieve informatie-uitwisseling. Op basis van hoofdstuk 6 en product 3 kan antwoord worden gegeven op deelvraag 3.


6.3 Beantwoording deelvraag 3 Deze paragraaf is de beantwoording van deelvraag 3:“Welke informatie over eisen is wel en welke informatie over eisen is niet effectief uitgewisseld bij de ontwerpkeuze van voegovergangen in Nederlandse DBFM weginfrastructuurprojecten?” De voorwaarden van product 1 en product 2 zijn samen met eisen uit DBFM contracten gebruikt om in interview op te zetten en in de praktijk interviews te houden. Uit de interviews blijken grote verschillen te bestaan tussen de praktijk en de theorie met betrekking tot de voorwaarden voor informatieuitwisseling. Op basis van de resultaten per voorwaarde is geconcludeerd dat in vijf van de zes relaties niet voldaan wordt aan alle voorwaarden voor informatie-uitwisseling (tabel 11). Dit betreft de relatie tussen Eis en Functie, Eis en Locatie, Eis en Object, Eis en Fase en Eis en Risico. De relatie die wel voldoet aan de voorwaarden voor effectieve informatie-uitwisseling betreft de relatie tussen Eis en Organisatie. Hiermee wordt invulling gegeven aan in ieder geval één relatie door opdrachtnemers. Uit de resultaten lijkt een trend zichtbaar te zijn in de resultaten van verschillende voorwaarden voor effectieve informatie-uitwisseling. De geïnterviewde opdrachtnemers blijken de informatie in iedere relatie relevant te vinden. Deze informatie is echter niet altijd aanwezig binnen het project. Wanneer de informatie wel aanwezig is binnen het project blijkt deze informatie vaak niet tijdig beschikbaar te zijn. Als de respondenten de informatie tijdig beschikbaar vinden, dan is deze vaak niet expliciet of niet traceerbaar. Op basis van de beantwoording van deelvraag 3 kan een vergelijking worden gemaakt tussen de praktijk en een deel van de theorie in hoofdstuk 7. Daarom zijn de resultaten van deelvraag 3 de input voor de vergelijking van de theorie met de praktijk.



Deel D Discussie

Deel A Opzet

Deel B Theorie




Deel C Resultaten

Deel D Discussie


(4)



Deel Evaluatie

Veldonderzoek




LEGENDA Theorie

Empirie

Producten

(1)




7 Verschillen en overeenkomsten Dit hoofdstuk is de discussie tussen de verschillen en overeenkomsten. In dit onderdeel worden de resultaten van deel C vergeleken met theorie van deel B. In dit hoofdstuk wordt in paragraaf 7.1 de andere resultaten uit de praktijk (interviews) besproken en vergeleken met de theorie uit hoofdstuk 4. Vervolgens wordt in paragraaf 7.2 de casus voegovergang besproken om te bepalen of deze generaliseerbaar is voor andere ontwerpkeuzes. In paragraaf 7.3 worden de verschillen besproken en gereflecteerd aan de theorie van SE. In paragraaf 7.4 worden de verschillen samengevoegd in product 4. Paragraaf 7.1 tot en met 7.4 leiden tot beantwoording van de deelvraag in paragraaf 7.5.

7.1 Andere resultaten uit de praktijk In dit onderzoek zijn in hoofdstuk 6 de resultaten van de casus voegovergangen besproken. Om de casus voegovergangen te generaliseren zullen andere resultaten uit interviews gebruikt worden voor onderbouwing. Hiermee kunnen de conclusies en aanbevelingen beter worden onderbouwd. In subparagraaf 7.1.1 zijn de problemen in de praktijk geschetst. 7.1.1

Problemen bij Life Cycle Based afwegingen

In de interviews zijn respondenten gevraagd naar problemen bij het maken van LCB afwegingen. In tabel 12 zijn deze problemen samengevat en vergeleken met LCC problemen in de theorie (Wübbenhorst, 1986; Ellram, 1994) van hoofdstuk 4. Tabel 12 Problemen bij LCC analyses in de theorie en afspiegeling van de praktijk

1.

Problemen (theorie)

Problemen (praktijk)

Analyse

Informatie

Juiste informatie verkrijgen

Probleem komt overeen

Geen sturing/ informatie vanuit onderhoud Informatie is niet expliciet (is blijven zweven)

2.


Welke raakvlakken zijn met andere onderdelen? Tekort aan inzicht van de gevolgen van keuzes

3.

Kosten

Hoever ga je in detail? (vb. 1 generiek type in tender gekozen voldoende) Moeilijk te bepalen hoeveel onderhoud nodig is

Probleem komt overeen Probleem komt overeen

Schatten van kosten beheer en onderhoud

4.

Cultuur

Budgetten van partijen Onvoldoende beleving urgentie onderhoud


Verschil in kennis van disciplines: tekort kennis onderhoud Onvoldoende scherp op eisen (m.n. boete en beschikbaarheideisen) Onderhoud werkt vanaf eiland Partijen werken op eilanden Belangen van partijen

5.

Onwetendheid

Bepalen hoeveel onderhoud nodig is Geen ervaringsdeskundigheid ("boekjeswijsheid")


Trade-offs zijn van onvoldoende kwaliteit Financiële component meenemen is moeilijk Moeilijk juiste parameters te bepalen Kwantificeren is moeilijk


De problemen in de literatuur komen overeen met problemen die geïnterviewden ervaren in de praktijk. Met deze tabel kunnen verklaringen worden gegeven ter onderbouwing van de aanbevelingen. In de volgende subparagraaf worden succesfactoren benoemd, die gebruikt worden om de richting van de aanbevelingen te bepalen voor product 4. 7.1.2

Succesfactoren voor informatie-uitwisseling

Om aanbevelingen te kunnen doen in dit onderzoek is in de interviews gevraagd naar kritieke succesfactoren voor informatie-uitwisseling (vraag 7 in het interview in bijlage 7). In dit onderzoek zijn kritieke succesfactoren benoemd door de geïnterviewden. De geïnterviewden zijn mensen op de werkvloer die uiteindelijk moeten werken naar effectieve informatie-uitwisseling. Zij bepalen daarmee de factoren die informatievoorziening, structurering en uiteindelijk uitwisseling kunnen faciliteren. In tabel 13 zijn succesfactoren benoemd en gecategoriseerd naar voorwaarden voor effectieve informatieuitwisseling. Tabel 13 Succesfactoren voor informatie-uitwisseling als afspiegeling van de interviews

Nr.

Voorwaarde

Succesfactor

1. (a)

Relevant

1. (b)

Aanwezig

2.

Tijdig beschikbaar

3.

Expliciet

4.

Traceerbaar

Bewust zijn informatie-uitwisseling met onderhoud Aansturing vanuit management Ontwerpmanager initieert Juiste informatie uitwisselen Sturing management op informatie-uitwisseling Hoe organiseer je het project? Medewerkers die informatie willen delen Eén centraal informatie systeem Goede tools voor informatie-uitwisseling Klein kernteam beginnen Bewaken afspraken over informatie-uitwisseling Kennis van medewerkers Tijdig aanleveren van informatie. Toegankelijkheid van informatie Verwachtingspatroon van partijen Compleetheid documenten Gestructureerd raakvlakkenoverleg vastleggen Duidelijkheid in de Organisatie wie eigenaar van de life cycle analyse is Gebruiksvriendelijke systemen Simpele en gebruiksvriendelijke inrichting ICT infrastructuur

Betrokken actoren voor aanbevelingen IF-3

ON-1

ON-2

ON-3

ON-4; IF-1; IF-2

In de kolom zijn in de vierde tabel Iter Fidelis (IF) en opdrachtnemer (ON) benoemt. Op basis van de succesfactoren zijn dus aanbevelingen afgeleid voor IF en ON om tot effectievere informatie-uitwisseling te komen binnen en buiten de gestelde werkprocessen van de medewerkers. De succesfactoren zijn input voor product 4 om een richting van de aanbevelingen voor opdrachtnemers en Iter Fidelis te geven. De lijst met succesfactoren is in bijlage 6 te vinden. Om de resultaten uit de interviews van de casus voegovergangen uit hoofdstuk 6 te generaliseren wordt in de volgende paragraaf ingegaan op andere ontwerpkeuzes.


7.2 Generaliseerbaarheid van de casus voegovergangen Deze paragraaf heeft betrekking op de generaliseerbaarheid van de casus voegovergangen. Onder generalisatie wordt in het kader van dit onderzoek het volgende verstaan: het algemeen kunnen toepassen van de bevindingen uit dit onderzoek op (vergelijkbare) projecten in de markt waar dit soort projecten van toepassing is. Voor de generaliseerbaarheid van de casus voegovergangen is de respondenten onder andere gevraagd: - Bij welke andere ontwerpkeuzes speelt de beschikbaarheid van het systeem een rol; - Waar is informatie-uitwisseling tussen meerdere teams van groot belang. Dit is ondervangen in interviewvraag 25. Figuur 32 geeft de resultaten weer.

Ontwerpkeuzes waarbij informatie van beschikbaarheid een rol speelt

2

2 3 4

4

2

10

10 6

5

6

1 12

8

9

3

1

4

Ja

7

4

Nee

Onbekend

Figuur 32 Andere ontwerpkeuzes waarbij beschikbaarheid een rol speelt

Het getal in de balk geeft het aantal reacties weer waarin beschikbaarheid van informatie wel, dan wel geen rol speelt in de visie van de respondenten. Uit de antwoorden in de interviews wordt duidelijk dat alle ontwerpkeuzes benoemd zijn door meerdere respondenten waar beschikbaarheid een rol speelt. De respondenten geven aan dat meerdere ontwerpkeuzes problemen kennen met informatie-uitwisseling in relatie tot het maken van LCB afwegingen. Opmerkelijk uit de bovenstaande data is dat verschillende respondenten niet eens zijn dat de beschikbaarheid van informatie een invloed heeft op het maken van bepaalde ontwerpkeuzes.


De reden hiervoor kan zijn dat men niet betrokken is geweest bij ontwerpkeuzes of in het specifieke project de beschikbaarheid geen rol heeft gespeeld. Uit de resultaten blijkt bij de ontwerpkeuzes voor leuningen van de brug, geleiderail en asfalt vergelijkbaar te zijn met de casus voegovergangen (figuur 32) als uitgegaan wordt dat meer dan 75% van de respondenten representatief is. (De percentages zijn arbitrair gekozen door de onderzoeker). Uitgaande van 50% respondenten komen problemen bij LCB afwegingen bij alle ontwerpkeuzes voor. De ontwerpkeuzes van portaal, afsluitboom, lichtmast en kabels worden meegenomen als 25% representatief wordt genoemd. De antwoorden van respondenten bij deze ontwerpkeuzes kan verklaard worden, omdat de respondenten (wegen en kunstwerken) mogelijk niet de ervaring en kennis hebben van het vakgebied van deze discipline. Het volgende voorbeeld vanuit een gehouden interview, is daarvan sprekend: Voorbeeld geleiderail “Een voorbeeld waar informatie niet uitgewisseld is tussen het team van Ontwerp, Realisatie en Onderhoud is bij de ontwerpkeuze voor de geleiderail. Bij de ontwerpkeuze van geleiderail ging het Realisatieteam uit dat zij een 50%^ van de planken terug mochten plaatsen, dus konden hergebruiken. Tegelijkertijd had het onderhoudsteam beloofd de geleiderail te vervangen. Als ergens is vastgelegd dat wij overal nieuwe geleiderail toepassen, maar het Realisatie team gaat uit van hergebruik dan kom je vervolgens financieel niet uit” (PO1)

Dit voorbeeld heeft betrekking op de ontwerpkeuze voor geleiderail. Enige nuancering is nodig, omdat de praktijk voorbeelden zijn waarbij wel informatie effectief uitgewisseld wordt. Een voorbeeld is de ontwerpkeuze voor de leuning van een brug tussen de projectleider realisatie en projectleider onderhoud: Voorbeeld leuning brug “De leuning van de brug is uitgevoerd in RVS. "Direct na de tender kwam de projectmanager met het verzoek om een ander type leuning te kiezen in verband met de hoge kosten voor het realiseren. Wij, als onderhoudsteam, hebben toen duidelijk onze voorkeur uitgesproken om RVS te gebruiken, omdat we daardoor minimaal onderhoud aan de leuningen hebben"(PO1).

De respondent in bovenstaand voorbeeld gaf aan dat de informatie duidelijk was vastgelegd en eenvoudig kon toelichten op welke wijze in de tender de afweging is gemaakt voor het type leuning. De keuze voor dit type leuning (RVS) zou namelijk, op basis van LCB afwegingen, leiden tot een beter overall eindresultaat dan het vervangen voor een ander type leuning. Enkele respondenten geven aan dat een Object als totaal niet gezien kan worden als “het te onderhouden onderdeel” (PO2, PO4). Een respondent vraagt: “Welk Element/ deel is het deel waar het pijn gaat doen bij de ontwerpkeuze van een voegovergang (PO4)? In het geval van een stalen voegovergang is het niet staal, maar het rubber dat onderhoud nodig heeft. Enkel een te licht type staal of een slechte uitvoering kan leiden tot niet-beschikbaarheid”. Duidelijk is dat vaak onderdelen van


objecten ervoor zorgen dat objecten onderhoud nodig hebben. Daarom is enige nuance nodig bij het benoemen welke objecten wel en niet voor beschikbaarheid van belang zijn. Dat de voegovergang niet de enige ontwerpkeuze is waar problemen spelen kan verklaard worden dat binnen het systeemdenken in hoofdstuk 3 de verschillende Elementen onderling met elkaar verbonden zijn. De ontwerpkeuze van voegovergangen kan andere delen binnen een project beïnvloeden. Dit geldt ook andersom. Gezien de overeenkomstige problemen bij andere ontwerpkeuzes rechtvaardigt dit de generaliseerbaarheid van de casus voegovergangen. In de volgende paragraaf worden de verschillen en overeenkomsten tussen theorie en praktijk geanalyseerd.


7.3 Verschillen en overeenkomsten theorie en praktijk In deze paragraaf worden de verschillen en overeenkomsten tussen de praktijk en de theorie zijn vergelijken. Daarbij wordt per voorwaarde voor effectieve informatie-uitwisseling de verschillen en overeenkomsten vergeleken. De werkwijze is gevisualiseerd in de onderstaande toelichting.

Toelichting werkwijze De verschillen en overeenkomsten worden per voorwaarde geanalyseerd. De voorwaarden zijn relevant, aanwezig, tijdig beschikbaar, expliciet, traceerbaar. De voorwaarden kennen een nummering, die volgt uit de beantwoording van deelvraag 2. Dit zijn de nummers 1a, 1b, 2, 3 en 4.

Relaties

Voorwaarden

1 (a)

1 (b)

2

3

4

a) Relatie tussen eis en functie; b) Relatie tussen eis en organisatie; c) Relatie tussen eis en locatie; d) Relatie tussen eis en fase; e) Relatie tussen eis en object; f) Relatie tussen eis en risico

Figuur 33 Visualisatie per voorwaarde De relaties komen voort uit deelvraag 1 en zijn in de beantwoording van deelvraag 3 gebruikt. De nummering van de relaties (a t/m f) komen overeen met de nummering in hoofdstuk 5. De hoogte van de grafieken fluctueert. De hoogte geeft aan hoeveel relaties voldoen aan de voorwaarde. Elk figuur is een voorbeeld van de resultaten uit de praktijk. Onder elk figuur volgt een verklaring van de verschillen tussen de praktijk en theorie en de bevinding die hieruit volgt. De afkorting van elke bevinding is gerelateerd aan een van de voorwaarden

REL = relevant (1 a) AANW = aanwezig (1b) TIJ = tijdig beschikbaar (2) EXP = expliciet (3) TRAC = traceerbaar (4)

In het voorbeeld staat de werkwijze van deze paragraaf. Elk van de volgende figuren geeft dus aan om welke voorwaarde het gaat en welke relaties aan de desbetreffende voorwaarde voldoen. De kleur bij een voorwaarde geeft aan dat dit over die desbetreffende voorwaarde gaat. Hierbij is te zien in hoeverre men invulling heeft gegeven aan de voorwaarde voor effectieve informatie-uitwisseling.


Informatie relevantie In dit onderzoek wordt gesproken van effectieve informatie-uitwisseling als informatie relevant wordt gevonden (1a). In figuur 34 zijn de resultaten uit hoofdstuk 6 voor de relevantie te zien. Relaties

Voorwaarden

1 (a)

1 (b)

2

3

4

a) Relatie tussen eis en functie; b) Relatie tussen eis en organisatie; c) Relatie tussen eis en locatie; d) Relatie tussen eis en fase; e) Relatie tussen eis en object; f) Relatie tussen eis en risico

Figuur 34 Informatie is relevant bij relaties a t/m f

Uit beantwoording van deelvraag 4 blijkt dat aan deze voorwaarde wordt voldaan, omdat men de informatie relevant vindt. In dit onderzoek staat de relevantie niet ter discussie. Hieruit volgt de volgende bevinding:

Theorie versus praktijk: Aan deze voorwaarde wordt voldaan door de praktijk. Daarom zullen geen aanbevelingen voor deze voorwaarde worden gedaan (REL-1) In dit onderzoek worden geen aanbevelingen gedaan voor deze voorwaarde. Informatie aanwezig in project In dit onderzoek wordt gesproken van effectieve informatie-uitwisseling als informatie in een project aanwezig is (1b). In figuur 35 zijn de resultaten uit hoofdstuk 6 voor de aanwezigheid te zien. Relaties

Voorwaarden

1 (a)

1 (b)

2

3

4

a) b) Relatie tussen eis en organisatie; c) Relatie tussen eis en locatie; d) Relatie tussen eis en fase; e) Relatie tussen eis en object; f) Relatie tussen eis en risico

Figuur 35 Informatie is aanwezig bij relaties b t/m f

De praktijk geeft aan dat bij relatie a in meerdere gevallen in het project niet gelegd is of wordt. Kortom, men heeft niet op die manier gewerkt in het project. Dit kan tweeledig verklaard worden: (1) de informatie uit de SE Processen zijn niet centraal vastgelegd of (2) verschillende SE processen zijn niet uitgevoerd. Volgens de respondenten wordt in de praktijk niet vanuit functies gewerkt. Men gebruikt wel de functionele eisen die in het contract zijn gesteld door RWS, maar leidt niet zelf eisen vanuit functies af. Eerder onderzoek (Kluis, 2012) geeft aan dat niet vanuit functies gewerkt is in de vraagspecificatie voor de A15. In dit onderzoek was de Botlekbrug de casus en onderwerp van discussie. Hierbij stonden zowel Thesis Jeremy de Bruijn_5-12-2013 95

tijdens het voortraject van als na gunning bij de opdrachtnemer de functies niet centraal. Dit sluit aan op de resultaten uit de interviews. Hiermee wordt bevestigd dat in projecten onvoldoende vanuit functies wordt geredeneerd. Hieruit volgt de volgende bevinding:

Theorie versus praktijk: In de praktijk worden functie en functionaliteit nauwelijks centraal gesteld, terwijl dit volgens de theorie één van de basis Structuren van Systems Engineering is (AANW-1) Uit resultaten van hoofdstuk 6 blijkt dat informatie niet in de getoetste relaties aanwezig is. Daarbij is onbekend of SE processen gevolgd worden en/ of überhaupt uitgevoerd worden. Volgens de SE Life Cycle processen, die gedefinieerd zijn in de ISO 15288, dienen meerdere processen opgezet te worden. De SE Life Cycle processen zijn te verdelen in vier categorieën (Nederlands Normalisatie Instituut, 2008): - Agreement processes; - Enterprise processes; - Project processes; - Technical processes. Van deze categorieën moeten meerdere processen worden ingericht. Voor de projectprocessen moeten onder andere Project Planning, Risk Management, Configuration Management en Decision Making worden ingericht (Nederlands Normalisatie Instituut, 2008). Onder de technische processen worden onder andere Stakeholder Requirements Definition, Requirements Analysis, Architectural Design genoemd(Nederlands Normalisatie Instituut, 2008). Deze komen overeen met het DoD model in figuur 14. RWS heeft contractueel vastgelegd dat de SE processen volgens de norm ISO 15288 ingericht dient worden (Rijkswaterstaat, 2012). In de praktijk interpreteert elke organisatie de abstracte beschrijving van de ISO15288 op een andere manier (Ruijven, 2013). Elke organisatie gebruikt een “eigen” taal om deze processen te beschrijven (Ruijven, 2013). De verschillende interpretaties van de ISO15288 kunnen leiden tot problemen in interoperabiliteit als partijen in één gezamenlijk project gaan werken. Dit komt overeen met de fragmentatie, zoals benoemd in hoofdstuk 1. In hoofdstuk 1 is geconstateerd dat een projectorganisatie een eigen identiteit heeft, zodat zij samen kunnen werken met een gemeenschappelijk set van waarden en normen om de projectdoelstellingen van het project te behalen (Verbraeck, 2012). Elke activiteit die een team binnen een organisatie moet doen kost geld. Een verklaring voor de verschillende interpretaties kan zijn dat het geld kost om informatie in een project te organiseren. Aangezien organisaties beperkt ervaring hebben met informatie-uitwisseling tussen veel verschillende partijen kan verklaard worden dat de wil er niet is om te bepalen voor informatie-uitwisseling. Hieruit volgt de volgende bevinding:

Theorie versus praktijk: In de praktijk interpreteren verschillende teams de ISO15288 anders. Om de processen van de ISO15288 te doorlopen en de informatie vast te leggen kost geld. In de praktijk wordt minder gestructureerd gewerkt volgens SE dan de theorie voorschrijft (AANW-2)


Tijdige beschikbaarheid van informatie In dit onderzoek wordt gesproken van effectieve informatie-uitwisseling als informatie tijdig beschikbaar is (2). In figuur 36 zijn de resultaten uit hoofdstuk 6 voor de tijdige beschikbaarheid te zien. Relaties

Voorwaarden

1 (a)

1 (b)

3

4

2

a) b) Relatie tussen eis en organisatie; c) Relatie tussen eis en locatie; d) Relatie tussen eis en fase; e) Relatie tussen eis en object. f) -

Figuur 36 Informatie is beschikbaar bij relaties b t/m e

De praktijk geeft echter aan dat bij relatie a en f deze niet in projecten tijdig beschikbaar zijn. Het proces van ontwerpen en afleiden verloopt volgens de theorie uit hoofdstuk 3 parallel. Echter, in het geval van voegovergangen zien enkele respondenten een voegovergang als onderdeel van het kunstwerk. Om die reden geven zij aan dat de voegovergang niet apart gespecificeerd wordt, maar als onderdeel van het kunstwerk. Dit sluit niet aan op het apart specificeren en ontwerpen, volgens het SE Proces van hoofdstuk 3. Contracteisen zijn interpretatiegevoelig voor teams in een DBFM project. Vanuit de interviews is geconstateerd dat contracteisen niet altijd worden afgeleid tot SMART eisen, maar de opdrachtnemers wel verder gaan met het vaststellen van het ontwerp op detailniveau. Contracteisen zijn doorgaans abstract, waardoor bij het detail ontwerp geen gebruik wordt gemaakt van een groeiende eisenboom, die afgeleide eisen kent. Hieruit volgt de volgende bevinding:

Theorie versus praktijk: In de praktijk lopen SE processen door elkaar heen, terwijl in de theorie aparte SE processen moeten worden opgezet. Daarvan is het ontwerpproces één proces van een groter aantal op te zetten processen tijdens de ontwerpfase (TIJ-1) In een aantal gevallen is de informatie van afgeleide eisen van het asfalt niet gebruikt voor de keuze voor voegovergangen, omdat de informatie niet tijdig beschikbaar was gesteld. De theorie geeft aan dat raakvlakken tussen objecten tijdig inzichtelijk moeten worden gemaakt, in de vorm van raakvlakeisen (Werkgroep leidraad SE, 2009). De praktijk wijst echter uit dat informatie van asfalt pas laat in het traject beschikbaar komt en vervolgens niet meer afgestemd is met voegovergangen. Kortom, het eisen analyse proces wordt niet meerdere malen (continue) doorlopen. Hieruit volgt de volgende bevinding:

Theorie versus praktijk: In de praktijk is het afleiden van eisen een proces van afstemmen, terwijl in de theorie het volledige eisen analyse proces meerdere malen (continue) doorlopen moet worden (TIJ-2) In de basisuitgangspunten van Systems Engineering wordt uitgegaan dat medewerkers kennis hebben van alle levenscyclus fasen van objecten (zowel ontwerp, realisatie als onderhoud). Eén van de bevindingen is dat vooral informatie betreffende het onderhoud zeer laat of niet tijdig beschikbaar wordt gemaakt. Dit bemoeilijkt het meenemen van onderhoud bij het maken van adequate LCB Thesis Jeremy de Bruijn_5-12-2013 97

afwegingen. Een veelgenoemde reden in de interviews is dat het onderhoudsteam wel beperkte kennis heeft van operationeel onderhoud, maar kennis gelimiteerd is bij het meenemen van het totale onderhoudspakket om een LCB afweging te maken. Kortom, er is een tekort aan kennis van Maintenance (Onderhoud) Engineering in de praktijk. Hieruit volgt de volgende bevinding:

Theorie versus praktijk: In de praktijk wordt een tekort aan kennis binnen het onderhoudsteam geconstateerd. In de theorie is informatie die aanwezig moet zijn tijdens het proces (TIJ-3)

Expliciete informatie In dit onderzoek wordt gesproken van effectieve informatie-uitwisseling als informatie expliciet is (3). Informatie is expliciet als de informatie helder is vastgelegd in een database. In figuur 37 zijn de resultaten uit hoofdstuk 6 voor de expliciet te zien. Voorwaarden

Relaties

1 (a)

a) b) Relatie tussen eis en organisatie; c) d) e) f) -

4 1 (b) 2 3

Figuur 37 Informatie is expliciet bij relatie b

Op basis van de resultaten uit de praktijk blijkt soms informatie expliciet te worden gemaakt. Volgens de theorie zou altijd een afleiding van de eisen plaats moeten vinden voordat de eisen toegewezen worden. Dit zou onderdeel moeten zijn van iedere iteratieslag in het SE proces. Een voorbeeld is de eisen analyse bij één van de projecten. “De hoofdaannemer moest eisen analyseren en eisen afleiden, maar de eisen bleven op contract niveau”. De theorie over SE volgens Department of Defense (2001) geeft aan dat in het begin van het project eisen analyses plaatsvinden waarbij onder andere de performance eisen verfijnd moeten worden. Later moet deze werkwijze meerdere keren herhaald worden (Werkgroep leidraad SE, 2009). Hieruit volgt de volgende bevinding:

Theorie versus praktijk: In de praktijk worden eisen worden niet of eenmalig afgeleid volgens het eisen analyse proces, terwijl in theorie alle eisen afgeleid moeten worden (EXPL-1)


Traceerbaarheid van informatie In dit onderzoek wordt gesproken van effectieve informatie-uitwisseling als informatie traceerbaar is naar een bron (4). In figuur 38 zijn de resultaten uit hoofdstuk 6 voor de traceerbaarheid te zien.

Voorwaarden

Relaties

1 (a)

a) b) Relatie tussen eis en organisatie; c) d) e) f) -

1 (b) 2 3

4

Figuur 38 Informatie is traceerbaar bij relatie b

Op basis van de resultaten uit de praktijk blijkt alleen de informatie bij de relatie tussen Eis en Locatie traceerbaar gemaakt te worden. De theorie over SE uit hoofdstuk 3 en het denken in systemen (In 't Veld, 2002) geeft aan dat men moet denken vanuit het geheel. Door later dit geheel op te delen en onderling relaties te leggen kan het geheel beheerst worden. In de praktijk worden echter weinig relaties gelegd tussen eisen en andere informatie. Volgens de respondenten in het onderzoek mist samenhang tussen informatie en is informatie moeilijk traceerbaar. Hieruit volgt de volgende bevinding:

Theorie versus praktijk: In de praktijk is niet één samenhangend geheel te herkennen in informatie, terwijl in de theorie een totaaloverzicht gewenst is volgens het systeemdenken. Daarmee kan geconcludeerd worden dat context en samenhang mist in informatie. (TRAC-1) De verschillen en overeenkomsten zijn input voor product 4.


7.4 Product 4: Verschillen analyse theorie en praktijk Vanuit de eerdere paragraven in dit hoofdstuk zijn bevindingen opgesteld. Vanuit deze bevindingen worden aanbevelingen afgeleid die handvatten bieden tot effectievere informatie-uitwisseling. Onderstaand een overzicht van verschillen en overeenkomsten tussen theorie en praktijk en de door de respondenten genoemde verbeteringen welke zijn vertaald in een mogelijke aanbeveling. In tabel 14 zijn de verschillen, bevindingen en aanbevelingen te zien. Tabel 14 Verschillenanalyse theorie en praktijk

Theorie

Praktijk

Informatie moet relevant gevonden worden. In SE werken vanuit functies

Opdrachtnemers vinden informatie relevant om uit te wisselen

Eén informatie voorziening tussen partijen

In de praktijk heeft men te maken met verschillende teams, interpretaties en budgetten.

Aparte processen voor afleiden en ontwerpen

Men ziet SE in de praktijk meer als eisenbeheer, dat opgelegd is door publieke opdrachtgevers om aan de eisen te voldoen. In de praktijk is weinig afstemming tussen afgeleide eisen van kunstwerken en wegen. Beide komen te weinig met afgeleide eisen Informatie vanuit het onderhoudsteam is beperkt. De kennis van het onderhoudsteam wordt als ontoereikend ervaren. Eisen blijven in de praktijk op contractniveau en dus abstract

Afstemmen eisen door eisen analyse proces te herhalen Informatie is aanwezig vanuit het onderhoudsteam Contracteisen worden afgeleid tot SMART eisen In de theorie wordt gesproken over een System Design

De eisen zijn door RWS afgeleid uit functies en worden ervaren als vast staande (functionele) eisen.

In de praktijk worden beperkt relaties gelegd tussen eisen en andere Structuren, kortom geen System Design

Bevinding

Aanbeveling (richting)

REL-1: Zowel de praktijk als de theorie geeft aan dat informatie meegenomen moet worden AANW-1: Een opdrachtnemers redeneert niet opnieuw vanuit de functies, waardoor een deel van het SE proces niet doorlopen wordt AANW-2: Verschillen in teams, interpretatie en budgetten leidt tot verschillende informatie-uitwisseling. Niemand wil betalen voor het organiseren van de informatie TIJ-1: Onderscheid tussen verschillende Structuren om informatie in vast te leggen

Niet van toepassing

-

Werkwijze van opdrachtnemers veranderen (o.a. richting MBSE)

TV-1

Reserveren groter geldbedrag voor het organiseren van de informatie

ON-1

Vanaf start project werken volgens uitgangspunten van SE

IF-3

TIJ-2: Het eisen analyse proces wordt niet herhaald

Meerdere malen doorlopen processen (o.a. eisen analyse proces)

ON-2

TIJ-3: In de praktijk ligt de focus op de eisen van het ontwerp en de uitvoeringsfase en niet op het onderhoud. EXP-1: Het eisen analyse proces wordt niet voor alle eisen doorlopen, omdat niet alle eisen worden afgeleid. TRAC-1 Door de beperkte relaties tussen eisen en Structuren mist de informatie samenhang en context.

Geen aanbeveling voor informatieuitwisseling. Algemene aanbeveling: vergroot kennis van Maintenance Engineering afspraken maken over de interpretatie van ISO 15288. Bijvoorbeeld eisen afleiden, tot het detailniveau van het ontwerp Werken met standaard Structuren en relaties van SE voor een SD en vanaf begin van het project deze Structuren opzetten

-

ON-3

ON-4 TV-2 IF-1 F-2

De afkortingen in de tabel kennen de volgende toelichting: - TV: Een aanbeveling die verder uitgediept en ingekaderd moet worden door middel van literatuur/theoretisch onderzoek; - ON: Een aanbeveling die (generiek) opgaat voor opdrachtnemende partijen in DBFM projecten; - IF: Een aanbeveling, die specifiek voor opdrachtgever Iter Fidelis geldt in dit onderzoek De richting van de aanbevelingen wordt gebruikt in hoofdstuk 9 voor aanbevelingen. Op basis van hoofdstuk 7 en product 4 kan een antwoord worden gegeven op deelvraag 4.


7.5 Beantwoording deelvraag 4 Deze paragraaf is beantwoording van de deelvraag “Welke verschillen en overeenkomsten zijn te onderkennen tussen de praktijk en de theorie bij ontwerpkeuzes betreffende de informatieuitwisseling binnen Nederlandse weginfrastructuurprojecten?” Op basis van de resultaten zijn verschillen en overeenkomsten tussen praktijk en theorie gevonden. Op basis van de verschillen en overeenkomsten in paragraaf 7.3 zijn in tabel 14 in paragraaf 7.4 bevindingen en voorlopige aanbevelingen gedaan om informatie-uitwisseling effectiever plaats te laten vinden. In tabel 15 zijn de tussen de praktijk en de theorie samengevat. Tabel 15 Samenvatting bevindingen op basis van verschillen en overeenkomsten.

Nr.

Bevinding

Toelichting

REL-1

Overeenkomst

Zowel de praktijk als de theorie geeft aan dat informatie meegenomen moet worden

AANW1 AANW2 TIJ-1

Verschil Verschil

Opdrachtnemers redeneren niet (opnieuw) vanuit de functies, waardoor een deel van het SE proces niet doorlopen wordt Verschillen in teams, interpretatie en budgetten leidt tot verschillende informatie-uitwisseling

Verschil

Onderscheid tussen verschillende Structuren

TIJ-2

Verschil

Het eisen analyse proces wordt niet herhaald

TIJ-3

Verschil

EXP-1

Verschil

TRAC-1

Verschil

In de praktijk ligt de focus op de eisen van het ontwerp en de uitvoeringsfase en niet op het onderhoud Het eisen analyse proces wordt niet voor alle eisen doorlopen, omdat niet alle eisen worden afgeleid. Door de beperkte relaties tussen eisen en Structuren mist de informatie context. Dit beperkt de samenhang en context van informatie.

Iedere bevinding is gekoppeld aan één van de voorwaarden voor effectieve informatie-uitwisseling die vastgesteld zijn in hoofdstuk 4. Van de bevindingen zijn twee onderdelen uitgelicht. Deze onderdelen zijn belangrijk omdat ze een duidelijk verschil tussen theorie en praktijk weergeven. Algemeen geldt dat eisen onvoldoende afgeleid worden en expliciet worden gemaakt. In de praktijk worden contracteisen onvoldoende afgeleid, maar doorloopt men de ontwerpprocessen gelijkertijd op lager detailniveau. Dit zorgt ervoor dat verschillende teams (bijvoorbeeld per discipline als wegen en kunstwerken) parallel werken met eisen die meervoudig interpreteerbaar zijn, terwijl het ontwerp verder gedetailleerd wordt. Een voorbeeld uit hoofdstuk 6 zijn afgeleide eisen van het asfalt en afgeleide eisen vanuit de onderhoudsstrategie, die niet of te laat ter beschikking worden gesteld. Op basis van de verschillen en overeenkomsten tussen praktijk en theorie gevonden blijkt dat SE in de praktijk ervaren wordt als een vorm van eisenbeheer, opgelegd door publieke opdrachtgevers. In de praktijk ligt de focus op de eisen van het ontwerp en de uitvoeringsfase en niet op het onderhoud. Dit leidt uiteindelijk tot LCB afwegingen die niet de gehele levenscyclus van een object en het gehele systeem meenemen. Daarbij worden in de praktijk beperkt relaties gelegd tussen eisen en andere Structuren. Daardoor mist informatie context en samenhang waardoor gedurende de werkzaamheden gewerkt wordt met incomplete informatie, die gelijktijdig meervoudig geïnterpreteerd kan worden.


De conclusie is dat SE dus door de opdrachtnemers ontvangen en geïnterpreteerd als een verplichte exercitie van de (publieke) opdrachtgever in een DBFM project. Dit leidt tot het ongedragen implementeren van de structuren, waardoor onvoldoende wordt voldaan aan de gestelde voorwaarden voor informatie ontsluiting. Opdrachtnemers investeren daarbij onvoldoende in andere wijzen van effectief informatiebeheer en uitwisseling, waardoor de faalkosten hoog blijven De bevindingen uit dit hoofdstuk worden gebruikt voor conclusies in hoofdstuk 8. De richting van de aanbevelingen wordt gebruikt voor de aanbevelingen in hoofdstuk 9.


Deel E Evaluatie

Deel A Opzet

Deel B Theorie




Deel C Resultaten

Deel D Discussie


(4)



Deel Evaluatie

Veldonderzoek




LEGENDA Theorie

Empirie

Producten

(1)




8 Conclusies Het doel van dit onderzoek is om te bepalen of effectieve informatie-uitwisseling plaatsvindt bij het maken van ontwerpkeuzes en aanbevelingen te doen voor effectievere informatie-uitwisseling. De hoofdvraag in dit onderzoek is daarom tweeledig. In dit hoofdstuk wordt antwoord gegeven op het eerste deel van de hoofdvraag. Het tweede deel van de hoofdvraag wordt beantwoordt in hoofdstuk 9, waar aanbevelingen worden gegeven. Het probleem in dit onderzoek is dat bij het maken van Life Cycle Based afwegingen in de praktijk te weinig gebruik gemaakt van informatie van verschillende informatie dragers die bepalend is voor de levenscycluskosten. De informatie is binnen de Organisatie beschikbaar, maar informatie over systeemkenmerken en gedragingen wordt onvoldoende uitgewisseld tussen het ontwerpteam en de informatiedragers tijdens de ontwerpfase. De hoofdvraag van dit onderzoek is: “Vindt effectieve informatie-uitwisseling plaats tussen teams van opdrachtnemers binnen Nederlandse DBFM weginfrastructuurprojecten? En kan deze uitwisseling effectiever uitgevoerd worden?” Binnen Nederlandse DBFM weginfrastructuurprojecten vindt nauwelijks effectieve informatieuitwisseling (1) plaats volgens de gestelde voorwaarden in dit onderzoek. Daarom bestaat veel ontwikkelpotentieel (2) om tot effectievere informatie-uitwisseling te komen. Voor het benutten van deze potentie worden aanbevelingen gesteld, die terug te vinden zijn in hoofdstuk 9. Voor het onderzoeken van deze hoofdvraag zijn verschillende deelvragen bepaald. Aan de hand van literatuuronderzoek (theorie) een het uitvoeren van interviews (raakvlak met praktijk) is onderzocht hoe effectieve informatie-uitwisseling behoort plaats te vinden, en uiteindelijk plaatsvindt. In dit onderzoek is vastgesteld dat informatie-uitwisseling effectief is als LCB afwegingen gemaakt kunnen worden met behulp van LCC analyses en volgens de uitgangspunten van SE wordt gewerkt. Dit heeft geleid tot voorwaarden die bepalend zijn in welke mate succesvol informatie-uitwisseling kan plaatsvinden: Relevantie van informatie (1a); Aanwezigheid van informatie (1b); Tijdig beschikbaarheid van informatie (2); Expliciete vastlegging van informatie (3); Traceerbaarheid van informatie (4). Uit de interviewresultaten is geconcludeerd dat in vijf van de zes relaties niet voldaan wordt aan alle voorwaarden voor informatie-uitwisseling. Dit betreft: Relatie tussen Eis en Functie (a); Relatie tussen Eis en Locatie (b); Relatie tussen Eis en Object (d); Relatie tussen Eis en Fase (e); Relatie tussen Eis en Risico (f). De relatie die wel voldoet aan de voorwaarden voor effectieve informatie-uitwisseling betreft de relatie tussen Eis en Organisatie (c). Hiermee wordt invulling gegeven aan in ieder geval één relatie door opdrachtnemers.


De relatie tussen Eis en Organisatie wordt gelegd, maar is discutabel. Opdrachtnemers denken dat het leggen van de relatie tussen Eis en Organisatie voldoende houvast biedt om met SE te werken. Ondanks dat bij de relatie tussen Eis en Organisatie wel voldaan wordt aan de voorwaarden voor effectieve informatie-uitwisseling om LCB afwegingen te maken, kan dit een averechts effect hebben op informatie-uitwisseling. Wat is de waarde van het toekennen van eisen aan een Organisatie als de relatie tussen bijvoorbeeld Eis en Locatie niet gelegd is? Een relatie tussen Eis en Organisatie kan niet op zichzelf staan in projecten waar meerdere teams samen moeten werken, omdat de samenhang van de Eis met andere Structuren niet bekend is. In hoofdstuk 1 is de complexiteit van DBFM projecten benoemd. Dit geeft reden om aan te nemen dat het informatiemanagement niet eenvoudig is in te richten. Ook de volwassenheid van opdrachtnemers is dubieus als het gaat om informatie management, omdat dit een nieuwe taak voor opdrachtnemers is.


9 Aanbevelingen Gebrekkige informatie-uitwisseling staat op nummer één als factor voor faalkosten. De belangrijkste aanbeveling voor alle partijen die werkzaam zijn binnen de GWW sector strekt daarom tot het verbeteren van de wijze waarop in de projecten stuurt op informatie-uitwisseling. Om effectieve informatie-uitwisseling plaats te laten vinden is niet één oplossing voorhanden. Daarom worden meerdere aanbevelingen gedaan aan verschillende betrokkenen in dit onderzoek. In paragraaf 9.1 worden aanbevelingen gedaan voor theorievormend onderzoek (TV). Vervolgens volgen aanbevelingen voor opdrachtnemers van DBFM projecten (ON) in paragraaf 9.2. Tot slot worden in paragraaf 9.3 Specifieke aanbevelingen gedaan voor Iter Fidelis (IF) in het kader van de ontwikkeling van een database.

9.1 Aanbevelingen voor theorievormend onderzoek Deze paragraaf bestaat uit aanbevelingen voor theorievormend onderzoek (TV). In paragraaf 7.1.3 is geconstateerd dat opdrachtnemers problemen hebben met de beheersing informatie uit processen. Dit maakt wetenschappelijk onderzoek kansrijk, omdat opdrachtnemers meer geld zullen investeren in de beheersing van processen. De volgende aanbevelingen hebben hierop betrekking. In dit onderzoek is de procesbenadering SE gebruikt om informatie vast te leggen en te Structureren. Een volgende stap is om deze Structuren te modelleren. Het modelleren van Systemen krijgt nu ook veel aandacht binnen INCOSE (Incose, 2013). Binnen branches waar de klassieke SE processen tot de dagelijkse wijze van werken behoren, wordt nu MBSE toegepast om de interne en onderlinge samenhang + gedrag van systemen te modelleren. TV-1: Onderzoek naar de toepassing van Model Based Systems Engineering (MBSE) in Nederlandse DBFM weginfrastructuurprojecten

Het theoretisch onderdeel van dit onderzoek is beperkt tot tien Structuren waarin informatie vastgelegd kan worden. Uit de theorie over SE is in paragraaf 3.2.3 geconstateerd dat nog meer Structuren bestaan om informatie in te Structureren. In mijn onderzoek was het doel niet om oneindig veel Structuren te bedenken, maar zijn de Structuren gebruikt die nodig zijn om effectieve informatie-uitwisseling te kunnen toetsen. Vervolgonderzoek kan verder ingaan het aantal structuren (en relaties tussen Structuren), dat optimaal is voor een situatie. TV-2: Onderzoek naar optimale verhouding van Structuren en relaties om informatie in vast te leggen

In dit onderzoek hebben Structuren centraal gestaan. In dit onderzoek is daarbij beperkt tot het leggen van relaties tussen Structuren in hoofdstuk 0. Een vervolgonderzoek kan voortbouwen op het Theoretisch model in figuur 19. Daarbij kunnen wellicht meer Structuren en relaties worden blootgelegd dan de Structuren die tot nu toe geïdentificeerd zijn in. Een specifiek onderdeel daarbinnen kunnen het aantal relaties binnen en tussen Structuren zijn. TV-3: Aantal relaties bepalen tussen Structuren en binnen Structuren van SE


9.2 Aanbevelingen voor opdrachtnemers De belangrijkste aanbeveling komt uit de overall conclusie van hoofdstuk 8. Dit is dat opdrachtnemers meer dan nu het geval vanuit het management sturen op effectieve informatie-uitwisseling binnen een project. Daarbij moet een opdrachtnemer met een informatie management systeem komen dat nauw aansluit op de primaire werkprocessen van de medewerkers. Deze aanbeveling volgt uit de kritieke succesfactoren die in hoofdstuk 0 benoemd zijn door de respondenten. Het werken volgens de uitgangspunten van SE kan hierbij helpen om de faalkosten als gevolg van gebrekkige informatieuitwisseling te beperken. In dit onderzoek is binnen de praktijk gevraagd naar meningen over informatie-uitwisseling per voorwaarde. Hieronder volgen aanbevelingen voor opdrachtnemers. Uit de conclusies van hoofdstuk 8 bleek dat informatie beperkt aanwezig is binnen het project (1b). De auteur adviseert om een omvangrijker onderzoek op te zetten, waarbij alle relaties getoetst worden naar relevantie versus de aanwezigheid in een project. Dit kan dan op projecten van verschillende projectomvang om te toetsen of dit een overeenkomstig beeld schetst. De verwachting is dat dit beeld algemeen geldt bij Nederlandse weginfrastructuurprojecten, maar verschil in effectieve informatieuitwisseling bij enorm grote projecten mogelijk exponentieel groter is. Hieruit volgt de volgende aanbeveling: ON-1: Investeren in één centraal informatie management systeem. Reserveer een geldbedrag voor het organiseren van de informatie

Men kan spreken van effectieve informatie-uitwisseling als informatie tijdig beschikbaar is. In de praktijk wordt niet altijd de informatie tijdig uitgewisseld. Vooral afgeleide eisen die betrekking hebben op het asfalt en afgeleide eisen die voortvloeien uit de onderhoudsstrategie worden laat ter beschikking gesteld. In dit onderzoek is als uitgangspunt gebruikt dat men werkt volgens het SE proces. Uit hoofdstuk 7 blijkt echter dat informatie vanuit het SE proces niet binnen het project aanwezig is. Een voorbeeld is dat de eisen analyse niet of slechts eenmalig wordt uitgevoerd, zodat deze niet up to date blijft. Daarbij is voor de respondenten onbekend of het SE proces gevolgd is en/ of überhaupt uitgevoerd is. Om de informatie tot stand te laten komen zullen de opdrachtnemers de SE processen die gedefinieerd zijn in de ISO 15288 moeten inrichten, uitvoeren en vervolgens de informatie vastleggen en Structuren. De auteur beveelt aan dat opdrachtnemers deze SE processen vanaf de start van een project inrichten. Op die manier komt informatie uit deze processen tijdig beschikbaar. De informatie die ontstaat uit SE processen moet meegroeien met het ontwerpproces. Daarom moeten de SE processen meerder malen worden uitgevoerd. Hieruit volgt de volgende aanbeveling: ON -2: SE processen vanaf het begin van een project inrichten en de SE processen volgen

Op basis van de resultaten uit de praktijk blijkt soms informatie expliciet gemaakt te worden. Een voorbeeld is dat eisen niet afgeleid worden. Daardoor blijven opdrachtnemers te generiek om daadwerkelijk in een ontwerp te kunnen worden vertaald en aangetoond.


De belangrijkste aanbeveling voor verschillende teams binnen een project betreft het afstemmen van het detailniveau waarin een opdrachtnemer werkt op een bepaald moment en de behoefte aan informatie op dat moment. In het geval van eisen dienen zij tot voldoende detailniveau afgeleid te worden. Op die manier is maakt allocatie van eisen mogelijk. Om tot voldoende detailniveau af te leiden dienen meerdere malen eisen analyses uitgevoerd te worden. Hieruit volgt de volgende aanbeveling: ON -3: Afspraken maken over interpretatie van de ISO15288 en werken op hetzelfde detailniveaus tussen verschillende structuren

Op basis van de resultaten uit de praktijk blijkt heel af en toe informatie traceerbaar te zijn gemaakt. De auteur beveelt aan om Structuren vanaf begin van het project op te zetten voor de samenhang en context van informatie te borgen. Een volgende stap is om deze Structuren te modelleren. Dit moet aansluiten op het centrale informatiemodel (ON-1), waar altijd iedereen bij kan. Hieruit volgt de volgende aanbeveling: ON -4: Vanaf de start van een project (tenderfase) Structuren opzetten en aan elkaar te relateren om informatie vast te leggen in een System Design

De bovenstaande vier aanbevelingen hebben één kenmerk gemeen. Dat is namelijk dat, generiek gesteld, SE niet gedragen en adequaat wordt toegepast door de aannemende partijen in de markt. Hierdoor vallen gaten in het structureren en borgen van informatie, wat vervolgens leidt tot hogere faalkosten doordat informatie niet tijdig en/of niet volledig ontsloten wordt voor relevante partijen. De belangrijkste aanbeveling is daarom een samenspel van de bovenstaande vier aanbevelingen.


9.3 Aanbevelingen database Iter Fidelis Dit onderzoek is in samenwerking met het bedrijf Iter Fidelis uitgevoerd. In hoofdstuk 1 staat het belang van Iter Fidelis beschreven. Iter Fidelis wil inzicht in de Structuren en relaties tussen Structuren, zodat zij op basis daarvan een database kunnen opzetten. In de database moet informatie worden vastgelegd op basis van verschillende Structuren en relaties tussen Structuren. De theorie in dit onderzoek heeft geleid tot een Theoretisch model. Dit model bestaat uit Structuren en relaties die moeten worden gelegd tussen Structuren binnen de context van LCB afwegingen. Dit onderzoek is afgebakend tot de relaties tussen Elementen. Deze beschrijving van Structuren is een eerste stap om tot een database te komen. De eerste aanbeveling is om het Theoretisch model over te nemen. Het Theoretisch model is relationeel opgezet en sluit aan op de procesbenadering SE. Iter Fidelis wordt aanbevolen om het model in een project te toetsen of de beschikbare informatie van het project kan worden ondergebracht in één van de Structuren. Hieruit volgt de volgende aanbeveling: IF-1: Theoretisch model adopteren en concretiseren

Een derde aanbeveling voor Iter Fidelis is een onderzoek naar verschillende sofware pakketten waar informatie in gestructureerd kan worden. Daarbij dient Iter Fidelis een Structuur te kiezen waarin informatie kan worden vastgelegd brengt volgens de procesbenadering SE. In de sector biedt Relatics de meest gangbare software om volgens de procesbenadering SE te werken, maar op dit moment zijn meerdere pakketten beschikbaar om informatie kunnen Structureren. De auteur beveelt daarom een variantenstudie aan. Hieruit volgt de volgende aanbeveling: IF-2: Onderzoek doen naar de programmatuur voor een database

In praktijk is de opdrachtnemer met haar SE processen nog niet zover met het standaardiseren van deze processen of krijgt de informatie uit processen niet op de juiste plek. Om als Iter Fidelis voorop te blijven lopen in de sector is een investering in MBSE noodzakelijk. De theorie over SE geeft aan dat bij grote projecten tevens een grote investering van SE noodzakelijk is om het systeem te ontwikkelen. Dit betekent dat een investering in informatie management voor deze procesbenadering noodzakelijk is. Daarbij beveelt de auteur aan dat Iter Fidelis gaat investeren in Model Based SE. Iter Fidelis zou met de ontwikkeling van producten en diensten op deze blinde vlek in moeten spelen, vanwege de impact die goed informatie management kan hebben bij het terugbrengen van faalkosten. Hieruit volgt de volgende aanbeveling: IF-3: Informatie management – blinde vlek binnen projecten

In tabel 16 zijn de conclusies en aanbevelingen te vinden.


Tabel 16 Samenvatting conclusies en aanbevelingen

Conclusies en aanbevelingen Conclusies Conclusie 1: In Nederlandse DBFM weginfrastructuurprojecten is nauwelijks sprake van effectieve informatie-uitwisseling volgens de gestelde voorwaarden in dit onderzoek Conclusie 2: Er is groot ontwikkelpotentieel om tot effectievere informatie-uitwisseling te komen

Bevindingen

Nr.

Aanbeveling

REL-1: Zowel de praktijk als de theorie geeft aan dat informatie meegenomen moet worden AANW-1: Een opdrachtnemer redeneert niet opnieuw vanuit de functies, waardoor een deel van het SE proces niet doorlopen wordt

-

Geen aanbeveling

TV-1

Werkwijze van opdrachtnemers veranderen richting MBSE

TV-3

AANW-2: Verschillen in teams, interpretatie en budgetten leidt tot verschillende informatieuitwisseling TIJ-1: Onderscheid tussen verschillende Structuren

ON-1

Aantal relaties bepalen tussen Structuren en binnen Structuren van SE Investeren in één centraal informatie management systeem. Reserveer een geldbedrag voor het organiseren van de informatie Informatie management – blinde vlek binnen projecten

TIJ-2: Het eisen analyse proces wordt niet herhaald TIJ-3: In de praktijk ligt de focus op de eisen van het ontwerp en de uitvoeringsfase en niet op het onderhoud. EXP-1: Het eisen analyse proces wordt niet voor alle eisen doorlopen, omdat niet alle eisen worden afgeleid. TRAC-1: Door de beperkte relaties tussen eisen en Structuren mist de informatie context. Dit beperkt de samenhang en context van informatie.

ON-2

IF-3

-

Meerdere malen doorlopen processen (o.a. eisen analyse proces) Geen aanbeveling voor informatie-uitwisseling. Vergroot kennis van Maintenance Engineering

ON-3

afspraken maken over de interpretatie van ISO 15288 en werken op hetzelfde detailniveau

ON-4

Vanaf de start van een project Structuren opzetten en aan elkaar te relateren om informatie vast te leggen in een System Design Onderzoek naar optimale verhouding van Structuren en relaties om informatie in vast te leggen

TV-2 IF-1 IF-2

Theoretisch model adopteren en concretiseren Onderzoek doen naar de programmatuur voor een database

De belangrijkste bevinding is een combinatie van bevindingen in de tabel. De bevinding ligt in het onderkennen dat informatie cruciaal is voor de sturing van processen. Het verdient dan ook de aanbeveling om de informatie-uitwisseling centraal aan te sturen. Als advies wordt één centraal informatie management systeem voorgesteld dat aansluit op de SE processen (ON-1). Een tweede bevinding is de werkwijze van opdrachtnemers. SE wordt voor opdrachtnemers contractueel verplicht door een opdrachtgever en op die wijze als verplichting ervaren. Het gevolg hiervan is dat, generiek gesteld, SE niet gedragen en adequaat wordt toegepast door de aannemende partijen in de markt. Hierdoor vallen gaten in het structureren en borgen van informatie, wat vervolgens leidt tot hogere faalkosten doordat informatie niet tijdig en/of niet volledig ontsloten wordt voor relevante partijen. De auteur adviseert opdrachtnemers om SE meer te gaan beschouwen als een kans. SE kan gebruikt worden als hulpmiddel voor effectieve informatie-uitwisseling tussen teams. Dit is mogelijk door het inrichten en doorlopen van de processen (ON-2), afstemmen van de verschillende interpretaties van de ISO15288 (ON-3) en het vastleggen van gegenereerde informatie in Structuren (ON-4). Met effectievere informatie-uitwisseling kunnen opdrachtnemers beter invulling geven aan de vrijheid en verantwoordelijkheid, wat kan leiden tot een afname van de faalkosten.



10 Reflectie Elk onderzoek heeft zijn beperkingen. Zo ook dit onderzoek. De interviews voor effectieve informatieuitwisseling verdienen enige nuancering. De nuancering is noodzakelijk, omdat de interviewresultaten een andere verklaring kunnen hebben. Uit de resultaten van de interviews lijkt een groot verschil te bestaan tussen de ontwerpfase in de tender en de ontwerpfase na gunning. In de tender wordt veel meer op hoofdlijnen gewerkt volgens alle respondenten. Dit wordt bevestigd door een respondent die zegt: “In de tender zijn we met 30 man bezig geweest in een kort tijdsbestek. In de fase na gunning zijn we gegroeid tot 300 man. Natuurlijk komen we nu achter dingen tegen die voortschrijdend inzicht opleveren (OK2)”. Het V-model van figuur 12 in paragraaf 3.1 geeft aan dat het ontwerpproces in de ontwerpfase steeds verder gedetailleerd wordt. Daarmee groeit de omvang van informatie mee. In de praktijk blijkt echter sprake te zijn van groot informatie verlies tussen de tenderfase en de fase na gunning. Dit komt niet overeen met de theorie van SE, waarbij het ontwerp verder wordt gedetailleerd. In de leidraad SE (2009) staat dat informatie verlies tussen opdrachtgever en opdrachtnemer een aandachtspunt is. Hierbij wordt niet de extra knip tussen de fase voor gunning en de fase na gunning benoemd. De BIR (2012) geeft aan dat binnen de GWW sector sprake is van veel informatie verlies tussen verschillende levenscyclusfasen van een project. Dit geldt tevens voor de ontwerpfase van opdrachtnemers, die bestaat uit de tenderfase en fase na gunning (Fikkers, Nieuwenhuizen, Nijsen, & Schaap, 2012). In dit onderzoek is geen onderscheid in gemaakt, maar dit verlies kan de resultaten beïnvloed hebben, omdat uit beide fasen respondenten betrokken zijn geweest. SE wordt vanaf het begin van een project opgesteld worden en daarom blijft het gerechtvaardigd om effectieve informatieuitwisseling te toetsen in beide fasen. De resultaten van dit onderzoek geven een beeld van de mate van effectieve informatie-uitwisseling volgens de mening van respondenten. Hieruit blijkt dat informatie gebrekkig wordt uitgewisseld. De resultaten kunnen voor een deel een andere verklaring hebben, omdat enkele respondenten mogelijk antwoord hebben gegeven dat zij verkeerd geïnterpreteerd hebben. Enkele respondenten hadden behoefte hadden aan een toelichting tijdens het interview. Dit betekent dat zij niet elke vraag direct begrepen. Om misinterpretatie te voorkomen is de onderzoeker bij elk interview aanwezig geweest en zijn vragen verduidelijkt. Niet iedere respondent heeft echter om duidelijkheid gevraagd en mogelijk is hierdoor misinterpretatie ontstaan. Dit kan de resultaten hebben beïnvloed, omdat de resultaten voortkomen uit de meningen van de respondent. In dit onderzoek is gewerkt met de Likertschaal voor het meten van effectieve informatie-uitwisseling. Dit resulteert in resultaten op ordinaal niveau. Dit zijn metingen van ordinaal niveau, waarbij men het eens is of niet met de vraag over een stelling. In enkele gevallen gaven respondenten aan dat zij zich verplicht voelden om eens of niet mee eens aan te geven, terwijl zij graag een nuancering wilden geven bij een antwoord. Dit kan de resultaten hebben beïnvloed, omdat in dit onderzoek gewerkt is met de meetschaal. In dit onderzoek zijn de respondenten gevraagd of de werkwijze in de stelling een gewenst is. Elke stelling komt uit de theorie. De theorie geeft aan dat de stelling klopt als op die manier op procesmatige wijze gewerkt wordt. Kortom, de stellingen zijn positief gesteld. Door de respondenten te vragen of de


werkwijze volgens de theorie gewenst is, kunnen de resultaten beïnvloed zijn doordat men een wenselijk antwoord gaat geven. Dit kan invloed hebben gehad op de relevantie van informatie. De resultaten binnen dit onderzoek kunnen een andere verklaring hebben, omdat de vraag over explicietheid meerdere interpretaties kan hebben. Eerder in de verklaring is de abstractheid van de stellingen genoemd. Dit geldt specifiek voor het woord expliciet. Dit woord kan voor de respondenten verschillende interpretaties hebben gehad, ondanks dat het woord gedefinieerd is in de introductie van de vragenlijst. Aangezien respondenten van verschillende bedrijven die verschillende rollen hebben gehad kan dit de resultaten beïnvloed hebben. Een andere verklaring voor de resultaten over effectieve informatie-uitwisseling kan zijn dat respondenten niet bekend zijn met de achtergrond van SE, maar enkel SE binnen Nederlandse kaders kent. Hierdoor wordt de methodiek wellicht niet omarmd door opdrachtnemers en zien zij deze methodiek nog steeds als een verplichting in plaats van een kans. Zij proberen dan op een andere wijze effectief informatie uit te wisselen, maar niet op de voorgeschreven werkwijze van RWS. Dit kan de resultaten beïnvloeden, omdat in dit onderzoek vanuit wordt uitgegaan van een werkwijze conform SE. Een andere verklaring voor de resultaten is dat de respondenten niet zicht hebben op alle verschillende processen en informatie die gegenereerd tijdens het ontwerpproces. Daardoor kan informatie wel ergens binnen het project aanwezig en beschikbaar zijn, maar is het voor de respondenten niet bekend dat de informatie aanwezig is. Dit kan invloed hebben gehad op de resultaten van vraag twee bij elke stelling. In dit onderzoek wordt geredeneerd dat als men bij één van de criteria oneens heeft aangevinkt de volgende criteria komen te vervallen. Dit kan de resultaten hebben beïnvloed, omdat de traceerbaarheid getest wordt als laatste voorwaarde. Indien respondenten bijvoorbeeld eerder hebben aangegeven niet mee eens te zijn met één van de voorwaarden, dan geeft dit een vertekend beeld voor de traceerbaarheid van de informatie binnen Nederlandse DBFM weginfrastructuurprojecten. De respondenten zijn geselecteerd door een doelgerichte steekproef en de sneeuwbaleffectsteekproef te doen. Het nadeel van deze werkwijzen is dat de groep respondenten bij de sneeuwbaleffectsteekproef direct betrokkenen voordragen die wellicht hetzelfde soort antwoorden gaat geven. Binnen de groep respondenten zijn van project A en B meer respondenten gevonden die betrokken waren bij de ontwerpkeuze van voegovergangen. Zeker als zij in hetzelfde project werkzaam zijn of werkzaam zijn geweest. Dit zorgt ervoor dat project specifieke factoren een rol kunnen spelen bij beantwoording. Dit kan de antwoorden beïnvloeden, omdat dit een vertroebeld beeld kan geven in vergelijking met andere Nederlandse DBFM weginfrastructuurprojecten. Het doel van dit onderzoek was om te bepalen of effectieve informatie-uitwisseling plaats vindt en aanbevelingen te geven hoe dit beter kan. Dit doel is bereikt, omdat vast staat dat geen effectieve informatie-uitwisseling plaats vindt in de praktijk. Dit maakt geeft ontwikkelpotentieel om advies te geven om tot effectievere informatie-uitwisseling te komen.


11 Bronnenlijst 11.1 Boeken CROW. (2011). Handboek specificeren. Ede: CROW. Department of Defense. (2001). Systems Engineering Fundamentals. Virginia. Hull. (2005). Requirements Engineering. Kent: Gray Publishing. In 't Veld, J. (2002). Analyse van organisatieproblemen, een toepassing van denken in systemen en processen. Leiden: Stenford Croes. Martin, J. (1997). Systems Engineering Guidebook. Nederlands Normalisatie Instituut. (2008). NEN-ISO/IEC 15288. nen. Norris, G. (2001). Life Cycle Cost analysis and LCA. Landsberg: Ecomed publishers. Oostinga, D. (2011). SE 3.0: System Engineering models. Hoofddorp: Semmtech. Turner, J. R. (1999). The Handbook of Project-Based Management. Hill: McGraw. Verschuren, & Doorewaard. (2007). Het ontwerpen van een onderzoek. Den Haag: Lemma. Veeke, H., Ottjes, J., & Lodewijks, G. (2008). The Delft Systems Approach: Analysis and Design of Industrial Systems. Londen, Verenigd Koninkrijk: Springer-Verlag London Limited. Verbraeck, A. (2012). Project Management . Delft .

11.2 Tijdschriftartikelen Bosch-Rekveldt, M., Jongkind, Y., Mooi, H., Bakker, H., & Verbraeck, A. (2009, 07 27). Grasping project complexity in large engineering projects: The TOE. International Journal of Project Management, pp. 728-739. Clift, M. (2003). Life-cycle costing in the construction sector. UNEP Industry and Environment, 37-41. Ellram, L. (1994). A Taxonomy of total cost of ownership models. Journal of Business Logistics, 15, no. 1, 171-173. Markeset, & Kumar. (2003). Integration of RAMS and risk analysis in product design and development work processes. Journal of Quality and Maintenance Engineering, 393-410. NIST. (2002). Cost Analysis of Inadequate Interoperability in the U.S. Capital Facilities Industrie.


Ruijven, L. (2013). Ontology for Systems Engineering. Procedia Computer Science (pp. 383-392). Rotterdam: Elsevier. Taylor, W. (1981). The use of life cycle costing in acquiring physical assets. Journal of Long range Planning 14, no. 6, 32- 42. Woodward, D. (1997). Life cycle costing - Theory, information, acquisition and application. International Journal of Projectmanagement, 335-344. Wübbenhorst, K. (1986). Life Cycle Costing for Construction Projects. Long Range Planning, 19, no. 4 , 87-97.

11.3 Internet bronnen A-Lanes A15. (2012). Presentatie ontwerp in DBFM omgeving A15 . BAM. (2008). Handleiding Systems Engineering voor BAM Infra. Bunnik: BAM. BIR. (2012). Op weg naar werken met BIM. Gouda: Cur Bouw en Infra. Bouwend Nederland. (2012, november 14). Bouwend Nederland. Retrieved from Bouwend Nederland: http://www.bouwendnederland.nl/SiteCollectionDocuments/Podium%209%20tot%202012.pdf Coins. (2013, 05 10). SE proces. Opgehaald van Coins: http://www.coinsweb.nl/wiki/index.php/Systems_Engineering_-_proces_overzicht Dale, V. (2013, 8 30). Retrieved from Dikke van Dale. Fikkers, H., Nieuwenhuizen, L., Nijsen, J., & Schaap, H. (2012). Op weg naar werken met BIM. Gouda: Bouw Informatie Raad. Incose. (2013). system of interest. Retrieved from incose. INCOSE. (2013, junuari 6). What is Systems Engineering? Opgeroepen op october 5, 2012, van International Council On Systems Engineering: http://www.incose.org/practice/whatissystemseng.aspx Koster, J., Hoge, W., Geerling, A., Perie, P., van Baasbank, V., & Prinsen, D. (2008). DBFM-Handboek 'een verkenning van de contractonderdelen'. Den Haag : Defensie; Ministerie van Financien; Rijkswaterstaat; VROM; Rijksgebouwendienst. Ministerie van Financiën. (2012). Voortgangsrapportage DBFM(O). Den Haag: Ministerie van Financiën. PPS netwerk. (2013, mei 15). Retrieved from PPS netwerk. Sebok. (2011). The guide to the Systems Engineering Body of Knowledge. Stevens Institute of Technology.


Rijksoverheid. (2008, 08 2013). Rijksoverheid problemen tunnels. Retrieved from Rijksoverheid . Rijksoverheid. (2012, november 12). Rijksoverheid. Retrieved from Rijksoverheid: http://www.rijksoverheid.nl/documenten-enpublicaties/kamerstukken/2011/03/08/kabinetsvisie-op-dbfmo.html USP Marketing consultancy. (2011, 03 15). faalkosten-door-de-jaren-heen/. Retrieved from usp-mc: http://www.usp-mc.nl/nieuws/bouw-infra/faalkosten-door-de-jaren-heen/ How2SE. (2012). Validation & Verification: an inconvenient truth. INCOSE. Jacobs, D. (2013, 10 01). Mintzberg-safari. Retrieved from arcci: http://www.arcci.nl/attachments/172_Mintzberg-safari.pdf RWS, D. i. (2010). Meerkeuzematrix voegovergangen. RWS. Rijkswaterstaat. (2011). Leidraad RAMS - sturen op prestaties van systemen. Utrecht: rws. Rijkswaterstaat. (2012). Rijksbrede Modelovereenkomst DBFM Infrastructuur- standaard 3.0. Utrecht: RWS. SBR. (2013, 05 05). faalkosten. Opgehaald van SBR: http://www.sbrcurnet.nl/producten/publicaties/faalkosten-de-bouw-wereld-uit Werkgroep leidraad SE. (2009, November 27). Leidraad SE voor de GWW- sector. Retrieved September 24-27, 2011, from Leidraad SE voor de GWW- sector: http://www.leidraadse.nl/leidraadse_def_lowres%20%282%29.pdf wikixl. (2013, 01 10). semantisch model. Retrieved from semantisme: http://www.wikixl.nl/wiki/ictu/index.php/Component_semantisch_model Niet-gepubliceerde bron Breemer, J. v., Al-Jibouri, S., Veenvliet, K., & Heijmans, H. (2009). RAMS en LCC in the design process of infrastructural construction projects: an implementation case. Berg, V. d. (2010). Systems Engineering in de realisatiefase. De Wit, E. (2013). Establishing Preconditions for Life Cycle Costing in Dutch DBFM road projects. Delft: Technische Universiteit Delft. Ende, D. v. (2009). PMS: een voorspelbaar redement op DBFM-weginfrastructuurconcessies. Enschede: Universiteit Twente. Iter Fidelis. (2013). Business plan 2013-2015. Utrecht. Jonge, L. d. (2010). Ontwerpkeuzes op basis van een dynamische levenscyclus. Enschede: Universiteit Twente.


Hoeber. (2012). De meerwaarde van BIM in het specificatie- en ontwerpproces volgens SE. Twente: Universiteit Twente. Kluis. (2012). Systems Engineering and functional specification assessed. Amersfoort: Arcadis. Lenferink, S. a. (2012). Towards sustainable infrastructure development through integrated contracts: Experiences with inclusiveness in Dutch infrastructure projects. Ozbay, K., Jawad, D., Parker, N., & Hussain, S. (2004). Life Cycle Cost Analysis: State of the Practise vs. State of the Art. Van Esch, J. (2007). Ontwerpproces InfrastructuurSuperbus. Delft: Technische Universiteit Delft.

11.4 Interviews Visser, A. (2013, 08 12). Afstudeeronderzoek - ontwikkelingen sector SE en informatie management. (J. d. Bruijn, Interviewer)


Bijlagen van het rapport “Effectieve informatieuitwisseling binnen Nederlandse DBFM weginfrastructuurprojecten”

Jeremy de Bruijn

Bijlagen Thesis Jeremy de Bruijn_5-12-2013 2

Toelichting op de bijlagen De bijlagen in dit document vormen de achtergrondinformatie bij het hoofdrapport “Effectieve informatie-uitwisseling binnen Nederlandse DBFM weginfrastructuurprojecten. Het document bestaat uit acht bijlagen. De bijlagen zijn achtergrondinformatie bij verschillende hoofdstukken in het hoofdrapport. De definities in het hoofdrapport onderzoek staan beschreven in bijlage 1. Bijlagen 2 tot en met 5 zijn achtergrondinformatie voor Systems Engineering (SE) en voor levenscycluskosten (LCC) analyses. In bijlage 6 is de totstandkoming van de vragenlijst te vinden. De opbouw van de interviews en resultaten van de interviews zijn opgenomen in bijlage 7. Tot slot is een één op één interview opgenomen in bijlage 8. In het hoofdrapport begint ieder onderzoekdeel met een structuurbeschrijving. Deze structuurbeschrijving is hieronder te vinden. Deel A Opzet

Deel C Resultaten

Deel B Theorie





(4)


Deel Evaluatie

Deel D Discussie


Veldonderzoek




LEGENDA Theorie

Empirie

Producten

(1)


Op basis van de structuurbeschrijving zijn de verschillende bijlagen ingedeeld in de onderzoekdelen uit de structuurbeschrijving. Dit geldt niet voor bijlage 1, omdat definities door het onderzoek heen gebruikt worden. Deel B  Bijlage 2 heeft betrekking op de achtergrond van Systems Engineering (SE);  Bijlage 3 betreft Structuren die in het kader van SE in de literatuur voorkomen;  Bijlage 4 is de verantwoording voor Life Cycle Costing (LCC) methodiek; Deel C en D  Bijlage 5 betreft een uiteenzetting van de verschillende contractvormen;  Bijlage 6 heeft betrekking op de rollen die medewerkers in DBFM projecten vervullen;  Bijlage 7 gaat over de vragenlijst met de dataverzameling;  Bijlage 8 betreft een interview met een expert op het gebied van SE. Hierna volgt een overzicht per bijlage in de vorm van een inhoudsopgave.



Inhoudsopgave BIJLAGE 1 DEFINITIELIJST 7 BIJLAGE 2 SYSTEMS ENGINEERING ACHTERGROND 11 SYSTEMS ENGINEERING IN DE THEORIE ........................................................................................................................11 SYSTEMS ENGINEERING IN DE PRAKTIJK .......................................................................................................................13 SE bij ingenieursbureau: van probleem tot vraagspecificatie .........................................................................13 SE bij opdrachtnemers: van vraagspecificatie tot oplevering project ..............................................................13 SE bij Iter Fidelis............................................................................................................................................13 BIJLAGE 3 SYSTEMS ENGINEERING (BOOM) STRUCTUREN IN DE LITERATUUR 15 BIJLAGE 4 LIFE CYCLE COSTING (LLC) METHODIEKEN BIJLAGE 5 CONTRACTVORMEN

17

19

BIJLAGE 6 ROLLEN VAN ACTOREN VOOR INTERVIEWS BIJLAGE 7 VRAGENLIJST EN DATAVERZAMELING

21

23

TOTSTANDKOMING VRAGENLIJST ...............................................................................................................................23 ALGEMEEN ..........................................................................................................................................................23 PROJECT SPECIFIEK .................................................................................................................................................25 Deel 1: Ontwerpkeuzes binnen project ..........................................................................................................25 Deel 2: casus voegovergang ..........................................................................................................................27 BIJLAGE 7 RESULTATEN EN DATA ANALYSE ...................................................................................................................29 BIJLAGE 8 OVERIGE INTERVIEWS 53 GESPREKSVERSLAG A. VISSER EN J. DE BRUIJN_13-08-2013_14:00-17:15 ......................................................................53


Lijst met figuren - bijlagen Figuur A De SE Life Cycle processen .......................................................................................................12 Figuur B ontwerpproces met SE methodiek op basis van (Iter Fidelis BV, 2009) ......................................14 Figuur C generiek stappen LCCA .............................................................................................................17 Figuur D Ontwikkeling van contractvormen binnen Nederlandse weginfrastructuur (Lenferink, 2012) ...19 Figuur E Dimensies voor informatie-uitwisseling in dit onderzoek ..........................................................22 Figuur F Onderdelen in vragenlijst..........................................................................................................23 Figuur G resultaten aantal jaren werkzaam. ...........................................................................................29 Figuur H Resultaten betrokkenheid respondenten bij aantal DBFM projecten. .......................................30 Figuur I Contextdiagram ontwerpkeuze voegovergangen met focus op de eisen uit DBFM contracten. ...38 Lijst met tabellen - bijlagen Tabel A Overzicht verschillende processtappen bij LCC op basis van (Jonge, 2010) .................................17 Tabel B Generiek overzicht tien structuren in de vragen 8 tot en met 11 ................................................26 Tabel C Kruistabel met relaties tussen structuren...................................................................................26 Tabel D vragen in de interviews per stelling. ..........................................................................................27 Tabel E lijst met objecten. ......................................................................................................................28 Tabel F Functie, naam project, rol en fase in project per respondent......................................................29 Tabel G Codering ...................................................................................................................................30 Tabel H Betrokken in fase van het project. .............................................................................................30 Tabel I Lijst met geanonimiseerde respondenten en projecten...............................................................31 Tabel J Overzicht problemen bij Life Cycle based afwegingen. ................................................................32 Tabel K Geïdentificeerde succesfactoren van respondenten...................................................................33 Tabel L Grootste opdrachtgevers binnen Nederland ..............................................................................54


Bijlage 1 Definitielijst Definities

Beschrijving

Activiteit Allocatie

Alles dat door een opdrachtnemer wordt uitgevoerd Toewijzen van de gewenste functie aan een of meerder objecten die deze functie vervullen (Werkgroep Leidraad Systems Engineering, 2009) Een bijkomende functie of eigenschap van een product waar aan eisen kunnen worden gesteld (Leidraad voor Systems Engineering voor de GWW- sector, 2009) De beschrijving van de functie of eigenschap van een product (Werkgroep Leidraad Systems Engineering, 2009) Een gestructureerde verzameling gelijksoortige grootheden volgens de zuivere regels, bijvoorbeeld "is onderdeel van" of "is afgeleid van", met een enkelvoudige top (Werkgroep Leidraad Systems Engineering, 2009) Een digitale presentatie van functionele en fysieke karakteristieken van een bouwwerk, dat een uitgangspunt is voor en ondersteunend is aan activiteiten en besluitvorming in de levenscyclus van een bouwwerk en dat wordt gedeeld door de verschillende belanghebbenden in het bouwproces (BIR, 2012). Met complexiteit wordt binnen de systeemtheorie een eigenschap van een complex systeem of model bedoeld die niet is af te leiden uit elk van de afzonderlijke componenten maar alleen uit het systeem of model als geheel. (Werkgroep Leidraad Systems Engineering, 2009). Een element opdelen in zijn samenstellende elementen, bijvoorbeeld een object opdelen in zijn samenstellende objecten (Werkgroep Leidraad Systems Engineering, 2009) Contract type waarbij de aannemer verantwoordelijk is voor het ontwerpen en bouwen Contract type waarbij de aannemer verantwoordelijk is voor ontwerp, bouw en onderhouden

Aspect

Aspecteis (Boom) Structuur

Bouwwerk Informatie Model (BIM)

Complexiteit

Decomponeren

Design and Construct (D& C) Design, Built en Maintenance (DBFM) Design, Built, Finance en Maintenance (DBFM) Dienstverlening (Service) Discipline

Expliciet werken

Contract type waarbij de aannemer verantwoordelijk is voor ontwerp, bouw, financiering en onderhouden

Levering van een dienst of pakket van diensten door een persoon, instantie of onderneming aan een andere partij (Assetmanagement binnen Rijkswaterstaat, 2011 a) De specialisatie van een organisatie. Disciplines zijn van oudsher opgedeeld naar asfalt, beton en installaties, maar met de opkomst van geïntegreerde contractvormen is een integrale benadering noodzakelijk (Werkgroep Leidraad Systems Engineering, 2009). Communiceren op zo een manier dat bij de interpretatie van de informatie geen onzekerheden en onduidelijkheden optreden. Een werkwijze waarbij afwegingen, keuzes, definities, wijzigingen en afspraken worden vastgelegd, zodat zo min mogelijk onzekerheden en


Fase Informatie Informatieuitwisseling Levenscycluskost en (LCC)

Levenscycluskost en (LCC) Analyse

Ministerie van Infrastructuur & Milieu (I&M) Ontwerpproces

Optimalisatie

Proces

Procesmodel Randvoorwaarde

Rendement

Relevante informatie Rijkswaterstaat (RWS) Service Provider

onduidelijkheden optreden. (Leidraad voor Systems Engineering voor de GWW- sector, 2009) Periode als onderdeel van een langere ontwikkeling. (Leidraad voor Systems Engineering voor de GWW- sector, 2009) Gegevens, elk gegeven dat door een computer kan worden gelezen (Dikke van Dale, 2013). Verstrekking van gegevens van een instantie aan een andere instantie. (synoniem: informatieoverdracht) Alle levenscycluskosten voor realisatie als de toekomstige kosten voor onderhoud moeten worden gekeken. Een berekeningsmethodiek waarin op basis van de kosten in de tijd ontwerpalternatieven worden vergeleken om tot een ontwerpkeuze te komen over de levenscyclus. Life Cycle Costing Analyse is een economische analyse methode die de mogelijkheid geeft om een vergelijking te maken van verschillende systeem alternatieven door het beoordelen van de totale kosten in een netto contante waarde (NPV) begrip. Hierbij worden alle levenscycluskosten meegenomen(Jonge, 2010). Ministerie verantwoordelijk voor het maken van beleid. Zij hebben de rol van asset eigenaar. De zich herhalend voortschrijdende activiteiten om te komen van een functievervuller tot een concreet object. (Werkgroep Leidraad Systems Engineering, 2009) optimalisatie is het proces om de beste oplossing voor een probleem te vinden. Voor sommige optimalisatieproblemen bestaan algoritmen. Deze leiden niet altijd tot een optimale oplossing, maar worden tevens wel eens toegepast om de optimale oplossing te benaderen. (Leidraad voor Systems Engineering voor de GWW- sector, 2009) Verzameling van onderling gerelateerde of op elkaar inwerkende activiteiten die input vertalen naar output gebaseerd op NEN-ISO 9000:2005. De stroom van gelijksoortige gebeurtenissen of handelingen. (Werkgroep Leidraad Systems Engineering, 2009) Stappenplan, waarbij duidelijk is welke stappen ondernomen worden en acties ondernomen moeten worden. Buiten het project bestaande condities. Binnen deze condities moet het project zich moet afspelen. (Leidraad voor Systems Engineering voor de GWW- sector, 2009) Opbrengst of winst van een investering. Rendement zijn de opbrengsten in de tijd minus de kosten in de tijd minus de gemiste opbrengsten in de tijd. informatie die een rol speelt als input voor LCC analyse. De kosten manifesteren zich op verschillende niveaus en daardoor is inzicht welke informatie een rol speelt op verschillende niveaus relevant. Uitvoeringsorganisatie van de overheid, die verantwoordelijk is voor de uitvoering van het beleid van I&M. Zij hebben de rol van asset manager. De nieuwe rol van de aannemende partij: dienstverlener (Rijkswaterstaat, 2011 a).


Systeem

Een systeem is - afhankelijk van het doel van de onderzoeker - een verzameling van elementen die worden onderscheiden binnen de totale werkelijkheid. Deze onderscheiden elementen hebben wederzijdse relaties en (eventueel) relaties met andere elementen van de totale werkelijkheid (Veeke, Ottjes, & Lodewijks, 2008).

Structuur

Structuur is de manier waarop iets in elkaar zit, waarop elementen van een verzameling samenhangen. Niet alle verzamelingen hoeven geheel of gedeeltelijk samenhangend te zijn, maar in een structuur is een verband tussen alle elementen. Dat verband wordt bepaald door relaties tussen elementen onderling. Systems Engineering is een interdisciplinaire benadering, die bijdraagt aan het ontwikkelen en realiseren van succesvolle systemen. Niet alleen de technische, maar ook de bedrijfsdoelen van de stakeholders hebben een grote rol. Het einddoel is het bieden van een kwaliteitsproduct dat in de gebruikersbehoefte voorziet (Leidraad voor Systems Engineering voor de GWW- sector, 2009)


Systems Engineering proces

Het SE Proces (SEP) wordt een iteratief en recursief oplossingsproces genoemd. Recursief omdat bij iedere iteratieslag in het ontwerpproces eenzelfde proces wordt doorlopen. Iteratief omdat elke iteratieslag een verdiepingsslag in detailniveau is, waardoor het ontwerp van grof naar fijn verloopt. Een oplossingsproces, omdat bij iedere stap keuzes worden gemaakt.

Theoretisch model

Een model, waarbij Structuren en relaties tussen Structuren inzichtelijk worden gemaakt.



Bijlage 2 Systems Engineering achtergrond Systems Engineering in de theorie Onderzoek in andere sectoren naar SE heeft aangetoond dat toepassing van SE kan leiden tot een verbeterde kwaliteit van het ontwikkelproces ten opzichte van processen waarbij geen gebruik wordt gemaakt van Systems Engineering (Martin, 1997). Dit wordt bevestigd door Honour (2004) waarbij hij de relatie aangeeft tussen SE inspanning en de kostenreductie van toepassing van SE. Binnen de Nederlandse GWW sector zijn verschillende onderzoeken uitgevoerd naar de toegevoegde waarde van SE. Binnen deze onderzoeken is gebleken dat binnen Systems Engineering verschillende onderdelen van de systeem analyse verbetering behoeft en de samenhang van informatie niet geborgd is (Hoeber, 2012). Dit betreft het configuratie management dat niet goed wordt uitgevoerd, raakvlakken die niet goed worden beheerd, waardoor ontwerpwijzigingen lang duren en de vertaling van de wens van opdrachtgever in de vraagspecificatie niet traceerbaar is. Daarbij hebben eisen, functies, objecten en ontwerp geen duidelijke relatie en het is niet duidelijk en navolgbaar hoe de projectdoelen bereikt worden (Ozkay & Akin, 2006). Dit onderzoek is echter uitgevoerd in de fase van initiatie tot vraagspecificatie. Recentelijk onderzoek (How2SE, 2012) heeft aangetoond dat opdrachtgevers problemen hebben met het specificatie proces in het proces tot vraagspecificatie en onderzoek Kluis (2012) heeft aangetoond dat niet volledig functioneel gespecificeerd wordt in de praktijk. Dit zijn echter voornamelijk voorbeelden van het specificatieproces tot vraagspecificatie waarbij het onderzoek heeft plaatsgevonden bij een ingenieursbureau aan de zijde van een opdrachtgever (Kluis, 2012). Aangezien opdrachtnemers in DBFM projecten een deel van het specificatie- en ontwerpproces moeten uitvoeren, in hoeverre komen deze problemen dan voor bij opdrachtnemers? Zij moeten binnen de kaders van een vraagspecificatie van probleem tot oplossing komen. Maar werken zij met traceerbare en herleidbare informatie, bijvoorbeeld bij het maken van ontwerpkeuzes? Van origine zijn opdrachtnemers in de bouwsector gefragmenteerd (Werkgroep Leidraad Systems Engineering, 2009; BIR, 2012) en zijn zij gewend keuzes impliciet te maken (Werkgroep Leidraad Systems Engineering, 2009). Optimalisaties in kosten en opbrengsten worden doorgaans in één fase van de levenscyclus gemaakt en niet over verschillende levenscyclusfasen (Werkgroep Leidraad Systems Engineering, 2009). Om financieel en prestatiegericht te kunnen sturen op functies en prestaties is informatie van het specificatie proces die invloed heeft op de levenscycluskosten nodig (Breemer, 2010; Jonge, 2010). Opdrachtnemers zijn echter niet gewend om de meest optimale balans tussen kosten en zekerheid van opbrengsten over de levenscyclus te zoeken tussen realisatie en onderhoud van weginfrastructuur (Werkgroep Leidraad Systems Engineering, 2009; Bosch, 2011). Uit eerder onderzoek is op basis van ervaringen criteria voor falen en successen opgesteld bij projecten (Hull, 2005; USG Marketing consultancy, 2007). Systems Engineering adresseert de verschillende problemen als gewerkt wordt volgens SE. Maar wat als men niet volgens de Systems Engineering principes werkt? Wat als men niet specificeert zoals men dient te specificeren? En wat als men niet expliciet en transparant werkt? Met de opkomst van Systems Engineering wordt in projecten de benodigde en beschikbare informatie meer gestructureerd (RWS, 2009). Project informatie bestaat daarbij onder andere uit de eisen, functies en gewenste prestaties over de doorlooptijd van een project en de verdere ontwikkeling/ uitwerking van deze informatie (RWS,2012; BAM, 2009). Bijlagen Thesis Jeremy de Bruijn_5-12-2013 11

Ontsluiten van informatie op basis van Systems Engineering (SE) betreft het leggen van relaties tussen informatie, tijdig beschikbaar stellen van informatie, expliciet werken met informatie en de traceerbaarheid van informatie die betrekking heeft op verschillende levenscyclusfasen (Incose, 2013). In Figuur A zijn de SE life cycle processen volgens de ISO15288 te zien.

Figuur A De SE Life Cycle processen

De ISO15288 schrijft verschillende processen voor. Een aantal van deze processen moeten door zowel opdrachtgevers als opdrachtgevers doorlopen worden. De verschillende processen genereren informatie, die gestructureerd moet worden.


Systems Engineering in de praktijk Diverse onderzoekers hebben onderzoek gedaan naar Systems Engineering in de praktijk binnen de GWW sector, waarbij de focus op verschillende onderdelen van deze methodiek lag. Deze onderzoeken kunnen onderverdeeld worden in twee groepen: onderzoeken bij ingenieursbureaus die van probleem tot vraagspecificatie betrokken zijn in het traject en onderzoeken bij opdrachtnemers die vanaf vraagspecificatie tot realisatie en/ of onderhoud betrokken zijn. SE bij ingenieursbureau: van probleem tot vraagspecificatie Bij ingenieursbureaus zijn diverse onderzoeken gedaan om het proces te analyseren van probleem tot vraagspecificatie (Vink, 2008; li, 2008). Zij kwamen daarbij tot de conclusie dat de werkwijze vraagt om een andere manier van het gebruik van informatie bij opdrachtgevers. Kluis (2012) geeft daarbij aan dat een verschil bestaat tussen de theorie van SE in andere branches en de theoretische interpretatie in de Nederlandse sector, waarbij de Nederlandse theorie veel minder nadruk legt op de functies en een integrale benadering waarbij alle processen van de ISO norm 15288 integraal zijn opgenomen. SE bij opdrachtnemers: van vraagspecificatie tot oplevering project Parallel aan deze onderzoeken hebben andere onderzoekers hebben zich gefocust op de werkwijze conform Systems Engineering met het oogpunt vanuit de opdrachtnemer (Leeuw, 2009; dimmendaal, 2007), waarbij tevens opdrachtnemers zelf leidraden hebben ontwikkeld voor SE (BAM, 2008)(Vakgroep Systems Engineering Volker Infra, 2009). Leeuw (2009) geeft daarbij aan dat alle processen centraal integraal moeten staan bij het gebruik van Systems Engineering. Maar hoe moet die informatie dan integraal ontsloten worden? SE bij Iter Fidelis Systems Engineering bij Iter Fidelis is opgebouwd op basis van ervaringen bij D&C en DBFM projecten (Iter Fidelis BV, 2009). Hieronder volgt een toelichting van de werkwijze volgens Iter Fidelis. Op deze wijze krijgt de opdrachtgever precies datgene dat gevraagd is. Iter Fidelis heeft enkele jaren geleden (Iter Fidelis BV, 2009) een visie ontwikkeld op het uitvoeren van SE op een project. Een samenvatting van deze visie is hieronder weergegeven. In het geval van nieuwbouw, de scope van dit onderzoek, dient Systems Engineering als ontwerpmethodiek. Hierin is ook de concurrentiegerichte dialoog verwerkt. De concurrentie gerichte dialoog valt buiten dit onderzoek.


X Eisen naar type en niveau Y

nc tie s(

in ge va l

Functional Breakdown Z Structure (FBS) (NL: Functieboom)

va n

op

los s

systeem

ing svr ijh eid )

Subsysteem

Trade-Off N1 Niveau 2 Niveau 3 Niveau 4

Requirements Breakdown Structure (RBS) Niveau 6 (NL: Eisenboom) Niveau 5

Keuze

Object

System Breakdown Structure (SBS) (NL: Objectenboom)

Component

Element

Ei se n

Soms gegeven, soms definiëren obv opbouw PvE

Functionele analyse (stap 1)

Eisen afstemming

…

Fu

Functionele analyse (stap 2)

Eisen

Eisenanalyse

Programma van eisen Concurrentiegerichte dialoog

topfunctie

Figuur B ontwerpproces met SE methodiek op basis van (Iter Fidelis BV, 2009)

Ontwerpproces volgens SE methodiek IF bij DBFM contracten Voor het ontwerpproces moet allereerst een eisenanalyse plaatsvinden. Input voor deze eisenanalyse is het programma van eisen en de concurrentiegerichte dialoog. In de volgende paragraaf wordt verder ingegaan op de eisenanalyse en op welke wijze deze twee factoren samenkomen in de eisenanalyse. Uit deze eisenanalyse moet een eisenboom (RBS) en een functieboom (FBS) gerealiseerd worden. Dit proces wordt op verschillende niveaus gerealiseerd, te beginnen op systeemniveau, daarna op subsysteemniveau en tot slot op objectniveau. Dit proces wordt decomponeren genoemd. Op basis van de functies die vervult moeten worden en de eisen die gesteld worden ontstaat een ontwerpruimte waarbinnen de oplossing gerealiseerd moet worden. Hieruit moeten ontwerpalternatieven gegenereerd worden. Om tot een keuze te komen moet een trade-off plaatsvinden tussen de ontwerpalternatieven. Dit definitieve ontwerp wordt opgenomen in de System Breakdown Structure (SBS). De Systems Engineering methodiek schrijft geen manier voor waarop deze alternatieven beoordeeld moeten worden of op basis waarvan de trade-off moet plaatsvinden. Hiervoor moet dus een andere methodiek gebruikt worden. Dit impliceert dat deze trade-off een snijvlak tussen twee methodieken is. De trade-off moet plaatsvinden tussen ontwerpalternatieven op basis van levenscycluskosten en de onzekerheid in de levenscycluskosten(LCCA) analyse. De Jonge (2010) ging daarbij vanuit dat Systems Engineering en de concurrentiegerichte dialoog de juiste input brengen om naar de stap van inventarisatie te gaan. Belangrijk daarbij was dat hij een aanvulling deed op het model van Spaargaren, door de stap “analyseren” in de werkwijze te verwerken. Zoals hierboven is aangegeven is de werkwijze afgeleid van de ontwerpafwegingen binnen het ontwerpproces bij een DBFM project. Dit DBFM project betreft het DBFM-weginfrastructuurproject Capaciteitsuitbreiding Coentunnel Tracé. Tijdens het ontwerpproces van dit project stond Systems Engineering in de kinderschoenen en is deze bij de start van het project niet meteen opgezet. Na enige tijd ontstond de noodzakelijk van een systeem ontwerp en in 2009 heeft Iter Fidelis een voorstel gedaan tot een systeem ontwerp op basis andere literatuur over Systems Engineering (CROW, 2007; BAM, 2008). De benoemde processen en structuren zijn input voor deel B (hoofdstuk 3) in het hoofdrapport.


Bijlage 3 Systems Engineering (boom) structuren in de literatuur Normen Document

Organisatie

TBS

FBS

RBS

SB S

PB S

WB S

(ISO/IEC 12207) Standard for Information Technology (1995), Software life cycle processes—Life cycle data (1998)

x

Systems and software engineering — Software life cycle processes (2008) NEN-ISO15504 (2008)

x

Nederlands Normen Instituut

OBS

LBS

PB S

PhB S

DB S

CB S

RIB S

COB S

PA M

BE S

RIB S

COB S

PA M

BE S

x

CEI/IEC 300-3-3 (1996) Dependability management section 3: life cycle costing

x

x

x

Handleiding/ toepassing Document Leidraad V1 (2007) Leidraad SE_V2 (2009) BAM SE wijzer (2008) Dura Vermeer SE wijzer (2011) Volker Infra SE wijzer (2009)

Organisati e

TBS

Prorail/ ONRI BAM Dura Vermeer Volker Infra

FBS

RBS

x x

x x

SB S x x

x

x

x

SE voor de betonbouw Systems Engineering 3.0 (2011)

Semmtech

Ballast Nedam projectstructuren (2008)

Ballast Nedam

Stappenplan SE (2011) bij RWS projectvoorbereidin g Handreiking oplossingsvrij specificeren (2005)

RWS

x

x

x

RWS

WB S x x

OBS

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

PB S

WB S x

OBS

LBS

x

x

x

x

x

x

COINS referentiekader (2010)

PB S

LBS

PB S

PhB S

DB S

CB S

x

x

x

x x

x

Werkwijze bedrijf Document Interne bedrijfsvoering SE (2009), masterclass

Organisati e Iter Fidelis

TBS

FBS

RBS

x

x

SB S x

PB S

PhB S

DB S

CB S

RIB S

COB S

PA M

BE S


Contract Document

TBS

FBS

RBS

SB S x

PB S

WB S

OBS

LBS

PB S

PhB S

DB S

CB S

RIB S

COB S

PA M

BE S

Organisati e Consortium 2e Coentunnel

TBS

FBS

RBS

PB S

LBS

PB S x

PhB S

DB S

CB S

RIB S

COB S

PA M

BE S

x

WB S x

OBS

x

SB S x

Document

Organisati e

TBS

FBS

RBS

SB S

PB S

WB S

OBS

LBS

PB S

PhB S

DB S

CB S

RIB S

COB S

PA M

BE S

Uijl (2006) Dimmendaal (2007)

Movares BAM/ koac/ universiteit Twente

Hartman (2007) Esch (2007) Vink (2008)

Siemens

Tan Li (2008) Van Leeuwen (2009) Hoop (2010)

DHV BAM BAM/ Waternet/ TUD

De Vree (2010) van 't Ende (2010) Smit (2010) Leicher (2010)

GMB Iter Fidelis Pioneering Universiteit Twente InfraNea/ Lessius (Belgie)

COB S x

PA M x

BE S

Rijksbrede DBFM overeenkomst (2012)

Organisati e RWS

Project specifiek Document 2e Coentunnel werkwijze consortium

Scripties

Lessius (2010)

x x

x

x

x

x x

x

x

Grontmij/ TU Delft

x

x

x

x x

x

x x

x

x

x

(x) x

x x

x

x

x

x

x

x

x

x

x

De Jonge (2010) Mohan (2011)

Iter Fidelis Gemeente Den Haag

x

Swaaij (2011)

Royal Haskoning

x

Donkers (2011)

Grontmij/ TU Delft

x

Kluis (2012)

Arcadis

x

x

x

FBS

RBS

SB S x

x

X x

x

x

x

x x

Overige bronnen Document Artikel "Validation & verification: an inconvenient truth" (2012)

Organisati e How2SE

TBS

PB S

WB S

OBS

LBS

PB S

PhB S

DB S

CB S

RIB S

De verschillende structuren zullen in deel B (hoofdstuk 3) van het hoofdrapport gebruikt worden voor de vorming van het theoretisch model.


Bijlage 4 Life Cycle Costing (LLC) methodieken Het doel van een LCCA is het helder krijgen wat de invloed van functionaliteiten en eisen is op de levenscycluskosten. Het optimaal beheren van assets of systemen is complex en vraagt een zorgvuldige afweging tussen prestaties, risico's en investeringen gedurende de levenscyclus van systemen. Om die reden is de keuze die je maakt in de ontwerpfase relevant voor het vervolg en daarom moet beheer en onderhoud in LCCA meegenomen worden. Tegenstrijdigheden in afwegingen zijn daarbij:  Korte termijn versus lange termijn;  Kosten versus zekerheid van prestaties;  preventief onderhoud versus correctief onderhoud (ongepland falen);  Bouwkosten versus onderhoudskosten. Proces stappen Life Cycle Costing Analyse In Tabel A is een overzicht van verschillende LCCA te zien. Hieruit blijkt dat partijen verschillende stappen aanhouden bij het maken van een LCCA (Federal Highway Administration, 2002), (Kaini & Zongzhi, 2007), (US Department of Transportation, 1998). Tabel A Overzicht verschillende processtappen bij LCC op basis van (Jonge, 2010)

Stappenplan 1

Stappenplan 2

1. Inventariseer ontwerp alternatieven;

1. Definieer de basis optie en de mogelijke alternatieven;

2. Bepaal het tijdstip van activiteiten;

2. Bepaal het benodigde detail niveau van de benodigde informatie;

3. Bepaalde kosten van de activiteiten;

3. Bepaal de factoren die resulteren in kosten voor de asset eigenaar;

4. Bereken de levenscycluskosten;

4. Bepaal de factoren die resulteren in kosten voor de asset gebruiker;

5. Analyseer de berekeningsresultaten.

5. Bepaal de economische factoren;

Stappenplan 3 1. Stel de alternatieven vast voor de analyse periode; 2. Bepaal de prestaties van de alternatieven en bepaal de activiteiten planning; 3. Bereken de kosten voor de asset eigenaar; 4. Bereken de kosten voor de asset gebruiker; 5. Maak uitgave stroom diagrammen; 6. Bepaal de Netto Present Value; 7. Analyseer de resultaten;

6. Verkrijg de benodigde data; (Federal Highway Administration, 2002)

7. Bereken de kosten voor asset gebruiker en asset eigenaar voor de basis optie en de alternatieven.

8. Evalueer de verschillende alternatieven op basis van de resultaten. (US Department of Transportation, 1998)

(Kaini & Zongzhi, 2007)

De Jonge (2010) heeft in zijn onderzoek naar Life Cycle Costing Analyse (LCCA) generieke processtappen geïdentificeerd die bij verschillende LCCA gebruikt worden. Dit bestaat uit drie generieke stappen die hieronder te vinden is. LCCA proces Inventariseren alternatieven

LCC berekeningen maken

Analyseren resultaten

Figuur C generiek stappen LCCA

De LCC benadering van De Jonge (2010) zal aangehouden worden als uitgangspunt voor LCC analyses in deel B (hoofdstuk 4) in het hoofdrapport.



Bijlage 5 Contractvormen Het middel dat wordt gebruikt door opdrachtgevers om de activiteiten in verschillende fasen van het bouwproces te bundelen zijn geïntegreerde contractvormen (Lenferink, 2012). Er zijn verschillende contractvormen van traditionele contracten tot uitgebreide geïntegreerde contracten. In

Figuur D Ontwikkeling van contractvormen binnen Nederlandse weginfrastructuur (Lenferink, 2012)

Hieronder een overzicht van de hoofdvormen van contracten (PPS Netwerk, 2013). De volgende contractvormen kunnen onderscheiden worden: Traditioneel     

De fasen van het bouwproces worden afzonderlijk aangepakt Voor elke fase opnieuw een opdracht Gedetailleerd programma van eisen Harde scheiding tussen ontwerp en uitvoering Gunning naar laagste prijs

Geïntegreerd      

Design & Build (DB) en Design & Construct (DC) Opdrachtgever – opdrachtnemer relatie Opdrachtgever stelt functionele eisen voor ontwerp en bouw op Opdrachtnemer verzorgt ontwerp en bouw Ontwerp en bouw in één integraal contract Gunning naar laagste prijs of EMVI (economisch meest voordelige inschrijving)


Engineering & Construct (EC) 

Een variant op Design & Construct waarbij het ontwerp al is vastgesteld door de opdrachtgever. De engineering is verantwoordelijkheid van de opdrachtnemer

Design, Build en Maintain (DBM)    

Opdrachtgever – opdrachtnemer relatie Opdrachtgever stelt functionele eisen op voor ontwerp, bouw en onderhoud Eén opdrachtnemer verzorgt ontwerp, bouw en onderhoud Gunning naar laagste prijs of EMVI

Design, Build, Finance en Maintain (DBFM)      

Opdrachtgever – opdrachtnemer relatie Opdrachtgever stelt de functionele eisen op in een outputspecificatie Eén opdrachtnemer is verantwoordelijk voor het ontwerp, bouw, financiering en onderhoud Prestatie van de dienstverlening gemeten naar beschikbaarheid Verdeling van projectrisico’s naar levensduur Veelal gunning naar EMVI

Design, Build, Maintain, Finance en Operate (DBFMO) 

Een uitbreiding van DBFM met exploitatie/beheer waar de opdrachtnemer eveneens verantwoordelijk voor is

Alliantie   

I.

Een samenwerkingsverband tussen opdrachtgever en opdrachtnemer bij een project of onderdelen daarvan waarbij risico’s en kosten worden verdeeld Veelal een samenwerkingsrelatie op basis van ingenomen posities binnen de scope van het project Een alliantie in het project kan ook betrekking hebben op een specifiek moeilijk te beheersen onderdeel waarvan de kosten en opbrengsten worden gedeeld Afbakening

In dit onderzoek wordt beperkt tot DBFM projecten. Deze afbakening wordt in deel A van het onderzoek al gemaakt. Deze afbakening is van belang, omdat in deel C van het onderzoek de geldende eisen bij DBFM weginfrastructuurprojecten worden onderzocht.


Bijlage 6 Rollen van actoren voor interviews In het kader van mijn onderzoek heb ik bepaald welke rollen binnen het consortium van de opdrachtnemer verantwoordelijk zijn of invloed hebben op de ontwerpkeuzes van voegovergangen. Hieronder volgt een opsomming van de verschillende rollen. II.

Rollen

De Projectmanager stuurt het volledige projectteam aan. Hij is verantwoordelijk voor ontwerp, realisatie en onderhoud van systeem. Relevantie: teveel detailniveau om deze rol vragen te stellen welke soort informatie nodig is bij het maken van ontwerpkeuze voor voegovergangen. De ontwerpleider kunstwerken stuurt het ontwerpteam die kunstwerken ontwerpen. Hij is verantwoordelijk voor het ontwerp van de kunstwerken. Relevantie: maakt ontwerpkeuze voor voegovergangen of heeft raakvlak met de voegovergang in de weg. De ontwerpleider wegen stuurt het ontwerpteam aan die het wegontwerp doen. Hij is verantwoordelijk voor het wegontwerp binnen het systeem. Relevantie: maakt ontwerpkeuze voor voegovergangen of heeft raakvlak met de voegovergang. De projectleider realisatie – kunstwerken stuurt het projectteam realisatie aan. Binnen het projectteam wordt hij inhoudelijk ondersteund door werkvoorbereiders realisatie – kunstwerken. Gezamenlijk hebben zij contacten met andere actoren voor de kunstwerken, zoals planning kunstwerken en leveranciers/ onderaannemers. Zij zijn verantwoordelijk voor het realiseren van de kunstwerken. Relevantie: maakt/ heeft invloed op de ontwerpkeuze voor voegovergangen of heeft raakvlak met de kunstwerk voegovergang in de uitvoeringsfase. Zij adviseren over de uitvoeringswijze van kunstwerken bij het maken van ontwerpkeuzes. De projectleider realisatie – wegen stuurt projectteam realisatie aan. Binnen het projectteam wordt hij inhoudelijk ondersteund door werkvoorbereiders realisatie – wegen. Gezamenlijk hebben zij contacten met andere actoren voor de wegen, zoals fasering en leveranciers/ onderaannemers. Zij zijn verantwoordelijk voor het realiseren van de weg. Relevantie: maakt/ heeft invloed op ontwerpkeuze voor voegovergangen of heeft raakvlak met de kunstwerk voegovergang in de uitvoeringsfase. Zij adviseren over de uitvoeringswijze van wegen bij het maken van ontwerpkeuzes. De projectleider onderhoud stuurt projectteam onderhoud aan. Binnen het projectteam wordt hij inhoudelijk ondersteund door werkvoorbereiders onderhoud. Zij zijn verantwoordelijk voor het onderhouden van de weg en de kunstwerken (totale systeem). Relevantie: zij zijn verantwoordelijk voor de onderhoudsfase en adviseren bij het maken van een ontwerpkeuze. De technische manager draagt zorg voor integraal ontwerp tussen kunstwerken en wegen. Hij stemt af tussen ontwerpteam, realisatieteam en onderhoudsteam. Relevantie: hij is verantwoordelijk voor de integraliteit binnen het totale systeem. Dit betekent voor een voegovergang de afstemming tussen kunstwerken en asfalt. De informatie manager draagt zorg voor informatie-uitwisseling binnen het projectteam. Zodoende is één centraal informatiesysteem waar verschillende informatie toegankelijk is voor de verschillende


projectteams. Relevantie: hij weet welke relaties tussen soorten informatie liggen (generiek, maar naar verwachting niet specifiek voor een voegovergang). III.

Afbakening van rollen van actoren voor de interviews

In dit onderzoek kijk ik alleen naar de ontwerpleiders en projectleiders realisatie en onderhoud. Daarbij maak ik een onderscheid naar de disciplines kunstwerken en wegen.

Informatie-uitwisseling in ontwerpfase

OntwerpTender

Actoren verdeeld naar team Ontwerp

Per discipline

Realisatie Ontwerp Na gunning

Kunstwerken

Wegen

Onderhoud

Figuur E Dimensies voor informatie-uitwisseling in dit onderzoek


Bijlage 7 Vragenlijst en dataverzameling Totstandkoming vragenlijst De interviews bestaan uit een vragenlijst. In figuur f zijn de verschillende onderdelen te vinden. Algemeen

Projectspecifiek

Deel 1:Project breed

Evaluatie

Deel 2: casus voegovergang

- Achtergrond informatie respondent - Problemen Life Cycle based afwegingen - Kritieke succesfactoren informatie-uitwisseling

Informatie-uitwisseling bij ontwerpkeuzes in project

Informatie-uitwisseling bij ontwerpkeuzes Voor voegovergang

Andere ontwerpkeuzes?

Figuur F Onderdelen in vragenlijst

De vragenlijst is opgedeeld in drie hoofddelen. Dit zijn een algemeen deel, project specifiek deel en evaluatie deel. Het project specifieke deel bestaat twee onderdelen: deel 1 gaat over structuren waarin informatie wordt vastgelegd (algemeen) en deel 2 gaat over de casus voegovergangen.

Algemeen In het algemene deel worden vragen gesteld over de karakteristieken vaan de respondent. Deze karakteristieken zijn nodig om te valideren of de respondenten die aan het interview mee doen overeenkomen met de criteria voor respondenten. Een tweede reden is dat verschillen in antwoorden mogelijk verklaard kunnen worden door de karakteristieken van een respondent.


De eerste vraag gaat over de functie van de respondent binnen zijn of haar bedrijf. Deze karakteristiek is van belang om bij de antwoorden eventuele verschillen in antwoorden te kunnen verklaren met verschillende belangen. De volgende vraag is daarom gesteld: 1. Wat is uw functie binnen uw bedrijf? De tweede vraag gaat over het aantal jaren dat een respondent werkzaam is in de civiele sector. Een respondent die slechts 1 a 2 jaar werkt in de civiele sector kan een verklaring zijn waarom bepaalde antwoord zijn gegeven op de vragen die totaal verschillen met andere verklaringen. De volgende vraag is daarom gesteld: 2. Hoeveel jaar bent u werkzaam in de civiele sector? De derde vraag gaat over de ervaringen van de respondent door het vragen naar het aantal grootschalige infrastructuurprojecten waar men bij betrokken is geweest. Een van de selectiecriteria van respondenten was dat zij in een DB(F)M project werkzaam zijn. Op basis van deze vraag wordt gevalideerd of de respondent voldoet aan de selectiecriteria. Daarnaast geeft het aantal projecten enig zicht op de ervarenheid van een respondent. De volgende vraag is daarom gesteld: 3. In hoeveel DBFM projecten bent u werkzaam of heeft u gewerkt? En op welke wijze bent u in andere projecten betrokken? De vierde vraag gaat over de rol van de respondent binnen een project. Deze vraag is gesteld om te valideren of de respondent voldoet aan de gedefinieerde rollen. De volgende vraag is daarom gesteld: 4. Wat is uw huidige rol binnen het DBFM project? De vijfde vraag gaat over de fase waarin de respondent betrokken is geweest in een rol binnen een project. Deze vraag is gesteld, omdat in veel gevallen een team de tenderfase doorloopt en een ander team verantwoordelijk is in de fase na gunning. De volgende vraag is daarom gesteld: 5. In welke fase(n) bent u in uw rol werkzaam of werkzaam geweest binnen het project? Om te valideren of de problemen die men in de praktijk heeft bij Life Cycle afwegingen overeen komen met de problemen uit de theorie is een vraag gesteld over problemen. Hiermee kan bekeken worden welke verschillen (gaps) en overeenkomsten verder bestaan tussen theorie en praktijk. Dit verantwoordt het stellen van de volgende vraag: 6. Wat zijn de drie voornaamste problemen bij het maken van Life Cycle afwegingen? Om aanbevelingen te geven, is de respondenten gevraagd om meest kritieke succesfactoren voor goede informatie-uitwisseling te benoemen voor projecten. Dit leidt tot de volgende vraag: 7. Wat zijn de drie meest kritieke succesfactoren voor goede informatie-uitwisseling in projecten?

Met de informatie van het algemene deel kan een validatie worden met betrekking tot LCC problemen in de theorie. Daarnaast biedt het algemene deel handvatten voor verschillenanalyse in hoofdstuk 7 en handvat voor aanbevelingen voor opdrachtnemers in hoofdstuk 9. Bijlagen Thesis Jeremy de Bruijn_5-12-2013 24

De volgende vragen zijn per project gesteld waarin de respondent in haar rol betrokken is geweest bij de ontwerpkeuze voor voegovergangen. Daarbij zijn de ervaringen van respondenten een weerspiegeling van de praktijk van het desbetreffende specifieke project.

Project specifiek Het project specifieke deel bestaat dus uit twee onderdelen. In het deel over structuren in informatie wordt project breed antwoord gegeven op vijf vragen (8 tot en met 11). In het deel over de casus voegovergangen wordt antwoord gegeven op 13 stellingen (13 tot en met 24) met elk vijf vragen. De van 8 tot en met 11 en de vragen bij de stellingen komen zijn de voorwaarden voor effectieve informatie-uitwisseling. Deze voorwaarden zijn:  Relevant;  Aanwezig;  Tijdig beschikbaar;  Expliciet;  Traceerbaar. De bovenstaande informatie is verwerkt in de vragen op de volgende paragrafen. Deel 1: Ontwerpkeuzes binnen project Op basis van de structuren en de voorwaarden voor effectieve informatie-uitwisseling leidt tot de volgende vragen: 8 Introductie: Om over informatie-uitwisseling iets te zeggen is het noodzakelijk om te inventariseren welke elementen gebruikt worden en of deze tijdig beschikbaar zijn. De volgende vragen hebben hierop betrekking. 8a. In het ontwerp heb ik informatie nodig van de volgende elementen voor ontwerpkeuzes gedurende: 8b.In het ontwerp is in het project informatie beschikbaar van de volgende elementen voor ontwerpkeuzes gedurende: 9. Bij ontwerpkeuzes heb ik tijdig beschikking over informatie van de volgende elementen: 10. Expliciet staat in dit onderzoek voor dit onderzoek voor de duidelijke vastlegging van informatie. Bij het maken van ontwerpkeuzes heb ik beschikking over expliciete informatie van de volgende elementen: 11. Traceerbaar betekent in dit onderzoek dat informatie herleidbaar is naar een bron. In dit project zijn de volgende elementen te traceren naar een bron: Bij elke vraag kan de respondent antwoord geven op de structuren die geïdentificeerd zijn in paragraaf 3.4 van het onderzoek. In zijn deze tien structuren te zien in een overzicht.


Tabel B Generiek overzicht tien structuren in de vragen 8 tot en met 11

Tender Ja ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐

Objecten Doelen Functies Eisen Risico’s Organisaties Fasen Locaties Werkpakketten Processen Anders, nl

Na gunning Ja ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐

Nee ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐

Nee ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐

Weet ik niet ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐

Toelichting

In deze tabel is onderscheid gemaakt tussen de twee deelfasen waarin respondenten betrokken zijn geweest en vanuit die fase antwoord hebben gegeven op de vragen. Deze twee deelfasen zijn: de tender en na gunning. Aangezien binnen dit onderzoek respondenten in verschillende fasen zijn geïnterviewd is dit onderscheid opgenomen in dit deel van het onderzoek. De volgende vragen gaan over relaties tussen de structuren. Daarbij is aan de respondenten gevraagd naar de relaties die de respondenten zelf wenselijk vinden om te leggen. Dit leidt tot de volgende vragen: 12a. Voor het maken van een ontwerpkeuze is in het project een relatie gelegd tussen de volgende elementen: 12b. Voor het maken van een ontwerpkeuze leg ik zelf een relatie tussen de volgende elementen: Voor de beantwoording van deze vragen is een kruistabel opgesteld. Daarin zijn alle relaties 1 maal aan te kruisen. In tabel c is deze kruistabel te vinden. Tabel C Kruistabel met relaties tussen structuren. Objecten

Doelen

Functies

Eisen

☐

☐ ☐

☐ ☐ ☐

Risico’s

Organisa ties

Fasen

Locaties

☐ ☐ ☐ ☐ ☐

☐ ☐ ☐ ☐ ☐ ☐

☐ ☐ ☐ ☐ ☐ ☐ ☐

Werk

Processen

Anders, namelijk..

☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐

☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐

pakketten

Objecten Doelen Functies Eisen Risico’s Organisaties Fasen Locaties Werkpakkette n Processen Anders, namelijk…

☐ ☐ ☐ ☐

☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐

☐


Deel 2: casus voegovergang Voor de casus voegovergangen zijn 12 stellingen opgesteld. De stellingen komen voort uit totstandkoming van informatie volgens Systems Engineering (SE) uit hoofdstuk 3 en relaties tussen structuren van het beschrijvende informatie model in paragraaf 3.4. De volgende stellingen zijn in de interviews opgenomen: 13. (A1) Voor de ontwerpkeuze van voegovergangen maak ik gebruik van de eisen die het team heeft afgeleid van functies. 14. (A2) Voor de ontwerpkeuze voor voegovergangen maak ik gebruik van de beschikbaarheideisen van het contract per locatie. 15. (A3) Voor de ontwerpkeuze voor voegovergangen wil ik van elke eis weten wie de verantwoordelijkheid heeft om aan de eis te voldoen 16. (A4) Voor de ontwerpkeuzes van voegovergangen maak ik onderscheid in eisen die betrekking hebben op de realisatieen de exploitatiefase. 18. (B1) Voor een ontwerpkeuze voor voegovergangen maak ik gebruik van locatie specifieke eisen van het kunstwerk. 19. (B2) Voor de ontwerpkeuze voor voegovergangen maak ik gebruik van de eisen die voortvloeien uit onze onderhoudsstrategie. 20. (B3) Voor een ontwerpkeuze voor voegovergangen maak ik gebruik van de eisen die uit ontwerpkeuzes voor kunstwerken voortvloeien. 21. (B4) Voor de ontwerpkeuze van voegovergangen maak ik gebruik van eisen die uit ontwerpkeuzes voor asfalt voortvloeien. 22. (C1) Voor de ontwerpkeuze voor voegovergangen maak ik gebruik van de risico's die de doelen bedreigen. 23. (C2) Bij een ontwerpkeuze van voegovergangen genereren de eisen van beschikbaarheid risico's voor niet-beschikbaarheid. 24. (C3) Voor een ontwerpkeuze voor voegovergangen neem ik beheersmaatregelen mee voor risico's. Bij iedere stelling zijn dezelfde vijf vragen gesteld. Deze vragen zijn in tabel d te zien. Tabel D vragen in de interviews per stelling.

1.a Bent u het eens met de stelling, ofwel is zo gewerkt? 1.b Bent u het eens met de stelling, ofwel is dit gewenst? (mondeling gevraagd) 2.De informatie over de functies is tijdig beschikbaar 3. De informatie over de functies is expliciet gemaakt 4. De informatie over de functies is traceerbaar

Mee eens ☐ ☐ ☐ ☐ ☐

☐ ☐

☐ ☐

Niet mee eens ☐ ☐

☐ ☐ ☐

☐ ☐ ☐

☐ ☐ ☐

Onbekend ☐ ☐ ☐ ☐ ☐

Op basis van de bovenstaande vragen kan met de antwoorden de mate van effectieve informatieuitwisseling bepalen voor de casus voegovergangen. Om de resultaten van de casus voegovergang te generaliseren naar andere ontwerpkeuzes wordt de respondenten in vraag 25 gevraagd antwoord te geven bij welke andere ontwerpkeuzes issues zijn met de Life Cycle based afwegingen.


25. De vragen bij de stellingen in dit interview gingen over ontwerpkeuzes voor voegovergangen. Welke andere ontwerpkeuzes zijn vergelijkbaar met uw antwoorden in dit onderzoek op het gebied van tijdige beschikking, expliciet en traceerbaarheid van informatie? Bij deze vraag krijgen de respondenten een lijst met objecten waar men in een project een ontwerpkeuze voor moet maken. Deze, niet-limitatieve lijst, is in tabel e te vinden. Tabel E lijst met objecten.

Ja Leuning brug Berm Portaal Afsluitboom Geleiderail Geluidsscherm Asfalt Zettingen ondergrond Lichtmast Kabels Anders, namelijk…

☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐

Nee ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐

Weet ik niet ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐

Toelichting

De respondenten is de mogelijkheid gegeven uit een niet-limitatieve lijst objecten aan te vinken of de ontwerpkeuze relevant is in het kader van Life Cycle based afwegingen. Daarbij is het wenselijk als de respondent een korte toelichting geeft met voorbeelden.


Bijlage 7 Resultaten en data analyse IV.

Algemene informatie respondenten

1. Wat is uw functie binnen uw bedrijf?

De antwoorden op deze vraag zijn in Tabel F te vinden. Tabel F Functie, naam project, rol en fase in project per respondent. Nr.

Naam

1

Afkorting

Functie en bedrijf

Project

Fase

Geanonimiseerd

Rol in project OK

Geanonimiseerd

Geanonimiseerd

2

Geanonimiseerd

Geanonimiseerd

Geanonimiseerd

PK

OT – OG - RE

3

Geanonimiseerd

Geanonimiseerd

Geanonimiseerd

OK

OT – OG – RE

4

Geanonimiseerd

Geanonimiseerd

Geanonimiseerd

OW

OG

5

Geanonimiseerd

Geanonimiseerd

Geanonimiseerd

PO

OT – OG – RE

6

Geanonimiseerd

Geanonimiseerd

Geanonimiseerd

OW

OG

7

Geanonimiseerd

Geanonimiseerd

Geanonimiseerd

PW

OT

8

Geanonimiseerd

Geanonimiseerd

Geanonimiseerd

PO

OT

9

Geanonimiseerd

Geanonimiseerd

Geanonimiseerd

PW

OG

10

Geanonimiseerd

Geanonimiseerd

Geanonimiseerd

PO

OG

11

Geanonimiseerd

Geanonimiseerd

Geanonimiseerd

PO

OT

12

Geanonimiseerd

Geanonimiseerd

Geanonimiseerd

PW

OG

OG

2. Hoeveel jaar bent u werkzaam in de civiele sector?

De antwoorden op deze vraag zijn in figuur g te vinden.

Hoeveel jaar bent u werkzaam in de civiele sector? 30

20 10 0

Figuur G resultaten aantal jaren werkzaam.


3. In hoeveel DBFM projecten bent u werkzaam of heeft u gewerkt? En op welke wijze bent u in andere projecten betrokken?

In hoeveel DBFM projecten bent u werkzaam of heeft u gewerkt? 5 4 3 2 1 0

Figuur H Resultaten betrokkenheid respondenten bij aantal DBFM projecten.

4. Wat is uw huidige rol binnen het DBFM project? In Tabel G is de codering te zien. Op basis van deze codering kan een onderscheid gemaakt worden naar type respondent. Tabel G Codering

OK OW PK PW

Ontwerpleider/ ontwerper kunstwerken Ontwerpleider/ ontwerper wegen Projectleider/ werkvoorbereider realisatie kunstwerken Projectleider/ werkvoorbereider realisatie wegen

PO TM IM

Projectleider/ werkvoorbereider onderhoud Technisch manager Informatie manager

AN

Anders, namelijk…

Op basis van bovenstaande onderverdeling zijn de respondenten gecodeerd. Zo is een ontwerpleider kunstwerken OK en een projectleider onderhoud PO. De rollen zijn opgenomen in tabel f. 5. In welke fase(n) bent u in uw rol werkzaam of werkzaam geweest binnen het project? De antwoorden van deze vraag zijn opgenomen in Tabel H. Tabel H Betrokken in fase van het project.

Fase in project

Rol

Nr.

OT

Ontwerpleider en projectleiders ( realisatie en onderhoud)

7,8,11

OG


1,4,6,9,10,12

OT & OG


2,3,5


De antwoorden op deze vraag zijn in Tabel F te vinden.

Tabel I Lijst met geanonimiseerde respondenten en projecten. Nr.

Rol

Discipline

1 2 3 4 5 6 7 8 9 10 11 12

Ontwerpleider

Kunstwerken

Projectleider realisatie Ontwerpleider

Project

Fase

Codering

A

Ontwerp na gunning

OK1

Kunstwerken

A


PK1

Kunstwerken

A


OK2

Ontwerpleider

Wegen

B

Ontwerp na gunning

OW1



C


PO1

Ontwerpleider onderhoud

Realisatie Wegen

A

Ontwerp na gunning

OW2


Wegen

D

Ontwerp tender

PW1



A

Ontwerp tender

PO2


Wegen

B

Ontwerp na gunning

PW2



B

Ontwerp na gunning

PO3



D

Ontwerp tender

PO4


Wegen

E

Ontwerp na gunning

PK2


V.

Problemen Life Cycle based afwegingen en succes criteria voor informatie-uitwisseling

6. Wat zijn de drie voornaamste problemen bij het maken van life cycle based afwegingen? (gap analyse)

In de theorie van hoofdstuk 4 zijn vijf problemen bij LCC analyses gevonden. Op basis van deze problemen is in de praktijk getoetst of de praktijk dergelijke problemen erkend bij het maken van Life Cycle based afwegingen. In Tabel J zijn de geïdentificeerde problemen bij Life Cycle based afwegingen te zien. Tabel J Overzicht problemen bij Life Cycle based afwegingen.

Probleem in de praktijk Moeilijk te bepalen hoeveel onderhoud nodig is Schatten van kosten beheer en onderhoud Juiste informatie verkrijgen Bepalen hoeveel onderhoud nodig is Geen ervaringsdeskundigheid ("boekjeswijsheid") Verschil in kennis van disciplines: tekort kennis onderhoud Moeilijk juiste parameters te bepalen Hoever ga je in detail? (vb. 1 generiek type in tender gekozen voldoende) Welke raakvlakken zijn met andere onderdelen? Trade-offs zijn van onvoldoende kwaliteit Tekort aan inzicht van de gevolgen van keuzes Onvoldoende scherp op eisen (m.n. boete en beschikbaarheideisen) Informatie is niet expliciet (is blijven zweven) Kwantificeren is moeilijk Financiële component meenemen is moeilijk Onderhoud werkt vanaf eiland Partijen werken op eilanden Belangen van partijen Budgetten van partijen Onvoldoende beleving urgentie onderhoud Geen sturing/ informatie vanuit onderhoud De problemen zijn benoemd door de respondenten. De lijst zal in paragraaf 7.1 gebruikt worden om te vergelijken met LCC problemen in de theorie. Daarmee kan gevalideerd worden of de LCC problemen in de theorie overeenkomsten vertonen met ervaringen in de praktijk


7. Wat zijn de drie meest kritieke succesfactoren voor goede informatie-uitwisseling in projecten? In Tabel K zijn de kritieke succesfactoren genoemd. Tabel K Geïdentificeerde succesfactoren van respondenten

Kritieke succesfactoren

Voorwaarden voor effectieve informatie-uitwisseling

Gestructureerd raakvlakkenoverleg vastleggen Verwachtingspatroon van partijen Partijen elkaar begrijpen Bewaken afspraken over informatie-uitwisseling Tijdigheid van informatie Deel de juiste informatie Juiste informatie uitwisselen Compleetheid documenten Kennis van mensen Gebruiksvriendelijke systemen Goed informatie systeem Toegankelijkheid van informatie Goede tools Simpele en gebruiksvriendelijke inrichting ICT infrastructuur Sturing management op informatie-uitwisseling Aansturing vanuit management Hoe organiseer je het project? Inrichting organisatie Ontwerpmanager initieert Klein kernteam beginnen Duidelijkheid in de organisatie wie eigenaar van de life cycle analyse is Mensen die informatie willen delen Bewust zijn informatie-uitwisseling met onderhoud

3. Expliciet 2. Tijdig beschikbaar 3. Expliciet 2. Tijdig beschikbaar 2. Tijdig beschikbaar 3. Expliciet 3. Expliciet 3. Expliciet 1.a.Relevant 4. Traceerbaar 4. Traceerbaar 4. Traceerbaar 4. Traceerbaar 4. Traceerbaar 1.b Aanwezig 1.a.Relevant 1.b Aanwezig 1.b Aanwezig 1.a.Relevant 2. Tijdig beschikbaar 3. Expliciet 1.a.Relevant 1.a.Relevant

De kritieke succesfactoren kunnen gecategoriseerd worden naar een voorwaarde voor effectieve informatie-uitwisseling. Een samenvatting van kritieke succesfactoren wordt in het hoofdrapport gebruikt in paragraaf 7.1.


VI.

Informatie-uitwisseling project breed

Vraag 8a is niet in de bijlage gezet. 8b. Welke van deze informatie is gewenst? - aanwezig Tender Ja ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐

Objecten Doelen Functies Eisen Risico’s Organisaties Fasen Locaties Werkpakketten Processen Anders, namelijk…

Na gunning Ja ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐

Nee ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐

Nee ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐

Weet ik niet ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐

Toelichting

Aantal respondenten

Structuren - aanwezig

Objecte Functie Organis Locatie Werkpa Process Objecte Doelen Eisen Risico's Fasen n s aties s kketten en n weet ik niet

0

1

0

0

0

1

0

0

0

0

0

nee

0

2

0

0

1

1

1

3

3

2

5

Ja

10

6

10

10

8

8

8

6

6

7

5

Deze informatie bevestigd het beeld dat in veel gevallen alle Structuren in enige vorm aanwezig zijn binnen een project in hoofdstuk 6.


9. Bij ontwerpkeuzes heb ik tijdig beschikking over informatie van de volgende elementen: Tender Ja ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐


Nee ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐

Na gunning Ja ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐

Nee ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐

Weet ik niet ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐

Toelichting

Aantal respondenten

Structuren - tijdig beschikbaar

Objecte Doelen Functies Eisen n

Risico's

Organis aties

Fasen Locaties

Werkpa Process kketten en

weet ik niet

0

2

0

0

0

1

2

1

2

1

nee

5

3

4

3

4

3

3

2

3

4

Ja

5

5

6

7

6

6

5

7

5

5

Deze informatie bevestigd het beeld dat in ongeveer de helft van alle Structuren de informatie tijdig beschikbaar is in hoofdstuk 6. JBR: Om informatie te kunnen gebruiken is het noodzakelijk dat de kwaliteit van de aangeleverde informatie juist is. In het kader van dit onderzoek wordt de kwaliteit van informatie-uitwisseling bepaald aan de hand van expliciet en traceerbaar. De volgende twee vragen hebben betrekking op de kwaliteit van informatie-uitwisseling.


10. Expliciet staat in dit onderzoek voor dit onderzoek voor de duidelijke vastlegging van informatie. Bij het maken van ontwerpkeuzes heb ik beschikking over expliciete informatie van de volgende elementen: Tender Ja ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐


Nee ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐

Na gunning Ja ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐

Nee ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐

Weet ik niet ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐

Toelichting

Aantal respondenten

Structuren - expliciet


Risico's

Organis aties

Fasen Locaties


weet ik niet

0

3

1

0

1

1

3

0

1

1

nee

6

3

5

5

5

5

3

3

5

5

Ja

4

5

4

5

4

4

4

7

4

4

Deze informatie bevestigd het beeld dat in veel gevallen de helft of minder van alle Structuren de informatie expliciet is in hoofdstuk 6.


11. Traceerbaar betekent in dit onderzoek dat informatie herleidbaar is naar een bron. In dit project zijn de volgende elementen te traceren naar een bron:

Objecten Doelen Functies Eisen

Tender Ja ☐ ☐ ☐ ☐

Risico’s Organisaties Fasen Locaties Werkpakketten Processen Anders, namelijk…

☐ ☐ ☐ ☐ ☐ ☐ ☐

Nee ☐ ☐ ☐ ☐

Na gunning Ja ☐ ☐ ☐ ☐

☐ ☐ ☐ ☐ ☐ ☐ ☐

☐ ☐ ☐ ☐ ☐ ☐ ☐

Nee ☐ ☐ ☐ ☐

Weet ik niet ☐ ☐ ☐ ☐

☐ ☐ ☐ ☐ ☐ ☐ ☐

☐ ☐ ☐ ☐ ☐ ☐ ☐

Toelichting

Aantal respondenten

Structuren - traceerbaar


Risico's

Organis aties

Fasen Locaties


weet ik niet

0

2

2

0

1

2

3

1

1

1

nee

4

4

4

4

5

4

2

2

4

3

Ja

6

4

4

6

4

4

5

7

5

6

Deze informatie bevestigd het beeld dat in veel gevallen de helft of minder van alle Structuren de informatie traceerbaar is in hoofdstuk 6.


12b. Voor het maken van een ontwerpkeuze leg ik een relatie tussen de volgende elementen (wenselijk): Met deze informatie is niks meer gedaan. Dit is niet van belang voor dit onderzoek, maar wel voor Iter Fidelis.

VII.

Informatie-uitwisseling bij de casus voegovergangen

Het volgende deel van dit onderzoek gaat over de informatie-uitwisseling bij de ontwerpkeuze voor voegovergangen. (vragen 13 t/m 24). Bij elke vraag komt het vierluik van vragen terug. 1. 2. 3. 4.

A) Bent u het eens met de stelling, ofwel het is zo gegaan in dit project? B) Bent u het eens met de stelling, ofwel deze werkwijze is gewenst volgens u? Tijdig beschikbaar - De informatie over … is tijdig beschikbaar Expliciet - De informatie over … is expliciet gemaakt Traceerbaar - De informatie over … is traceerbaar

In Figuur I is het contextdiagram voor de stellingen over eisen bij voegovergangen te zien..

13) Functionele eisen

21)

14) Eisen per locatie

Eisen vanuit asfalt

20) Eisen vanuit kunstwerke n

Ontwerpkeuze voegovergangen - eisen

19)

15) Verantwoor delijkheid per eis

16) Eisen per fase

Eisen vanuit onderhoud

18) Eisen per locatie

17) Verantwoor delijke per eis

Figuur I Contextdiagram ontwerpkeuze voegovergangen met focus op de eisen uit DBFM contracten.


13. (A1) Voor de ontwerpkeuze van voegovergangen maak ik gebruik van de eisen die het team heeft afgeleid van functies. Mee eens ☐ ☐ ☐ ☐

Bent u het eens met de stelling? De informatie over de functies is tijdig beschikbaar De informatie over de functies is expliciet gemaakt De informatie over de functies is traceerbaar



☐ ☐ ☐ ☐

☐ ☐ ☐ ☐

Niet mee eens ☐ ☐ ☐ ☐

Onbekend ☐ ☐ ☐ ☐

JBR: Gewenst?

Functional Breakdown Structure (FBS)

Is afgeleidt in (prestatie)


Gesplitst per respondent - Relatie functies en eisen Mee eens A) Relevant – gewenst B) Relevant gegaan C) Tijdig beschikbaar D) Expliciet E) Traceerbaar

Deels mee eens

OK1,2,3,4,5,6,7 8,9,10,11,12 3,5,10

7

3

7

3,5 3,5

Deels niet mee eens

Niet mee eens

Onbekend

OK1,2,4,5,6,8,9,11,12 5

OK1,2,4,5,6,8,9,10,11,12 OK1,2,4,5,6,7,8,9,10,11,12 OK1,2,4,5,6,7,8,9,10,11,12


14. (A2) Voor de ontwerpkeuze voor voegovergangen maak ik gebruik van de beschikbaarheidseisen van het contract per locatie.

Bent u het eens met de stelling? De informatie over de beschikbaarheidseisen per locatie is tijdig beschikbaar De informatie over de beschikbaarheidseisen per locatie is expliciet gemaakt De informatie over de beschikbaarheidseisen per locatie is traceerbaar



Mee eens ☐ ☐

☐ ☐

☐ ☐


Onbekend ☐ ☐

☐

☐

☐

☐

☐

☐

☐

☐

☐

☐

JBR: Gewenst?



Bepaalt

Gesplitst per respondent - Relatie locatie en eisen

A) Relevant – gewenst B) Relevant gegaan C) Tijdig beschikbaar D) Expliciet E) Traceerbaar

Mee eens OK1,2,3,4,5,6,7,8,,910,11,12

Niet mee eens

OK1, 2,4,5,6,7,8,10,11,12

3,9

3,5,6,7,8,10,12

4,9

2,11

OK1

2,3,5,6,7,10,12 2,3,5,7,9,10,12

8,9 8

4 4,11

OK 1,11 OK 1

Onbekend

6


15. (A3) Voor de ontwerpkeuze voor voegovergangen wil ik van elke eis weten wie de verantwoordelijkheid heeft om aan de eis te voldoen Mee eens Bent u het eens met de stelling? De informatie over de verantwoordelijkheid van eisen is tijdig beschikbaar De informatie over verantwoordelijkheid van eisen is expliciet gemaakt De informatie over verantwoordelijkheid van eisen is traceerbaar



☐ ☐

☐ ☐

☐ ☐


Onbekend ☐ ☐

☐

☐

☐

☐

☐

☐

☐

☐

☐

☐

JBR: Gewenst?




Gesplitst per respondent - Relatie organisatie en eisen

A) A) Relevant – gewenst B) Relevant gegaan C) Tijdig beschikbaar D) Expliciet E) Traceerbaar

Mee eens OK1,2,3,4,5,6,7,8,9,10,11,12

Niet mee eens

OK1,2,3,4,6,7,8,9,10,11,12

5

OK1,3,5,10,12

4,7

2,9

6,8,11

OK1,2,3,5,7,10 OK1,2,3,5,7,10

4,9 11

4

6,8,11,12 6,8,9,12

Onbekend


16. (A4) Voor de ontwerpkeuzes van voegovergangen maak ik onderscheid in eisen die betrekking hebben op de realisatieen de exploitatiefase.

Bent u het eens met de stelling? De informatie over de eisen per fase is tijdig beschikbaar De informatie over de eisen per fase is expliciet gemaakt De informatie over eisen per fase is traceerbaar



Mee eens ☐ ☐ ☐ ☐

☐ ☐ ☐ ☐

☐ ☐ ☐ ☐



JBR: Gewenst?



Genereren

Gesplitst per respondent - Relatie fase en eisen


Mee eens OK1,2,3,4, 6,7,8, 9,10,11,12 OK1,2,3,4,7,8,10,11,12

Niet mee eens 5 9

5,6

2,3,8,9,10

4,7

OK1,5,6,11,12

3,9,10 3,10

2 2

4,7,8 9

OK1,5,6,11,12 OK1,5,6,7,8,11,12

Onbekend

4


17. (A5) Bij het maken van ontwerpkeuzes voor voegovergangen is een ontwerpleider verantwoordelijk voor de eisen waar het werkpakket voegovergangen aan moet voldoen.

Bent u het eens met de stelling? De informatie over de verantwoordelijkheid is tijdig beschikbaar De informatie over de verantwoordelijkheid is expliciet gemaakt De informatie over de verantwoordelijkheid is traceerbaar



Mee eens ☐ ☐


Onbekend ☐ ☐

☐ ☐

☐ ☐

☐

☐

☐

☐

☐

☐

☐

☐

☐

☐

JBR: Gewenst?




Gesplitst per respondent - Relatie werkpakket en eisen


Mee eens OK1,2,3,4,5,6,7,8,9,10,11,12 OK1,2,3,4,6,7,8,10,11,12

Niet mee eens

5

OK1,2,3,4,5,6,7,8,10,12 OK1,2,3,5,6,10,12 OK1,2,3,5,6,10,12

9 11

7 7

Onbekend

9 8,9,11 8,9,11

4 4


18. (B1) Voor een ontwerpkeuze voor voegovergangen maak ik gebruik van locatie specifieke eisen van het kunstwerk.

Bent u het eens met de stelling? De informatie over de locatie eisen van kunstwerken is tijdig beschikbaar De informatie over de locatie eisen van kunstwerken is expliciet gemaakt De informatie over de locatie eisen van kunstwerken is traceerbaar



Mee eens ☐ ☐

☐ ☐

☐ ☐


Onbekend ☐ ☐

☐

☐

☐

☐

☐

☐

☐

☐

☐

☐

JBR: Gewenst?



Bepaalt

Gesplitst per respondent - Relatie locatie en eisen


Mee eens OK1,2,3,4,6,7,8,10,11,12

5,9

Niet mee eens

2,3,4,7,8,10,11,12

5,9

3,4,5,12

7,10

3,5,10 3,5,10

Onbekend

OK1,6 2,9,11

OK1,6

8

2,4,7,9 2,4,7

OK1,6,11,12 OK1,6,9,11,12

8 8

Respondenten

Stelling B1: Voor een ontwerpkeuze voor voegovergangen maak ik gebruik van locatie specifieke eisen van het kunstwerk 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Vragen aan respondenten Eens

deels eens

deels niet mee eens

niet mee eens

Onbekend

Niet van toepassing


19. (B2) Voor de ontwerpkeuze voor voegovergangen maak ik gebruik van de eisen die voortvloeien uit onze onderhoudsstrategie.

Bent u het eens met de stelling? De informatie over de onderhoudsstrategie is tijdig beschikbaar De informatie over de onderhoudsstrategie is expliciet gemaakt De informatie over de onderhoudsstrategie is traceerbaar



Mee eens ☐ ☐


Onbekend ☐ ☐

☐ ☐

☐ ☐

☐

☐

☐

☐

☐

☐

☐

☐

☐

☐

Niet mee eens

Onbekend

JBR: Gewenst?



Genereren

Gesplitst per respondent - Relatie doel en eisen


Mee eens OK1,2,3,4,5,6,8, 9,10,11,12 OK1,2,3,4,5,6,8

12

9,10,11

3,5,6

OK1,4,8,9,11,12

2,10

3,5 3,5

OK1,4,6,8,9,11,12 OK1,4,6,8,9,11,12

2,10 2,10


20. (B3) Voor een ontwerpkeuze voor voegovergangen maak ik gebruik van de eisen die uit ontwerpkeuzes voor kunstwerken voortvloeien.

Bent u het eens met de stelling? De informatie over de afgeleide eisen uit de geometrie van kunstwerken is tijdig beschikbaar De informatie over de afgeleide eisen uit de geometrie van kunstwerken is expliciet gemaakt De informatie over de afgeleide eisen uit de geometrie van kunstwerken is traceerbaar



Mee eens ☐ ☐


Onbekend ☐ ☐

☐ ☐

☐ ☐

☐

☐

☐

☐

☐

☐

☐

☐

☐

☐

JBR: Gewenst?


Is bepalend voor


Gesplitst per respondent - Relatie ontwerp en eisen

A) Relevant – gewenst Relevant – gegaan C) Tijdig beschikbaar D) Expliciet E) Traceerbaar

Mee eens OK1,2,3,4,5,6,7,9,10,11,12

Niet mee eens

Onbekend

OK1,2,3,4,5,6,7,10,11,12

9

8

OK1,3,5,6,10

4,11

9,12

2,7,8

OK1,3,5,6,10,11 OK1,3,5,6,10,11

4 4

9,12 9,12

2,7,8 2,7,8


21. (B4) Voor de ontwerpkeuze van voegovergangen maak ik gebruik van eisen die uit ontwerpkeuzes voor asfalt voortvloeien.

Bent u het eens met de stelling? De informatie over de afgeleide eisen is tijdig beschikbaar De informatie over de afgeleide eisen is expliciet gemaakt De informatie over de afgeleide eisen is traceerbaar




☐ ☐ ☐ ☐

☐ ☐ ☐ ☐



JBR: Gewenst?



Is bepalend voor

Gesplitst per respondent - Relatie ontwerp en eisen


Mee eens 2,3,4,5,6,7, 9,10,11,12 2,3,4,5,7,10,11,12

Niet mee eens OK1

3,5,7,10

11

3,5,10 3,5,10

7

Onbekend

6

OK1,9

8

12

OK1,4,6,9

2,8

7

OK1,4,6,9,11,12 OK1,4,6,9,11,12

2,8 2,8

22. (C1) Voor de ontwerpkeuze voor voegovergangen maak ik gebruik van de risico's die de doelen bedreigen.



Bent u het eens met de stelling? De informatie over de doelen is tijdig beschikbaar De informatie over de doelen is expliciet gemaakt De informatie over de doelen is traceerbaar



☐ ☐ ☐ ☐

☐ ☐ ☐ ☐



JBR: Gewenst?

Objectives Breakdown Structure (OBBS)

Bedreigt


Relatie risico’s en doelen


Mee eens 2,3,7,9,11

Niet mee eens OK1,4,8,10,12

2,3,7,11

5

OK1,4,6,8,9,10,12

3,5

7,11

OK1,2,4,6,8,9,10,12

3,5 3,5

11

7

Onbekend

OK1,2,4,6,8,9,10,12 OK1,2,4,6,7,8,9,10,11,12

23. (C2) Bij een ontwerpkeuze van voegovergangen genereren de eisen van beschikbaarheid risico's voor nietbeschikbaarheid.


Bent u het eens met de stelling? De informatie over de risico’s voor niet-beschikbaarheid is tijdig beschikbaar De informatie over de risico’s voor niet-beschikbaarheid is expliciet gemaakt De informatie over de risico’s voor niet-beschikbaarheid is traceerbaar



Mee eens ☐ ☐


Onbekend ☐ ☐

☐ ☐

☐ ☐

☐

☐

☐

☐

☐

☐

☐

☐

☐

☐

JBR: Gewenst?


Genereert


Gesplitst per respondent - Relatie eisen en risico’s


Mee eens OK1,2,3,5,6,7,8,9,10,11,12

Niet mee eens

2,3,5,7,8,10,11,12

9

OK1,6

3,5,10

7,8,11

OK1,2,6,12

3,5,10 3,5,9,10

8,9,11 8,11

7 (8%)

Onbekend

9

OK1,2,6,12 OK1,2,6,7,12

24. (C3) Voor een ontwerpkeuze voor voegovergangen neem ik beheersmaatregelen mee voor risico's.

Bent u het eens met de stelling?

Mee eens ☐

☐

☐

Niet mee eens ☐

Onbekend ☐


De informatie over de beheersmaatregelen is tijdig beschikbaar De informatie over de beheersmaatregelen is expliciet gemaakt De informatie over de beheersmaatregelen is traceerbaar



☐

☐

☐

☐

☐

☐

☐

☐

☐

☐

☐

☐

☐

☐

☐

JBR: Gewenst?


Wordt beheerst door


Gesplitst per respondent - Relatie risico’s en activiteiten


Mee eens OK1,3,4,5,7,8,10,11

9

Niet mee eens 2,6,12

OK1,3,4,5,7,8,10,11

9

3,5,8,10

4,7

9,11

OK1,2,6,12

3,5,8,10,11 3,5,8,10,11

7,9 7

4 9

OK1,2,6,12 OK1,2,6,12

Onbekend

2,6,12

4

25. De vragen bij de stellingen in dit interview gingen over ontwerpkeuzes voor voegovergangen. Welke andere ontwerpkeuzes zijn vergelijkbaar met uw antwoorden in dit onderzoek op het gebied van tijdige beschikking, expliciet en traceerbaarheid van informatie? Ja Leuning brug

☐

Nee ☐

Weet ik niet ☐

Toelichting


☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐

☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐

Berm Portaal Afsluitboom Geleiderail Geluidsscherm Asfalt Zettingen ondergrond Lichtmast Kabels Anders, namelijk…

☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐ ☐

Ontwerpkeuzes waarbij informatie van beschikbaarheid een rol speelt

2

0

2 3 4

4

2

10

10 6

5

6

1 0

12 8

9

3

4

Ja

1

7

4

Nee

Onbekend



Bijlage 8 overige interviews Gespreksverslag A. Visser en J. de Bruijn_13-08-2013_14:00-17:15 Interviewer: J. de Bruijn Geïnterviewde: A. Visser Datum: 13-08-2013 Akkoord geïnterviewde: Ja Voorbereiding gesprek Voorafgaand aan het verslag heeft via de mail communicatie plaatsgevonden tussen Jeremy de Bruijn (JBR) en Arjan Visser (AVI). Deze communicatie was nodig om de context van het afstudeeronderzoek voor het gesprek te bepalen. JBR heeft daarbij de samenvatting van zijn onderzoek gestuurd om context te schetsen. AVI gaf naar aanleiding van deze samenvatting aan dat hij het onderwerp en thema interessant vond en zelf ook bezig was met opstellen van een informatie model. Kortom, informatieuitwisseling kan voor beide partijen meerwaarde bieden. Tijdens de mailwisseling kreeg JBR tips om aansluiting te zoeken op forums, zoals de linkedin groepen SE voor alumni en specificeren aan te melden Verloop gesprek Op dinsdag 13 augustus heeft een gesprek plaatsgevonden tussen Jeremy de Bruijn (JBR) en Arjan Visser (AVI) in het kader van het afstuderen van JBR. Het doel van dit gesprek was voor om te valideren of de ingeslagen weg overeenkomt met de trend binnen Systems Engineering en de relatie met informatiekunde door het ontwikkelen van (beschrijvende) informatie modellen voor verschillende typen informatie. Onder typen informatie wordt hier onder andere functies, doelen, processen, eisen, objecten en organisatie genoemd. Een informatie model bestaat daarbij uit data (elementen) en relaties, omdat op deze wijze informatie uitgewisseld kan worden volgens de informatiekunde. In het kader van SE hebben wij het over elementen en relaties. Arjan Visser is relevant om te interviewen, omdat hij Projectmanager bij CROW is en daarbij lid is van diverse werkgroepen van SE. Hij heeft daarom goed zicht heeft op de huidige stand van zaken op SE. Hij kan daarom perspectief bieden op de ontwikkelingen en veranderingen binnen de sector en daarbij valideren dat de richting van dit onderzoek zowel praktische als wetenschappelijke meerwaarde heeft binnen de GWW sector. Indeling gesprek Tijdens het gesprek zijn de volgende onderwerpen aan de orde geweest:         

Perspectieven op SE; Ontwikkelingen in SE; Ontwerpkeuzes; Eisen; Informatie management: structuren in SE; Nieuwe ontwikkelingen in informatie management; Validatie broninformatie; Conclusie; Afspraken.


Perspectieven op SE AVI is vanuit verschillende perspectieven ingegaan op SE, zowel verschillen tussen sectoren als verschillen in opleidingen. AVI gaf aan dat er geen consensus is in de interpretatie van de ISO15288 en SE Life Cycle processen. De verschillen gelden voor zowel tussen sectoren als binnen één sector (GWW sector). Op deze basis zijn een aantal onderwerpen de revue gepasseerd. Grote opdrachtgevers in Nederland In Tabel L zijn de twee grootste opdrachtgevers binnen Nederland te zien. Tabel L Grootste opdrachtgevers binnen Nederland

Prorail Def. Eisen: CEM Prorail kent een specifieke railmarkt en past diverse soorten aanbestedingen en contracten toe (zowel UAV(RAW) als UAVgc Prorail kent zogenaamde kernprocessen die toegepast worden in projecten die per type financiering ontwikkeld zijn.

RWS Def. Eisen: KES RWS van oorsprong RAW projecten gebaseerd op interne meerjarenplanningen (DWW, bouwdienst), nu uitsluitend UAVgc en DBFMO, met eigen contractmodellen RWS maakt onderscheid in grote projecten en past daar vooral DBFM(O) toe, rest UAVgc

De twee grootste opdrachtgevers binnen Nederland zijn Prorail en RWS. In het onderzoek van JBR wordt beperkt tot Nederlandse weginfrastructuurprojecten, waardoor alleen RWS een belangrijke actor is. JBR: Waarom zijn zoveel verschillen tussen de verschillende houdingen en interpretaties ten aanzien van SE? AVI: Een reden van de verschillen is de wijze van adoptie en de (noodzakelijke) interpretatie van de abstracte ISO15288 norm de reden dat de verschillende toepassingen ontstaan zijn. Dit sluit aan op de theorie van JBR over de verschillende documentatie die gevonden is (leidraad SE 2.0, Prorail SE, BAM wijzer SE, Volker Infra SE wijzer). Ontwikkelingen in SE JBR: Binnenkort komt de leidraad SE 3.0 uit (bron: http://www.leidraadse.nl/nieuwsitem/93/WerkgroepLeidraad-SE-3.0-van-start). In hoeverre is de leidraad uniform en wanneer komt deze definitief uit? AVI geeft aan dat door de verschillende interpretaties dit niet 1,2,3 mogelijk is. AVI: “Consensus is op dit moment nog niet aan de orde en het is de vraag of dit met leidraad 3.0 wel gaat ontstaan (assumptie)”. JBR: In het kader van mijn onderzoek wil ik graag onderbouwing voor de relevantie van mijn onderzoek. Wat ziet het CROW voor toekomstige ontwikkelingen in het kader van Systems Engineering en informatie-uitwisseling? Hij heeft onderkend dat dit topic nu erg hoog in het vaandel staat (Bouw Informatie Raad). Om in de toekomst de informatie-uitwisseling en communicatie te verbeteren en is hij zelf bezig met het opbouwen van een informatie model gemaakt in het kader van het project ´provinciaal contractenbuffet´. Dit project beoogt meer uniformiteit en een hoger kennisniveau voor UAVgc contracten van provincies.


Contractvormen JBR: Welke veranderingen in de contracten, samenwerking en daarmee wijze van informatie-uitwisseling kunnen onderscheiden worden? AVI: Wat betreft de provincies en waterschappen is dit ook op een andere manier geregeld. AVI: Nuancering dat Rijkswaterstaat in het verleden niet nadacht over planning van projecten. Zij maakten de keuze wel en planden vervolgens RAW projecten. Niet nagedacht is dus niet waar, maar wel waar voor bouwers, omdat zij niet “denken aan hadden staan”. Ze kregen de instructie om te bouwen en dat was het. Het ontwerp was tot in detail uitgewerkt (in de vorm van een bestek). AVI: “Meest doelmatige contract moet je zoeken”. RWS is echter gewend aan geïntegreerde contractvormen en gaat daar mee verder. Er wordt daarbij gewerkt conform de UAVGC. DE DBFM projecten zijn ook meestal op basis van UAVgc, maar dan wordt de F in een aparte (koepel)overeenkomst geregeld. UAVGC Hoewel RWS en Prorail grote opdrachtgevers zijn, moet niet vergeten worden dat de gww markt veel groter is. Andere overheden besteden in totaal veel meer aan en hier wordt de UAVgc nog veel minder toegepast dan bij RWS (evenals SE, BIm ea). Sterker nog, veel gemeentes werken nog geheel niet met UAVgc en besteden veel van hun werk onderahands aan, ook vaak niet met RAW.. Nieuwe aanbestedingswet Er zijn een aantal belangrijke wijzigingen te noemen in de nieuwe aanbestedingswet. De gids proportionaliteit geeft handsvat hierbij. De belangrijkste wijzigingen zijn o.a. :   

Oneigenlijk clusteren mag niet meer; EMVI tenzij beleid; Enz (zie website CROW of die van Pianoo).

Nieuwe manieren van aanbesteden: BVP BVP (is geen contractvorm, maar een manier van denken en aanbesteden, veelal wordt hier uiteindelijk gekozen voor een UAVgc contract of iets gelijksoortigs)projecten leiden, naar het nu lijkt (let op: niet wetenschappelijk onderbouwt) te leiden tot meer oplossingsvrije contracten en goede samenwerking in projecten. Speelveld bij ontwerpkeuzes JBR: Wat is het speelveld bij ontwerpkeuzes? En welke rollen hebben daarbij tegenstrijdige belangen? AVI geeft een voorbeeld het speelveld tussen een projectleider, een ontwerpleider en een RAMS adviseur. De ontwerpleider wil een goed ontwerp maken, terwijl de projectleider zo efficiënt mogelijk wil bouwen. In zijn voorbeeld geeft hij RAMS adviseur (als nar) als oplossing om integrale ontwerpkeuze te maken, waarin de verschillende aspecten (o.a. uitvoerbaarheid, maar tevens beschikbaarheid worden meegenomen). In het figuur hieronder is dit te zien.


projectleider (GOTIK)

Ontwerpleider

RAMS (Nar)

Tabel 2

Kostenberekeningen AVI: Voor GWW kan voor het bepalen van de kosten gebruik worden gemaakt van SKK. Hiermee kunnen LCC analyses worden gemaakt. Diverse ingenieursbureaus berekenen de kosten voor opdrachtnemers op deze wijze. De levenscycluskosten van een object uitrekenen is mogelijk over de life Cycle op deze manier. Bijvoorbeeld in de kosten brug van een brug kan ontwerpvrijheid gegeven zijn. Deze ontwerpvrijheid is ruimte voor de opdrachtnemer. Andersom is de ontwerpvrijheid ook de onzekerheid van de opdrachtgever die hij in de markt weg zet. Daarbij moet een duidelijk onderscheid worden gemaakt tussen de ontwerpkeuze, waarbij de invulling wordt gegeven aan de eisen en functionaliteit. Risico’s JBR: Hoe moet men omgaan met risico’s binnen SE en het bepalen van kosten? Risico’s zijn apart weer te geven. Zij zitten niet in dezelfde kostenpot en moeten ook apart behandeld worden. KING => Relatie omgevingsmanagement met SE. Projectmanagement – contract – enz. Oplossingsvrijheid/ ontwerpvrijheid JBR: Hoe vrij is de opdrachtnemer nog in het ontwerpproces? Of wordt tijdens het aanbestedingstraject het meeste dichtgetimmerd? AVI: Bij UAVgc is het de bedoeling ontwerpwerkzaamheden te gunnen, in de praktijk is vaak weinig sprake van ontwerpwerkzaamheden (zeker niet na gunning). Trade Off JBR: In de theorie wordt bij het maken van beslissingen het woord “trade off” of “trade of matrix” genoemd? Zijn de trade-offs van de kwaliteit die ze moeten hebben? En zijn ze herleidbaar naar andere informatie? Hoe zit het met de TOM die in de BAM wijzer wordt genoemd? AVI: De BAM SE wijzer betreft een kwalitatieve trade off. Het dient als een “praatplaatje”, waarbij iedereen weet welke parameters van invloed zijn. Timo Gieling (oud voorzitter van INCOSE) heeft voor cofely meerdere modellen gemaakt, kwalitatief en kwantitatief, wellicht goede bron. Bijlagen Thesis Jeremy de Bruijn_5-12-2013 56

 

Verschillende niveaus => wetenschappelijke naam is MCA Trade off betekent letterlijk: maak een keuze (onderhandel)

JBR: Wat is de relatie tussen ontwerpkeuzes met behulp van trade offs en informatie management? AVI: Informatie management zegt: traceerbaarheid van eisen, maar het is meer dan dat. Het betreft traceerbaarheid van informatie. AVI: “Je wilt historie vasthouden”. Een keuze dient men te motiveren en naderhand dienen de overwegingen die tot een keuze leiden terugvindbaar te zijn. AVI: “Bedrijven kunnen hun productencatalogus expliciet beschrijven en middels trade-offs kijken welk product het beste past bij de vraag”. De productencatalogus wordt actueel gehouden door kennismanagement. Sommige producten worden door opdrachtgevers voorgeschreven, bijvoorbeeld vanwege projectoverschrijdende invloeden. Neem IBA die het type spoor voorschrijft, de constructie wellicht niet. AVI: Een ander idee/ ontwikkeling is de morfologische box ipv brainstorm. Of productvergelijk ernaast houden. MB genereert oplossingen (refereert aan artikel dat hij later heeft gestuurd). In het geval van de GWW markt: vs verschillende functionaliteiten AVI: Het kennismanagement komt op deze manier in één systeem. Met SE is onderzoek te doen: “wat is de staat van”…

Basisfunctie

• Ondersteunende functie: onderhoudsvriendelijk

Verbinding • "Kwaliteit wordt verbeterd tussen A en B"

Oplossing • Kunstwerk is 20 jaar onderhoudsvrij (groot onderhoud)

Uiteindelijk met TOM’s ook de bedoeling. Eisen bij ontwerpkeuzes van een object JBR: Welke eisen veranderingen/ komen erbij later in het ontwerpproces? AVI: denk aan de “BIM gedachte”: hier wordt het object centraal gemanaged. Wat is interessant om te weten? Vb. gebruikerseisen. Als er eisen bijkomen => vooral gebruikseisen en procesmatige eisen. JBR: Wanneer ga je uit het abstracte? AVI: Ligt eraan. Uiteindelijk moet je de constructie bouwen en daarna ook nog wegdek zelf (verder detailleren). Opl =


Concept  Type  opl € AVI: Zie aangepast V-model. AVI: Vanuit aanbestedingsleidraad: “vraag moet voldoende bepaald zijn”. Oftewel, je kunt niet alles overgeven aan de markt. Wijze van specificeren en formuleren eisen JBR: Uit de literatuur blijkt dat men waar mogelijk functioneel (oplossingsvrij) zal specificeren. De praktijk laat echter zien dat beperkt functioneel gespecificeerd wordt (bron: Kluis, 2012). Welke ontwikkelingen zijn in dit gebied? AVI: Op dit moment worden meer positief geformuleerde eisen gesteld (ipv voorheen: wat ze NIET wilden). Die waren gefocust op faalgedrag geënt. RWS/ IBA doen hier goede ervaringen mee op. JBR: hoe ervaren opdrachtnemers de wijze van specificeren en het ontvangen van informatie (in de vorm van vraagspecificatie)? AVI: Opdrachtnemers geven aan dat de algemene trend bij informatie-uitwisseling te weinig informatie voorhanden is. Voorbeelden zijn CFE/ BAM/ Dura Vermeer. De opdrachtgever en opdrachtnemer hebben een “informatie gap” te dichten, omdat de opdrachtgever veel langer in het traject al is betrokken. AVI: De aanvulling op de informatie-uitwisseling kan worden gevonden door een extra deel in de vraagspecificatie op te nemen. Dit zou deel 0 worden. In het provinciaal contractenbuffet zijn hierin de verwachtingen, wat willen ze bereiken en het onderdeel binnen het contract te vinden. In deel 0 staat dus de aanleiding. A la RWS (Verschillende model contracten) SE vs. Eisenmanagement AVI geeft aan dat doorgaans binnen SE enkel het eisenmanagement wordt opgezet, maar “alleen eisen

management systeem inrichten is niet genoeg”. De vraag is: “Wat is (nog) relevant en wat niet? Wat benadrukt wat? “ In de vorm van ICT componenten kan de informatie hiervan eruit gehaald worden. De data kan in een

informatie management systeem geplaatst worden, omdat ze expliciet werken  Voorbeelden van dergelijke systemen zijn Doors/ Cradle/ Relatics Typering van eisen JBR: hoe is de consensus over typering van eisen? Wat houdt RWS aan? Vb. functioneel, Niet-functioneel en randvoorwaarden? Vb. Raakvlakeisen, proceseisen, raakvlakeisen? AVI: Vier belangrijke type eisen met eigens karakter: a) Functie eisen = niet onderhandelbaar; b) Aspect eisen; toegevoegde waarde (vb. beschikbaarheid kun je “ab” noemen, zodat je queries kunt maken) = onderhandelbaar – EMVI op; Bijlagen Thesis Jeremy de Bruijn_5-12-2013 58

c) Raakvlakeisen; intern en extern (** Gaat fout bij opknippen in wegvakken of disciplines**) d) Proceseis; hoe doe je dingen = onderhandelbaar – EMVI op; e) Objecteis = eigenlijk geeft dit eigenschappen waar een object aan moet voldoen = gekozen eis oplossing AVI: Een voorbeeld is het hamburgermodel, wat binnen Nederland door van Leo van Ruijven wordt toegepast. De eis is hierbij de verbindende schakel.

d1

d3 -->

d2

Voorbeeld van AVI: lezer wil bovenstaande “view” in context zien. Terwijl je in informatie management blok d1 en d2 definieert en de relatie vastlegt met d3. Er is dus een verschil tussen presentatie en de wijze waarop informatie kan worden vastgelegd. In de context van SE is de informatie in elementen (data) en relaties vastgelegd. Informatiemanagement: Structuren in SE JBR: De theorie in SE heeft het over “zuivere” structuren en verschillende typen structuren. Wat zijn de ervaringen van CROW met structuren? AVI: “Heb je ooit een goede set bomen gezien” die een relatie heeft met FBS? JBR: nee AVI: Vanuit wat komt het? Kan ook vanuit de brug komen (met stuk reverse engineering), maar dat moet dan wel vastleggen. Let daarbij op dat niet alle elementen hiërarchische structuren hoeven te zijn. JBR: De vraagspecificatie bevat al structuren (bijvoorbeeld FBS, SBS, RBS). Is het de opdrachtgever die in eerste instantie tot een bepaald detailniveau invulling geeft aan de elementen? AVI: In het begin vult de opdrachtgever het model. Data is hetzelfde. Vraag om afweging. Productencatalogus. Op verschillende niveaus data management (niet tot op detailniveau). Traditioneel was dit de functie van de KAM manager. Irt EMVI: Andersoortige relaties *** Advies AVI: “Maak eens zelf eens een MS acces database. Wat hoort erbij en wat nog meer? (Sets van data). Logische structuur aanbrengen (LEAN)”. Achterhoofd houdend met de volgende elementen:  Waarom ontstaat die informatie?  Hoe komt die eruit? Bijlagen Thesis Jeremy de Bruijn_5-12-2013 59

 Afhankelijkheid anders? Praktijk werkt heel divers. Moeilijk om te testen, omdat iedereen anders werkt. JRB: Waarom is dat zo? AVI: Omdat het belang + denken anders kan zijn. Andere basis van de keuzes. In de sfeer voor ON met dergelijke triggers moet je het model motiveren. Data niet anders, maar de relaties mogelijk wel. “Parameter voor de afweging”. Wat leg je vast? Vb. tijdig betaald: relevante parameter? TOM’s hebben namelijk iteratieslagen. Verschillende boomstructuren JBR: In de literatuur is verschillende informatie over boomstructuren te vinden. Is consensus over boomstructuren? AVI: nee, boomstructuren zijn om het eenvoudiger te maken en met die gedachte kies je wel/ niet voor bepaalde structuren. Bijvoorbeeld enkele structuren vanuit object bezien:    

Planningboom Kostenboom Functieboom Locatieboom: hoe deze boom? GIS

Locatie ivm“Externe relevante bronnen” Taal voor SE AVI: Om informatie te structureren is een gemeenschappelijke taal nodig. CROW heeft gewerkt aan een objectenbibliotheek voor de gww, hier was gebruik gemaakt van Gellish. De STABU – Lexicon is mogelijk een interessante bron is. Nieuwe ontwikkelingen met informatie management: MBSE en BIM JBR: In de theorie wordt gesproken over Model Based Systems Engineering (MBSE). Wat zijn de verschillen tussen MBSE en SE? AVI: “MBSE is een vorm van SE, maar dat met een andere naam”. Het is een verdere uitwerking van SE, maar in de essentie is MBSE hetzelfde als SE Bij MBSE is het in iedere geval zo dat informatie in een (object gestuurd) model wordt weergegeven., a la BIM . Als je meer informatie wilt over MBSE => Avionica – ABSE => Jasper Braakhuis. BIM vs SE JBR: In de theorie is een grote opkomst van BIM te zien. Wat zijn de verschillen tussen BIM en SE? AVI: Verschil: je legt met BIM alles data vast in 1 model die gebruikers vanuit verschillende views kunne bekijken, overigens is dat ook zo met SE, zeker bij MBSE, het is amar hoe je de scope van SE ziet.. (Maar wel zuiver werken is dan het credo). Vb. van object naar OBS en WBS (het object is dan een soort data ). Het object is gerelateerd aan activiteit en een rol. De rol voert de activiteit uit, dus zit daar de dimensie tijd. De verschillende gegevens moet je uit elkaar halen, maar de relaties moet je wel goed vastleggen. Bijlagen Thesis Jeremy de Bruijn_5-12-2013 60

Dus een WBS met daarin een SBS is verkeerd. Clue van het verhaal: wat is relevant om vast te leggen? “Relevantie van bomen” => zuivere data. Dan is het eigenlijk meer een relationele database. AVI Conclusie: niet mengen van bomen + vastleggen van informatie is heel belangrijk voor het werken met elementen en relaties. Optie hiervoor is Gellish. In het kader van aspecten kun je meer denken aan lijstjes (semi hiërarchisch), omdat structuur hierin aanbrengen complex is. Traceerbaar en herleidbaar werken: nut & noodzaak

JBR: Vanuit de theorie moet informatie traceerbaar en herleidbaar zijn. Welke voorbeelden zijn vanuit andere sectoren? En binnen welke onderdelen in de civiele sector wordt al traceerbaar gewerkt? AVI: Boeiing is een goed voorbeeld van zeer goed informatie management. Tot op boutje niveau is alles traceerbaar en herleidbaar. JBR: Voorbeeld Toyota (bron: http://kassa.vara.nl/actueel/onderwerpen/onderwerp/?tx_varakassanews%5Btag%5D=toyota&cHash= 63da005e6e) en terughalen paar honderdduizend auto’s?

AVI: idem dito goed voorbeeld van traceerbaar werken. Voorbeelden binnen de civiele sector: -

Offshore MOET expliciet en transparant werken Prorail ook wettelijk verplicht volgens SE te werken ivm Cenelec norm.

Bron informatie JBR: Ik heb voor het onderzoek broninformatie van RWS en vanuit de informatie kunde aangesloten bij van Ruijven en Oostinga. AVI: Van Ruijven is al eerder de revue gepasseerd. Wat betreft de boomstructuren => zij geven alleen een representatie van het geheel. *** Advies AVI: “blijf uit boomstructuren als je niet zeker weet dat ze als een “gewone” structuur ook opgelost kunnen worden. Is voldoende om informatie te kunnen representeren en de relatie weer te geven”. *** Advies AVI: aangezien de opdrachtgever leidend is door de wijze van uitvraag zal in dit onderzoek de terminologie van RWS aangehouden worden. Om die reden worden de volgende documenten aangehouden: -

Leidraad SE V2.0 uit 2009 Handboek RWS uit 2011 (stappenplan, zie leidraad SE site)

JBR: Het informatie model is voor een deel gebaseerd op ervaringen van verschillende deskundigen die bij DBFM weginfrastructuurprojecten binnen Nederland werkzaam zijn. Dit zijn o.a. Daan Oostinga en Leo van Ruijven. AVI is bekend met deze namen en geeft aan dat zij hier druk mee bezig zijn om verder Bijlagen Thesis Jeremy de Bruijn_5-12-2013 61

te ontwikkelen. Dit sluit aan op de wijze waarop het huidige informatie model van JBR is gebaseerd en is voor JBR een interne validatie. *** Advies AVI: Zoek naar de vraag achter de vraag: “Waarom is de informatie nodig? En waar zit een relatie tussen informatie?” Om te bepalen hoe configuratie management toegevoegde waarde kan hebben zal inzichtelijk moeten zijn op welke wijze configuratie management doorwerkt tussen informatie. Conclusie Het ging in dit gesprek om zicht te krijgen op de ontwikkelingen van SE in relatie tot informatieuitwisseling. We zijn gezamenlijk erover eens dat informatie modellen nodig zijn voor de sector ter bevordering van informatie-uitwisseling en communicatie. In verband met de abstractheid van de ISO 15288 en de “overname” van SE vanuit andere sectoren hebben partijen deze methodiek op zijn/ haar eigen manier geïnterpreteerd, waarbij elke partij vanuit het oogpunt van zijn/ haar belangen en noodzakelijke informatie behoefte modellen/ werkwijzen heeft opgesteld. De wijze waarop huidige modellen zijn opgesteld betreft het belang/ noodzaak aan informatie die voortkomt uit de “views” die verschillende partijen hebben. In de context van het onderzoek binnen DBFM, waarin verschillende partijen (in de vorm van een consortium) samenwerken is uniformiteit in de context van SE gewenst. De ontwikkeling van een informatie model kan daarbij helpen. Dit kan op korte termijn helpen door te gebruiken als communicatie tussen partijen om de informatie behoefte bloot te leggen. Op de lange termijn kan een dergelijk model mogelijk geautomatiseerd worden om de informatie te ontsluiten. De randvoorwaarden bij een dergelijk model is de context waarin het model is opgebouwd. ”Niet één model is de waarheid. De context van dit onderzoek ligt binnen de GWW sector en daarbij de focus op grote weginfrastructuurprojecten. Daarbinnen is de opdrachtgever Rijkswaterstaat en zijn consortia van bedrijven de opdrachtnemers. Houdt je tot de type informatie die geldt in deze context”. Afspraken JBR: Stuurt huidige notulen en lijst op. AVI: Stuurt figuren op. Tweet A. Visser

1.

Arjan Visser @CROWarjanvisser13 augustus

Zo, leuk gesprek gehad over #SE en #informatiemangement met afstudeerder @tudelft Openen

-



Effectieve informatie-uitwisseling binnen Nederlandse DBFM weginfrastructuurprojecten

Recommend Documents