Van traditioneel ontwerpproces naar Systems Engineering
advertisement
Van traditioneel ontwerpproces naar Systems Engineering Een onderzoek naar het verminderen van knelpunten in de planstudiefase van infrastructuur projecten doormiddel van verificatiematrices volgens Systems Engineering Dhr. P. Smit Bachelor Scriptie December 2010 Colofon Titel Van traditioneel ontwerpproces naar Systems Engineering Een onderzoek naar het verminderen van knelpunten in de planstudiefase van infrastructuur projecten doormiddel van verificatiematrices volgens Systems Engineering Plaats en datum Stageperiode Omvang Bijlagen Status Enschede, 9 december 2010 mei - november 2010 33 pagina’s (exclusief bijlagen) 5 Definitief Auteur Studentnummer E-mailadres P. Smit 0155438 [email protected] Begeleiders ing. J.M. Kruitwagen Provincie Overijssel ir. A.T.A.P. Adriaansen Tauw Eerste corrector Dr. ir. R.S. de Graaf Universiteit Twente Tweede corrector Drs. J.L.M. Schretlen Universiteit Twente Organisaties Provincie Overijssel Afdeling Wegen en Kanalen Projecten (WKP) Luttenbergstraat 2 Postbus 10087 8012 EE Zwolle Tauw Sector Civiel Handelskade 11 Postbus 133 7400 AC Deventer Universiteit Twente Faculteit: Construerende Technische Wetenschappen Opleiding: Civiele Techniek Postbus 217 7500 AE Enschede 2 Samenvatting Het doel van dit onderzoek was om te inventariseren wat de belangrijkste knelpunten waren binnen het proces van de traditionele planstudiefase van projecten zoals de N34 en of een verbetervoorstel op basis van Systems Engineering deze knelpunten kon verminderen. De N34 is een provinciale weg tussen Coevorden en Hardenberg die opnieuw zal worden ingericht als een zogenaamde stroomweg. De provincie Overijssel is de opdrachtgever van het project en een combinatie van ingenieursbureaus Tauw en Goudappel Coffeng de opdrachtnemers. Het onderzoek is bij beide organisaties uitgevoerd en bestond uit een inventarisatieonderdeel en een implementatieonderdeel. In het inventarisatieonderdeel werden interviews en enquêtes afgenomen met specialisten en projectleiders van de provincie Overijssel en de combinatie van Tauw/Goudappel Coffeng. Uit dit onderdeel kwamen de volgende vier hoofdknelpunten naar voren: 1. Raakvlakken tussen specialisten: de planstudiefase vergde intensieve samenwerking tussen verschillende disciplines, maar de specialisten werkten geregeld langs elkaar heen. 2. Structurering van informatie: informatie over het project werd onvoldoende gestructureerd, waardoor belangrijke informatie soms maar deels werd meegenomen bij beslissingen. 3. Interpretatie van de vraagspecificatie: door het impliciete karakter van de vraagspecificatie was het moeilijk voor opdrachtgever en opdrachtnemer om af te stemmen wat men werkelijk van elkaar verwachtte, dat leidde ondermeer tot onnodige ontwerpherzieningen. 4. Moeilijke herleidbaarheid van eisen: de eisen die werden gesteld aan een te ontwerpen weg of een te ontwikkelen rapportage waren veelal moeilijk herleidbaar. De methode Systems Engineering was gekozen om de ondervonden knelpunten te verminderen. Systems Engineering is een specificatie- en ontwerpmethode die sinds de jaren negentig haar opmars maakt in de Nederlandse bouw- en infrastructuurwereld. Systems Engineering speelt in op het beheersbaar, gestructureerd en transparant maken van complexe projecten. De ondervonden knelpunten uit het inventarisatieonderzoek hadden voornamelijk betrekking op het structureren en beheren van informatie over het project en tussen de disciplines. Binnen Systems Engineering wordt het structureren en beheren van informatie vormgegeven door verificatiematrices gevuld met eisen die samen de oplossingsruimte bepalen en afspraken vastleggen. Als verbetervoorstel is daarom gekozen voor deze oplossing. Binnen het implementatieonderdeel is er eerst een format voor een verificatiematrix ontwikkeld en onderbouwd op basis van de theorie van Systems Engineering. Daarna is het verbetervoorstel toegepast voor een aspect van het project N34. De uitgangspunten voor het implementatieonderdeel waren het vinden van een goede balans tussen de theorie van Systems Engineering en de functionele toepasbaarheid voor in de praktijk. De resultaten van het implementatieonderzoek waren dat de toepassing van het verbetervoorstel de ondervonden knelpunten in het proces van de planstudiefase van de N34 grotendeels konden verminderen. De projectinformatie was beter gestructureerd en de behoefte van belanghebbenden kon explicieter worden overgebracht. Daarnaast waren de eisen (beter) herleidbaar naar bronnen en bovenliggende en onderliggende eisen én specialisten konden elkaar beter onderling een expliciete ‘deelopdracht’ meegeven. Door de vermindering van de hoofdknelpunten wordt verwacht dat het proces van de planstudiefase in de toekomst minder te maken zal hebben met o.a. vertragingen en budgetoverschrijdingen. Dat de knelpunten niet in het geheel werden verminderd, werd veroorzaakt door afwegingen die zijn gedaan aan het verbetervoorstel om de balans met de praktische toepasbaarheid te behouden. De afwegingen zijn mogelijk van tijdelijke aard. De aanbevelingen voor de provincie Overijssel en Tauw/Goudappel Coffeng waren vooral gericht op de toekomst. Daarbij was aandacht voor het ontwikkelen van één technische taal voor Systems Engineering, waarbij kennis en ervaring uitwisselbaar en toepasbaar zal zijn voor toekomstige projecten. 3 Voorwoord Na een interessant project op de universiteit waarbij gebruik werd gemaakt van de Systems Engineering methodiek, sprak een bachelor opdracht rondom dit onderwerp mij erg aan. Mede door deze interesse ben ik uiteindelijk terecht gekomen bij de provincie Overijssel en Tauw, waar ik een onderzoek heb mogen uitvoeren over de implementatie van Systems Engineering rondom het project van de herinrichting van de N34. Het komt niet vaak voor dat bij twee verschillende organisaties een bachelor opdracht wordt uitgevoerd. Dit maakte de stage voor mij extra interessant, maar soms ook complex. Deze scriptie is de uitkomst van vijf maanden hard werken. Het was een interessante tijd waarin ik veel heb geleerd en veel ervaring heb opgedaan. Er zaten af en toe wat hobbels op de weg, maar uiteindelijk zijn deze overwonnen en presenteer ik met trots mijn scriptie. Graag wil ik enkele mensen bedanken die belangrijk waren tijdens de uitvoer van de opdracht. Allereerst wil ik Joost Kruitwagen van de provincie Overijssel en Rogier Adriaansen van Tauw bedanken voor hun begeleiding en de vele interessante gesprekken die we onderling hebben gehad. Zij hebben mij verder geholpen op momenten dat ik even vastzat en zij hebben mij inzicht gegeven om dingen van verschillende kanten te belichten. Daarnaast hebben zij mij een kijkje gegeven in de wereld van de civiele techniek en hebben mij daardoor ook op een breder terrein kennis bijgebracht. Daarnaast wil ik projectleider Maurice Lunenborg van de N34 bedanken voor tevens de vele interessante gesprekken en zijn hulp bij het onderzoek. Ook wil ik mijn voormalige collega’s van de provincie Overijssel en Tauw bedanken voor hun gezelligheid, de koffieronden en de medewerking aan het onderzoek. Vanuit de universiteit wil ik dhr. De Graaf bedanken voor zijn begeleiding, zijn advies en goede terugkoppeling. Tot slot wil ik bepaalde mensen in mijn persoonlijke omgeving bedanken, namelijk mijn ouders en vrienden voor hun interesse en mijn vriendin Roos voor haar steun en geduld. 4 Inhoudsopgave 1. 2. 3. 4. 5. 6. 7. Inleiding .................................................................................................................................................... 6 1.1. Aanleiding ....................................................................................................................................... 6 1.2. Doelstelling ..................................................................................................................................... 6 1.3. Vraagstelling ................................................................................................................................... 7 1.4. Leeswijzer ....................................................................................................................................... 7 Achtergrond Informatie ............................................................................................................................. 8 2.1. Planstudiefase ................................................................................................................................ 8 2.2. Systems Engineering ...................................................................................................................... 8 2.3. Deelconclusie en relevantie voor onderzoek ................................................................................ 13 Inventarisatie traditionele planstudiefase ............................................................................................... 14 3.1. Methode ........................................................................................................................................ 14 3.2. Resultaten inventarisatieronden ................................................................................................... 16 3.3. Typologieën .................................................................................................................................. 17 3.4. Deelconclusie................................................................................................................................ 19 Theorie verbetervoorstel......................................................................................................................... 21 4.1. Methode ........................................................................................................................................ 21 4.2. Omschrijving verbetervoorstel ...................................................................................................... 21 4.3. Theoretische onderbouwing .......................................................................................................... 22 4.4. Deelconclusie................................................................................................................................ 25 Toepassing verbetervoorstel .................................................................................................................. 26 5.1. Methode ........................................................................................................................................ 26 5.2. Kernpunten voor het opstellen van een specificatie ..................................................................... 26 5.3. Verantwoording werkwijze ............................................................................................................ 27 5.4. Deelconclusie................................................................................................................................ 29 Aanbevelingen voor organisaties ........................................................................................................... 30 6.1. Standaardisatie van definities en werkwijzen ............................................................................... 30 6.2. Overnemen van verbetervoorstel .................................................................................................. 31 6.3. Informatiepunten, kennisverspreiding en draagvlak ..................................................................... 32 6.4. Deelconclusie................................................................................................................................ 32 Conclusies .............................................................................................................................................. 33 Referenties .................................................................................................................................................... 35 5 1. Inleiding 1.1. Aanleiding Overheden zoals Rijkswaterstaat meten zich de laatste tien jaar een andere rol als opdrachtgever aan. Ze nemen meer afstand van het te ontwikkelen product en verwachten een actievere rol van de opdrachtnemer. Daarnaast worden de infrastructuur- en bouwprojecten complexer, doordat steeds meer aspecten bij de projecten worden betrokken en er een toename is van eisen vanuit belanghebbenden. De ontwikkelingen hebben tot gevolg dat grote infrastructuur- en bouwprojecten moeilijker beheersbaar worden voor zowel opdrachtgever als opdrachtnemer. Dit heeft weer invloed op de kwaliteit van het te ontwikkelen product en het proces daarvan. Mede door deze ontwikkelingen lopen projecten vertragingen op, blijven niet binnen het vastgestelde budget of sluiten niet aan op het verwachtingspatroon van de belanghebbenden. Dit vormt een belangrijke problematiek binnen de Nederlandse bouwwereld. De ontwikkelingen van een terugtredende overheid en complexer wordende projecten zijn voornamelijk externe invloeden op het proces van projecten. Het is echter onduidelijk welke knelpunten binnen het proces van de projecten de problemen van vertragingen, kostenoverschrijdingen en kwaliteitseisen veroorzaken. Het project omvorming N34 is een voorbeeld van een complex en multidisciplinair project. De N34 is een provinciale weg tussen Coevorden en Hardenberg en vervult een belangrijke functie voor de ontsluiting van het noordoosten van de provincie Overijssel en het zuidoosten van de provincie Drenthe. De provincie Overijssel wil de N34 inrichten als een stroomweg, waar veilig met 100 km per uur gereden kan worden. Bij een zogenaamde stroomweg kan het autoverkeer goed doorrijden zonder dat er vertragingen optreden door bijvoorbeeld de aanwezigheid van uitritten of rotondes en verkeerslichten. In de huidige situatie zijn er veel gelijkvloerse kruisingen (verkeerslichten) en uitritten van woningen aanwezig. Het project bevindt zich momenteel in de planstudiefase, wat onderdeel is van het MIT-traject voor grote infrastructuurprojecten. Provincie Overijssel is de opdrachtgever van het project en een combinatie van ingenieursbureaus Tauw en Goudappel Coffeng (hierna te benoemen: de combinatie) de opdrachtnemer. Zowel de provincie Overijssel als de combinatie hebben ervaring met vergelijkbare infrastructuurprojecten en ondervinden de genoemde problemen van vertragingen, kostenoverschrijdingen en discussies over kwaliteit. Het project van de N34 is daarmee een duidelijke illustratie van de maatschappelijke ontwikkelingen in Nederland van het laatste decennia. Provincie Overijssel en de combinatie geven aan dat er knelpunten zijn binnen het proces van de planstudiefase waardoor projecten worden geconfronteerd met de genoemde problemen, maar wat deze knelpunten zijn is nog onduidelijk. Om de beheersbaarheid van het project te vergroten en de problemen te verminderen hebben de provincie Overijssel en de combinatie gekozen voor de methode Systems Engineering. Systems Engineering is een gestructureerde specificatie- en ontwerpmethode die sinds de jaren negentig professioneel wordt toegepast in Nederland. Dit onderzoek is er op gericht om te onderzoeken wat de knelpunten zijn waar de planstudiefase van projecten zoals de N34 mee worden geconfronteerd en of de implementatie van Systems Engineering deze knelpunten kan verminderen. 1.2. Doelstelling Het doel van dit onderzoek is om te inventariseren wat de belangrijkste knelpunten zijn binnen het proces van planstudiefase van projecten zoals de N34 en of een verbetervoorstel op basis van Systems Engineering de belangrijkste knelpunten kan verminderen. 6 1.3. Vraagstelling Hoofdvraag: Wat zijn de belangrijkste knelpunten binnen het proces van de planstudiefase van projecten vergelijkbaar met de N34 en hoe kan de implementatie van Systems Engineering deze knelpunten verminderen? Deelvragen: 1. Wat zijn de belangrijkste kenmerken van Systems Engineering, hoe werkt de methode en welke rol speelt Systems Engineering binnen Nederland? 2. Wat zijn de belangrijkste knelpunten binnen het proces van de planstudiefase van projecten vergelijkbaar met de N34 en wat zijn de oorzaken en gevolgen hiervan? 3. Hoe zou een verbetervoorstel op basis van de theorie van Systems Engineering kunnen worden vormgegeven om de belangrijkste knelpunten in de planstudiefase te verminderen? 4. Hoe zou het verbetervoorstel kunnen worden toegepast voor het project N34 en welke afwegingen en problemen komen daarbij kijken? 5. Kan de toepassing van het verbetervoorstel de belangrijkste knelpunten in de planstudiefase verminderen? 6. Welke aanpassingen dienen te worden doorgevoerd bij de provincie Overijssel en de combinatie om de implementatie haalbaar te maken? 1.4. Leeswijzer In het hoofdstuk Achtergrond Informatie worden de termen planstudiefase en Systems Engineering uitgebreid toegelicht aan de hand van literatuur en informatie van organisaties zoals Rijkswaterstaat. Het hoofdstuk vormt een theoretische basis voor zowel het inventarisatieonderdeel als het implementatieonderdeel. Het hoofdstuk zal worden afgesloten met een beantwoording van deelvraag 1 en een opsomming van de onderdelen die relevant zijn voor het onderzoek. In het hoofdstuk Inventarisatie traditionele planstudiefase, wordt het inventarisatieonderdeel beschreven. In dit hoofdstuk worden de methoden van onderzoek, de gevonden resultaten en de hoofdknelpunten van de traditionele planstudiefase beschreven. De projecten N34 en N340 zullen als casestudy dienen. In de deelconclusie zal antwoord worden gegeven op deelvraag 2. In het hoofdstuk Theorie verbetervoorstel wordt het verbetervoorstel eerst beschreven en vervolgens vormgeven aan de hand van de theorie van Systems Engineering. Gemaakte afwegingen worden hierin toegelicht. In de deelconclusie zal antwoord worden gegeven op deelvraag 3. In het hoofdstuk Toepassing verbetervoorstel wordt beschreven hoe de toepassing van het verbetervoorstel in de praktijk vorm is gegeven en welke afwegingen daar opnieuw bij kwamen kijken. Tot slot wordt in de deelconclusie antwoord gegeven op de deelvragen 4 en 5. In het hoofdstuk Aanbevelingen wordt toegelicht welke aanpassingen binnen de organisaties van Provincie Overijssel en de combinatie nodig zijn om de implementatie van Systems Engineering mogelijk te laten maken. In de deelconclusie wordt antwoord gegeven op deelvraag 6. In de Conclusie worden de resultaten van het onderzoek bijeen gebracht en een eindoordeel gegeven over de mogelijkheid om de belangrijkste knelpunten in de planstudiefase van projecten zoals de N34 te verminderen doormiddel van de implementatie van Systems Engineering. 7 2. Achtergrond Informatie In dit hoofdstuk worden de termen planstudiefase en Systems Engineering toegelicht aan de hand van literatuur en informatie van organisaties zoals Rijkswaterstaat en ProRail. Het doel van dit hoofdstuk is om uiteen te zetten wat de belangrijkste kenmerken van Systems Engineering zijn, hoe de methode werkt en welke rol Systems Engineering speelt binnen Nederland. Daarnaast heeft dit hoofdstuk tot doel een theoretische basis te vormen voor het inventarisatieonderdeel en het implementatieonderdeel van het onderzoek. 2.1. Planstudiefase De planstudiefase maakt onderdeel uit van het Meerjarenprogramma Infrastructuur en Transport, de zogenaamde MIT-procedure van het ministerie van Verkeer en Waterstaat. De MIT-procedure is een standaard voor omvangrijke infrastructuurprojecten boven een bepaald aanbestedingsbedrag. De MIT-procedure onderscheidt een verkenningsfase, planstudiefase en realisatiefase en binnen deze fasen zes beslismomenten. De procedure geeft per fase en beslismoment aan wat de rol en verantwoordelijkheden zijn van de betrokken partijen, welke wettelijke regels van toepassing zijn en welke informatie nodig is om een beslissing te kunnen nemen (Rijksoverheid, 2010). Planstudiefase De planstudiefase van de MIT-procedure bestaat uit twee delen: (1) de planvorming waarbij een oplossing wordt gezocht voor het verkeers- en vervoersprobleem en (2) de voorbereiding voor de uitvoering (Van Netten, 2005). Binnen de planvorming worden haalbare oplossingsvarianten gegenereerd, afgewogen en de gekozen variant verder uitgewerkt. Tijdens dit proces volgen een structuurontwerp, voorlopig ontwerp en definitief ontwerp elkaar op, waarbij de oplossing steeds gedetailleerder wordt uitgewerkt. Het planvormingsproces heeft een sterk multidisciplinair karakter. Binnen het proces wordt nadrukkelijk gekeken naar zaken als inpassing, milieu, ruimtegebruik, verkeersveiligheid en economische effecten (Rijksoverheid, 2010). m.e.r. procedure Een milieueffectrapportage (m.e.r.) kan een onderdeel vormen van de planstudiefase. De m.e.r. is een procedure die tot doel heeft de milieugevolgen van plannen en projecten in kaart brengt en daarmee tracht het milieubelang volwaardig mee te laten wegen bij besluitvorming. De m.e.r. procedure wordt omschreven in de Wet Milieu Beheer. De procedure is verplicht voor plannen met een grote veronderstelde impact op het milieu of de omgeving. Europese wetgeving bepaalt welke projecten daarvoor in aanmerking komen. Het milieueffectrapport (MER) beschrijft de resultaten van de uitgevoerde onderzoeken voor de MER. In de Wet Milieu Beheer staan de eisen vermeld ten aanzien van de inhoudelijke eisen voor de MER en de eisen voor de te volgen procedure (Rijksoverheid, 2010). 2.2. Systems Engineering In deze paragraaf wordt Systems Engineering beschreven op basis van beschikbare literatuur. Daarbij wordt ingegaan op het ontstaan van de methode, het proces, de belangrijkste kenmerken en de meerwaarde. Vervolgens wordt Systems Engineering beschouwd in de context van organisaties zoals Rijkswaterstaat en ProRail. Rijkswaterstaat en ProRail hebben deels een eigen definitie en interpretatie aan de methode Systems Engineering gegeven, die meer is toegespitst op de werkzaamheden van de organisaties. De paragraaf wordt afgesloten met de beantwoording van de eerste deelvraag. 8 2.2.1. Het ontstaan van Systems Engineering De basis voor Systems Engineering ligt in de algemene systeemtheorie die is ontwikkeld halverwege de twintigste eeuw door Von Bertalanffy (Strijbos, 1988). Von Bertalanffy omschreef de algemene systeemtheorie als ‘het wetenschappelijk onderzoek in gehelen en totaliteit’. De algemene systeemtheorie was een nieuwe benadering in het streven naar een eenheidswetenschap, waarbij de wetenschap het systeem voorstelt dat als een geheel of totaal moest worden bezien. Vanuit de algemene systeemtheorie is het systeemdenken ontwikkeld. Systeemdenken kan worden omschreven als een doorontwikkeling van de algemene systeemtheorie (Strijbos, 1988). Van Netten (2005) omschrijft systeemdenken als een methode waarbij vanuit een holistische visie naar complexe problemen en mogelijke oplossingen wordt gekeken. Systems Engineering is een van de disciplines waarbinnen het systeemdenken wordt toegepast. Door de jaren heen is Systems Engineering verder ontwikkeld door en voor ingenieurs (Van Netten, 2005). Systems Engineering als methode is voor het eerst toegepast in de telefoniesector en daarna doorontwikkeld en toegepast in de ruimtevaart, vliegtuigbouw en de Amerikaanse defensie-industrie (Department of Defence, 2001). In de jaren negentig is Systems Engineering vanuit de Verenigde Staten overgewaaid naar Nederland. Binnen Nederland zijn Rijkswaterstaat en ProRail de grote opdrachtgevers die werken met de methode (Van Netten, 2005). 2.2.2. Omschrijving Systems Engineering Systems Engineering is de discipline van het ontwikkelen van producten en processen, waarbij alles wordt bekeken vanuit het perspectief van het totaalsysteem en het belang van alle aspecten zorgvuldig wordt afgewogen (INCOSE, 2006). Deze definitie voor Systems Engineering is afkomstig van het International Council on Systems Engineering (INCOSE). INCOSE is een toonaangevende organisatie op het gebied van kennisvorming over Systems Engineering (Van Netten, 2005). INCOSE (2006) benadert Systems Engineering als een discipline. Systems Engineering is niet alleen een stappenplan, maar een denkwijze (Van Netten, 2005). Met het totaalsysteem perspectief bedoeld INCOSE dat het te ontwikkelen product of proces wordt bezien als een groot systeem en kan worden onderverdeeld in elementen die onderling interactie ondervinden. Deze omschrijving komt overeen met de gedachte van de algemene systeemtheorie en het systeemdenken. Verder beschrijft INCOSE (2006) dat Systems Engineering zorgvuldig een afweging maakt tussen het belang van diverse aspecten. Deze aspecten kunnen de behoefte van de opdrachtgever of andere belanghebbenden zijn of de beperkingen ten aanzien van wetgeving of techniek (Ter Huerne & Veenvliet, 2007). Systems Engineering concentreert zich op het vroegtijdig specificeren van een behoefte en het helder krijgen van het probleem (Bahill & Dean, 2005). Het proces van Systems Engineering ontwikkelt een pakket aan klantwensen en eisen dat vervolgens op een transparante en navolgbare wijze wordt omgezet in (systeem) producten en procesbeschrijvingen (Van Netten, 2005). Systems Engineering is voornamelijk geschikt voor complexe, unieke en multidisciplinaire projecten zoals grote infrastructuur- en bouwprojecten (Martin, 1997). 2.2.3. Het proces van Systems Engineering Bahill & Dean (2005) onderscheiden vijf belangrijke processtappen binnen de methode Systems Engineering: (1) het expliciet specificeren van eisen waaraan een te ontwikkelen product of proces dient te voldoen, (2) het op een gestructureerde wijze ontwerpen van een passende oplossing aan de hand van deze opgestelde specificatie, (3) het realiseren van deze oplossing, (4) het verifiëren en 9 valideren en (5) het onderhouden van de gerealiseerde oplossing. De Systems Engineering methode werkt van abstract naar concreet, waarin de genoemde processtappen iteratief worden toegepast in verschillende ontwikkelfasen (Bahill & Dean, 2005). Een andere veelvoorkomende procesbeschrijving van Systems Engineering komt van Martin (1997) en gaat uit van de volgende drie fundamentele processtappen binnen Systems Engineering: (1) eisenanalyse, (2) functionele analyse en allocatie en (3) ontwerp synthese. Bahill & Dean (2005) beschrijven met hun vijf processtappen de gehele levenscyclus van Systems Engineering. Martin (1997) richt zich met zijn drie processtappen voornamelijk op het specificatie- en ontwerpproces en de gelaagdheid daarbinnen, waarbij het te ontwikkelen systeem wordt ontrafeld in subsystemen en elementen. Om een volledig beeld van werking van de methode Systems Engineering te krijgen, zal eerst worden ingegaan op het brengen van gelaagdheid binnen het systeem, waarbij de termen decompositie en integratie worden geïntroduceerd. Vervolgens zal het proces van Bahill & Dean (2005) worden beschreven, waarbij voornamelijk zal worden ingegaan op de processen van specificatie, ontwerp en verificatie en validatie. Decompositie Decompositie is het opdelen van het project in overzichtelijke onderdelen of niveaus, met als doel de complexiteit van het project terug te brengen en het project beheersbaar te houden (Van Netten, 2005). De onderdelen of niveaus worden gezien als subsystemen binnen het hoofdsysteem van het totale project. Deze gedachte sluit aan op het systeemdenken. Decompositie kan ondermeer worden vormgegeven in een niveauopdeling, geografische opdeling, activiteitenopdeling en functionele opdeling (Van Netten, 2005). Het opnieuw verbinden van afzonderlijke onderdelen of elementen tot een nieuw geheel wordt binnen Systems Engineering gedefinieerd als integratie of synthese (Martin, 1997). Systems Engineering hecht veel aandacht aan de inhoudelijke verbindingen tussen de subsystemen of onderdelen van het totaalsysteem, als gevolg van decompositie. Deze verbindingen worden omschreven als interne raakvlakken. Systems Engineering kent ook de term externe raakvlakken en deze worden beschreven als inhoudelijke verbanden tussen het systeem en zijn omgeving (INCOSE, 2006). De raakvlakken worden gedetailleerd omschreven en vormen een belangrijk onderdeel van de specificatie. Raakvlakken tussen subsystemen, of raakvlakken tussen een totaalsysteem en zijn omgeving, zijn vaak de oorzaken van problemen. Het ene systeem dient aan te sluiten op het andere, maar de systemen worden apart van elkaar ontwikkeld en dat vormt een risico wanneer de systemen in elkaar worden gepast (Van Netten, 2005). Specificatie en ontwerp Bahill en Dean (2005) maken onderscheid tussen het eerst specificeren van de eisen waar een te ontwikkelen product of proces aan dient te voldoen (processtap 1) en het vervolgens ontwerpen van een passende oplossing aan de hand van de specificatie (processtap 2). Deze splitsing tussen specificatie en ontwerp is een belangrijk kenmerk van Systems Engineering (Van Netten, 2005). Specificeren wordt gedefinieerd als het formuleren en vervolgens geordend vastleggen van eisen en functies die gezamenlijk bepalen waar een te ontwikkelen product of proces (of onderdeel daarvan) aan dient te voldoen. Ontwerpen wordt beschouwd als het proces om tot een optimale oplossing te komen binnen de kaders van de specificatie (Van Netten, 2007). In de specificatiefase zijn de wensen van de klant en andere belanghebbenden uitgangspunt (Bahill & Dean, 2005). Volgens Van Netten (2005) zijn specificeren en ontwerpen parallel lopende processen waarbij steeds voor een niveau of onderdeel van het te ontwikkelen product of proces wordt gespecificeerd en vervolgens eisen gestuurd wordt ontworpen. Bij een gedetailleerder of onderliggend niveau van het te ontwikkelen product of proces vindt opnieuw specificatie en ontwerp plaats. Zo ontstaat er een proces dat leidt tot decompositie van het systeem en tot een volledige specificatie en ontwerp van het te ontwikkelen product of proces. 10 Volgens Van Netten (2005) dwingt het eerst specificeren en vervolgens ontwerpen de ontwerpers om beter na te denken over de eisen waar een te ontwikkelen product of proces aan dient te voldoen. De splitsing schept bovendien een kader waarbinnen ruimte is voor innovatie en het vaak efficiënter en doeltreffender vormgeven van een oplossing (Ter Huerne & Veenvliet, 2005). Verificatie en validatie De splitsing tussen het vooraf specificeren en vervolgens ontwerpen, realiseren of beheren van een product of proces biedt de mogelijkheid tot controle. Systems Engineering kent twee methoden van controle: verificatie en validatie. Verificatie is het proces waarbij wordt vastgesteld of de uitwerkte oplossingsvariant of gerealiseerde product of proces voldoet aan de vooraf gespecificeerde eisen. Validatie is het proces waarbij wordt vastgesteld of de uitwerkte oplossingsvariant of gerealiseerde product of proces voldoet aan de behoefte van de klant (Van Netten, 2005). Validatie gebeurt in navolging van verificatie en is een subjectievere toets. Binnen de verschillende ontwikkelfasen van Systems Engineering vindt ‘continue’ controle plaats. Met continue controle wordt bedoeld dat veelvuldig en op verschillende momenten binnen het procesverloop van Systems Engineering wordt gecontroleerd of het ontwikkelde product of proces in overeenstemming is met de vooraf opgestelde specificatie. In de toepassing van Systems Engineering kunnen de eisen van de specificatie, de gebruikte verificatiemethode en het resultaat daarvan worden omschreven in zogenaamde verificatiematrices (Van Netten, 2005). Verificatie en validatie worden binnen de literatuur ook in verband gebracht met het decomponeren en integreren (synthese) van een systeem (INCOSE, 2006). Tijdens het decomponeren spelen verificatie en validatie een rol bij het controleren of de specificatie van een bepaald niveau in lijn is met de specificatie van een onderliggend of bovenliggend niveau (INCOSE, 2006). Tijdens de integratiefase spelen verificatie en validatie een rol bij het samenvoegen van componenten en subsystemen. Deze wijze van controle wordt beschreven als ‘verticale’ controle, omdat de gelaagdheid binnen het ontwikkelproces wordt gecontroleerd. De beschrijvingen van verificatie en validatie in de voorgaande alinea wordt beschreven als ‘horizontale’ controle. Internationaal is er geen eenduidig standpunt over de termen verificatie en validatie (Van Netten, 2005). Voor dit onderzoek worden de definities van Van Netten (2005) aangenomen omdat deze overeenkomen met de veelgebruikte definitie binnen Nederland van Rijkswaterstaat. De levenscyclus als uitgangspunt De levensloop van projecten als uitgangspunt nemen is een ander belangrijk kenmerk van Systems Engineering (Van Netten, 2005). In de specificatiefase worden daarom eisen en functies meegenomen voor het kunnen onderhouden van het product gedurende de gehele levenscyclus en de sloop. De term levenscyclus wordt ook gebruikt als een aanduiding voor de verschillede fases waarin het te ontwikkelen systeem zich bevindt. De output van elke levenscyclusfase is de input voor een opeenvolgende levenscyclusfase (Martin, 1997). 2.2.4. Systems Engineering werkwijze Systems Engineering wordt gekenmerkt door expliciet formuleren en een gestructureerde werkwijze (INCOSE, 2004). Expliciet formuleren wordt omschreven als het zodanig formuleren dat niets kan worden geïmpliceerd of slechts gesuggereerd blijft van wat wordt bedoeld (Van Dale, 2004). Controle in de vorm van verificatie en validatie kan niet goed plaatsvinden wanneer eisen niet expliciet zijn omschreven, omdat een eis dan op meerdere manieren te interpreteren valt (Van Netten, 2005). Daarom speelt de expliciete werkwijze voornamelijk binnen de specificatiefase een belangrijke rol, zodat de vervolgfases van ontwerp en realisatie correct en toetsbaar uitgevoerd kunnen worden. De gestructureerde werkwijze binnen Systems Engineering wordt vorm gegeven door een werkwijze waarbij afwegingen, keuzes, definities, wijzigingen en afspraken worden vastgelegd zodat er zo min 11 mogelijk onzekerheden en onduidelijkheden optreden. Het gestructureerd werken is een vorm van informatiebeheersing en vindt gedurende het gehele proces van Systems Engineering plaats (Martin, 1997). 2.2.5. Meerwaarde van Systems Engineering Diverse onderdelen van Systems Engineering zijn niet nieuw en draaien al een langere tijd mee in ondermeer de civiele wereld (Van Netten, 2005). Een functionele analyse of decompositie zijn daar voorbeelden van. Het nieuwe van Systems Engineering is dat al deze onderdelen samen worden gebracht onder één procesmodel en dat daarmee een methode ontstaat dat complexe projecten beheersbaar kan houden van begin tot afronding van het project. In de literatuur wordt verder ingegaan op de meerwaarde van Systems Engineering: Honour (2004) geeft aan dat Systems Engineering leidt tot een verzwaring van de eerste fase van het ontwikkelproces van een project, maar dat de methode over de gehele projectcyclus leidt tot een vermindering van: (1) de totaalinspanning, (2) de totale ontwikkelkosten en (3) het aantal ontwerpwijzigingen gedurende het proces. Martin (1997) voegt hieraan toe dat de toepassing van Systems Engineering leidt tot: (4) een betere aansluiting op de eisen van de opdrachtgever en (5) het opleveren van een beter kwalitatief product. 2.2.6. Systems Engineering in Nederland Rijkswaterstaat en ProRail hebben deels een eigen definitie en interpretatie aan de methode Systems Engineering gegeven, die meer is toegespitst op de werkzaamheden van de eigen organisaties. De organisaties beschrijven Systems Engineering in essentie als een gestructureerde specificatie- en ontwerpmethode. Systems Engineering heeft daarbij tot doel structuur te geven aan en inzicht te verschaffen in de complexiteit van het te realiseren object. Met behulp van Systems Engineering kunnen risico’s die ontstaan door verkeerde of niet volledige informatie en uitgangspunten worden beheerst. Belangrijk is dat het systeem als totaal wordt beschouwd, over de gehele levenscyclus, inclusief de samenhang met zijn omgeving. Systems Engineering biedt een geïntegreerde en gestructureerde set methodieken om projecten succesvol te verwezenlijken en te beheren. Voor Rijkswaterstaat en ProRail is Systems Engineering een methode om enerzijds een groot deel van het ontwikkelproces uit te besteden aan de markt en anderzijds toch beheersbaarheid te houden op de gewenste uitkomt. Dit is voornamelijk mogelijk door de top-down benadering van Systems Engineering in combinatie met de expliciete controle bij de processen van decompositie en integratie. De opdrachtgever formuleert een oplossingskader doormiddel van topfuncties en topeisen en de opdrachtnemer specificeert deze gedetailleerder en ontwikkeld een (eisen gestuurde) oplossing. De opdrachtnemer past daarbij continue controle toe, zowel verticaal als horizontaal. Daarmee kan Systems Engineering inspelen op de ontwikkelingen van een terugtredende overheid, steeds maar complexer wordende projecten en de roep om transparantie en beheersbaarheid in het ontwikkelproces (Rijkswaterstaat e.a., 2007). Rijkswaterstaat en ProRail richten zich met Systems Engineering op zowel het product dat dient te worden ontwikkeld als het proces wat daar aan te grondslag ligt. Voor de toepassing van Systems Engineering voor grote infrastructuurprojecten worden daarom ook twee soorten specificaties ontwikkeld (Rijkswaterstaat e.a., 2007). Er worden inhoudelijke eisen opgesteld die gelden voor het uiteindelijk op te leveren (fysieke) product en er worden proceseisen opgesteld. Proceseisen worden binnen Systems Engineering omschreven als eisen aan activiteiten die nodig zijn om het systeem of product tot stand te brengen (Rijkswaterstaat e.a., 2007). 12 2.3. Deelconclusie en relevantie voor onderzoek Dit hoofdstuk had tot doel om uiteen te zetten wat de belangrijkste kenmerken van Systems Engineering zijn, hoe de methode werkt en welke rol Systems Engineering speelt binnen Nederland. Daarnaast diende dit hoofdstuk een theoretische basis te vormen voor het inventarisatieonderdeel en het implementatieonderdeel van het onderzoek. Systems Engineering is een specificatie- en ontwerpmethode voor het ontwikkelen van producten en processen, waarbij alles wordt bekeken vanuit het perspectief van het totaalsysteem en het belang van alle aspecten zorgvuldig wordt afgewogen. Systems Engineering heeft tot doel structuur te geven aan en inzicht te verschaffen in de complexiteit van een te realiseren systeem. Systems Engineering is een van de disciplines waarbinnen het systeemdenken wordt toegepast. De belangrijkste kenmerken van Systems Engineering zijn: 1. Het systeemdenken en decompositie: een te ontwikkelen project, product of proces wordt binnen Systems Engineering benaderd als een systeem. Dat systeem kan worden opgedeeld in overzichtelijke onderdelen of niveaus en dat wordt decompositie genoemd. Decompositie van het systeem heeft als doel de complexiteit terug te brengen en het totaalsysteem beheersbaar te houden. Het systeem heeft raakvlakken met de omgeving en tussen de systeemelementen. 2. Het proces van specificatie, ontwerp en (continue) controle: de essentie is dat eerst wordt specificeert waar een te ontwikkelen product of proces aan dient te voldoen, vervolgens wordt het product of proces ontworpen aan de hand van de specificatie en uiteindelijk vindt er een controleslag plaats waarin wordt vastgesteld of het product of proces voldoet aan de vooraf opgestelde specificatie. Continue controle is van toepassing omdat op meerdere momenten in het proces wordt gecontroleerd. Controle vindt plaats met behulp van verificatiematrices. 3. De levenscyclus als uitgangspunt: Systems Engineering kent hier enerzijds een inhoudelijke benadering, waarin de methode aandacht heeft voor het opstellen van voorwaarden en prestaties ten aanzien van de gehele levensloop van het product of proces. Systems Engineering onderscheid anderzijds een procesmatige benadering van de levenscyclus waarin het van toepassing is op alle levensstadia van het project. Van ontwerp tot realisatie en sloop. Systems Engineering wordt gekenmerkt door expliciet formuleren en een gestructureerde werkwijze. Systems Engineering is voornamelijk geschikt voor complexe, unieke en multidisciplinaire projecten zoals grote infrastructuur- en bouwprojecten. Systems Engineering leidt tot een verzwaring van de eerste fase van het ontwikkelproces van een project, maar over de gehele projectcyclus leidt de methode tot een vermindering van de totaalinspanning, de totale ontwikkelkosten en het aantal ontwerpwijzigingen gedurende het proces. Binnen Nederland geven o.a. Rijkswaterstaat en ProRail vorm aan de ontwikkeling en standaardisering van Systems Engineering. Systems Engineering speelt binnen Nederland in op de ontwikkelingen van een terugtredende overheid, steeds maar complexer wordende projecten en de roep om transparantie en beheersbaarheid in het ontwikkelproces. Relevantie voor onderzoek Het onderzoek is opgebouwd in een inventarisatiefase en implementatiefase. In de inventarisatiefase zal onderzoek plaatsvinden naar knelpunten binnen het proces van de traditionele planstudiefase, waarbij wordt gekeken naar planstudiefases van projecten vergelijkbaar met de N34 en waarbij geen gebruik wordt gemaakt van de methode Systems Engineering. In de implementatiefase van het onderzoek zal Systems Engineering worden geïmplementeerd voor het project N34. De planstudiefase van het project N34 is voorbeeld van een complex, uniek en multidisciplinair project. Voor het project N34 dient tevens een MER te worden opgesteld. De processtappen van specificeren, ontwerpen en controleren en decompositie zullen worden geïmplementeerd voor het project N34 en er wordt gekeken of de ondervonden knelpunten uit de inventarisatiefase kunnen worden verminderd door de methode Systems Engineering. 13 3. Inventarisatie traditionele planstudiefase In dit inventarisatieonderdeel van het onderzoek is gekeken naar de knelpunten binnen het proces van de planstudiefase van multidisciplinaire infrastructuurprojecten zoals de N34. Tijdens de inventarisatie wordt onderzocht waar in het proces deze knelpunten zich bevinden, wat de oorzaken en gevolgen daarvan zijn en welke knelpunten als belangrijkste worden ondervonden. 3.1. Methode In het onderzoek is gekeken naar planstudiefases van multidisciplinaire infrastructuurprojecten die op de traditionele wijze zijn uitgevoerd, daarmee wordt bedoeld: zonder implementatie van Systems Engineering. Enkele voorbeeldprojecten waren: de omvorming van de N34 en N340. Organisaties Het onderzoek is uitgevoerd bij de provincie Overijssel en de combinatie. Voor deze organisaties is gekozen omdat zij continue planstudiefases van multidisciplinaire infrastructuurprojecten zoals de N34 en N340 doorlopen. Daardoor hebben deze organisaties veel kennis en ervaring opgedaan met deze projecten en de knelpunten die daarbij kwamen kijken. Er is voor een inventarisatie bij beide organisaties gekozen omdat dan een vollediger beeld van de problematiek kon worden verkregen. In bijlage 2 is aanvullende informatie te vinden over de organisaties van de provincie Overijssel en de combinatie. Onderzoeksstrategie Onder een onderzoeksstrategie wordt verstaan het geheel met elkaar samenhangende beslissingen over de wijze waarop het onderzoek wordt uitgevoerd. (Verschuren & Doorewaard, 2007) Er kunnen een vijftal strategieën worden onderscheiden, namelijk: (1) survey, (2) experiment, (3) casestudy, (4) gefundeerde theoriebenadering en (5) bureauonderzoek. Volgens Verschuren en Doorewaard (2005) bepalen drie kernbeslissingen de afweging voor een onderzoeksstrategie: 1. Breedte versus diepgang 2. Kwalitatief versus kwantitatief onderzoek 3. Empirisch versus bureauonderzoek Bij de eerste afweging is gekozen voor diepgang. Er zijn onvoldoende mogelijkheden om een breed scala aan planstudiefases van projecten te onderzoeken. Bovendien geeft een diepgaand onderzoek meer inzicht in de achtergronden en de oorzaken en gevolgen van de knelpunten. Bij de tweede afweging is gekozen voor een kwalitatief onderzoek. Opnieuw is bij deze keuze van belang dat er inzicht wordt verkregen in de achtergronden van het project en de knelpunten. Bij de derde afweging is gekozen voor empirisch onderzoek. In het implementatieonderdeel van het onderzoek wordt namelijk Systems Engineering voor het project N34 toegepast en daarom is het juist van belang om projecten zoals de N34 te onderzoeken. Momenteel is er onvoldoende specifieke informatie over dit soort projecten beschikbaar voor het uitvoeren van een bureauonderzoek om de knelpunten te achterhalen. Voor het inventarisatieonderdeel dient er dus een diepgaand, kwalitatief en empirisch onderzoek plaats te vinden en daarom is gekozen voor een (meervoudige) casestudy als onderzoeksstrategie. Een voordeel van een casestudy is dat het de mogelijkheid biedt om een integraal beeld te vormen van het onderzoeksobject. Hierin wijkt de casestudy af van een survey en experiment. Het integrale beeld kan een voordeel zijn voor een onderzoek dat is gericht op een verandering van een bestaande situatie, zoals bij dit onderzoek. Een ander voordeel van een casestudy is dat het gegevens oplevert die meer herkenbaar zijn en beter geaccepteerd worden dan in een survey. De acceptatie door de ‘mensen in het veld’ is vaak een voorwaarde om een daadwerkelijke bijdrage aan een 14 veranderingsproces te kunnen leveren. Een mogelijk nadeel van de casestudy is dat de externe geldigheid van de resultaten soms onder druk staan. Naarmate minder gevallen worden bestudeerd, is het moeilijker de bevindingen van toepassing te verklaren. (Verschuren & Doorewaard, 2007) Delphi-techniek Om de knelpunten in de planstudiefase te achterhalen is gebruik gemaakt van de Delphi-techniek. Deze ondervragingstechniek verloopt in meerdere interviewronden. In de eerste interviewronde worden vragen voorgelegd aan een aantal deskundigen op het gebied van het onderzoek. De respons wordt daarbij zorgvuldig geanalyseerd en de grote lijnen worden aangegeven. De uitkomsten gaan vervolgens terug naar de ondervraagden in de vorm van een enquête, met het verzoek aan te geven hoe ze tegen hun eigen antwoorden en de antwoorden van andere ondervraagden staan. Vervolgens worden de uitkomsten van deze tweede ronde verwerkt en kunnen conclusies worden getrokken. (Verschuren & Doorewaard, 2007) Het belangrijkste voordeel van de Delphi-techniek is dat de deelnemers tot een weloverwogen oordeel kunnen komen, waarin diverse mogelijke standpunten tegen elkaar worden afgewogen. Dit is belangrijk omdat de uitkomsten van de interviews anders losse analyses blijven waaruit moeilijk een conclusie te vormen is. Als er maar één ronde van interviews zou worden afgenomen, zou het daarnaast arbitrair zijn om te bepalen welke knelpunten als belangrijkste worden aangezien. Daarnaast biedt het alleen afnemen van een enquête onvoldoende de mogelijkheid om open te staan voor nieuwe knelpunten die tijdens de interviews naar boven komen en de interpretaties van knelpunten. Door het afnemen van een enquête kan juist worden bepaald welke knelpunten als belangrijkste worden ondervonden door de ondervraagden. Door het toepassen van de Delphitechniek kunnen beide voordelen van een interview en enquête worden behaald en daarom is voor deze methode gekozen. In bijlage 3.1 wordt dieper ingegaan is de Delphi-techniek en welke afwegingen zijn gemaakt om het onderzoek uit te voeren. 15 3.2. Resultaten inventarisatieronden In deze paragraaf worden de resultaten van de inventarisatieronden besproken. Eerst zullen de resultaten van de interviewronden worden uiteengezet, daarna van de enquêteronde. 3.2.1. Resultaten Interviews Uit de interviewronden met de ondervraagden van provincie Overijssel en de combinatie kwamen acht knelpunten met bijbehorende oorzaken en gevolgen naar voren. De ondervonden knelpunten worden weergegeven in tabel 3.1. De inhoudelijke beschrijving van de knelpunten zijn toegelicht in bijlage 3.3. De knelpunten kunnen worden gezien als stellingen, die zijn gebaseerd op de interviews. Knelpunt I Raakvlakken tussen specialisten Oorzaak Onvoldoende vastleggen (expliciet maken) wat input en output van specialisten onderling dient te zijn II Impliciete toetsingscriteria Toetsingscriteria zijn impliciet en Ontwerpfouten, daardoor kan de kwaliteit moeilijk vertraging proces, worden gewaarborgd kosten III Onvoldoende afstemming (impliciet) wat opdrachtgever en Interpretatie vraagspecialisatie opdrachtnemer van elkaar verwachten IV Herleidbaarheid ontwerpkeuzes V Structurering informatie VI Herleidbaarheid eisen VII Herleidbaarheid aanpassingen Financieel VIII schrappen in vage aspecten Gevolg Vertraging proces, oplopende kosten Aanpassingen aan producten, vertraging, kosten Onvoldoende vastgelegd waarom Opnieuw discussies, ontwerpkeuzes zijn gemaakt vertraging, kosten Veel informatie en weinig structurering daarvan Onvolledige ontwerpen en daardoor vertraging en oplopende kosten Moeilijk herleidbaar waar eisen vandaan komen Vergrootte kans bezwaarschriften, vertraging Moeilijk kunnen aantonen wat met de terugkoppeling van de opdrachtgever is gebeurd Ontwerpfouten, aanpassingen, vertraging en kosten Als aspecten vaag zijn, zoals Ambities komen ecologie kunnen ze gemakkelijker onvoldoende tot worden geschrapt uitwerking Tabel 3.1: Oorzaak-gevolg matrix Tabel 3.1 geeft de oorzaken en gevolgen van de knelpunten beknopt weer. Opvallend is dat veel knelpunten worden veroorzaakt door impliciete formulering van eisen en wensen en daarnaast onvoldoende structurering en herleidbaarheid van informatie. De gevolgen van de knelpunten zijn vertragingen in het planstudieproces, ontwerpfouten en oplopende kosten. 16 3.2.2. Resultaten Enquête Tijdens de enquête konden de ondervraagde specialisten en projectleiders 10 punten verdelen over de 8 knelpunten. De tabel met resultaten is opgenomen in bijlage 3.4. De volgende knelpunten werden als belangrijkste aangemerkt: 1. 2. 3. 4. Raakvlakken tussen specialisten Onvoldoende structurering van informatie Verkeerde interpretatie van vraagspecificatie Moeilijke herleidbaarheid van eisen Voornamelijk de bovenste drie belangrijkste knelpunten kwamen duidelijk naar voren door het hoge puntenaantal. De herleidbaarheid van eisen wordt als vierde belangrijkste knelpunt geselecteerd. Het knelpunt financieel schrappen in vage aspecten krijgt alleen punten van de twee ecologen, dat zegt dat het knelpunt lijkt te zijn gerelateerd aan een specialisme. De herleidbaarheid van ontwerpkeuzes en ontwerpaanpassingen worden niet als belangrijke knelpunten gezien. Impliciete toetsingscriteria wordt wel als een redelijk belangrijk knelpunt gezien. 3.3. Typologieën In figuur 3.2 staan de resultaten van het onderzoek ingedeeld naar groepen van generalisten en specialisten en opdrachtgever en opdrachtnemer. De aanleiding voor deze figuur is het aantonen of er grote verschillen zijn tussen de typologieën. Daarmee kunnen de resultaten beter worden geïnterpreteerd. Opdrachtnemer Opdrachtgever Specialisten Generalisten Een generalist wordt gezien als een persoon die voornamelijk met het project als geheel bezig is, zoals een projectleider of een projectmedewerker. Een specialist wordt gezien als een persoon die zich voornamelijk met één aspect bezighoudt. De opdrachtgever is provincie Overijssel en de opdrachtnemer is de combinatie. In bijlage 3.2 is uiteengezet welke ondervraagden als generalist en welke als specialist worden gezien. I Knelpunten Raakvlakken tussen specialisten 8 4 4 8 II Impliciete toetsingscriteria 4 3 4 3 III Interpretatie vraagspecificatie 9 4 4 9 IV Herleidbaarheid ontwerpkeuzes 4 0 0 4 V Structurering informatie 8 5 6 7 VI Herleidbaarheid eisen 5 5 5 5 VII Herleidbaarheid aanpassingen 2 2 4 0 VIII Financieel schrappen in vage aspecten 0 7 3 4 Figuur 3.2: Typologieën [Gebaseerd op figuur 3.4.1 in bijlage 3.4] 17 3.3.1. Generalisten versus specialisten Tabel 3.2 toont de belangrijkste knelpunten volgens de ondervraagde generalisten enerzijds en de specialisten anderzijds. De generalisten zien voornamelijk de interpretatie van de vraagspecialisatie, raakvlakken tussen specialisten en de structurering van informatie als belangrijkste knelpunten. Specialisten zien voornamelijk financieel schrappen in vage aspecten, structurering van informatie en herleidbaarheid van eisen als belangrijkste knelpunten. Generalisten Specialisten 1 Interpretatie vraagspecificatie (9) 1 Financieel schrappen in vage aspecten (7) 2 Raakvlakken tussen specialisten (8) 2 Structurering van informatie (5) 3 Structurering van informatie (8) 3 Herleidbaarheid eisen (5) Tabel 3.2: Top 3 knelpunten Generalisten/Specialisten De overeenkomt in de top 3 van beide groepen ondervraagden is het knelpunt van structurering van informatie. Het grote verschil tussen is het knelpunt van financieel schrappen in vage aspecten. Dit verschil kan worden verklaard doordat generalisten het project als een geheel aanschouwen en de specialisten het project vaak vanuit hun eigen discipline. Specialisten kunnen snel het gevoel krijgen dat juist op hun aspect wordt bezuinigd. Daarnaast is opvallend dat juist de generalisten de raakvlakken tussen specialisten als een belangrijk knelpunt ervaren, terwijl de specialisten zelf dit niet in belangrijke mate ondervinden. 3.3.2. Opdrachtgever versus opdrachtnemer Tabel 3.3 toont de belangrijkste knelpunten volgens de ondervraagde deskundigen van de opdrachtgevende partij enerzijds en de opdrachtnemende partij anderzijds. De opdrachtgever ziet voornamelijk de structurering van informatie en de herleidbaarheid van eisen als belangrijkste knelpunten. Een derde belangrijke knelpunt is moeilijk te bepalen, omdat vier knelpunten een derde plaats delen. De scores van de opdrachtgever over de knelpunten zijn redelijk verdeeld over de knelpunten. De opdrachtnemer ziet voornamelijk de interpretatie van de vraagspecificatie, raakvlakken tussen specialisten en de structurering van informatie als belangrijkste knelpunten. Opdrachtgever Opdrachtnemer 1 Structurering van informatie (6) 1 Interpretatie vraagspecificatie (9) 2 Herleidbaarheid eisen (5) 2 Raakvlakken tussen specialisten (8) 3 – (Viermaal gelijke score) 3 Structurering van informatie(7) Tabel 3.3: Top 3 knelpunten Opdrachtgever/Opdrachtnemer De overeenkomst in de top 3 van belangrijkste knelpunten tussen beide groepen is de structurering van informatie, net zoals bij het onderscheid tussen generalisten en specialisten. Het grote verschil tussen beide groepen is dat de opdrachtnemer vooral de interpretatie van de vraagspecialisatie als belangrijkste knelpunt ziet. Dit verschil met de opdrachtgever kan worden verklaard doordat de opdrachtnemer vaak degene is die moet aftasten bij de opdrachtgever wat deze nou eigenlijk wil. Daarnaast is het ook de opdrachtnemer die het product dient aan te passen, wanneer blijkt dat de opdrachtgever wat anders voor ogen had. Een ander belangrijk verschil is het knelpunt van raakvlakken tussen specialisten. Dit verschil kan worden verklaard doordat de opdrachtnemer over het algemeen intensiever moet samenwerken met verschillende specialisten, dan de opdrachtgever. De opdrachtnemer moet een product vervaardigen met verschillende specialisten en de output van de ene specialist is de input van de andere. De vele raakvlakken tussen specialisten maakt het proces complex. De opdrachtgever controleert voornamelijk de producten. Daarbij is in mindere mate samenwerking tussen specialisten en zijn er minder raakvlakken waar problemen kunnen ontstaan. 18 3.4. Deelconclusie Dit hoofdstuk had tot doel de belangrijkste knelpunten in de planstudiefase van projecten zoals de N34 te achterhalen en de oorzaken en gevolgen daarvan uiteen te zetten. Daarvoor hebben interviews en een enquête met specialisten en projectleiders van de provincie Overijssel en de combinatie plaatsgevonden. Tijdens de interviews zijn acht knelpunten naar voren gekomen, tijdens de enquête zijn de knelpunten teruggekoppeld en de vier belangrijkste geselecteerd. Voor een specifieke beantwoording van deelvraag 2, worden de vier belangrijkste knelpunten die zich voordoen in de planstudiefase van projecten zoals de N34 zijn overzichtelijk uiteen gezet met oorzaken en gevolgen: 1. Raakvlakken tussen specialisten: De planstudiefase vergt een intensieve samenwerking tussen verschillende disciplines, maar de specialisten werken geregeld langs elkaar heen. Hierdoor wordt niet de juiste informatie aan elkaar afgeleverd of te laat afgeleverd. Dit heeft weer tot gevolg dat er vertragingen in het proces ontstaan. Bij projecten zoals de N34 is dit juist een belangrijk knelpunt omdat veel specialisten afhankelijk van elkaar zijn, door het multidisciplinaire karakter van het project. De oorzaak van het knelpunt is dat specialisten elkaar niet goed informeren of te weinig communiceren, het gevolg is dat specialisten worden opgehouden door het wachten op producten van andere specialisten en daardoor het proces wordt vertraagd. 2. Onvoldoende structurering van informatie: Informatie wordt onvoldoende gestructureerd opgeslagen en verwerkt. Bij projecten zoals de N34 is dit juist een probleem omdat het project een langdurig proces is waar veel informatie wordt geproduceerd en veel verschillende belanghebbenden bij betrokken zijn. Als informatie niet goed gestructureerd is, wordt het vaak maar deels meegenomen in het project en dat heeft invloed op de kwaliteit van de producten. Een oorzaak voor het knelpunt kwam niet duidelijk naar voren, mogelijk heeft tijdsdruk een invloed. Het gevolg van het knelpunt is dat producten deels moeten worden aangepast en dat vertraagt het proces en verhoogt de kosten. 3. Verkeerde interpretatie van vraagspecificatie:Het is voor opdrachtgever en opdrachtnemer moeilijk om af te stemmen wat men van elkaar verwacht en wat elkaars interpretatie is van een vraagspecificatie. Vaak komt dit pas naar boven op het moment dat de eerste versie wordt aangeleverd. Dit knelpunt geldt in versterkte mate voor projecten zoals de N34, omdat het project zich in de planstudiefase bevindt en opdrachtgever en opdrachtnemer in bepaalde mate nog zoekende zijn naar een product en de eisen waar het aan dient te voldoen. Daardoor zijn eisen vaak minder expliciet geformuleerd waardoor er ruimte in de interpretatie ontstaat. Het gevolg daarvan is dat ontwerpen moeten worden aangepast en opnieuw een afstemming nodig is. Dit heeft uiteindelijk tot gevolg dat het proces wordt vertraagd en dat kosten oplopen. 4. Moeilijke herleidbaarheid van eisen: De eisen die worden gesteld aan een te ontwerpen weg of een te ontwikkelen rapportage zijn soms moeilijk herleidbaar. Het gevolg is dat een opdrachtgever moeilijk kan aantonen wat er met een bepaalde eis is gebeurd en of deze eis is meegenomen in het ontwerp of de rapportage. Voor projecten zoals de N34 is dit een belangrijk knelpunt, omdat de opdrachtgever (vaak politieke instantie) gehoor wil geven aan een steeds grotere roep aan transparantie naar de burger toe. Dit wordt bemoeilijkt door het moeilijk herleidbaar zijn van eisen. Het knelpunt kan leiden tot een slechtere relatie met omwonenden en mogelijk tot meer bezwaarschriften, wat een vertraging van het planvormingproces tot gevolg kan hebben. Opvallend is dat veel knelpunten worden veroorzaakt door impliciete formulering van eisen en wensen en daarnaast onvoldoende structurering en herleidbaarheid van informatie. De gevolgen van de knelpunten zijn over het algemeen vertraging van de planstudiefase en oplopende kosten. De hoofdlijn in de vier benoemde knelpunten is vooral de structurering van informatie. Alle knelpunten hebben daar in meer of mindere mate betrekking op. Bij het ontwikkelen van het verbetervoorstel dient daarom de nadruk te worden gelegd op het structureren van informatie. 19 Typologieën Tijdens het onderzoek is tevens gekeken naar typologieën. De ondervraagden zijn ingedeeld in groepen van generalisten en specialisten, en opdrachtgever en opdrachtnemer en daarbij is gekeken naar welke knelpunten zij als belangrijkste aanduiden. Bij de generalisten en specialisten viel het op dat het knelpunt van structurering van informatie bij beiden in de top drie van belangrijkste knelpunten was opgenomen. Verder waren er geen overeenkomsten. Het grote verschil tussen de generalisten en specialisten omvatte het knelpunt van financieel schrappen in vage aspecten. Daarnaast was het opvallend dat juist de generalisten de raakvlakken tussen specialisten als een belangrijk knelpunt aanmerkten, terwijl de specialisten dit knelpunt in mindere mate ondervonden. Bij de generalisten en specialisten was het knelpunt van de structurering van informatie bij beide groepen in de top drie van belangrijkste knelpunten opgenomen, net zoals bij de generalisten en specialisten. Het grote verschil tussen de opdrachtgever en opdrachtnemer was dat de opdrachtnemer de interpretatie van de vraagspecialisatie als belangrijkste knelpunt ondervond en opdrachtgever niet. Rapportage versus ontwerp In het project van de N34 zijn eigenlijk twee op te leveren producten: een planstudie MER en een omgevormde N34. Het ene product is kort gezegd een stapel papieren en het andere een weg van asfalt. De opdrachtgever ziet vooral de weg als eindproduct, de opdrachtnemer de rapportage. De opdrachtnemer is namelijk alleen ingehuurd voor de planstudie MER fase. Het gevolg hiervan is dat de insteek van personen in het project soms verschilt. Een voorbeeld is dat voor het aspect ecologie de opdrachtnemer voornamelijk kijkt naar de wettelijke toetsingskaders, zodat de MER rapportage wordt goedgekeurd. Echter wil de ecoloog van de opdrachtgever meer nieuw beleid vertaald hebben in het ontwerp. 20 4. Theorie verbetervoorstel Hoofdstuk 3 maakte duidelijk welke knelpunten binnen het proces van de planstudiefase voorkomen. Dit hoofdstuk heeft tot doel om op basis van de theorie van Systems Engineering een verbetervoorstel te ontwerpen, dat de knelpunten in het proces van de planstudiefase zou kunnen verminderen. 4.1. Methode Het verbetervoorstel op basis van Systems Engineering kan op verschillende manieren worden vormgegeven. Onderstaand wordt aangegeven welke uitgangspunten leidend zijn geweest voor het vormgeven van het verbetervoorstel: I. II. Het verbetervoorstel diende zoveel mogelijk te zijn gebaseerd op de uitgangspunten en de definities van Rijkswaterstaat. Rijkswaterstaat* is de trendgevende organisatie binnen Nederland op het gebied van Systems Engineering en heeft veel kennis en ervaring opgedaan met de methode. Daarnaast stimuleert het overnemen van de werkwijzen en definities van Rijkswaterstaat het ontstaat van één ‘technische taal’ voor Systems Engineering binnen Nederland. Daarmee wordt informatie uitwisselbaar en zijn vaardigheiden met betrekking tot Systems Engineering ook toepasbaar voor toekomstige projecten. Het verbetervoorstel diende zo praktisch en functioneel mogelijk te zijn voor de toepassing in de praktijk. Efficiëntie en draagvlak binnen de organisaties nam daarbij een belangrijke rol in. Binnen de provincie Overijssel en de combinatie heeft lang niet iedere projectwerknemer voldoende inzicht in de werking en werkwijze van Systems Engineering. Een te theoretische benadering, diende dus voorkomen te worden. Binnen de paragraaf Theoretische onderbouwing verbetervoorstel wordt specifieker ingegaan op hoe de uitgangspunten zijn vertaald in keuzes voor het verbetervoorstel. Voor het vormgeven van het verbetervoorstel zijn de volgende informatiebronnen geraadpleegd: Handreiking Functioneel Specificeren (2005) Leidraad SE voor GWW (2003)(2009) Lessons Learned (2009) *Rijkswaterstaat werkt bij de ontwikkeling van Systems Engineering nauw samen met organisaties zoals ProRail, Bouwend Nederland en CROW. Uit praktische overwegingen wordt vanaf nu alleen de organisatie van Rijkswaterstaat genoemd. 4.2. Omschrijving verbetervoorstel Systems Engineering bestaat uit een veelomvattende set methodieken die op verschillende manieren een project kunnen beheersen en structureren. Gezien de tijdsbeperkingen van dit onderzoek is het niet mogelijk om het gehele proces van Systems Engineering te implementeren. Daarom is gekeken naar onderdelen van Systems Engineering die zo effectief mogelijk de ondervonden hoofdknelpunten uit het implementatieonderzoek zouden kunnen verminderen. De ondervonden knelpunten hadden voornamelijk betrekking op het structureren en beheren van informatie over het project en tussen de disciplines. Binnen Systems Engineering wordt het structureren en beheren van informatie vormgegeven door verificatiematrices gevuld met eisen die samen de oplossingsruimte vastleggen. Keuzes, wijzigingen en afspraken kunnen tevens expliciet 21 worden vastgelegd in eisen en worden vervolgens opgenomen en beheerd in de matrix. Om deze reden is gekozen voor het opstellen van verificatiematrices als verbetervoorstel. De verificatiematrices zijn ‘levendige’ producten, die groeien naarmate het project vordert. De verschillende matrices vormen samen de specificatie van de oplossingsruimte gedurende het project. Doordat de eisen expliciet worden opgesteld (SMART), zijn ze verifieerbaar. Met de verificatiematrix kan daardoor worden vastgesteld of de ontwerpen en rapportages voldoen aan de eisen. 4.3. Theoretische onderbouwing In deze paragraaf worden de verschillende onderdelen van de verificatiematrix omschreven en onderbouwd. Het format van de verificatiematrix is hierbij opgedeeld in vier delen: (1) Specificatie, (2) Eisinformatie, (3) Verificatieplan en (4) Verificatierapport. Het gehele verbetervoorstel is opgenomen in bijlage 4.3. 4.3.1. Specificatie Een specificatie is een document met daarin een verzameling geordende eisen die samen bepalen waaraan een te ontwikkelen object of activiteit dient te voldoen. Alle specificaties samen vormen het Programma Van Eisen (PVE) voor het project (Functioneel Specificeren, 2005). De specificatie is opgebouwd uit een unieke code (ID), een onderwerp van de eis, de omschrijving van de eis en de bovenliggende en onderliggende eis(en). ID 1.1 1.1.1 Onderwerp Keren hemelwater, opvangen en afvoeren Keren hemelwater, maatgevende regenbui Specificatie Eis De verbinding dient zodanig te zijn uitgevoerd dat hemelwater op afdoende wijze wordt opgevangen en afgevoerd. De verbinding dient gedimentioneerd te zijn op een maatgevende regenbui met een hoeveelheid hemelwater van 184 l/s per hectare Bovenl. Eis 1 Onderl. Eisen 1.1.1 1.1 Geen Figuur 4.1: Voorbeeld Specificatie Aandachtspunten de beschrijving van de eis: Rijkswaterstaat hanteert het gebruik van de term ‘dienen’ voor het stellen van voorwaarden in een eis, niet ‘zullen’ en zeker niet een combinatie van beide termen. Rijkswaterstaat vermijdt daarnaast: voornaamwoorden, bijvoeglijk naamwoorden en bijwoorden, zoals: tijdig, precies, ongeveer, veel etc. gelaagdheid in de eisen: niet elke eis kan en hoeft expliciet of SMART te zijn. Een beleidseis of systeemeis kan maar zelden expliciet zijn. Beleidseisen staan vaak ten grondslag aan een visie voor het project. Impliciete eisen kunnen doorvertaald worden naar onderliggende eisen. De eisen in tabel 4.1 zijn daar een voorbeeld van: daar wordt een niet toetsbare eis expliciet gemaakt doormiddel van een onderliggende eis. Binnen het verificatieproces is de bovenliggende eis dan te verifiëren doormiddel van de onderliggende eis. Naast een specificatieboom, ontstaat op deze manier een eisenboom. Het is belangrijk om de eisen te specificeren op het juiste niveau. het nut van het weergeven van het onderwerp: organisaties buiten Rijkswaterstaat kiezen er geregeld voor om het onderwerp van de eis niet te benoemen. Binnen het verbetervoorstel is hier wel voor gekozen. Door het benoemen van het onderwerp van de eis wordt het duidelijker welke groepen van eisen te onderscheiden zijn. Dat verhelderd de structuur van de specificatie en daardoor kan beter worden gecontroleerd of de specificatie volledig is. Bovendien kunnen eisen gemakkelijker worden opgezocht in de specificatie. het nut van de bovenliggende eis: organisaties buiten Rijkswaterstaat kiezen er tevens geregeld voor om alleen de onderliggende eis te benoemen in de specificatie en niet de 22 bovenliggende eis. Hiermee wordt een belangrijk kenmerk van Systems Engineering bemoeilijkt, namelijk het traceerbaar maken van eisen vanuit het meest gedetailleerde niveau tot aan het beleidsniveau. Met het weergeven van de bovenliggende en onderliggende eisen, is elke eis te traceren en tevens te verantwoorden. tegenstrijdigheid tussen eisen: in bepaalde gevallen kunnen zich strijdigheden tussen de eisen onderling voordoen. Een voorbeeld hiervan is het behoud van bepaalde gebouwen in de omgeving versus de dimensionering van een weg. Uit het ontwerp moet blijken of aan beide eisen kan worden voldaan. Indien dit niet het geval is dient één van de eisen te worden aangepast. oplossingsvrijheid van eisen: Rijkswaterstaat hanteert het principe dat eisen zoveel mogelijk oplossingsvrij dienen te zijn. Echter geldt dit alleen voor een opdrachtgever, een opdrachtnemer zoals de combinatie dient de eisen door te vertalen naar oplossingvervullers. Zij kunnen zich dus niet beperken tot oplossingsvrije eisen. Het is wel aan te raden de eisen zo lang mogelijk in de eisenboom oplossingsvrij te houden, om toch een zoveel mogelijk innovatief en efficiënt ontwerp te ontwikkelen. de ‘knip’ tussen opdrachtgever en opdrachtnemer: binnen Systems Engineering wordt gesproken over een zogenaamde ‘knip’ tussen opdrachtgever en opdrachtnemer. Daarmee wordt verwezen naar op welk punt in de eisenboom, de verdere uitwerking van de eisen aan de opdrachtnemer wordt overgelaten. De ‘knip’ balanceert tussen het bieden van zoveel mogelijk oplossingsruimte aan de opdrachtnemer en de mate van sturing over waar de grenzen van de oplossingsruimte zich bevinden. Binnen het verbetervoorstel dient hier ook een goede balans in te worden gevonden. De provincie Overijssel moet enerzijds concreet genoeg zijn in haar eisen, zodat de combinatie de juiste oplossingsruimte kan identificeren en de eisen kan doorspecificeren. Anderzijds moet de provincie Overijssel niet teveel de oplossingsruimte beperken, zodat innovatie en efficiëntie worden bevorderd. 4.3.2. Eisinformatie De kolommen van de eisinformatie zijn formeel onderdeel van de specificatie, maar worden niet altijd weergegeven. De eisinformatie vormt de aanvullende informatie over de eis en verwijst naar een initiator, een bron, een bijlage en kwalificeert het type eis. De kolommen in de eisinformatie zijn over het algemeen alleen van belang wanneer er problemen zijn met de eisen, bijvoorbeeld wanneer eisen conflicteren. Doormiddel van de eisinformatie kan bij een conflict tussen eisen de herkomst van de eisen worden bepaald en overlegd worden met de eisinitiator(en). Eisinitiator Rijkswaterstaat Eis-informatie Bron Bijlage Nota van inlichtingen Nee d.d. 9/6/09 Type eis Functionele eis Figuur 4.2: Voorbeeld Eisinformatie Aandachtspunten: indeling in type eisen: Rijkswaterstaat hanteert in elke specificatie clusters van typen eisen. Daarbij wordt elk type eis apart benoemd in een paragraaf van de specificatie. Rijkswaterstaat onderscheid vijf typen eisen: (1) functionele eisen, (2) randvoorwaarden, (3) interne raakvlakeisen, (4) externe raakvlakeisen en (5) aspecteisen. In bijlage 4.1 staan de typen eisen toegelicht. Binnen het verbetervoorstel is niet voor gekozen voor een clustering in type eisen. Er is gekozen de eisen te rangschikken op basis van het onderwerp, zodat er clusters van gerelateerde eisen op basis van inhoud ontstaan. Deze werkwijze is meer toereikend voor het ontwikkelen van structuur en volledigheid in de specificatie. 23 minimaliseren van de randvoorwaarden: binnen de specificatie moet worden getracht de randvoorwaarden zoveel mogelijk te minimaliseren. Hiermee wordt voorkomen dat er onnodig veel vrijheidsbeperkingen in het ontwerp optreden. 4.3.3. Verificatieplan Het verificatieplan zet uiteen hoe zal worden aangetoond of aan een eis is voldaan. Het plan moet iets zeggen over de methode van toetsing, het toetsingsmoment en de toetsende persoon. Het is belangrijk om duidelijke afspraken te maken over het verificatieplan, in de praktijk komt het namelijk geregeld voor dat er onenigheid ontstaat over het aantonen of aan een eis is voldaan. (Leidraad SE, 2007) Verificatiemethode Tekening Verificatieplan Verificatiemoment Verificator Definitief Ontwerp (DO) B. Jansen Figuur 4.3: Voorbeeld Verificatieplan Aandachtspunten: verificatiemethode: hiermee wordt aangegeven hoe wordt aangetoond dat het systeem voldoet aan de eisen. Bijvoorbeeld door het maken van berekeningen, het weergeven van kaarten. In bijlage 4.2 wordt ingegaan op de verschillende typen verificatiemethoden. verificatiemoment: het moment waarop zal worden vastgesteld of aan de eis is voldaan. Dit kunnen fases in het project zijn, zoals bij afsluiting van het structuur ontwerp of voorontwerp. verificator: de persoon die het product verifieert en de bewijslast levert. 4.3.4. Verificatierapport De kolommen in het verificatierapport vormen samen de bewijslast of aan de eis is voldaan. Hierbij hoort een resultaat, een bewijsdocument, een datum, opnieuw een verificator en de te ondernemen corrigerende maatregelen wanneer niet aan een eis is voldaan. Resultaat Voldoet Verificatierapport Bewijsdocument Verificatiedatum Verificator Tekening 1-12-2010 B. Jansen hemelwaterafvoer Corrigerende maatregel Ontwerp aanpassen Figuur 4.4: Voorbeeld Verificatierapport Toelichting het dubbel voorkomen van tijdsbepaling en verificator: het verificatieplan dient onderdeel te zijn van een vooraf overeengekomen afspraak. De bewijslast zelf, het verificatierapport, dient daarom ook een tijdsbepaling en verificator aan te geven. Zo kan worden aangetoond of het verificatieplan correct is uitgevoerd en dat daarmee het resultaat van de verificatie betrouwbaar is. 24 4.4. Deelconclusie Dit hoofdstuk had tot doel om op basis van de theorie van Systems Engineering een verbetervoorstel te ontwerpen dat de knelpunten in het proces van de planstudiefase zou kunnen verminderen. De belangrijkste knelpunten uit het inventarisatieonderzoek hadden betrekking op het structureren van informatie en daarom is als verbetervoorstel gekozen voor het ontwikkelen van een matrix waarin informatie kan worden vastgelegd en beheerd doormiddel van het opstellen van eisen. Omdat de eisenmatrix ook wordt gebruikt voor verificatie, wordt binnen Systems Engineering gesproken over verificatiematrices. De structuur van de verificatiematrix is grotendeels gebaseerd op de theorie van Rijkswaterstaat. Om praktische redenen is op bepaalde punten afgeweken van Rijkswaterstaat. De gemaakte afwegingen zijn onderbouwd in het hoofdstuk. Voor een specifieke beantwoording van deelvraag 3, wordt voor elk geselecteerd knelpunten uit het inventarisatieonderzoek uiteen gezet wat de verwachte invloed is van het verbetervoorstel op de knelpunten: 1. Raakvlakken tussen specialisten: Doormiddel van een verificatiematrix op basis van Systems Engineering kunnen de raakvlakken tussen specialisten explicieter worden benoemd en beheerd. Specialisten kunnen op deze manier beter van elkaar weten welke input op welk tijdstip gewenst is. De specialisten kunnen elkaar een ‘deelopdracht’ geven. 2. Onvoldoende structurering van informatie: Informatie, ontwerpkeuzes, ontwerpwijzigingen en afspraken kunnen worden vastgelegd in eisen en worden beheerd in het verbetervoorstel. Daarnaast kan er worden bijgehouden welke documenten of gesprekken ten grondslag liggen aan de eis en wie de initiator is. 3. Verkeerde interpretatie van vraagspecificatie: Door het expliciete karakter van het formuleren van eisen en door het opstellen van onderliggende eisen, zou een verkeerde interpretatie van de vraagspecificatie nog nauwelijks voor moeten kunnen komen. Bij de toepassing van het verbetervoorstel zal het waarschijnlijk van belang zijn om de structuur van de matrix helder weer te geven, om een goed totaalbeeld te ontwikkelen van het gevraagde. 4. Moeilijke herleidbaarheid van eisen: Doormiddel van het weergeven van bovenliggende en onderliggende eis(en) kan de verificatiematrix de eisen herleiden binnen de eisenboom. Daarnaast biedt het verbetervoorstel de mogelijkheid om eisen aan elkaar en aan de bron van de eis te koppelen, zodat de eisen eenvoudig te herleiden zijn De belangrijkste knelpunten uit het implementatieonderzoek kunnen in theorie worden verminderd doormiddel van het verbetervoorstel. Het verbetervoorstel kan theoretisch leiden tot een vermindering van alle vier knelpunten. Uit de toepassing van het verbetervoorstel zal moeten blijken of de verificatiematrices daadwerkelijk de knelpunten kunnen verminderen. Bij de vormgeving van het verbetervoorstel zijn er enkele afwegingen gemaakt ten aanzien van de praktische toepasbaarheid van het verbetervoorstel. Het is de verwachting dat deze afwegingen ook voor de toepassingsfase zullen opgaan. 25 5. Toepassing verbetervoorstel Na het vormgeven van het verbetervoorstel, wordt in dit hoofdstuk het verbetervoorstel toegepast voor een aspect van het project N34. Met het toepassen van het verbetervoorstel wordt het opstellen van een specificatie met bijbehorend verificatieplan bedoeld. Het hoofdstuk heeft tot doel om uiteen te zetten hoe het verbetervoorstel kan worden toegepast en of het de knelpunten in het planstudieproces daarmee worden verminderd. In het hoofdstuk wordt tevens ingegaan op de belangrijkste uitgangspunten en afwegingen die kwamen kijken bij het opstellen van de specificaties en verificatieplannen. 5.1. Methode Uitgangspunten De toepassing van het verbetervoorstel diende (opnieuw) een goede balans te vinden tussen de uitgangspunten en de definities van Rijkswaterstaat én de functionele toepasbaarheid voor in de praktijk. Binnen de paragraaf Kernpunten voor het opstellen van een specificatie (par. 5.2) wordt specifieker ingegaan op hoe de uitgangspunten zijn vertaald in keuzes voor de toepassing van het verbetervoorstel. Voor het proces van het toepassen van het verbetervoorstel zijn de volgende informatiebronnen geraadpleegd: Handreiking Functioneel Specificeren (2005) Lessons Learned (2009) Aspect ecologie Gezien de beperkingen van tijd, was het niet mogelijk om het verbetervoorstel toe te passen op het gehele project N34. In overleg met de organisaties is daarom besloten om het verbetervoorstel toe te passen op een gedeelte van het aspect ecologie. Hiervoor waren twee redenen: 1. Binnen de combinatie kwam vaak ter sprake dat Systems Engineering alleen voor technische afdelingen toepasbaar zou zijn, maar niet voor afdelingen die minder technisch van aard zijn. Door het toepassen van Systems Engineering op het deelaspect ecologie zou mogelijk het tegendeel kunnen worden aangetoond. 2. Binnen de combinatie wilde men weten of het mogelijk was om de raakvlakken tussen een ecoloog en een MER opsteller, expliciet te maken. Op deze manier zou een MER opsteller een explicietere ‘deelopdracht’ kunnen geven aan een ecoloog. Dit punt ging in op één van de belangrijkste ondervonden knelpunten, namelijk het knelpunt van raakvlakken tussen de specialisten. 5.2. Kernpunten voor het opstellen van een specificatie Aanvullend op de uitleg van de structuur van het verbetervoorstel (Hoofdstuk 4), zijn er belangrijke kernpunten te onderscheiden die van belang zijn voor opstellen van een specificatie. Deze kernpunten betreffen: (1) de structuur van de specificatie, (2) risico gestuurd specificeren en (3) de toetsbaarheid van de specificatie. Uiteindelijk dient er een balans te worden gevonden tussen deze kernpunten. De kernpunten zijn samengesteld op basis van de theorie van Systems Engineering. Rijkswaterstaat hanteert meer voorwaarden aan eisen, maar binnen de toepassing van het verbetervoorstel wordt uit praktische overwegingen hier in mindere mate naar gekeken. De afwegingen zullen wel deels ter sprake komen in dit hoofdstuk. 1. Structuur in specificatie Een groot risico binnen het specificatieproces is het niet weten of de specificatie volledig is. Daarmee wordt onbedoeld oplossingsruimte open gelaten en dat kan leiden tot aanzienlijke risico’s voor het 26 project. Hoe weet een opsteller of een specificatie compleet is en hoe wordt de kans verminderd om eisen over het hoofd te zien? Een belangrijk middel om te voorkomen dat een specificatie onvolledig is, is het aanbrengen van structuur in de specificatie. Structuur kan worden verkregen door het aanbrengen van een gelaagdheid in de eisen en een indeling van eisen op basis van onderwerp. Door deze structurering wordt de context van de eis verduidelijkt en dat verbeterd de mogelijkheid om onvolledigheid in de specificatie te constateren. Andere middelen zijn het raadplegen van specificaties van vergelijkbare projecten en het opstellen van de specificatie samen met een tweede opsteller. Volledigheid is belangrijk voor vertrouwen in de specificatie. Als projectmedewerkers geen vertrouwen in de volledigheid van de specificatie hebben, zijn ze geneigd om op de traditionele werkwijze te blijven werken. 2. Risico gestuurd specificeren Een ander relevant uitgangspunt bij het opstellen van een specificatie is hoe gedetailleerd en uitgebreid een specificatie moet te zijn. Moet een opsteller doorspecificeren tot ‘bout en moer’ niveau of is dat ineffectief? Een belangrijk middel om tot het juiste detailniveau te specificeren, is het zogenaamde ‘risico gestuurd’ specificeren. Daarmee wordt bedoeld dat voornamelijk de gebieden waar relevante risico’s worden verwacht, nader worden gespecificeerd. Deze werkwijze maakt de specificatie effectief en het gehele proces efficiënt. Het doorspecificeren tot op alle detailniveaus kan leiden tot een bureaucratisch en bijna onbeheersbaar proces. Daarom moet er ergens een lijn worden getrokken. Rijkswaterstaat hanteert het principe dat er bij zowel de opdrachtgever als opdrachtnemer genoeg ‘vertrouwen’ moet te zijn dat de belangrijkste risico’s zijn gespecificeerd. Dat is dan een goed moment om te stoppen met het gedetailleerder specificeren. Echter blijft dit een discutabel punt, omdat de opdrachtgever mogelijk meer risico’s ziet dan de opdrachtnemer. 3. Toetsbaarheid van de specificatie Als de eisen binnen de specificaties niet toetsbaar zijn, kan de kwaliteit van het ontwerp niet worden vastgesteld. Het niet kunnen vaststellen van de kwaliteit, betekent ondermeer het niet weten of het ontwerp mogelijk is, of het ontwerp gewenst is en of de projectelementen op elkaar aansluiten. Daarom is het zo belangrijk om eisen SMART of expliciet te formuleren. Zoals eerder omschreven in Hoofdstuk 4, hoeft en kan niet elke eis SMART of expliciet zijn. Eisen moeten of meteen eenduidig en meetbaar zijn, òf zodanig worden doorgespecificeerd dat de laagste eis in de eisenboom expliciet is en dat daarmee de bovenliggende eisen kunnen worden getoetst. 5.3. Verantwoording werkwijze In deze paragraaf wordt ingegaan op de werkwijze waarop de specificaties zijn opgesteld. De paragraaf dient verantwoording te geven over de gemaakte afwegingen en resultaten. Specificaties In overleg met de organisaties zijn drie verschillende specificaties ontwikkeld: 1. Planvorming ecologie: betreffen inhoudelijke eisen voor ecologie die als input dienen voor het ontwerp van de N34 en de omliggende landschapsinrichting. 2. Deelopdracht ecologie voor MER: betreffen inhoudelijke eisen voor de paragrafen over de ecologische effectbeoordeling van de MER. 3. Ecologisch veldonderzoek: betreffen proceseisen voor het juist uitvoeren van de veldonderzoeken voor het onderdeel ecologie van de MER. Inhoudelijke informatie specificaties De inhoudelijke informatie voor het opstellen van de specificaties zijn gebaseerd op wetgeving, beleidsdocumenten van de provincie Overijssel, literatuur van de Universiteit van Wageningen en optimalisaties door gesprekken met specialisten van de provincie Overijssel en de combinatie. 27 Werkwijze algemeen Het toepassingsproces van het verbetervoorstel was iteratief van aard. Telkens werd er een specificatie opgesteld en vervolgens besproken met specialisten. Op basis van de gesprekken zijn er aanpassingen gedaan en zijn de resultaten opnieuw besproken. Tijdens de gesprekken werd voornamelijk gevraagd of de specificatie volledig was en of deze duidelijk en werkbaar was voor in de praktijk. In de onderstaande punten worden de gemaakte afwegingen weergegeven: 1. Strijdigheid tussen enkelvoudige eisen en te lange specificatie: Rijkswaterstaat hanteert het principe dat eisen enkelvoudig dienen te zijn. Dat betekent één eis, per eis. Binnen de toepassing van het verbetervoorstel is hier incidenteel van afgeweken, omdat anders te lange specificaties met eisen ontstonden. Er werd geconstateerd dat te lange en ingewikkelde specificaties niet goed werkbaar zouden zijn en tevens het draagvlak voor de methode zouden aantasten. 2. Toetsbaarheid van de specificatie: Binnen de uitgangspunten is vermeld dat eisen zoveel mogelijk toetsbaar dienen te zijn. Binnen de toepassing is hier tevens incidenteel van afgeweken. Tijdens het opstellen van de specificaties ontstond er een strijdigheid tussen de mate van explicietheid van eisen en opnieuw te lange specificaties. Om eisen expliciet te maken moest er soms zoveel worden doorgespecificeerd dat opnieuw de specificatie te lang en niet werkbaar werd. Bij de afweging om eisen op te nemen in de specificatie, is doorgaans gebruik gemaakt van het uitgangspunt van ‘risico gestuurd’ specificeren. (par. 5.2) 3. Complexiteit van de eiscodering: Rijkswaterstaat hanteert het principe dat eisen een unieke code binnen het Programma van Eisen horen te hebben. (par. 4.3.1) Binnen de toepassing is hiervan afgeweken. Het voorstel was dat de eisen de afkorting van het betreffende object of activiteit zouden krijgen, dit had namelijk veel raakvlakken met de werkwijze van Rijkswaterstaat. De organisaties vonden echter dat de eiscodering hierdoor te ingewikkeld werd. Uiteindelijk is er een middenweg gekozen, waarbij binnen de specificatie eenvoudige codering van toepassing is en alleen bij een verwijzing naar de eisen van een andere specificatie, de objectcode werd weergegeven. Zo ontstond er toch een eisenboom door de specificaties heen en bleef de eiscodering eenvoudig en overzichtelijk. 4. Ontwikkeling standaard specificatie: tijdens de toepassing bleek dat veel specialisten het idee van een standaard specificatie goed beviel. Om de specificaties toepasbaar te maken voor verschillende projecten was de gelaagdheid in de eisen erg belangrijk. Pas op een laag niveau in de eisenboom zouden de eisen projectspecifiek worden gemaakt. De opgestelde specificaties zijn opgenomen in bijlage 5.1 en 5.2. In bijlage 5.1 staan specificaties met de complexere eiscodering en teveel aan eisen. In bijlage 5.2 zijn de definitieve specificaties opgenomen. De veranderingen die zijn gedaan ter bevordering van de praktische toepasbaarheid, hoeven mogelijk niet in de toekomst plaats te vinden. Nu is hier wel gekozen omdat het toepasbaar zijn van het verbetervoorstel ook een belangrijk uitgangspunt vormde voor de implementatie. Wanneer de organisaties beter gewend zijn aan het toepassen van Systems Engineering, zou meer kunnen worden opgeschoven naar de werkwijze van Rijkswaterstaat. Toetsingsmethode resultaten Er heeft geen expliciete toetsing plaatsgevonden om te achterhalen of de knelpunten worden verminderd doormiddel van de toepassing van het verbetervoorstel. Tijdens en na de toepassing hebben zoals eerder vermeld, verschillende gesprekken plaatsgevonden waarin de opzet van het verbetervoorstel in combinatie met vermindering van de knelpunten is besproken. Er is niet gekozen om explicieter te toetsen op de resultaten, voornamelijk door de beperkingen van tijd. De uitkomsten van gesprekken met specialisten staan vermeld in bijlage 5.3. De deelconclusie is samengesteld op basis van deze gesprekken met de projectmedewerkers, de gemaakte afwegingen en kennis van Rijkswaterstaat (Functioneel Specificeren/Lessons Learned). 28 5.4. Deelconclusie Dit hoofdstuk had tot doel om uiteen te zetten hoe het verbetervoorstel kon worden toegepast voor het project N34 en of de toepassing de ondervonden knelpunten in het planstudieproces kon verminderen. Om dit te onderzoeken zijn verificatiematrices opgesteld voor het aspect ecologie. De structuur van de eisen en de matrix zijn grotendeels gebaseerd op de theorie van Rijkswaterstaat. Toepassing en belangrijkste afwegingen Het verbetervoorstel kan worden toegepast door het opstellen van inhoudelijke eisen en proceseisen voor objecten en activiteiten voor het project N34. Daarbij dient te worden gestreefd naar een goede balans tussen de volledigheid, effectiviteit en toetsbaarheid van de specificatie. De belangrijkste afwegingen waren de mate van expliciet formuleren ten opzichte van de werkbaarheid en de overzichtelijkheid van de matrix én het wel of niet aanhouden van unieke eiscodering. (Deelvraag 4) Voor een specifieke beantwoording van deelvraag 5, wordt voor elk geselecteerd knelpunten uit het inventarisatieonderzoek uiteen gezet wat de invloed is van de toepassing van het verbetervoorstel op het betreffende knelpunt: 1. Raakvlakken tussen specialisten: De problemen met raakvlakken tussen specialisten kunnen worden verminderd door de toepassing van de verificatiematrices. De specificatie voor de ‘deelopdracht’ ecologie voor het MER is hier een voorbeeld van. De betrokken specialisten geven aan dat nu beter vaststaat wat van hen wordt verwacht, zodat zij gerichter hun taak kunnen uitvoeren. 2. Onvoldoende structurering van informatie: De structurering van informatie is verbeterd door de toepassing van het verbetervoorstel. De eisen zelf vormen beknopt de essentiële informatie voor het project en kunnen worden gekoppeld aan objecten of activiteiten. Daarnaast kan goed worden verwezen naar bijlagen, bronnen en andere eisen doormiddel van de matrix. 3. Verkeerde interpretatie van vraagspecificatie: De problemen van het verkeerd interpreteren van de vraagspecificatie kunnen worden verminderd door de toepassing van het verbetervoorstel. Grotendeels klopte de toepassing dus met de theorie, echter moesten er wel concessies worden gedaan aan de explicietheid van het gevraagde, om te voorkomen dat er bureaucratische en lange specificaties ontstonden. 4. Moeilijke herleidbaarheid eisen: Eisen konden met het verbetervoorstel zoals verwacht goed worden herleid naar een bron(document) en initiator. Daarnaast konden detaileisen worden getraceerd naar topeisen, door van het weergeven van bovenliggende en onderliggende eis. De toepassing van het verbetervoorstel kan de knelpunten in het proces van de planstudiefase van het project N34 verminderen. De toepassing wijkt op bepaalde punten af van de theorie van het verbetervoorstel. De oorzaak hiervan is vooral de afwegingen die zijn gedaan met betrekking tot het afzien van de unieke eiscodes en het voorkomen van te lange specificaties. Dit hoeft echter niet te betekenen dat in de toekomst deze veranderingen ook hoeven plaats te vinden. Wanneer beide organisaties beter gewend zijn om met Systems Engineering te werken, zou de werkwijze van de organisaties kunnen worden geoptimaliseerd naar die van Rijkswaterstaat. Een belangrijke reden voor de keuze voor het aspect ecologie, was de twijfel of Systems Engineering ook geschikt zou zijn voor afdelingen die minder technisch van aard waren. Uit de resultaten van het onderzoek kan worden opgemaakt dat Systems Engineering ook voor deze afdelingen een uitkomst kan bieden. In essentie is Systems Engineering voor alle projectonderdelen toepasbaar, alleen weegt de inspanning die de methode vergt, niet altijd op tegen de baten. Hierbij kan worden verwezen naar de theorie van Honour (2004) en Martin (1997) over de meerwaarde van Systems Engineering. (par.2.2.5) In het geval van de afdeling Ruimte voor de MER heeft de methode een meerwaarde. 29 6. Aanbevelingen voor organisaties In deze paragraaf worden aanbevelingen gedaan omtrent de implementatie van Systems Engineering voor het project N34 en mogelijk vervolgprojecten. De aanbevelingen zijn gedaan op basis van de onderzoekresultaten, de theorie van Systems Engineering en de gesprekken met medewerkers van de provincie Overijssel en de combinatie. Allereerst wordt er geadviseerd om door te gaan met Systems Engineering bij het project N34 en mogelijke vervolgprojecten. De resultaten van het onderzoek tonen aan dat de belangrijkste knelpunten die de provincie Overijssel en de combinatie ondervinden, worden verminderd door de toepassing van Systems Engineering. Bovendien maakt Systems Engineering steeds meer haar opmars in de bouw- en infrastructuurwereld en zullen beide organisaties vroeg of laat meer in aanraking komen met de methode. Binnen de aanbevelingen zijn drie hoofdlijnen te onderscheiden: 1. De standaardisering van definities en werkwijzen 2. Het overnemen van het verbetervoorstel en andere SE-methoden 3. Informatiepunten, kennisverspreiding en draagvlak 6.1. Standaardisatie van definities en werkwijzen Standaardisering algemeen Er wordt geadviseerd om bij de implementatie van Systems Engineering toe te werken naar het standaardiseren van definities en werkwijzen. Binnen het huidige implementatieproces is lang niet bij iedere projectmedewerker duidelijk wat bijvoorbeeld onder verschillende typen eisen wordt verstaan en hoe een specificatie dient te worden opgesteld. Een eerste stap is dus het afspreken hoe vorm wordt gegeven aan Systems Engineering. Dan reikt de vraag: wat zijn de juiste definities en werkwijzen? Daarvoor wordt met klem geadviseerd om zoveel mogelijk de werkwijzen en definities van Rijkswaterstaat (en partners) aan te houden. Er zijn drie belangrijke redenen waarom standaardisatie volgens Rijkswaterstaat aan te bevelen zijn: 1. Kennis en ervaring: Rijkswaterstaat (e.a.) zijn de trendgevende organisaties binnen Nederland voor de toepassing van Systems Engineering. Rijkswaterstaat heeft kennis en ervaring met de methode en biedt toegang tot kennis in de vorm van leidraden, workshops en handige tips & tricks. 2. Toekomstige projecten: de combinatie doet geregeld opdrachten voor Rijkswaterstaat en de provincie Overijssel zal hoogstwaarschijnlijk in de toekomst ook met andere opdrachtnemers Systems Engineering toepassen. Daarom zou het verstandig zijn om een werkwijze aan te houden waardoor kennis en vaardigheden ook toepasbaar zijn voor toekomstige projecten. 3. Kennis uitwisselen: met het overnemen van de methoden van Rijkswaterstaat wordt toegewerkt naar een ‘technische taal’ binnen Nederland van Systems Engineering. Dat biedt beter de mogelijkheid om bijvoorbeeld het proces en werkzaamheden deels uit te besteden aan een professional. De provincie Overijssel zou bijvoorbeeld de verificatiematrices kunnen laten doorlichten door een externe controleur. Het advies betekent niet dat alle werkwijzen en definities van Rijkswaterstaat (meteen) moeten worden overgenomen. De werkbaarheid van het proces staat voorop en er is tijd nodig voor de omschakeling. De kern van deze aanbeveling blijft: probeer toe te werken naar één technische taal voor Systems Engineering, dat duurzaam ingezet kan worden voor verschillende projecten. De huidige werkwijze van de projectorganisaties verschilt van Rijkswaterstaat o.a. op het gebied van definities, de opzet en omschrijving van eisen, de opzet van de matrices en de gelaagdheid in eisen. Standaardisering van een leidraad Als onderdeel van de standaardisatie wordt geadviseerd om naast de leidraden van Rijkswaterstaat een eenvoudige leidraad over Systems Engineering op te stellen voor intern gebruik binnen de 30 projectorganisaties. Deze leidraad zou praktischer van aard moeten zijn dan die van Rijkswaterstaat en vooral moeten richten op het correct opstellen van verificatiematrices. De leidraad zou handige en tips & tricks, voorbeelden van uitgewerkte specificaties en een lijst met definities voor type verificatiemethoden, type eisen en andere belangrijke termen moeten bevatten. Standaardisering van specificaties Er wordt tevens geadviseerd om toe te werken naar het ontwikkelen van standaard specificaties voor bepaalde objecten en activiteiten. Daarmee wordt bedoeld dat de eerste paar lagen van de eisenboom zodanig worden opgesteld, dat de uitwerkingen daarvan toepasbaar zijn voor meerdere projecten. Het standaardiseren zou kunnen worden toegepast voor objecten en activiteiten die in beginsel voor veel projecten hetzelfde zijn, zoals de specificatie voor de deelrapportage ecologie van het MER, de Veldonderzoeken en de Planvorming voor Ecologie. Wanneer er voor een nieuw project specificaties moeten worden opgesteld, kunnen de standaard specificaties projectspecifiek worden gemaakt doormiddel van het invullen van de onderliggende (detail)eisen. 6.2. Overnemen van verbetervoorstel Een tweede hoofdlijn binnen de aanbevelingen zijn het overnemen van het verbetervoorstel en andere specifieke Systems Engineering methoden. Overnemen van verbetervoorstel Er wordt geadviseerd om het verbetervoorstel op basis van het onderzoek over te nemen. Het verbetervoorstel is overzichtelijker, draagt beter bij aan een standaardisatie en is zodanig opgezet dat het goed kan bijdragen aan een gestructureerde opzet van eisen. Specifieke adviezen zijn: Het overnemen van de opzet van het verbetervoorstel Het overnemen van de vijf standaard typen eisen met definitie (bijlage 4.1) Het overnemen van de standaard verificatiemethoden met definitie (bijlage 4.2) Het overnemen van een gelaagdheid in de eiscodering Het opstellen van proceseisen Er wordt tevens geadviseerd om toe te werken naar een duidelijke scheiding tussen inhoudelijke eisen en proceseisen. Proceseisen zijn belangrijk omdat de kwaliteit van de resultaten van een project zoals de N34, voor een groot deel afhankelijk zijn van de kwaliteit van de uitgevoerde onderzoeken en de methode van het maken van (ontwerp)keuzes. Een opdrachtgever van een MER wil bijvoorbeeld dat het MER aan alle inhoudelijke eisen voldoet die de wet stelt, maar de opdrachtgever wil ook dat het proces om te komen tot de resultaten, zodanig is uitgevoerd dat de resultaten betrouwbaar zijn. Kwaliteitsborging voor een project zoals de N34 zit dus ook voor een groot gedeelte in het toepassen van het juiste proces en daarvoor moeten ook eisen voor het proces expliciet gemaakt worden. Het expliciet scheiden van inhoudelijke eisen en proceseisen is daarin belangrijk omdat zo meer overzicht en orde ontstaat in de specificatie en daarmee beter kan worden gecontroleerd of de specificatie volledig is. De methode Systems Engineering is in feite ook een procesbeschrijving dat waarborgt dat met de correcte toepassing van de methode en gedegen uitgangspunten (input), het meest optimale en kwalitatieve resultaat wordt gegenereerd. Het opstellen van processpecificaties is daar een verlengde van. Het opstellen van topeisen Momenteel is de opdrachtnemer (de combinatie) binnen het project N34 volledig verantwoordelijk voor het opstellen van de verificatiematrices. Binnen Systems Engineering in Nederland is dat een ongebruikelijke rolverdeling. Systems Engineering is een top-down methode, waarbij de opdrachtgever vaak de eerste lagen van de eisenboom weergeeft en de opdrachtnemer deze correct doorspecificeert tot op het gewenste niveau. Er wordt geadviseerd dat de provincie Overijssel bij vervolgprojecten topeisen formuleert, mogelijk in overleg en op advies van de opdrachtnemer. 31 6.3. Informatiepunten, kennisverspreiding en draagvlak Een derde hoofdlijn binnen de aanbevelingen is het opzetten van informatiepunten en het verspreiden van kennis over Systems Engineering. Daarnaast komt het ontwikkelen van draagvlak ter sprake. Informatiepunt Systems Engineering Er wordt geadviseerd om een vast informatiepunt over Systems Engineering op intranet aan te maken, bij zowel de provincie Overijssel als de combinatie. Het informatiepunt zou kunnen bestaan uit de geadviseerde korte leidraad, definities, de standaardspecificaties voor bepaalde objecten en activiteiten en mogelijk de leidraden van Rijkswaterstaat. Doormiddel van een vast informatiepunt kan voor projectmedewerkers eenvoudig inzichtelijk worden gemaakt hoe een specificatie dient te worden opgesteld of gecontroleerd en wat onder begrippen wordt verstaan. Informatiepunt verificatiematrices projecten Naast een informatiepunt over de kennis van Systems Engineering, wordt geadviseerd om een informatiepunt voor alle verificatiematrices van het project N34 aan te maken. Deze kunnen worden gerangschikt op basis van de objectenboom of activiteitenboom. Samen vormen deze matrices het Programma van Eisen voor het project. Veranderingen in de verificatiematrices naar aanleiding van ontwerpkeuzes, vergaderingen en ontwerpwijzigingen, zouden bovendien alleen in deze map verwerkt moeten worden. Zo blijft de meest recente en complete versie van het Programma van Eisen altijd op één plek en vormt daarmee het uitgangspunt. Workshops Voor de kennisverspreiding binnen de organisaties zou het verstandig zijn om minimaal eens per half jaar een workshop te houden over Systems Engineering. Daarbij kan de leidraad worden uitgedeeld en kunnen samen met de deelnemers specificaties worden opgezet en vragen worden beantwoord. Draagvlak en ambitieniveau Draagvlak ontwikkelen is een belangrijk onderdeel voor het mogelijk maken van de implementatie van Systems Engineering. Het ambitieniveau voor Systems Engineering moet daarbij worden afgestemd op het draagvlak binnen de organisaties. Tijdens het onderzoek werd duidelijk dat er weinig begrip was voor ingewikkelde eiscodes of te lange matrices. Er moet eenvoudig begonnen worden door het opstellen van gestructureerde matrices met daarin de belangrijkste inhoudelijke of proceseisen. Langzamerhand kan het ambitieniveau worden uitgebreid en toe worden gewerkt naar een professionalisering van de werkwijze. 6.4. Deelconclusie Dit hoofdstuk had tot doel om uiteen te zetten welke aanpassingen dienen te worden doorgevoerd bij de provincie Overijssel en de combinatie om de implementatie van Systems Engineering haalbaar te maken. De aanpassingen die worden geadviseerd betreffen: (1) de standaardisatie van definities en werkwijzen, (2) het overnemen van het verbetervoorstel en andere Systems Engineering methoden en (3) het aanmaken van informatiepunten waarbij de kennis over Systems Engineering centraal kan worden opgeslagen én verspreid doormiddel van leidraden en workshops. De aanbevelingen zijn vooral gericht op de toekomst, waarbij aandacht is voor het ontwikkelen van één technische taal voor Systems Engineering binnen Nederland en waarbij kennis en ervaring uitwisselbaar en toepasbaar zijn voor toekomstige projecten. 32 7. Conclusies Dit onderzoek had tot doel om te inventariseren wat de belangrijkste knelpunten waren binnen het proces van de planstudiefase van projecten zoals de N34 en of een verbetervoorstel op basis van Systems Engineering de belangrijkste knelpunten kon verminderen. Om dit te onderzoeken heeft er een inventarisatie van knelpunten plaatsgevonden en is er een format ontwikkeld en toegepast voor het project N34 op basis van de theorie van Systems Engineering. In deze conclusie worden eerst de ondervonden knelpunten uit het inventarisatieonderzoek uiteen gezet en vervolgens de resultaten van het ontwikkelen en toepassen van het verbetervoorstel. Inventarisatieonderdeel Bij de inventarisatie is gebruik gemaakt van de Delphi-techniek. Daarbij werden eerst interviews afgenomen met vooraf geselecteerde projectleiders en specialisten en vervolgen werden enquêtes samengesteld op basis van de uitkomsten van de interviews en tevens afgenomen bij deels dezelfde en deels andere ondervraagden. De inventarisatie heeft plaatsgevonden bij de provincie Overijssel en een combinatie van Tauw en Goudappel Coffeng, binnen de scriptie vermeld als de ‘combinatie’. Het feit dat de betrokken organisaties allen veel ervaring hadden met planstudiefases en het feit dat zowel de kant van de opdrachtgever als opdrachtnemer kon worden belicht, maakte het dat deze organisaties geselecteerd waren voor het onderzoek. Het eerste deel van de hoofdvraag betrof een uiteenzetting van de belangrijkste knelpunten in de planstudiefase. Deze belangrijkste knelpunten zijn hieronder uiteen gezet: 1. Raakvlakken tussen specialisten: de planstudiefase vergt een intensieve samenwerking tussen verschillende disciplines, maar de specialisten werken geregeld langs elkaar heen Hierdoor wordt niet altijd de juiste informatie aan elkaar afgeleverd of te laat afgeleverd. 2. Onvoldoende structurering van informatie: informatie wordt onvoldoende gestructureerd opgeslagen en verwerkt. Als informatie niet goed gestructureerd is, wordt het maar deels meegenomen in het project en dat heeft invloed op de kwaliteit van het product én proces. 3. Verkeerde interpretatie van vraagspecificatie: het is voor opdrachtgevers en opdrachtnemers moeilijk om af te stemmen wat men van elkaar verwacht en wat elkaars interpretatie van de vraagspecificatie is. Vaak komt dit pas naar boven op het moment dat de eerste versie wordt aangeleverd. 4. Moeilijke herleidbaarheid van eisen: de eisen die worden gesteld aan een te ontwerpen weg of een te ontwikkelen rapportage zijn soms moeilijk herleidbaar. Het gevolg is dat een opdrachtgever moeilijk kan aantonen wat er met een bepaalde eis is gebeurd en of deze eis is meegenomen in het ontwerp of de rapportage. Implementatieonderdeel De ondervonden knelpunten hadden voornamelijk betrekking op het structureren en beheren van informatie over het project en tussen de disciplines. Binnen Systems Engineering wordt het structureren en beheren van informatie vormgegeven door matrices gevuld met eisen die samen de oplossingsruimte specificeren en afspraken vastleggen. Als verbetervoorstel is daarom gekozen voor de ontwikkeling van deze matrices, die ook wel verificatiematrices worden genoemd. Binnen het implementatieonderdeel is er eerst een format voor een verificatiematrix ontwikkeld en onderbouwd op basis van de theorie van ondermeer Rijkswaterstaat. Daarna is het verbetervoorstel toegepast voor het project N34. Voor een specifieke beantwoording van het tweede deel van de hoofdvraag, wordt voor elk geselecteerd knelpunten uit het inventarisatieonderzoek uiteen gezet wat de invloed is van de toepassing van het verbetervoorstel op het betreffende knelpunt: 1. Raakvlakken tussen specialisten: De problemen met raakvlakken tussen specialisten kunnen worden verminderd door de toepassing van de verificatiematrices. De betrokken specialisten geven aan dat nu beter vaststaat wat van hen wordt verwacht, zodat zij gerichter hun taak kunnen uitvoeren of een taak kunnen uitbesteden. 33 2. Onvoldoende structurering van informatie: De structurering van informatie is verbeterd door de toepassing van het verbetervoorstel. De eisen zelf vormen beknopt de essentiële informatie voor het project en kunnen worden gekoppeld aan objecten of activiteiten. Daarnaast kan goed worden verwezen naar bijlagen, bronnen en andere eisen doormiddel van de matrix. 3. Verkeerde interpretatie van vraagspecificatie: De problemen van het verkeerd interpreteren van de vraagspecificatie konden worden verminderd door de toepassing van het verbetervoorstel. Echter moesten er concessies worden gedaan aan de explicietheid van het gevraagde, om te voorkomen dat er bureaucratische en lange specificaties ontstonden. 4. Moeilijke herleidbaarheid van eisen: Eisen konden met het verbetervoorstel zoals verwacht goed worden herleid naar een bron(document) en initiator. Daarnaast konden detaileisen worden getraceerd naar topeisen, doormiddel van het weergeven van bovenliggende en onderliggende eis. De toepassing van het verbetervoorstel kon de knelpunten in het proces van de planstudiefase van het project N34 verminderen. Er zijn geen reden om te veronderstellen dat deze uitkomsten anders zouden zijn voor projecten vergelijkbaar met de N34. De toepassing wijkt op bepaalde punten af van de theorie van het verbetervoorstel. Daarbij waren de aanpassingen om te komen tot een goede balans tussen theorie en toepasbaarheid van het verbetervoorstel de oorzaak. De aanpassingen zijn bovendien mogelijk van tijdelijke aard. Aanvullend zijn er binnen het onderzoek aanbevelingen gedaan over welke aanpassingen dienen te worden doorgevoerd bij de provincie Overijssel en bij ingenieursbureaus Tauw en Goudappel Coffeng om de implementatie van Systems Engineering haalbaar te maken. De aanbevelingen zijn vooral gericht op de toekomst, waarbij aandacht is voor het ontwikkelen van één technische taal voor Systems Engineering binnen Nederland en waarbij kennis en ervaring uitwisselbaar en toepasbaar is voor toekomstige projecten. Tevens wordt er geadviseerd toe te werken naar een standaardisatie van werkwijzen en definities en het overnemen van het verbetervoorstel. Deze conclusie heeft duidelijk gemaakt wat de belangrijkste knelpunten binnen de planstudiefase van projecten vergelijkbaar met de N34 zijn en in hoeverre een verbetervoorstel op basis van Systems Engineering deze knelpunten kan verminderen. Daarmee is de hoofdvraag beantwoord en de doelstelling van het onderzoek bereikt. Discussie Dit onderzoek vormt een goede basis voor de provincie Overijssel en Tauw/Goudappel Coffeng om de implementatie van Systems Engineering te bevorderen. Echter is de structurering van informatie, waar deze scriptie hoofdzakelijk op was gericht, maar een onderdeel van Systems Engineering. Een belangrijke vervolgstap van het verbetervoorstel is dat eisen een explicietere rol zouden moeten innemen bij het maken van variantafwegingen. De eisen uit de specificaties dienen correct te worden gealloceerd naar objecten (functievervullers) en zouden uitgangspunt moeten zijn voor beslissingen. Er bevinden zich dus meer belangrijke schakels om tot een optimalisering van het ontwikkelproces te komen en daar dient tevens aandacht voor te zijn. 34 Referenties Bahill, A & Dean, F. (2005) What is Systems Engineering?, Tucson: University of Arizona Department of Defense (2001). Systems Engineering Fundamentals. Fort Belvoir, Virginia: Supplementary text prepared by the defense acquisition university press. INCOSE (2006) Systems Engineering handbook, Seatle: INCOSE Central Office Huerne, H.L. ter & Veenvliet, K.Th. (2007). Functioneel specificeren: de weg naar economisch meest haalbare oplossing. Enschede: KOAC.NPC Honour, E. (2004). Understanding the value of systems engineering. Pensacola USA Martin, J. N. (1997). Systems Engineering Guidebook. A process for developing systems and products. Boca Raton, Florida: CRC Press. Netten, J. van (2005). Handreiking Functioneel Specificeren. Utrecht: Expertise Centrum Opdrachtgeverschap Prorail, Rijkswaterstaat, ONRI & Bouwend Nederland (2007). Leidraad voor Systems Engineering binnen de GWW-sector. ProRail & Rijkswaterstaat Rijkswaterstaat (2009): Lessons Learned, toetsen van vraagspecificaties eisendeel. Rijkswaterstaat Rijksoverheid. (sd) . www.rijksoverheid.nl. Opgeroepen op: 28 09, 2010, van: http://www.rijksoverheid.nl/onderwerpen/milieubeleid/milieueffectrapportage Strijbos, S., (1988). Het Technisch Wereldbeeld, een wijsgerig onderzoek van het systeemdenken. Amsterdam: Buijten & Schipperheijn Verschuren, P., & Doorewaard, H. (2005). Het ontwerpen van een onderzoek. Utrecht: Lemma. 35
