Startnotitie programmacommissie Systems Engineering
F.J. Willems Flow-Way, K.Th. Veenvliet Universiteit Twente Oktober 2008
1 Management samenvatting 1.1 Aanleiding Een eerste oriëntatie op de toepassing van Systems Engineering (SE) in GWW-projecten is opgesteld door vertegenwoordigers van RWS, ProRail, Bouwend Nederland en ONRI. Dit heeft geleid tot het verschijnen van de Leidraad SE op 19 februari 2007. Deze Leidraad is geen handboek of werkinstructie, maar een beschrijving van de inrichting van een verificatie georiënteerde projectstructuur op basis van het V-model. Het is niet verwonderlijk dat het V-model in de Leidraad is opgenomen al is de keuze niet specifiek onderbouwd. Vanuit de doelstelling meer markt minder overheid is een verificatie georiënteerde structuur van het voortbrengingsproces echter een logische aanpak. Het V-model biedt de opdrachtgevers immers de mogelijkheid een expliciete wijze tot verantwoording van ontwerp- en uitvoeringsactiviteiten voor te schrijven aan gegadigden en opdrachtnemers. De Leidraad benadrukt dan ook een groot aantal voorwaarden waaraan de structuur van die expliciete beschrijvingswijze moet voldoen, maar gaat in veel mindere mate in op ontwerpstrategieën, doelgerichte procesbeschrijvingen, bijbehorende methoden en gereedschappen en de omgevingscondities voor de organisatie. Om op professionele en volwassen wijze de SE benadering in te zetten in een project- en bedrijfsomgeving is naast inzicht en kennis over principes en procesbeschrijvingen ook kennis en inzicht nodig over bijbehorende procedures, methoden, gereedschappen en omgevingscondities. De laatste jaren hebben vele opdrachtnemende bedrijven geïnvesteerd in het uitwerken van de SE benadering. Als een aandachtsgebied groeit naar volwassenheid dan leidt dit vaak tot een veelheid aan gedifferentieerde werkwijzen. Enerzijds is dit een positieve ontwikkeling anderzijds kan het leiden tot fragmentatie wanneer elk gerenommeerd bedrijf zijn werkwijze ontwikkeld vanuit eigen belangen en bedrijfsdoelstellingen. Aangezien vele bedrijven intern trainingen en opleidingen op dit gebied ontwikkelen is de kans op fragmentatie niet ondenkbeeldig. De CROW ziet voor zichzelf als taak fragmentatie van werkwijzen zoveel mogelijk in te beperken door te streven naar sectorbreed gedragen uniforme werkwijzen. In dit kader heeft de CROW een programmacommissie SE ingesteld. Aan de Universiteit Twente afdeling Bouw/Infra is de opdracht verstrekt een missie statement te schrijven dat moet dienen als startdocument voor de werkzaamheden van de programmacommissie. Het document verschaft hiertoe inzicht in de wijze waarop aanvaardbare uniforme omgevingcondities voor de SE benadering in de GWW ontwikkeld kunnen worden, gekoppeld aan al bestaande uniforme omgevingen zoals de UAV-gc. Het visie document bevat daartoe concrete aanbevelingen.
1.2 Visie en missie Visie Het bevorderen van een integraal voortbrengingsproces waarmee alle partijen in de GWW-sector op een duurzame wijze, maatschappelijk verantwoord en internationaal concurrerend waarde creëren over de hele levensduur (aanleg, beheer, onderhoud en sloop) van de fysieke infrastructuur.
Missie: Het creëren van een uniforme voortbrenging omgeving op basis van Systems Engineering ten behoeve van een duurzame samenwerking in de waardeketen van de GWW-sector opdat de verwachte waarde voor de klant over de gehele levensduur gewaarborgd wordt.
1
1.3 Aanbevolen wordt: ●
De Win-condities van de verschillende actoren ten aanzien van de ontwikkeling van uniforme SE omgevingen met elkaar in balans te brengen;
●
Draagvlak binnen de programmacommissie SE creëren over de missie, doelstellingen en rol van CROW Uit de missie kunnen de volgende doelstellingen ter ondersteuning van de implementatie van Systems Engineering worden afgeleid: ◦
Uitdragen gedachtegoed Systems Engineering De sector van informatie voorzien waaruit blijkt dat een op Systems Engineering gebaseerd voortbrengingsproces de transparantie verhoogd en technische risico's beheersbaar maakt.
◦
De drempel voor de implementatie van een op Systems Engineering gebaseerd voortbrengingsproces verlagen Ontwikkelen van een procesondersteunende architectuur. Vanuit de architectuur moet ook een filosofie ontwikkeld worden over de organisatie specifieke implementatie rekening houdend met de omvang van de organisatie en de rol in de waardeketen.
◦
Stimuleren van competentie- en loopbaanontwikkeling van sleutelspelers in de Systems Engineering Ontwikkelen van competentieprofielen en loopbaantrajecten voor spelers in de Systems Engineering en de coördinatie met het MBO, HBO en WO op dit gebied.
◦
Stimuleren van het meten van de kwaliteit van het voortbrengingsproces Ontwikkelen van een assessmentkader van het voortbrengingsproces en het opzetten van een databank waar de resultaten van de verschillende assessments verzameld worden, zodat uitspraken over Return on Investment en Return on Knowledge gedaan kunnen worden.
Rol CROW ◦
Regisseur van het versterken van de waardeketens in de GWW-sector. De regisseursrol krijgt vorm door de spelers in de sector bij elkaar te brengen in de programmacommissie Systems Engineering;
◦
Eigenaar van de procesondersteunende architectuur De CROW neemt het initiatief om tot een Systems Engineering handboek voor de GWW-sector te komen. Daarnaast stimuleert zij partijen om een architectuurkader te ontwikkelen waarin de gebruiker eenvoudig toegang krijgt tot de afsprakenstelsels, kennisbanken en andere IT gereedschappen. Voor het ontwikkelen en onderhouden van het Systems Engineering handboek kan de CROW een 'open source' filosofie entameren waardoor organisaties en kennisinstellingen gestimuleerd worden een bijdrage te leveren en waarbij de CROW de kwaliteitsborging organiseert.
◦
Regisseur voor het ontwikkelen van competentieprofielen voor Systems Engineering rollen De CROW kan de verschillende partijen in de sector (bedrijven, overheidsagentschappen en kennisinstellingen) bij elkaar brengen. Daarnaast kan de CROW ook als beheerder van de profielen optreden.
◦
Regisseur bij het ontwikkelen van een assessmentkader voor de Systems Engineering implementatie. Het verbeteren van het voortbrengingsproces levert nooit meteen kosten voordelen op. Het voorkomt kostenoverschrijdingen in de toekomst. Dit aspect bemoeilijkt de “verkoop” van de implementatie van Systems Engineering. Wanneer op initiatief van de 2
CROW een assessmentkader voor een Systems Engineering implementatie wordt ontwikkeld en als de CROW resultaten van assessments in de GWW-sector verzameld en analyseert kan zij een extra dimensie aan haar rol als kennisplatform geven. De analyses leiden hopelijk tot een methode om de implementatie van Systems Engineering te kunnen kapitaliseren en verder kan een uitspraak gedaan worden over de efficiëntie van de verschillende implementatie trajecten. ●
Ontwikkelen van een SE roadmap door de programmacommissie op basis van missie, doelstellingen en rol CROW, vanuit de aspecten markt, product, proces, procesondersteuning en medewerkers;
●
Opstellen van een programmaplan met daarin doelstellingen, vraagstellingen en op te leveren producten door verschillende SE werkgroepen;
●
Versterken van de SE begripsbepaling binnen de programmacommissie door de SEdenkwijze en –werkwijze in hun samenhang pragmatisch uit te werken voor een eenvoudig project.
1.4 Motivatie Door de Universiteit Twente afdeling Bouw / Infra en Flow-Way te Borne is op basis van kennis en ervaring op het gebied van de implementatie van SE werkwijzen in de GWW-sector de startnotitie voor de programmacommissie SE opgesteld. Het belang van SE als middel tot het ondersteunen van de waardeketen wordt hierin benadrukt. Het gaat dan niet alleen om het beteugelen van de problematiek van faalkosten, maar ook om die van de toenemende complexiteit van organisatie, product en proces. In een drietal scenario’s is aangegeven wat SE kan betekenen voor de bouw. Het invoeringsproces van SE heeft grote consequenties voor het technische en projectmanagement proces, onverlet welk scenario gevolgd wordt. De SE benadering is gebaseerd op systeem denken, waarin analyse en synthese elkaar dienen te versterken. Alleen uitgaan van een analytisch denkvermogen is te beperkt om de SE benadering te begrijpen, adopteren, implementeren en assimileren. Het invoeringsproces van SE vraagt om verandering van traditionele denkwijzen bij zowel technici als managers. Deze verandering van denkwijze leidt tot verandering van werkwijzen. Dit betekent aanpassing van zowel abstracte zaken, de bestaande principes en procesbeschrijvingen, als concrete zaken, de bestaande procedures, methoden, gereedschappen en omgevingscondities. Opvallend, maar niet verwonderlijk, is dat in vele bedrijven en organisaties in de GWW juist de ontwikkeling van SE procedures, methoden en gereedschappen een grote vlucht neemt. De nadruk ligt dan minder op de abstracte denkwijzen, maar meer op de verandering van concrete werkwijzen. In deze startnotitie wordt het belang van de samenhang tussen denkwijze en werkwijze benadrukt om sectorbrede doelgerichte en projectcontext afhankelijke procedures, methoden en gereedschappen te ontwikkelen. Hiermee wordt voorkomen dat SE benaderingen een doel op zichzelf worden, maar juist een middel om een specifieke problematiek aan te pakken.
1.5 Consequenties ●
De SE begripsbepaling toelichten aan de hand van een eenvoudig project;
●
Het overleg over de Win-condities van de actoren uit de programmacommissie intensiveren.
●
Het draagvlak ten aanzien van de missie uiteengezet en toegelicht in het startdocument op korte termijn creëren.
●
Om de SE werkgroepen te kunnen starten de SE roadmap samenstellen met de betrokken actoren
3
1.6 Eindbeeld De programmacommissie sytems engineering (PC SE) kan zijn missie als een succes beschouwen wanneer het erin slaagt de volgende vier producten te realiseren: 1. Een architectuur waarmee aan de hand van wensen en behoeften van een organisatie in de GWW-sector een op maat gesneden Systems Engineering implementatie geleverd kan worden. Deze implementatie omvat procesbeschrijvingen, procesondersteuning en rollen van de spelers in het proces; 2. Een competentiehandboek met competentieprofielen van de verschillende rollen in het Systems Engineering proces; 3. Een methodiek om de kwaliteit van de Systems Engineering implementatie te meten en een databank met metingen van de kwaliteit van de implementatie bij verschillende organisaties. Met de gegevens uit de databank een optimale Systems Engineering implementatie voor een organisatie bepaald worden. 4. Een verzameling van relevante gegevens over het Systems Engineering proces (case studies, succes verhalen, enz.). De verzamelde gegevens kunnen gebruikt worden bij het uitdragen van het Systems Engineering gedachtegoed.
4
2 Inleiding Deze notitie geeft een visie op de implementatie van Systems Engineering in de Grond-, Weg- en Waterbouw (GWW). De notitie is de startnotitie voor de programmacommissie Systems Engineering binnen de CROW. Samen met het programmaplan Systems Engineering dient deze notitie als leidraad voor de implementatie van Systems Engineering in de bouwsector. Er bestaan vele definities voor het begrip Systems Engineering. De leidraad voor Systems Engineering binnen de GWW sector geeft de volgend omschrijving: 'Systems Engineering biedt een geïntegreerde en gestructureerde set methodieken om projecten succesvol te verwezenlijken en te beheren.'. Systems Engineering is de engineering discipline, die het volledig voortbrengingsproces ondersteunt. Het geeft een visie op de hele levensduur van het product of systeem, zowel de creatie-, realisatie- als exploitatiefase. Vanuit dit gezichtspunt is een visie op de implementatie van Systems Engineering direct gekoppeld aan de visie op de ontwikkeling van de bedrijfsdoelstellingen. Vandaar dat in deze notie gekozen is om de implementatie van Systems Engineering te bekijken vanuit een kwaliteitsstandpunt. Het uitgangspunt is de kwaliteitspiramide (afbeelding 1)
Afbeelding 1: Kwaliteitspiramide
Een onderneming streeft naar duurzame winstgevendheid. Teneinde dit te realiseren formuleert de onderneming op ondernemingsniveau een missie, visie en ondernemingsdoelen. In haar kwaliteitssysteem geeft de onderneming aan op welke wijze de processen op procesniveau bijdragen aan het realiseren van de ondernemingsdoelen. Op hun beurt sturen de processen de activiteiten, die op activiteitenniveau door de werknemers worden uitgevoerd. Redenerend vanuit de kwaliteitspiramide is een visie op de implementatie van Systems Engineering in het voortbrengingsproces een afgeleide van de missie, visie en doelstellingen van de onderneming. De kwaliteitspiramide dient als rode draad bij de opbouw van deze notitie. In het hoofdstuk Visie belichten wij het ondernemingsniveau. De GWW sector is in beweging. Voor het realiseren van complexe projecten, die met hoogwaardige technische kennis gerealiseerd moeten worden ontstaan kansen voor nieuwe businessmodellen. Maar ook in de traditionele waardeketen treden verschuivingen op. Wij laten zien dat een voortbrengingsproces gebaseerd op Systems Engineering ondernemingen in staat stellen optimaal van deze kansen te profiteren. De implementatie van Systems Engineering is niet het enige veranderingsproces dat in de sector plaats vind. In dit hoofdstuk zal de implementatie van Systems Engineering in het perspectief van de verschillende initiatieven, die op dit moment in de sector lopen, geplaatst worden. Tevens geven we een doorkijk naar de toekomst van de bouw vanuit een Systems Engineering perspectief. Hiervoor worden drie scenario’s geïntroduceerd; status quo, meest waarschijnlijke en radicale 5
veranderingen.
Afbeelding 2: De drie gezichtspunten voor High Performance systeemvoortbrenging
Het procesniveau is onderwerp van het hoofdstuk Processen. Hierin wordt de wijze waarop Systems Engineering in het voortbrengingsproces wordt verwerkt belicht. Tevens is er aandacht voor de rollen in het proces, de procesovergangen en de aansluiting van deze overgangen met de afsprakenstelsels (UAV-GC 2005, UAV 89 en VISI), die in de sector gebruikt worden. Een verandering in het voortbrengingsproces introduceert nieuwe rollen en vraagt om aanpassingen van bestaande rollen. Het hoofdstuk Human Resource Management adresseert de competentieprofielen en opleidingstrajecten voor de uitvoerders van de rollen. Het activiteitenniveau van de kwaliteitspiramide is onderwerp van het hoofdstuk Procesondersteuning. Door de procesondersteuning sectorwijd te uniformeren ontstaat er één Systems Engineering taal. Deze standaard procesondersteuning kan dan door ieder bedrijf worden aangevuld met bedrijfsspecifieke informatie, zodat de medewerkers optimaal worden ondersteund in hun activiteiten. De ingrediënten van de procesondersteuning zijn: ●
Een Systems Engineering handboek voor de GWW sector;
●
Gestandaardiseerde IT tooling;
●
Sectorspecifieke kennisbank (bijvoorbeeld functiebibliotheek en richtlijnen in het kader van wet- en regelgeving)
Zoals afbeelding 2 laat zien is een goede samenhang tussen het proces, geschoolde medewerkers en procesondersteuning (gerei en technologie) noodzakelijk voor een optimale voortbrenging van systemen. Het hoofdstuk Rol CROW bespreekt de rol van CROW. De CROW is de aangewezen partij om op sectorniveau de regie te voeren over de ondersteuning van de Systems Engineering implementatie. De regierol sluit aan bij de profilering van CROW als het nationale kennisplatform 6
voor infrastructuur, verkeer, vervoer en openbare ruimte. In dit hoofdstuk wordt invulling gegeven aan de visie in termen van initiatieven over de invulling van de rol en interactie met andere op Systems Engineering gebaseerde initiatieven op lange termijn. De notie wordt afgesloten met een plan van aanpak voor een implementatietraject in de sector.
7
3 Visie Door zowel maatschappelijke ontwikkelingen als de internationalisering is de GWW-sector in beweging. Het programma Systems Engineering van de CROW ondersteunt de partijen in de GWW-sector om op deze ontwikkelingen in te spelen. De visie van het programma laat zich als volgt verwoorden Visie Het bevorderen van een integraal voortbrengingsproces waarmee alle partijen in de GWW-sector op een duurzame wijze, maatschappelijk verantwoord en internationaal concurrerend waarde creëren over de hele levensduur (aanleg, beheer, onderhoud en sloop) van de fysieke infrastructuur. Systems Engineering is de basis voor het in de visie genoemde integrale voortbrengingsproces dat organisaties in staat stelt hun doelstellingen te verwezenlijken. Systems Engineering is gekoppeld aan de bedrijfsprocessen, die op hun beurt de bedrijfsdoelstellingen ondersteunen. Voor een succesvolle implementatie van Systems Engineering is het dus van belang inzicht te krijgen in de ontwikkelingen in de GWW sector. Iedere organisatie, die in de GWW sector wil overleven zal zijn doelstellingen aanpassen aan de veranderingen in de sector. Daarnaast bevordert de Systems Engineering benadering als concept deze ontwikkelingen. In dit geval is er sprake van push. Dit hoofdstuk geeft een beeld van de dynamiek van de GWW sector en laat zien hoe Systems Engineering helpt bij het inrichten van bedrijfsprocessen waardoor de organisatie optimaal kan inspelen op de kansen, die ontstaan in de GWW sector. Het hoofdstuk wordt afgesloten met een doorkijk op de toekomst van Systems Engineering in de bouw in drie scenario’s.
3.1 Waardeketen Op het Nederlandse Wegencongres in 2006 zei de toenmalige minister van Verkeer en Waterstaat Karla Peijs het volgende : “Het is fout als een sector leeft van de fouten in bestekken. Je moet leven van eerlijk samenwerken.”. Wat betekent eerlijk samenwerken? Het antwoord op deze vraag ligt verscholen in de waardeketen van de GWW sector. Een organisatie kan alleen duurzaam winst maken, wanneer de organisatie het genereren van waarde voor de klant als leidend principe hanteert. Van Dale geeft omschrijft “waarde” als “betekenis die iets heeft als bezit of ruilobject”. Verschillende partijen die begrip hebben voor de betekenis, die diensten en goederen voor elkaar hebben, zijn uitstekend in staat eerlijk samen te werken. Wij laten nu zien hoe waardeketens in de GWW sector er uit zien en vervolgens lichten we toe hoe dit inzicht helpt bij het eerlijk samenwerken.
8
Afbeelding 3: Waardeketen in de GWW sector
In afbeelding 3 is een waardeketen van een spoor- water- of verkeersweg afgebeeld. Als voorbeeld nemen we een spoorweg. In Nederland wordt door ProRail de rol van Systeemintegrator, Infraprovider en Verkeersmanager ingevuld. NS is een spoorgebruiker, die diensten aan de reiziger aanbiedt. Verschillende gebruikers bieden goederenvervoerscapaciteit aan. Betonbouwers, technische installateurs, verkeerstechniek leveranciers en ingenieursbureaus leveren aan de systeemintegrator toe. Neem nu als voorbeeld de renovatie van bestaande spoorinfrastructuur. In zijn rol als systeemintegrator zal ProRail de markt aansturen met een uitvraag. De belangrijkste waarde voor ProRail is dat de werkzaamheden een minimale verstoring geven op de beschikbaarheid van het spoor voor de spoorgebruiker. Een potentiële aanbieder kan goed scoren door met ProRail mee te denken over het optimaliseren van de beschikbaarheid en door ProRail het vertrouwen te geven dat het werk op schema wordt uitgevoerd. Dit vertrouwen kan gebaseerd worden op een transparant voortbrengingsproces door aan te geven op welke wijze risico gemanaged wordt en hoe ontwerp beslissingen genomen worden en door inzage te geven in dit proces tijdens de uitvoering. Andere kansen voor eerlijk samenwerken ontstaan wanneer partijen opschuiven in de waardeketen. Onder druk van de politiek moeten de landelijke infrastructuurmanagers Rijkswaterstaat en ProRail met minder mensen meer output leveren. Door de rol van systeemintegrator in de markt te leggen schuiven ProRail en Rijkswaterstaat op in de waardeketen en voldoen ze aan de wensen van de politiek. De belangrijkste succesfactoren voor het uitbesteden van de systeemintegrator rol zijn tweeledig. Ten eerste dat de marktpartij aan kan tonen de daarbij behorende risico's op een adequate wijze te managen en ten tweede dat er een samenwerkingsvorm wordt gekozen tussen infrastructuurmanager en systeemintegrator, die recht doet aan de wederzijdse afhankelijkheid. De systeemintegrator is zich bewust van de complexiteit van proces en product, wederzijdse afhankelijkheid van proces en product, veranderbaarheid van proces en product en de beslissingsbevoegdheden. Een voortbrengingsproces dat helpt complexiteit te beheersen en transparantie garandeert is noodzakelijke voorwaarde voor het uitbesteden van de systeemintegrator rol.
3.2 Effect van Systems Engineering als “Haarlemmerolie” Organisaties, die optimaal willen profiteren van de veranderingen in de waarde keten binnen de GWW sector hebben een behoefte aan een voortbrengingsproces dat transparantie waarborgt en dat complexiteit beheersbaar maakt. Een voortbrengingsproces gebaseerd op Systems Engineering voldoet aan deze eisen. Transparantie kan worden bereikt door processen Reviews uitvoeren en herplannen en Change control in te voeren en door het beheersbaar maken van de procesovergangen. 9
Het proces Reviews uitvoeren en herplannen houdt toezicht op alle taken die nog uitgevoerd moeten worden. In de reviews wordt de consistentie van het ontwerp bewaakt. De reviews zijn fijnmazig op het niveau van de werkvloer en wijdmazig op het niveau van het management en de klant. Het doel van dit proces is om ontwerpproblemen in een zo vroeg mogelijk stadium te detecteren zodat deze tegen minimale kosten en vertragingen opgelost kunnen worden. De transparantie wordt gegarandeerd door met de klant in het contract een aantal essentiële reviews op te nemen. Daarnaast kan de klant ook inzage gegeven worden in hoe de gedetecteerde problemen worden opgelost en hoe de planning wordt aangepast. Het proces Change control is het omgekeerde proces. In dit proces worden gedetecteerde problemen geanalyseerd en wordt bepaald in hoeverre reeds afgerond werk aangepast moet worden. Hier wordt de transparantie gewaarborgd door van te voren met de klant af te spreken wanneer en op welke wijze de klant betrokken wordt bij het detecteren en oplossen van problemen. Het begrip klant in het bovenstaande kan op verschillende niveaus bekeken worden. De opdrachtgever is de klant voor de opdrachtnemer. De opdrachtnemer is de klant van de onderaannemer (enz.). De Systems Engineering processen risico management, configuratie management en requirements management ondersteunen het management van complexe projecten. Het effect van Systems Engineering wordt maximaal als alle partijen in de waardeketen een uniforme aanpak van Systems Engineering gebruiken en zo vroeg mogelijk in de levensduur starten met het gebruik. De uniforme aanpak draagt zorg voor een eenduidige fasering van het proces, voor standaardisatie van reviews, die gebruikt worden bij de faseovergangen en voor een eenduidige visie gericht op het voortdurend aantonen van de verwachtingswaarde voor de klant.
3.3 Pijlers van Systems Engineering In het voorgaande is de term Systems Engineering verschillende keren gebruikt. Het is tijd om stil te staan bij de uitgangspunten van Systems Engineering. Systems Engineering wordt gebruikt in ontwikkeltrajecten. Het doel van zo'n ontwikkeltraject is dat de opdrachtgever een systeem krijgt dat voldoet aan de verwachtingen en dat binnen het beschikbare budget en tijdschema wordt geleverd. Systems Engineering is gebaseerd op vier uitgangspunten. Deze zijn: ●
Regie versus creatie;
●
Eerst het probleem doorgronden en dan oplossen;
●
Verificatie en validatie;
●
De levenscyclus als uitgangspunt.
3.3.1 Regie versus creatie De ontwikkeling van een systeem wordt als een project uitgevoerd. Binnen zo'n project zijn twee activiteiten te onderscheiden nl. Systems Engineering en Projectplanning en -controle. Deze twee activiteiten overlappen deels. Zie afbeelding 4. De focus van beide activiteiten is echter verschillend. Projectplanning en -controle helpen de projectmanager bij het sturen op tijd, geld en kwaliteit. Een project is tijdelijk en de tijdshorizon van de projectmanager is beperkt. Na het project gaat de projectmanager een ander project doen. Echter het kader van de Systems Engineering wordt bepaald door de levensduur van het systeem. Het regie aspect richt zich op het sturen op geld en tijd en het creatie aspect richt zich op het creëren van een systeem van voldoende kwaliteit dat voldoet aan de wensen en behoeften van de klant en gebruiker van het systeem.
10
Afbeelding 4: Systems engineering / Project management (bron Alexander Kossiakoff en William N. Sweet (2003) Systems Engineering Principles and Practices, John Wiley & Sons Inc., p. 91)
Systems Engineering verankert het systeemdenken in het project en borgt het technisch en creatief geweten van een systeem. Systeem architectuur biedt goede aanknopingspunten om het systeemdenken te concretiseren. Het systeemdenken is het ontwikkelen van de bewustwording van complexiteit van proces en product, wederzijdse afhankelijkheden daarbinnen, gevoeligheid voor veranderingen en beslissingsbevoegdheden. In het kader van het Gaudi project heeft Gerrit Muller een aantal gezichtpunten ontwikkeld, die een systeemarchitect in staat stelt een totaal overzicht te krijgen van het system of interest (zie CAFCR framework binnen SARCH op www.gaudisite.nl). Deze gezichtspunten ondersteunen het systeemdenken. De vijf gezichtspunten zijn: Klantenperspectief ◦ Wie is de klant? ◦ Wat drijft de klant? ◦ Wanneer is de klant tevreden? ● Gebruik- / gebruikersperspectief ◦ Wie gebruiken het systeem? ◦ Hoe wordt het systeem gebruikt? ◦ Zijn er andere belanghebbenden en zo ja wat zijn hun belangen bij het systeem? ● Functionele perspectief ◦ Welke functionaliteit moet het systeem hebben? Prestaties, gebruikersgemak, etc. ◦ Welke fysieke eisen zijn er? Afmetingen, gewicht, etc. Bestand tegen omgevingsinvloeden (wind, zeewater, schokken, trillen, etc,) ◦ Welke niet-functionele kwaliteiten zijn vereist? Betrouwbaarheid, Veiligheid, Beschikbaarheid, Onderhoudbaarheid, etc. ● Conceptperspectief ◦ Welke systeem- en productconcepten bestaan er en welke worden toegepast door de systeemleverancier? ◦ Hergebruik van bestaande bouwblokken in het systeem ● Productieperspectief ◦ Welke productiemethoden worden toegepast? ●
11
◦ Wat is de status van de productiemethoden? ◦ Hoe ziet de supply chain er uit? Het functionele perspectief staat centraal bij het systeemdenken. Bij het van “buiten naar binnen” denken draait het vooral om het klanten- en gebruik-/gebruikersperspectief, terwijl het van “binnen naar buiten” denken door het concept- en productieperspectief wordt gedomineerd. De verwachtingswaarde van de klant is leidend. Vandaar dat het van “buiten naar binnen” denken dominant is binnen het voortbrengingsproces.
3.3.2 Eerst het probleem doorgronden en dan oplossen Het uitgangspunt bij Eerst het probleem doorgronden en dan oplossen is dat het probleem eerst gedefinieerd moet worden voordat de oplossing wordt geïmplementeerd. Systems Engineering is een iteratief proces met zowel een top-down als een bottom-up aspect. Deze iteratieslagen moeten eerst met een voldoende diepgang doorlopen worden voordat de definitieve oplossing wordt gekozen en vervolgens geïmplementeerd. Systems Engineering is gebaseerd op een hiërarchisch systeemmodel dat uit verschillende niveaus bestaat (systeemniveau, sub-systeemniveau, moduleniveau, componentniveau etc.). Het probleem wordt omschreven met eisen. Ieder niveau stelt eisen aan het niveau daaronder. De specificaties beschrijven de oplossing. Hierdoor ontstaat een vraag en antwoord spel. De specificaties van het systeem zijn een antwoord op de eisen van de klant. De specificaties van het sub-systeem zijn een antwoord op de eisen van het systeemniveau enzovoort. Bij de specificatie van het systeem stromen eisen van het hoogste systeem niveau naar de subsystemen. Hierbij is de traceerbaarheid van de eisen en ontwerpbeslissingen van groot belang. Verticale traceerbaarheid wordt bereikt door eisen op subsysteem te koppelen aan die op het bovenliggende niveau. Bij de horizontale traceerbaarheid wordt de link gelegd tussen de eis en de wijze waarop de eis wordt aangetoond tijdens de integratie. De analyse van de eisen wordt afgesloten met een review waarin getoetst wordt of de verzameling eisen volledig is en of de eisen goed geformuleerd zijn. Een aandachtspunt is dat bij de definitie van de oplossing rekening gehouden moet worden met de stand der techniek. Definieer daar waar mogelijk de oplossing functioneel en stel definitieve technische keuzes zo lang mogelijk uit. Denk hierbij aan bijvoorbeeld computersystemen. Gekozen oplossingen kunnen op het moment van realisatie al verouderd zijn. Aan de andere kant kan het ook voorkomen dat bepaalde technische oplossingen niet beschikbaar zijn ten tijde van de realisatie (de keuze van het beveiligingssysteem van de Hoge Snelheidslijn (HSL) is hier een voorbeeld van)
3.3.3 Verifiëren en valideren Een systeem wordt gebouwd aan de hand van een programma van eisen. Tijdens het ontwerp en realisatie van het systeem zijn er een aantal ijkpunten gedefinieerd in het contract, waarbij de systeemleverancier aan de klant moet aantonen dat het systeem aan het programma van eisen voldoet of gaat voldoen. Dit proces heet verifiëren. Daarnaast hebben de klant en de belanghebbenden ook een aantal wensen en verwachtingen met betrekking tot het operationeel gebruik van het systeem. Tijdens de validatie wordt aangetoond dat het systeem aan deze wensen en verwachtingen voldoet. Het verschil tussen verificatie en validatie kan op de volgende manier verduidelijkt worden. Bij de verificatie wordt gekeken of het systeem goed gebouwd is, terwijl de validatie onderzoekt of het goede systeem gebouwd is. Een belangrijk aspect bij verificatie en validatie is de zogenaamde kwalificatie. Bij de kwalificatie wordt verificatie- en validatiebewijslast verzameld per systeemonderdeel. Bij hergebruik van het systeemonderdeel in een volgend systeem kan de kwalificatiebewijslast worden hergebruikt, wat tot een kostenvoordeel leidt. Tijdens het verificatie- en validatieproces worden ontwerp- en productiefouten opgespoord. Een structurele aanpak van het verwerken van foutmeldingen, probleemrapporten en meldingen van defecte onderdelen en het daaraan gekoppelde wijzigingen proces is van groot belang. 12
3.3.4 Levenscyclus als uitgangspunt Na de validatiefase is het systeem volledig operationeel. Tijdens deze operationele fase genereert het systeem waarde voor de klant en belanghebbenden. Het “succes” van het lyfe cycle proces wordt voornamelijk bepaald door de niet functionele kwaliteiten (veiligheid, betrouwbaarheid, beschikbaarheid, onderhoudbaarheid, etc.) van het systeem. Daarom is het van belang te onderzoeken hoe zwaar de eisen van het life cycle proces meewegen in het ontwerpproces.
3.4 Coöperatief businessmodel We grijpen nu weer terug op de woorden van Karla Peijs in 2006 “Je moet leven van eerlijk samenwerken”. De Special Purpose Companies (SPC's) of Special Purpose Vehicles (SPV's) , die ontstaan in Publiek-Private Samenwerkingen kunnen ook onder Eerlijk samenwerken geschaard worden. Binnen een SPC/SPV is een gemeenschappelijk doel en wederzijdse afhankelijkheden. Dit leidt tot een coöperatief businessmodel. Publiek-Private Samenwerking is niet de enige aanleiding voor het ontstaan van een coöperatief businessmodel. Projecten in de GWW sector worden complexer en de “intelligentie” van de netwerken neemt toe. Voorbeelden hiervan zijn Autoweg Management Systemen, bediening van sluizen en bruggen op afstand en nieuwe generatie ATB systemen. Opdrachtgevers willen meer risico bij hun toeleveranciers neerleggen en de toeleveranciers moeten steeds meer vertrouwen op het innovatieve vermogen van hun supply chain. Vergelijkbare ontwikkelingen in de complexe maakindustrie, automotive en aerospace hebben in deze branches geleid tot constructieve samenwerkingsverbanden in de waardeketen, zowel verticaal als horizontaal.
3.4.1 Case1: A15 Maasvlakte Vaanplein. 3.4.1.1 Inleiding De Al5 is een essentiële schakel tussen de haven van Rotterdam en het achterland. De reconstructie van de A l5 Maasvlakte-Vaanplein (MaVa) is gerelateerd aan twee andere projecten, de ontwikkeling van de 2e Maasvlakte en de ontwikkeling van de Mainportcorridor Zuid (PMZ). De capaciteit van de A l5 moet gelijke tred houden met de ontwikkeling van de 2e Maasvlakte. Binnen PMZ wordt de corridor rond de A4 tussen Rotterdam en Antwerpen ontwikkeld. De verbreding van de A l5 is een noodzakelijke voorwaarde voor PMZ. MaVa wordt als DBFM in een Publiek-Private Samenwerking (PPS) op de markt gezet. Het beleid van de overheid is erop gericht de PPS in te zetten voor grote infrastructurele projecten. PPS biedt een optimale omgeving voor een succesvolle realisatie van het project. De overheid wil door het MaVa project PPS in Nederland op een hoger plan tillen. Het PPS beleid is gericht op prestatieverbetering. Middels een PPS wordt een integrale dienst aangeboden en geleverd. Een PPS stimuleert innovatieve oplossingen en geeft ruimte aan ontwerpbeslissingen, die de kosten over de totale levensduur optimaliseren.
3.4.1.2 Uitdagingen De uitdagingen voor MaVa zijn: ● Verkeerstromen van ongeveer 100.000 voertuigen per dag; ● Verhogen van de verkeersveiligheid; ● De toegankelijkheid van de Rotterdamse haven garanderen tijdens de werkzaamheden; ● Hinder voor de scheepvaart verminderen bij de Botlekbrug.
3.4.1.3 Doelstellingen Voor MaVa heeft Rijkswaterstaat de volgende doelstellingen gedefinieerd ● Robuuste en duurzame oplossing waarmee: ◦ De toegankelijkheid van de haven van Rotterdam vanuit het achterland verbeterd wordt; ◦ De verkeersveiligheid op de A15 verhoogd wordt; 13
◦ De hinder voor de scheepvaart bij de Botlekbrug verminderd wordt. Het project kent een aantal randvoorwaarden. Dit zijn: • Een minimaal ongemak voor de weggebruikers in het bijzonder tijdens de constructie fase; ◦ De verkeersstroom in stand houden; ◦ Aantal bestaande rijstroken in stand houden; • Geluidsoverlast en luchtverontreiniging binnen de perken houden; • Rekening houden met kabels en pijpleidingen; • Samenstelling van het wegverkeer (bijv. 30% zware opleggers); • Beperkte ruimte voor uitbreiding. De kerncijfers voor het project zijn: ● Een geschatte constructieperiode (verbreding en vernieuwing) van 6 jaar; ● Onderhoudperiode van 25 jaar; ● Eén DBFM contract (>20 jaar); ● Totale omvang ongeveer € 2 miljard; ● Primaire doelstelling: Beschikbaarheid
3.4.1.4 Verwachtingen opdrachtgever (Rijkswaterstaat) De opdrachtgever wil waar voor zijn geld door een concurrerend aanbiedingsproces dat leidt tot een succesvolle projectrealisatie met een optimale beheersbaarheid van de risico's. Rijkswaterstaat heeft gekozen voor een PPS constructie omdat dit een beleid ondersteunt dat focusseert op prestatieverbetering, een optimale afweging van kosten en baten mogelijk maakt over de totale levensduur (constructie, beheer en onderhoud). Daarnaast biedt het ruimte aan de markt om met innovatieve oplossingen te komen. Door het gebruik van een DBFM verwacht Rijkswaterstaat sterke en toegewijde partners te vinden, die een veilige en duurzame oplossing realiseren waarvoor zij de volle ontwerpverantwoordelijkheid dragen. Rijkswaterstaat streeft naar een langdurige relatie met hoogwaardige toeleveranciers, die hun volledige keten van toeleveranciers bij de partnerrelatie betrekken. De beoogde partners kunnen kennis en ervaring mobiliseren voor het leveren van excellente diensten aan weggebruikers en andere belanghebbenden.
3.4.1.5 Verantwoordelijkheden opdrachtnemer Met dit contract wil de overheid gebruiken om DBFM contracten in Nederland te stroomlijnen. Dit moet leiden tot het gebruik van een standaard DBFM procedure. De verantwoordelijkheden voor de opdrachtnemer zijn: ● Ontwerp (Design); ● Realisatie (Build); ● Onderhoud (Maintain); ◦ Bestaande infrastructuur; ◦ Nieuw aan te leggen infrastructuur; ● Financiering (Finance) Tijdens de uitvoering van het contract (>30 jaar) wil de opdrachtgever inzicht hebben in de prestaties van de opdrachtnemer. Hiervoor moet de opdrachtnemer een structuur optuigen waarmee aan de opdrachtgever aantoonbaar gemaakt wordt dat de risico's beheerst worden, de voortgang volgens schema is en dat de contractprestaties gehaald worden. De contractprestaties worden beschreven in de kwaliteit van de dienstverlening aan de weggebruikers en andere belanghebbenden. Voor MaVa is beschikbaarheid de belangrijkste prestatie. Beschikbaarheid uitgedrukt in een vlotte en veilige doorstroming op alle rijstroken in alle richtingen voor iedere weggebruiker. De betaling aan de opdrachtnemer worden gekoppeld aan deze prestaties. De prestaties worden genormeerd. Bij beter presteren dan de norm verdient de opdrachtnemer meer en bij slechter presteren legt de opdrachtgever boetes op.
3.4.1.6 Systems Engineering Binnen het project is een noodzaak voor een gestructureerd ontwerpproces. Deze noodzaak is 14
tweeledig. Ten eerste moet de systemintegrator / design authority de risico’s beheersen. Hiervoor is het van belang dat de ontwerpbeslissingen expliciet gemanaged worden en dat de partners in de supply chain inzage geven in de voortgang. Ten tweede is er een Performance Regime van kracht. Dit regime koppelt betalingen van de opdrachtgever aan de geleverde prestaties. De toekomstige kasstroom wordt voorspelbaar door dit regime. In het contract zullen eveneens een aantal prikkels voor prestatieverbeteringen opgenomen worden. De opdrachtnemende partij kan optimaal profiteren van dit regime wanneer de voortgang voorspelbaar is (transparant proces door de hele supply chain) en wanneer formele design reviews in de planning worden opgenomen.
3.4.2 Case 2: Trespa 3.4.2.1 Inleiding Trespa International BV is wereldwijd marktleider in de ontwikkeling, productie en levering van hoogwaardige panelen voor decoratieve gevelbekleding en interieuroppervlakken. Met bedrijfseigen technologieën streeft Trespa ernaar nieuwe hoge standaarden te realiseren in bouwen, persoonlijke levensstijl en de zorg voor de natuur. In de afgelopen 10 jaar heeft het bedrijf een succesvolle transformatie door gemaakt van leverancier van standaard gevelplaten naar een partner van de architect voor het ontwikkelen van innovatieve geveloplossingen.
3.4.2.2 Tepelarchitectuur In de jaren 70 en 80 van de vorige eeuw werden Trespa gevelplaten veelvuldig gebruikt in nieuwbouwwijken. Door de standaardplaten met de karakteristieke doppen voor de bevestiging aan de woning spreekt met ook wel van tepelarchitectuur voor de wijken, die in deze periode zijn gebouwd. Rond 1990 had Trespa een marktaandeel van rond de 85% in Nederland en België met de standaardplaten. Om de gewenste groei te generen heeft Trespa zich georiënteerd op het aanpassen van het businessmodel. In 1991 is Trespa door Hoechts aan Hal Investments verkocht. Door de komst van Hal kreeg dit nieuwe businessmodel een impuls.
3.4.2.3 Opschuiven in de waardeketen Het nieuwe businessmodel is gebaseerd op het innoveren van het Trespa merk waarmee nieuwe markten betreden kunnen worden. Het imago moest veranderen van saai en degelijk naar innovatief en trendy. Op haar website profileert Trespa zich op dit moment als volgt. Trespa voorziet architecten en installateurs van innovatieve, esthetisch aantrekkelijke en hoogwaardige oplossingen voor vrijwel alle toepassingen. Met andere woorden Trespa wil waarde creëren voor haar klant. Een essentieel onderdeel van deze strategie is dat naast nieuwe producten ook nieuwe competenties binnen het bedrijf ontwikkeld worden.
3.4.2.4 Design management Begin jaren negentig was het leveren van stadaard gevelplaten de core business van Trespa. De verkoopstaf ging met stalenboeken onder de arm langs aannemers. Echter met alleen een stalenboek maak je geen indruk op architecten. Onder het motto “Je bent alleen een gesprekspartner voor architecten wanneer je de taal van de architecten spreekt” is de competentie Design Management binnen Trespa ontwikkeld. Hiervoor zijn nieuwe mensen uit de markt aangetrokken. Systems Engineering is een essentieel onderdeel van Design Management (de term omvat zowel het creatieve als het regie aspect).
3.4.3 Systems Engineering ter ondersteuning van een coöperatief businessmodel Binnen de GWW sector is er een behoefte aan een coöperatief businessmodel voor de creatie, realisatie en exploitatie van complexe systemen. Binnen de samenwerkingsverbanden is het van 15
belang zowel projectrisico's als de systeemrisico's optimaal te managen. Systems Engineering biedt handvatten hiervoor. De bruikbaarheid van Systems Engineering voor het beheersen van de projectrisico's is in het voorgaande al voldoende belicht. De systeemrisico's refereren naar de risico's bij het gebruik van het systeem. Door voldoende aandacht te besteden aan systeem architectuur kunnen de systeemrisico's adequaat beheerst worden. Essentieel is dat tijdens het ontwerp de systeemverantwoordelijkheid belegd wordt. Het is de systeemverantwoordelijke, die zorg moet dragen voor een goede validatie van het systeem. Met de validatie kan de systeemverantwoordelijke gedurende de levensduur van het systeem bepalen wat de risico's zijn van het aangapassen onderhoud regimes en van het up graden van het systeem. Tevens kan via de discussie over de systeemverantwoordelijkheid de verantwoordelijkheid van toeleveranciers en partners afgebakend worden.
3.4.4 Voordelen op bedrijfseconomisch, maatschappelijk en operationeel gebied Door Systems Engineering op een juiste manier toe te passen levert een coöperatief businessmodel vele voordelen. Een coöperatief businessmodel biedt de randvoorwaarden om optimaal gebruik te maken van de intelligentie in de supply chain. De spelers worden gestimuleerd om met innovatieve en kosteneffectieve oplossingen te komen. Hierbij speelt de uniformering van het ontwerpproces een belangrijke rol. Voorwaarde hiervoor is wel dat er voldoende aanbieders zijn. Bij te weinig aanbieders driegt de zogenaamde vendor lock. Daarnaast kan de toeleverancier ook aan concurrenten van de systeemintegrator leveren. Echter er bestaat ook de kans dat door uniformere aanpak in het ontwerpproces en het verschuiven van ontwerpverantwoordelijkheid in de supply chain een sterke cluster van toeleveranciers ontstaat,die een belangrijke bijdrage levert aan de bedrijfseconomische en maatschappelijke ontwikkeling.
3.4.5 Invloed op de rollen in de keten en het werk- en denkniveau van de medewerkers Een gevolg van een coöperatief businessmodel is dat de verantwoordelijkheid van de partijen in de supply chain toeneemt. De grote bouwondernemingen zullen de rol van systemintegrator verder ontwikkelen. Waarschijnlijk zullen een aantal ingenieursbureaus zich ook in de rol van systemintegrator gaan profileren door allianties aan te gaan met partijen die risico kunnen dragen (bijv. banken). Zoals in het voorgaande is beschreven verandert ook de rol van toeleveranciers. Er wordt steeds meer product- en systeemverantwoordelijkheid in de keten gebracht. Dit houdt in dat er op alle niveaus in de waardeketen systeemdenken zijn intrede doet. Iedere speler in de keten moet beschikken over mensen die minimaal één niveau hoger mee kan praten over het ontwerp betreffende het “system of interest” .
3.4.6 Invloed van de levenscyclus In de markt worden contractvormen ontwikkeld, die niet alleen het ontwerp en realisatie maak ook de exploitatie van infrastructurele objecten en systemen omvatten. Al dan niet in PPS constructies worden consortia gevormd, die deze contracten uitvoeren. Het goed beleggen van de systeemverantwoordelijkheid over de hele levenscyclus is een belangrijke succesfactor in deze contracten. Deze verantwoordelijkheid ligt niet alleen op het niveau van het consortium maar heeft aspecten in de hele keten.
3.5 Implementatie van een voortbrengingsproces gebaseerd op Systems Engineering Het is duidelijk dat de veranderingen in de waardeketen in de GWW sector vragen om een voortbrengingsproces dat op Systems Engineering gebaseerd is. In de keten werken verschillende 16
partijen samen dus de eerste noodzaak is om tot een uniforme omgeving te komen zodat de transparantie gegarandeerd wordt. Dit betekent dat de faseovergangen in het proces benoemd moeten worden en dat ketenwijde afspraken gemaakt worden over de vorm en inhoud van de reviews, die deze overgangen aansturen. Daarnaast moet er in de sector eenduidigheid bestaan over de definitie van de verschillende fasen. Zoals reeds in de Leidraad voor Systems Engineering binnen de GWW-sector is geconstateerd is er behoefte aan een gemeenschappelijke taal binnen de sector. Het is dus voor de hand liggend om de taal, die in de Leidraad wordt voorgesteld te gebruiken bij de implementatie. De Leidraad voor Systems Engineering binnen de GWW-sector geeft een goede aanzet voor een uniforme omgeving van het voortbrengingsproces in de sector. Echter voor het optimaal managen van de complexiteit van ontwikkel-, realisatie- en exploitatieprojecten is een verdiepingsslag nodig. Elementen uit de verdiepingsslag zijn: ●
Uniforme fase reviews (Inhoud, rollen en go/ no go criteria)
●
Uniform Change control proces
●
Uniform risicomanagement, configuratie management en requirements management
Bij deze verdiepingsslag is een leidende rol voor de CROW weggelegd. De bovengenoemde elementen sluiten goed aan bij de CROW activiteiten op het gebied van afsprakenstelsels (bijv. UAV-GC 2005, U.A.V. '89, VISI). Daarnaast heeft CROW meerwaarde door inhoudelijke ondersteuning van het proces te bieden. Naast het Oplossingsvrij specificeren is de sector gebaad bij een Systems Engineering handboek gericht op de GWW sector. In dit handboek moeten de volgende aspecten herkenbaar zijn: proces, project, rollen en op te leveren documenten. Met dit handboek kan dan iedere partij in de sector een Systems Engineering implementatie kiezen, die past bij de organisatie. Dit betekent concreet dat de organisatie de processen kan vertalen in organisatiespecifieke procedures, een link kan leggen met de projectmanagement methodiek, die in de organisatie gebruikt wordt, de rollen kan projecteren op functies in de organisatie en organisatie specifieke sjablonen en 'best practices' kan koppelen aan de op te leveren documenten. Voor het succesvol uitvoeren van het voortbrengingsproces in de sector is het ook noodzakelijk dat de 'best practices' en kennisbanken in beheer bij het CROW worden gekoppeld aan het Systems Engineering proces. Daarom moet er in het handboek ook aandacht besteed worden aan de koppeling van de CROW databanken met de relevante processtappen. Voor de goede orde moet bij het begrip handboek niet aan een fysiek boek maar aan een website gedacht worden. Een zeer goed voorbeeld is het Systems Engineering Guidebook for ITS. (http://www.fhwa.dot.gov/cadiv/segb/).
3.6 Systems Engineering in de toekomst van de bouw Toepassing van SE in de bouw heeft zowel invloed op de bedrijfsprocessen van organisaties als op de technische en managementprocessen van projecten. Het gaat dan niet alleen om beïnvloeding van huidige werkwijzen maar ook om beïnvloeding van denk- en redeneerwijzen ter ondersteuning van het voortbrengingsproces van bouwobjecten. De denk- en redeneerwijzen zijn in te delen naar een drietal dimensies van het SE ontwikkelproces. In de eerste plaats de dimensie van de denkwijzen ingevuld door chaosdenken, systeemdenken en machinedenken. In de tweede plaats de dimensie van de abstracties ingevuld door de doel-middel redenering. Hiermee wordt van abstract naar concreet geredeneerd ofwel van behoefte naar oplossing. In de derde plaats de dimensie van de aggregatie ingevuld door de redenering van geheel naar delen. Hiermee wordt vanaf systeemniveau geredeneerd naar component niveau.
17
Schematisch zijn de drie dimensies als volgt weer te geven (zie afbeelding 5):
Oplossing
Oplossing Oplossing
Behoefte Machine Concreet
Behoefte
DENKWIJZE Systeem ABSTRACTIE Chaos
Behoefte Component
AGGREGATIE
Geheel
Abstract
Afbeelding 5: Drie dimensies van het Systems Engineeirng ontwikkelproces
De ontwikkelbenadering volgens Systems Engineering kan in meer of mindere mate opgespannen worden vanuit de dimensies. Aard en context van het ontwerpprobleem bepalen de benodigde specifieke procedures, methoden en technieken voor het inrichten, besturen en uitvoeren van het ontwikkelproces. Deze benaderingswijze van het voortbrengingsproces is betrekkelijk nieuw voor de bouw en noopt tot verandering van bestaande traditionele werkwijzen, maar ook van denk- en redeneerwijzen. Terwijl de eerste verandering beperkt kan blijven tot het aanpassen van bestaande methoden en technieken gaat het er bij de laatste twee om verandering van mind-set en dus competenties van medewerkers. Om die veranderingen in organisaties en projecten te bewerkstelligen is een traject van initiatie, adoptie, implementatie en assimilatie noodzakelijk. Bij de initiatie bepaalt de organisatie het standpunt om de werkwijze volgens SE al of niet te adopteren. Druk om te veranderen kan voortvloeien uit een interne behoefte, een externe opgelegde werkwijze of beide. Aangezien grote opdrachtgevende partijen, zoals ProRail en Rijkswaterstaat, de werkwijze volgens SE voorschrijven is aan een positief standpunt over adoptie van SE bijna niet te ontkomen. Bij de adoptie gaat het er in eerste instantie om de business waarde van de nieuwe werkwijze en de uitdagingen gepresenteerd door het verander perspectief af te wegen voordat een organisatie beslist om door te gaan en middelen vrij te maken. Vervolgens is het creëren van draagvlak en het veilig stellen van benodigde middelen essentieel. Ten slotte moet dit leiden tot het ontwikkelen van een implementatiestrategie en implementatieplan, waarmee de onderbouwing van het besluit de werkwijze daadwerkelijk te implementeren alsmede de wijze waarop wordt vastgelegd. In de implementatiefase gaat het om een groot aantal overwegingen, keuzes en acties die vorm geven aan de veranderde wijze van werken. Het gaat dan om het uitwerken van een aanpassingsfase en een acceptatiefase. In de aanpassingsfase staat het op maat maken van de 18
werkwijze centraal afgestemd tussen individuen, organisaties en/of andere werkwijzen. In de acceptatiefase staat de toepassing van de werkwijze centraal. Acceptatie is erop gericht om de medewerkers van de organisatie ervan te overtuigen de werkwijze op de juiste wijze toe te passen. In de assimilatie fase zal het nut van de werkwijze zichtbaar moeten worden. In eerste instantie zal sprake zijn van het opdoen van ervaring met de werkwijze om vervolgens de werkwijze ook in een bredere context toe te passen zodat het volledige vermogen benut kan worden. De bedoeling is dan dat de werkwijze volledig opgenomen wordt in de werkprocessen van de organisatie en in de competenties van de medewerkers. Tijdens deze fase zal het monitoren en evalueren van kenmerken van de werkwijzen en de reactie van medewerkers daarop een belangrijke rol vervullen om de waarde van de werkwijze te bepalen en te onderbouwen. Door een traject van initiatie naar assimilatie zorgvuldig te doorlopen kan de benaderingswijze volgens SE vanuit een ambachtelijke wijze van werken ontwikkeld worden tot een professionele technische en management ondersteuning van het voortbrengingsproces in de bouw, zowel op project- als bedrijfsniveau. Het is echter moeilijk de toekomst van de ontwikkeling van SE te beschrijven zonder de condities voor de toekomstige vraag en aanbod kant van de bouwmarkt daarin te betrekken. De toepassing van SE zal dan ook geplaatst moeten worden in de context van toekomstscenario’s met daarbinnen aandacht voor mogelijke ontwikkelingen in de houding van de opdrachtgevende partijen, contractstrategieën, structuur van de uitvoerende bouwbedrijven en ontwikkelingen in de adviesbranche. In deze paragraaf zullen een drietal scenario’s beschreven worden met daarbinnen een schets van mogelijke ontwikkelingen van SE in de toekomst. Hiertoe zullen huidige trends geëxtrapoleerd worden tot de drie scenario’s, te weten: 1. status quo; 2. meest waarschijnlijke; 3. radicaal gezichtspunt op de toekomst. Tegen de achtergrond van deze drie scenario’s worden voorstellen gedaan voor inzet van SE.
3.6.1 Scenario 1: Status quo Houding opdrachtgevers ten aanzien van hun onroerende goederen De private sector ziet bezittingen in het algemeen als kostenpost en in mindere mate als productiemiddelen om zaken mee te doen en winst mee te behalen. De publieke sector ziet het nut van hun bezittingen in het algemeen als dienstverlenend voor een grote groep mensen en meestal bepaald door de functionaliteit van het object (ProRail , RWS, Waterschappen,etc.). Het PPS concept, waarin het niet noodzakelijk is het gebouwde object te bezitten om de dienstverlening te waarborgen, wordt in deze context dan ook niet met veel enthousiasme omarmd. Contractstrategieën Traditionele contractvormen overheersen nog steeds ook al wordt door publieke partijen steeds vaker de contractvorm D&C toegepast. Echter de D&C wordt gezien als een middel het risico van de opdrachtgever zoveel mogelijk te verschuiven naar de opdrachtnemers tegen een vaste prijs. Structuur uitvoerende bouwbedrijven De beheersing van kosten staat in de bouwbedrijven centraal. Supply chain concepten zijn nog niet ver doorgevoerd. Wijzigingsmanagement wordt in beperkte mate binnen projecten toegepast, maar meestal in een laat tot zeer laat stadium van het project met alle gevolgen van dien. Daarnaast is het imago van de uitvoerende bouw laag en blijkt weinig attractief voor nieuwkomers op de arbeidsmarkt maar ook als keuze voor vervolgopleidingen. Ontwikkelingen in de adviesbranche In de adviesbranche zien we een hoge mate van professionalisering en tevens de drang naar 19
ontwikkeling van uniforme omgevingen ter ondersteuning van ontwerpprocessen, met name op het gebied van ICT. Daarnaast is er een verschuiving te zien in de omvang van bureaus. Het aantal grote bureaus wordt kleiner en het aantal kleine bureaus steeds groter. De eerste groep richt zich veelal op een brede portfolio aan dienstverlening terwijl de laatste groep zich specialiseert op een smalle portfolio (niches in de markt). Kleine bureaus blijken zich steeds meer te specialiseren op het leveren van diensten ten aanzien van project en proces management: een groeimarkt. De vraag naar uniforme omgevingen neemt sterk toe vooral om de communicatie en informatie doorstroming binnen projecten en bedrijven effectief en efficiënt te laten verlopen. Toekomst van SE in de context van scenario 1 De toekomst ontwikkeling van SE binnen scenario 1 is beperkt. Het zal slechts reactief door markpartijen toegepast worden. Het volle vermogen van de werkwijze zal niet onderkend worden en het gevaar bestaat dat het als een administratieve last wordt gezien waarbinnen dienstverlening in de vorm van project- en procesmanagement een steeds grotere rol gaat spelen, maar waarin de waardevolle bijdrage van specifieke denk- en redeneerwijzen minder tot hun recht kunnen komen.
3.6.2 Scenario 2: Meest waarschijnlijke Het meest waarschijnlijke scenario is ontwikkeld op basis van de huidige maar nog zeer spaarzame successen van SE assimilatie op project- en bedrijfsniveau. Scenario 2 is het meest waarschijnlijke maar zal mogelijk niet voor 2012 zijn volle beslag krijgen binnen de bouw. Houding opdrachtgevers ten aanzien van hun onroerende goederen Sommige delen van de bouwmarkt zullen bouwobjecten meer en meer gaan zien als producten zoals in de industrie het geval is. We kunnen dan met name denken aan de private markt van woningen en kantoren. In de toekomst zullen gebouwen meer en meer gezien worden als productiemiddelen die bijdrage leveren aan de efficiëntie en productiviteit van een organisatie. De financiële en vastgoed sectoren zullen gebouwen wensen die exact voldoen aan doelgerichte en operationele behoefte van henzelf of hun klanten. Industriële bedrijven zullen hun waarde en nut van hun gebouwen op dezelfde wijze gaan beschouwen als hun productiemiddelen om bedrijfseconomisch voordeel mee te behalen. Gebouwen zullen in toenemende mate ontwikkeld worden of vanuit architectonisch oogpunt waarin de esthetische waarde de primaire functie bepaalt of vanuit het oogpunt van productiemiddel waarin ontwerpen vanuit assemblage en disassemblage binnen de context van duurzaamheid benadrukt wordt vaak beschouwd vanuit korte of langere levenscycli. Facility- en assetmanagement zullen in toenemende mate de voortbrenging van gebouwen gaan bepalen. In de publieke sector zal deze ontwikkeling veel trager verlopen, alhoewel de toename van PPS constructies deze zal versnellen. Contractstrategieën De industrie laat zien dat de verschuiving naar samenwerkingsverbanden vruchten afwerpt ten aanzien van efficiëntie en effectiviteit van voortbrengingsprocessen ondanks de hoge kosten voor de ondersteuning ervan. De grote opdrachtgevende organisaties die objecten zowel in eigendom hebben, gebruiken en aan marktpartijen verhuren zullen evenals in de industrie meer en meer bepalen dat binnen de bouwindustrie concurrentie op basis van traditionele aanbesteding zal verschuiven naar dienstverlening vanuit het concept van Design & Construct gebruik makende van gestructureerde supply chains met beperkt gebruik van openbare aanbesteding op basis van concurrentie. Verondersteld mag worden dat concurrentie tussen opdrachtnemers meer en meer bepaald zal worden door de mate van dienstverlening, competenties, karakteristiek van de supply chain en meetbare en aantoonbare waardegeneratie voor de klant. In de publieke sector zal deze ontwikkeling minder zich prominent voordoen alhoewel PPS constructies een waardevolle bijdrage gaan leveren. Meer en meer zal deze sector gebruik maken van prestatiegerichte vraagspecificaties waar vele stakeholders op effectieve en efficiënte wijze aan bijgedragen hebben. Nieuwe onderhoudstrategieën en assetmanagement concepten zullen 20
hun intrede doen vanwege meerjarige afspraken tussen opdrachtgevers en opdrachtnemers over het waarborgen van de beschikbaarheid en betrouwbaarheid van objecten in de tijd. Als gevolg hiervan verschuift de nadruk van het realiseren van producten naar het leveren van diensten. Zowel in de private als publieke sectoren van de bouw zullen de projecten meer en meer voorbereid en uitgewerkt worden door integrale product en proces teams waarin de opdrachtgevende en opdrachtnemende partij samen met vertegenwoordigers van toonaangevende supply chains deelnemen. Structuur uitvoerende bouwbedrijven Allianties waarin voor een gegarandeerde maximale prijs en op basis van een gedetailleerde opdracht een object ontwikkeld wordt, wordt de norm. Toonaangevende supply chains zullen als sleutelfiguren in een alliantie overeenkomst participeren. Een heldere structuur ten aanzien van wijziging management vormt de basis van projecten ondersteund door een constructieve invulling van conflict management. Concepten van faclity- en assetmanagement zullen steeds professioneler worden en meer en meer toegepast worden. Uniforme omgevingen zullen toenemen vanwege het toenemende aantal toeleveranciers dat een volledig pakket aan diensten kan leveren aan aannemers die daardoor met een geringere personele bezetting kunnen volstaan. Ontwikkelingen in de adviesbranche De adviesbranche zal zich in toenemende mate ontwikkelen tot minder grote bedrijven met een groot aantal medewerkers en vele kleine bedrijven met specialistische kennis en dienstverlening. Toekomst van SE in de context van scenario 2 De ontwikkeling van SE in de context van scenario 2 zal extensief zijn. De waarborg van waardegeneratie en operationele prestaties gedurende de levens cyclus van objecten staan in het brandpunt van het voortbrengingsproces. Asset en facility management nemen een steeds belangrijker plaats in. Verhoudingen tussen opdrachtnemende en opdrachtgevende partijen ten aanzien van taken, bevoegdheden en verantwoordelijkheden gaan verschuiven, maar ook binnen de opdrachtnemende partijen veranderen de verhoudingen tussen aannemer en toeleveranciers. Het projectmatig ontwikkelen van objecten tussen bedrijven zal meer en meer gebeuren en plaatsvinden rondom 3D en 4D modellen. De communicatie en informatie doorstroming tijdens het ontwikkelproces zal steeds vaker over de grenzen van bedrijven plaatsvinden. De vraag naar uniforme omgevingen zal dan ook toenemen inclusief ICT ondersteuning. De vraag naar systematische, transparante en traceerbare werkwijzen is dan een logisch gevolg. Het conformeren aan een uniforme ontwikkelomgeving wordt een noodzakelijke voorwaarde voor deelname aan de supply chain. De vraag naar waardegeneratie zal leiden tot inzet van ontwerpstrategieën die innovatie zal stimuleren. De complexiteit van de ontwerpproblemen zal alsmaar toenemen vanuit de stelling dat de eenvoudige problemen al opgelost zijn. De context van ontwikkeling en uivoering van bouwwerken wordt steeds ingewikkelder. Inzet van het volle vermogen van de SE benadering op een volwassen niveau bouwbreed zal een effectieve en efficiënte bijdrage leveren aan het toekomstige alsmaar complexere voortbrengingsproces van bouwobjecten. Opdrachtgevende en opdrachtnemende organisaties zullen gezamenlijk de ontwikkeling van de SE benadering tot een volwassen werkwijze, denkwijze en redeneerwijze uitwerken en inzetten in projecten.
3.6.3 Scenario 3: Radicale verandering De meest radicale verandering zou eigenlijk scenario 2 al kunnen zijn uitgaande van een kortere tijdschaal tot 2010. Radicale veranderingen vanaf 2012 zouden dan de volgende kunnen zijn. Houding opdrachtgevers ten aanzien van onroerende goederen De meeste bezittingen zullen verhuurd of geleased worden. Het in eigendom hebben van bezittingen is weggelegd voor een klein aantal spelers in de markt. Wettelijke en financiële regelingen maken huren en leasen aantrekkelijker dan het in eigendom hebben van onroerende 21
goederen. Publieke en private sectoren onderscheiden zich slechts in hun doelstellingen ten aanzien van het maken van winst of de wijze waarop ze hun diensten verlenen, maar niet meer ten aanzien van hun houding naar marktpartijen. Contractstrategieën Werken vanuit allianties zal gemeen goed zijn. Opdrachtgevende partijen worden steeds groter en professioneler ten aanzien van asset en facility management. De link tussen deze organisaties en supply chains zal steeds sterker worden. De werkwijze van de publieke organisaties zal steeds meer de vorm aannemen van die van de private partijen. Structuur uitvoerende bouwbedrijven De transformatie van een productenmarkt naar een dienstenmarkt krijgt vorm waardoor grote bouwbedrijven zullen verdwijnen en Asset Management bedrijven de risicodragend de functie van systeem integrator zullen invullen. Supply chain management zal de norm worden. Vanuit een geïntegreerde projectomgeving zullen deze in een alliantie ingezet worden, waarin vanuit een waardegeneratie, risico, wijziging- en conflictmanagement een belangrijke plaats innemen. Kleine aannemers en onderaannemers zullen vanuit een overkoepelende organisatie opereren. Uniforme omgevingen ten behoeve van uitwisseling van informatie en communicatie in en tussen organisaties zal toenemen. Toeleveranciers zullen steeds meer een totaalpakket aan diensten leveren, vanaf conceptontwerp tot productie, onderhoud en ontmanteling. Ontwikkelingen in de adviesbranche Adviesbureaus zullen zich steeds meer richten op asset en facility management en de rol van Systeem Integrator gaan vervullen. De architect en constructeurs functie zal meer en meer ingevuld worden door kleine organisaties die geen ontwerpverantwoordelijkheid dragen maar deze verzekeren via professionele organisaties. Toekomst van SE in de context van scenario 3 Volwassen SE concepten vormen de basis van inrichting, besturing en uitvoering van elk bouwproject. Bouworganisaties beschikken over technisch en management geschoolde medewerkers die competenties op het gebied van SE bezitten en de werkwijze, denkwijze en redeneerwijze van de SE benadering beheersen. Opdrachtgevende en opdrachtnemende partijen hebben de benaderingswijze SE voor de bouwpraktijk in gezamenlijk overleg ontwikkeld en volledig geassimileerd. Branche organisaties zoals CROW en SBR ondersteunen op professionele wijze de uniforme omgevingen en gecertificeerde opleidingen van SE medewerkers. Onderwijsinstellingen met bouwtechnische en bouwmanagement afdelingen op de niveaus van WO, HBO en MBO zullen gezamenlijk onderwijstracks ontwikkelen en onderhouden, waarin de competenties ten aanzien van kennis en ervaring van en met SE op een hoog niveau bereikt worden.
22
4 Processen In dit hoofdstuk gaan we nader in op het Systems Engineering proces. Systems Engineering is een formeel gefaseerd ontwerpproces met gedefinieerde overgangen. Het is een gelaagde ontwerpmethode. Op een getrapte wijze worden operationele eisen en wensen van de klant vertaald naar ontwerpeisen, die aan onderling fysiek onderscheidbare sub-systemen worden gesteld. De consistentie van het systeem inclusief de non-functionele kwaliteiten zoals veiligheid, betrouwbaarheid, beschikbaarheid, onderhoudbaarheid en dergelijke worden op systeemniveau bewaakt. Systems Engineering heeft twee aspecten. Ten eerste geeft het een ontwerpmethode voor het doelmatig en doeltreffend ontwerpen, realiseren en exploiteren van systemen. Ten tweede introduceert het systeemdenken in alle facetten van het ontwerpproces. Systeemdenken is de notie dat het systeem van de één een sub-systeem van de ander is. In de tweede helft van de vorige eeuw zijn er een aantal standaarden ontwikkeld in de Systems Engineering. Met de uitgave van de Systems Engineering standaard ISO/IEC 15288 in 2002 is Systems Engineering formeel erkend als het voorkeursmechanisme voor het verkrijgen van overeenstemming over de voortbrenging van producten en diensten, die tussen twee organisaties worden verhandeld – de klant en de leverancier. ISO/IEC 15288 onderkent 6 fasen in de levensloop van een systeem. In tabel 1 staan deze vermeld. Het Systems Engineering paradigma kan op de hele levensloop van het systeem worden toegepast. Aangezien in de ontwikkeling- en productiefase de meeste kosten gemaakt worden, hebben deze fasen traditioneel de meeste aandacht. De levenscyclusbenadering levert echter toegevoegde waarde voor alle fasen van de levensduur van het systeem. Fasen
Strekking
Tolpoorten
Concept
Identificeren behoeften van de belanghebbenden; Concepten verkennen; Levensvatbare oplossingen opstellen.
Ontwikkeling
Systeemeisen verfijnen; Oplossing beschrijven; Systeem integreren; Systeem verifiëren en valideren.
Productie
Produceer systeem; Inspectie en test.
Exploitatie
Exploiteren tot tevredenheid van de gebruikers.
Onderhoud
Duurzaam gebruik ondersteunen.
Uitfasering
Opslag of sloop van het systeem
Tolpoorten zijn beslissingsmomenten gekoppeld aan gedefinieerde overgangen in het proces. De opties bij een tolpoort zijn: • Voer de volgende fase uit; • Vervolg de huidige fase; • Ga terug naar een vorige fase; • Leg het project stil; • Beëindig het project.
Tabel 1: Fasen in de levensloop van een systeem
Het procesverloop van de ontwikkeling- en productiefase wordt vaak weergegeven in het integrale V-model (zie afbeelding 5). Vanuit dit V-model is te zien dat de fasen Ontwikkeling en Productie in elkaar grijpen. Vanuit de ontwikkeling wordt de productie aangestuurd. Vervolgens wordt door de ontwikkeling de resultaten van de productie geïntegreerd in een het hogere systeemniveau en vindt de verificatie en validatie plaats. Binnen de V zijn twee assen te onderscheiden. De horizontale as geeft de transformatie van een abstract idee voor systeem/subsysteem/module/component naar de concrete realisatie. De verticale as geeft de verschillende aggregatieniveaus van het systeem (systeem/sub-systeem/module/component) weer. Het volgen van de verticale as benadrukt tevens dat het geheel meer moet zijn dan de som der delen. Afbeelding 6 geeft een overzicht over de hele levenscyclus. Het plaatje laat zien dat ook tijdens de exploitatiefase ontwerp- en productieactiviteiten zijn (Grootonderhoud, uitbreidingen, etc.). Echter 23
deze zijn veel kleinschaliger dan het initiële ontwerp en productie.
Afbeelding 5: Integraal V-model (bron Leidraad voor Systems Engineering in de GWW-sector)
Afbeelding 6: Overzicht van de hele levenscyclus van het systeem (bron Leidraad voor Systems Engineering in de GWW-sector)
4.1 Systems Engineering standaard In de vorige hoofdstuk is de standaard ISO/IEC 15288:2002 “Systems Engineering – System life cycle processes” (ISO 15288) geïntroduceerd. Deze standaard omvat de aspecten: ●
Splitsen van specificeren en ontwerpen;
●
Verifiëren en valideren;
●
De levenscyclus als uitgangspunt.
24
Afbeelding 7: Proceskaart met de processen uit ISO 15288
Binnen de ISO 15288 wordt een onderscheid gemaakt tussen Technische processen, Project processen en Ondernemingsprocessen.(zie afbeelding 7). De ondernemingsprocessen beschrijven de activiteiten op ondernemingsniveau, die het uitvoeren van de projecten ondersteund. De technische en project processen ondersteunen de uitvoering en management van de projecten. De afbeelding 4 geeft de interactie tussen Systems Engineering en Project Management weer. De technische processen uit de ISO 15288 zijn: a) Specificatieproces van eisen van belanghebbenden: omzetten van de behoeften en wensen van belanghebbenden in een gezamenlijke reeks eisen; b) Eisenanalyseproces: eisen vertalen in meetbare systeemvereisten en functies van het systeem; c) Architectuurontwerpproces: oplossing tot stand brengen die aan de systeemvereisten voldoet; d) Invoeringsproces: de systeemonderdelen bouwen; e) Integratieproces: samenstellen van het systeem uit de systeemonderdelen conform het architectuurontwerp; f) Verificatieproces: controleren of het systeem en de onderdelen daarvan voldoen aan de eisen; g) Overgangsproces: het systeem gebruiksklaar maken; h) Validatieproces: controleren of het systeem de geëiste functionaliteit biedt; i) Operationeel bedrijfsproces: gebruikmaken van het systeem; j) Beheer- en onderhoudsproces: onderhouden van het systeem, inclusief verbetering en hergebruik; 25
k) Verwijderingsproces: einde levenscyclus, sloop het systeem. Een standaard zoals de ISO 15288 geeft een kader voor het Systems Engineering proces. Het toepassen van het proces vereist een verbijzondering van het proces naar de specifieke toepassing. Voor de GWW sector hebben Rijkswaterstaat, ProRail, Bouwend Nederland en het ONRI onder het motto Bouwen aan één taal een leidraad opgesteld voor Systems Engineering binnen de GWW sector. Deze leidraad is beschikbaar op internet (www.leidraadse.nl). In tabel 2 is een koppeling gemaakt tussen de verschillende processtappen uit de ISO 15288 en de leidraad ISO 15288
GWW-sector
a) Specificatieproces van eisen van belanghebbenden
Specificatieproces van eisen belanghebbenden
b) Eisenanalyseproces
Eisenanalyseproces en Functionele analyse en allocatie
c) Architectuurontwerpproces
Ontwerpproces
d) Invoeringsproces
Uitvoeringsproces
e) Integratieproces
Uitvoeringsproces
f)
Verificatieproces
Verificatieproces
g) Overgangsproces
Opleveringsproces
h) Validatieproces
Validatieproces
i)
Operationeel bedrijfsproces
Operationeel bedrijfsproces
j)
Beheer- en onderhoudsproces
Beheer- en onderhoudsproces
k) Verwijderingsproces
Sloopproces
Engineeringproces (ontwikkeling)
Realisatieproces (productie)
Life cycle proces (exploitatie, onderhoud, uitfasering)
Tabel 2: De gangbare benaming van de ISO 15288 processen in de GWW-sector (Bron Leidraad voor Systems Engineering binnen de GWW-sector) (zie ook tabel 1) Bij de tabel 2 moet de volgende kanttekening geplaatst worden. De Leidraad Systems Engineering voor de GWW sector adresseert de conceptfase niet (zie tabel 1). Wanneer Systems Engineering is zijn volle breedte wordt toegepast omvat het specificatieproces ook de zoektocht naar de wensen en behoeften van de belanghebbenden en de afweging van de alternatieven. In de GWW sector worden deze activiteiten uitgevoerd voordat een tender of aanbesteding in markt wordt gezet. Vandaar dat aan deze activiteiten geen aandacht hebben gekregen in de Leidraad Systems Engineering. Wanneer echter vanuit een waardeketen wordt geredeneerd moeten alle aspecten van de voortbrenging meegenomen worden dus ook de conceptfase.
4.2 Koppeling proces aan de waardeketen Voor het optimaal functioneren van de waardeketen is het noodzakelijk dat de fase reviews gestandaardiseerd worden. Een fase review is een tolpoort (zie tabel 1). Binnen de GWW sector bestaan verschillende faseovergangen (bijvoorbeeld: Voorlopig Ontwerp (VO), Definitief Ontwerp (DO), Uitvoeringsontwerp(UO), Bestek, en Oplevering). De uniforme omgeving van de fase reviews houdt in dat de tolpoorten bij de procesovergangen ingericht worden. Een goede inrichting zorgt voor een overdracht van ontwerpverantwoordelijkheid en een herijking van planning en kosten. Hierdoor kan er een directe koppeling met de afsprakenstelsels in de contracten gemaakt worden. Een uniforme omgeving van de faseovergangen in het proces leidt ook tot een uniforme weergave van de activiteiten, die per fase worden uitgevoerd. Omdat bij deze reviews zowel de verantwoordelijkheid voor het ontwerp als planning en budget kan worden overgedragen is het belangrijk om de rollen van deelnemers te beschrijven inclusief hun taken, bevoegdheden en 26
verantwoordelijkheden. Daarnaast is het essentieel dat ook de escalatie bij voorbaat geregeld is. Omdat alle partijen in waardeketen hiervan profiteren is het belangrijk om op sector niveau een aantal modellen te ontwikkelen voor de fase reviews. Afhankelijk van de omvang en risico's van het project kan dan voor één van de modellen gekozen worden. De CROW ligt hier een taak omdat het streven naar een uniforme omgeving van de faseovergangen de-facto het Systems Engineeringproces in de GWW sector gestandaardiseerd wordt en gekoppeld kan worden aan de bestaande afsprakenstelsels in de sector. Het uitgangspunt van de startnotitie is dat procesverbeteringen in de organisatie bijdragen aan het behalen van de doelstellingen op organisatieniveau. Het is aannemelijk gemaakt dat het invoeren van Systems Engineering bijdraagt aan het behalen van de organisatiedoelstellingen. De grootste valkuil bij proces verbeterinitiatieven is dat het formaliseren van processen leidt tot bureaucratie met alle negatieve gevolgen van dien. Aangezien de CROW het kenniscentrum is voor de GWWsector ligt het voor de hand om ook vanuit de CROW aandacht te besteden aan de efficiëntie van de Systems Engineering implementatie middels het ontwikkelen van een assessmentkader en het beschikbaar stellen van de scores tegen dit kader.
4.3 Systems Engineering en de supply chain In de waardeketen kunnen verschillende knips aangebracht worden. In de GWW sector zijn voor de verschillende knips verschillende contractvormen ontwikkeld (RAW, Design and Construct en Design, Build, Finance an Maintain). In de afbeelding 7 zijn deze met inkoopontkoppelpunten aangegeven. Afhankelijk van de rol in de waardeketen zullen er verschillende accenten in het Systems Engineering proces zijn. Het speelveld is in afbeelding 8 weergegeven.
Afbeelding 8: Speelveld van het Systems Engineering proces
De uitersten in het speelveld zijn de toeleverancier met een lage ontwerpverantwoordelijkheid waarbij System Design dominant is in de toepassing van Systems Engineering en de system integrator met een hoge ontwerpverantwoordelijkheid waarbij System Architecture leidend is in Systems Engineering. De karakteristieken van System Design en System Architecting zijn in tabel 3 weergegeven. 27
System Design
System Architecture
Systeem-componenten ontwikkelen
Koop-maak beslissingen
Systeem bouwen
Onderscheid maken tussen de opties
Begrip voor de veranderingen in de configuratie bij systeemmodificaties
“Ontdekken” van de relevante eisen Sturen op gebruik en hergebruik van systeemconcepten
Tabel 3: System Design versus System Architeture
28
5 Human Resource Management Het inrichten van een nieuw proces brengt nieuwe rollen met zich mee. Ook door de veranderingen in de waardeketen ontstaan nieuwe rollen. In toenemende mate wordt ontwerpverantwoordelijkheid bij toeleveranciers gelegd. 'Men vraagt en wij draaien' is steeds minder van toepassing. De waardeketen vereist dat de spelers in de keten mee kunnen denken met de eisen formulerende partijen die hoger in de keten zitten. Wanneer functionele eisen worden gesteld moet de specificerende partij door middel van de 'waarom' vraag op zoek gaan naar de optimale ontwerpvrijheid. Concreet betekent dit dat het systeemdenken bij alle partijen in de keten ontwikkeld moet worden. In het hoofdstuk Processen wordt systeemdenken omschreven als Systeemdenken is de notie dat het systeem van de één een sub-systeem van de ander is. Systeemdenken houdt ook in dat over de ontwerpvrijheid onderhandeld moet worden tussen de eisende en specificerende partij. Daarnaast is het ontwerpen en realiseren van infrastructuur team werk. Dit betekent dat in een sector, die groeit van het leven van fouten naar eerlijk samenwerken, om Karla Peijs maar weer eens aan te halen, behoefte is aan systeemdenkers. Mensen, die naast hun technische ontwerpvaardigheden beschikken over sociale vaardigheden, die hen is in staat stellen om succesvol met opdrachtgever en toeleverancier te onderhandelen en om optimaal in een integraal team te kunnen opereren.
5.1 Rollen en competentieprofielen Het verbeteren van het voortbrengingsproces begint bij de medewerker, die het proces moet uitvoeren. Het implementeren en toepassen van Systems Engineering betekent dat nieuwe rollen ontstaan en dat bestaande rollen veranderen. Competentieprofielen zijn een goed hulpmiddel bij het veranderen van bestaande rollen en het introduceren van nieuwe rollen in de organisatie. Typische rollen in de het Systems Engineering proces zijn: ●
System Engineering Manager
●
System Architect
●
System Engineer
●
System Analyst
●
Test Manager
●
Test Engineer
●
Specialty Engineer (Veiligheid, Betrouwbaarheid, Beschikbaarheid, Onderhoudbaarheid, EMC, enz.)
●
Configuration Manager
●
Requirements Manager
●
Quality Assurance Manager
De rollen zijn voor een deel een andere invulling van bestaande rollen en voor een deel nieuwe rollen voor een organisatie. Afhankelijk van de complexiteit en omvang van de ontwikkelactiviteiten worden de rollen aan medewerkers toegekend. Soms is er een één op één relatie, meestal vervult één medewerker verschillende rollen. Competentieprofielen van de verschillende rollen ondersteunt de ontwikkeling van medewerkers in de rollen. De competentieprofielen beschrijven zowel de technische als de sociale vaardigheden, die nodig zijn voor het uitvoeren van de rollen. Vaak is het handig om verschillende gradaties te hanteren bij de competenties (bijvoorbeeld: Junior, Medior en Senior). Het ontwikkelen van competentieprofielen op het niveau van de GWW-sector heeft een aantal voordelen. Het draagt bij aan de gemeenschappelijke taal en het bevordert de uitwisselbaarheid van personeel in de sector, 29
hetgeen de sector aantrekkelijker maakt voor schoolverlaters en het draagt ook bij aan het verhogen van de concurrentiekracht van de sector. Het is duidelijk dat bij het opstellen van de competentieprofielen een rol is weggelegd voor de CROW. Met de sectorbrede competentieprofielen kunnen ook opleidingstrajecten ontwikkeld worden.
30
6 Procesondersteuning Het is nu tijd om Systems Engineering handen en voeten te geven voor de mensen, die het proces moeten uitvoeren. In het hoofdstuk Processen is de structuur van het Systems Engineering proces beschreven. Het proces gaat pas leven wanneer de medewerkers ondersteund worden bij het uitvoeren van de procesactiviteiten. Dit hoofdstuk adresseert het activiteitenniveau van de kwaliteitspiramide (zie afbeelding 1). Het uitgangspunt is dat de medewerker centraal staat. Binnen de ondersteuning aan de medewerker zijn vier aspecten te onderscheiden: ●
Communicatie ondersteuning;
●
Procedures en methoden;
●
IT gereedschappen;
●
Sectorspecifieke kennisbank.
Een sectorbrede aanpak van de procesondersteuning stimuleert de ontwikkeling van één Systems Engineering taal. Vanwege de verschillende aspecten van de procesondersteuning kun je spreken van een architectuur waarmee de medewerker ondersteund wordt. Door het als een architectuur te beschouwen kan een geïntegreerde ondersteuning aan de medewerkers aangeboden worden. Het maakt het ook mogelijk om de bedrijfseconomische voordelen van de ondersteuning helderder te krijgen.
6.1 Communicatie ondersteuning Binnen de sector zijn reeds een aantal afsprakenstelsels ontwikkeld: bijvoorbeeld UAV-GC 2005, U.A.V. '89, VISI-raamwerk. In het kader van Systems Engineering moet dit uitgebreid worden met de uniforme omgeving van de faseovergangen.
6.2 Procedures en methodes In het hoofdstuk Visie is reeds een verwijzing gegeven naar Systems Engineering Guidebook for ITS (http://www.fhwa.dot.gov/cadiv/segb/). Een soortgelijk handboek voor de GWW-sector is zeer aan te bevelen. De Leidraad voor Systems Engineering binnen de GWW-sector kan als uitgangspunt dienen voor de ontwikkeling van een handboek. CROW initiatieven als oplossingsvrij specificeren kunnen gekoppeld worden. Via hetzelfde handboek kunnen bijvoorbeeld ook initiatieven op gebied van risicomanagement, RAMS engineering en configuratiemanagement toegankelijk gemaakt worden voor de individuele medewerker. Het toevoegen van case studies, 'best practices' en 'worst practices' is ook heel leerzaam.
6.3 IT gereedschappen Het in de vorige hoofdstuk genoemde handboek is natuurlijk al een it-gereedschap. Daarnaast zijn er andere zaken zoals GWW-bibliotheek gebaseerd op ISO-PAS en NTA, VISI-tool. Vanuit een architectuur gedachte moeten ook de gereedschappen voor risicomanagement, requirements management en configuratiemanagement geïntegreerd worden. Op termijn ligt het voor de hand de architectuur uit te breiden met Product Data Management en Onderhoudsmanagement systemen.
6.4 Sectorspecifieke kennisbank De efficiëntie van het Systems Engineering proces wordt verhoogd door optimaal gebruik te maken van de aanwezige kennis. Deze kennis ligt vast in databanken zoals kentallen SSK voor wegenbouw, kwaliteitscatalogus Openbare Ruimte, Functiebibliotheek 'Faciliteren Wegverkeer' en RAW catalogus. De medewerkers hebben ook toegang nodig tot wet- en regelgeving. 31
7 Rol CROW Het CROW profileert zichzelf als het nationale kennisplatform voor infrastructuur, verkeer, vervoer en openbare ruimte. Het ligt voor de hand dat het CROW een belangrijke rol speelt in het versterken van de sector door aandacht te schenken aan het verbeteren van het voortbrengingsproces. Hieronder worden vier mogelijke rollen voor de CROW neergezet. Wij denken dat het nuttig is om over deze vier rollen te filosoferen. De mogelijke rollen zijn: ●
Regisseur van het versterken van de waardeketens in de GWW-sector. De regisseursrol krijgt vorm door de spelers in de sector bij elkaar te brengen in de programmacommissie Systems Engineering;
●
Eigenaar van de procesondersteunende architectuur De CROW neemt het initiatief om tot een Systems Engineering handboek voor de GWWsector te komen. Daarnaast stimuleert zij partijen om een architectuurkader te ontwikkelen waarin de gebruiker eenvoudig toegang krijgt tot de afsprakenstelsels, kennisbanken en andere IT gereedschappen. Voor het ontwikkelen en onderhouden van het Systems Engineering handboek kan de CROW een 'open source' filosofie entameren waardoor organisaties en kennisinstellingen gestimuleerd worden een bijdrage te leveren en waarbij de CROW de kwaliteitsborging organiseert.
●
Regisseur voor het ontwikkelen van competentieprofielen voor Systems Engineering rollen De CROW kan de verschillende partijen in de sector (bedrijven, overheidsagentschappen en kennisinstellingen) bij elkaar brengen. Daarnaast kan de CROW ook als beheerder van de profielen optreden.
●
Regisseur bij het ontwikkelen van een assessmentkader voor de Systems Engineering implementatie. Het verbeteren van het voortbrengingsproces levert nooit meteen kosten voordelen op. Het voorkomt kostenoverschrijdingen in de toekomst. Dit aspect bemoeilijkt de “verkoop” van de implementatie van Systems Engineering. Wanneer op initiatief van de CROW een assessmentkader voor een Systems Engineering implementatie wordt ontwikkeld en als de CROW resultaten van assessments in de GWW-sector verzameld en analyseert kan zij een extra dimensie aan haar rol als kennisplatform geven. De analyses leiden hopelijk tot een methode om de implementatie van Systems Engineering te kunnen kapitaliseren en verder kan een uitspraak gedaan worden over de efficiëntie van de verschillende implementatie trajecten.
32
8 Plan van aanpak voor de implementatiefase 8.1 Doelstellingen programmacommissie Systems Engineering De programmacommissie Systems Engineering stuurt het programma Systems Engineering binnen de CROW aan. De missie van het programma Systems Engineering kan omschreven worden als Missie: Het creëren van een uniforme voortbrenging omgeving op basis van Systems Engineering ten behoeve van een duurzame samenwerking in de waardeketen van de GWW-sector opdat de verwachte waarde voor de klant over de gehele levensduur gewaarborgd wordt.
Uit de missie kunnen de volgende doelstellingen ter ondersteuning van de implementatie van Systems Engineering worden afgeleid: ●
Uitdragen gedachtegoed Systems Engineering De sector van informatie voorzien waaruit blijkt dat een op Systems Engineering gebaseerd voortbrengingsproces de transparantie verhoogd en technische risico's beheersbaar maakt.
●
De drempel voor de implementatie van een op Systems Engineering gebaseerd voortbrengingsproces verlagen Ontwikkelen van een procesondersteunende architectuur. Vanuit de architectuur moet ook een filosofie ontwikkeld worden over de organisatie specifieke implementatie rekening houdend met de omvang van de organisatie en de rol in de waardeketen.
●
Stimuleren van competentie- en loopbaanontwikkeling van sleutelspelers in de Systems Engineering Ontwikkelen van competentieprofielen en loopbaantrajecten voor spelers in de Systems Engineering en de coördinatie met het MBO, HBO en WO op dit gebied.
●
Stimuleren van het meten van de kwaliteit van het voortbrengingsproces Ontwikkelen van een assessmentkader van het voortbrengingsproces en het opzetten van een databank waar de resultaten van de verschillende assessments verzameld worden, zodat uitspraken over Return on Investment en Return on Knowledge gedaan kunnen worden.
8.2 Actoren Vanuit de waardeketen kunnen verschillende groepen actoren worden onderscheiden. Iedere groep heeft zijn drijfveren met betrekking tot het verbeteren van het voortbrengingsproces. In tabel 3 zijn de verschillende actoren gegroepeerd en zijn tevens hun belangrijkste drijfveren en zorgen verwoord.
33
Actor Wetgever Opdrachtgevers ● Overheid Rijkswaterstaat, ProRail, Provinciale en locale overheden, waterschappen en Min. van Defensie ● Private partijen Schiphol, Gasunie, enz. Opdrachtnemers ● Bouwondernemingen (BAM, Dura Vermeer, VolkerWessels, Heijmans, enz.) ● SPV/SPC/SPE
Drijfveren
Naleven Europese regelgeving “Bouwfraude” “Meer doen met minder mensen” “Beschikbaarheid kopen / Infrastructuur leasen”
Overheid: Onrust bij het personeel (Minder en ander personeel)
Meer winst door hoger in de waardeketen te opereren
De partner van vandaag is de concurrent van morgen. Gedrag overheid: Handhaving van wetgeving wringt met stimuleren innovatief gedrag opdrachtnemer. “Conservatief” gedrag van raadgevende ingenieursbureaus. Hogere kosten voor het aanbiedingstraject.
Toeleveranciers ● Asfalt-, Betonindustrie, Meer winst door opschuiven in Technische Installateurs, de waardeketen Verkeerstechniek, enz.
Kennisinfrastructuur ● UT, TUD, TUE, HBO's, MBO's ● Ingenieursbureaus ● TNO Belangen- en beroepsorganisaties ● CROW, CUR, VCB, ONRI, BN ● INCOSE
Zorgen
Kwaliteit personeel. Ontbreken van systeemdenkers die met de opdrachtgever meedenken. “Conservatief” gedrag van raadgevende ingenieursbureaus.
Stimuleren innovaties in het voortbrengingsproces
Kwantiteit studenten. De markt vraagt meer personeel dan opgeleid wordt.
Verhogen duurzame winstgevendheid van de partijen in de branch. Kansen creëren voor system engineers
“Sector, die de kat uit de boom kijkt”
Tabel 4: Overzicht van actoren bij de implementatie van Systems Engineering
8.3 Aandachtspunten voor het implementatiescenario De overheid is als grote opdrachtgever een belangrijke speler bij het innoveren van de waardeketen in de GWW-sector. De agentschappen Rijkswaterstaat en ProRail stimuleren met innovatieve contracten samenwerking in de waardeketen. Er zijn twee belangrijke constateringen: 1. Ervaringen in Australië, Nieuw Zeeland en het Verenigd Koninkrijk leren dat bij het innoveren van de waardeketen in de GWW-sector markt en opdrachtgever gelijk optrekken. Het is niet realistisch om van de sector te verwachten dat zij van vandaag op morgen het door de overheid gewenste gedrag vertoont. Door meer verantwoordelijkheid in de markt te 34
zetten verwacht de overheid dat de GWW-sector onmiddellijk het gedrag van de supply chain in de complexe maakindustrie of de automitive overneemt. De realiteit is dat overheid en markt beide moeten leren. De overheid maakt kleine stapjes in het uitbesteden en de markt volgt. 2. De opdrachtgever en opdrachtnemer vertonen zelf-regulerend gedrag. De “angst” voor de Europese regelgeving leidt ertoe dat bij voorbaat voor de “veilige” weg wordt gekozen. Het uitgangspunt van de innovatieve contracten is dat de intelligentie van de markt wordt gestimuleerd. Echter wanneer na sluiten van het contract dezelfde marktpartij zijn intelligentie gebruikt, om met voortschrijdend inzicht verbeter voorstellen bij de opdrachtgever in te dienen, zie je dat de “angst” voor de Europese regelgeving de opdrachtgever zeer terughoudend maakt bij het honoreren van deze voorstellen. Een ander aandachtspunt is dat op dit moment het de GWW-sector economisch voor de wind gaat. In tijden van voorspoed zijn er maar weinig prikkels om dingen anders te gaan doen. Door het vele werk zal er bijvoorbeeld van ingenieursbureaus weinig stimulans uitgaan om lagere overheden te verleiden werk met innovatieve contracten in de markt te zetten. Immers nieuwe contractvormen gaan gepaard met risico's en waarom zou je risico's nemen als het werk nu al niet aan kan. Dit argument geldt natuurlijk niet alleen voor de ingenieursbureaus ook de andere partijen in de keten zien weinig aanleiding het businessmodel te veranderen. Het opschuiven van in de waardeketen heeft als voordeel dat de spelers potentieel meer winst kunnen maken. “Ieder voordeel heb zijn nadeel” zei Cruijff ooit. Zo is het ook met het opschuiven in de waardeketen. De prijs, die voor de hogere winstpotentie betaald moet worden, is dat de kosten in het aanbiedingstraject hoger zijn. Tevens zijn de schaarse talenten in de organisatie nodig om een concurrerende aanbieding te maken. Marktpartijen moeten dus hun bid/no bid strategie aanpassen, sleutelspelers vrij maken en zich realiseren dat er meer geld in het voortraject uitgegeven dient te worden.
8.4 Succesfactoren van de Systems Engineering implementatie Wanneer is de implementatie van Systems Engineering een succes? Een viertal attributen kunnen gedefinieerd worden om het succes van de Systems Engineering implementatie te meten. Deze zijn: ●
De ontwikkelkosten;
●
De faalkosten;
●
De Return On Investment;
●
De Return On Knowledge.
8.4.1 Ontwikkelkosten Zowel ProRail als Rijkswaterstaat verwachten met behulp van innovatieve contracten kosten te besparen. ProRail spreekt van 20%.
8.4.2 Faalkosten Sommige bronnen schatten dat de faalkosten zo'n 20% van de aanneemsom bedragen. De invoering van Systems Engineering moet dit bedrag drastisch terugbrengen.
8.4.3 Return On Investment (ROI) Bij de implementatie van Systems Engineering geldt “de kost gaat voor de baat uit”. Met de ROI wordt de winst door de vermindering van ontwikkelkosten en faalkosten gerelateerd aan de 35
investeringen, die een organisatie moet getroosten bij de implementatie van Systems Engineering.
8.4.4 Return On Knowledge (ROK) Systems Engineering stelt eisen aan het opleidingsniveau van de medewerker. Daarnaast heeft de organisatie ook spelers nodig, die met de opdrachtgever kunnen sparren. Met de ROK wordt de winst door de vermindering van ontwikkelkosten en faalkosten gerelateerd de kosten nodig voor de scholing van de medewerkers (opleiding, workshops, conferentiebezoek etc.) samen met de kosten voor het managen van kennis (kennisbank, coachingtrajecten).
8.4.5 Benchmark Aan de attributen moeten waardes gekoppeld worden. Het is aan de programmacommissie om deze waardes te bepalen. Vanuit zowel de complexe maakindustrie als vanuit softwarewereld zijn resultaten gepubliceerd op de vier bovenstaande attributen in relatie tot verbetertrajecten in het voortbrengingsproces, die gebruikt kunnen worden voor het bepalen van richtgetallen voor de GWW-sector.
8.5 Roadmap voor de Systems Engineering implementatie Het programma voor het programma Systems Engineering kan afgeleid worden uit de roadmap voor de implementatie. De roadmap beschrijft vijf aspecten Markt, Product, Proces, Procesondersteuning en Medewerkers. Naast deze aspecten heeft een roadmap een tijddimensie. Het geeft aan wanneer producten gereed moeten zijn voor introductie op verschillende markten. De productintroductie is op haar beurt weer afhankelijk van ontwikkelingen op het gebied van processen, procesondersteuning en het competentie niveau van de medewerkers.
8.5.1 Markt De volgende drie markten worden onderscheiden: ●
Overheidsagentschappen (Rijkswaterstaat, ProRail)
●
Private partijen (Schiphol, Gasunie, Havenbedrijf Rotterdam enz.)
●
Lagere overheden
8.5.2 Producten De CROW streeft naar een procesondersteunende architectuur waarin vier domeinen zijn te onderscheiden. Ieder domein omvat een aantal individuele producten. Vanuit de productvisie zullen er een aantal releases zijn van de procesondersteunende architectuur, die elk een verzameling producten omvat. Gezien de verschillende belangen van de partijen in de waardeketen zullen er verschillende realisaties van de procesondersteunende architectuur ontstaan. De vier productdomeinen zijn: ●
Afsprakenstelsels: UAV-GC 2005, U.A.V. '89, VISI-raamwerk
●
Processen /Procedures: Handboek Systems Engineering, oplossingsvrij specificeren enz.
●
Informatisering/Automatisering: Procesondersteunende architectuur, GWW bibliotheek gebaseerd op ISO-PAS en NTA, VISI-tool etn.
●
Databanken: bijvoorbeeld kengetallen SK voor wegenbouw, KOR, Functiebibliotheek 'Faciliteren Wegverkeer', RAW catalogus
Behalve de procesondersteunende architectuur zijn er nog een tweetal productdomeinen. ●
Competenties: Handboek competentieprofielen, opleidingstrajecten; 36
●
Assessment Systems Engineering implementatie
8.5.3 Processen Uitgangspunt is de Leidraad voor Systems Engineering binnen de GWW-sector. Ter ondersteuning van de voornoemde producten dienen de volgende zaken ontwikkeld te worden: ●
De conceptfase van het systeem toevoegen;
●
Per processtap de activiteiten benoemen;
●
Uniforme procesovergangen;
Naast de Systems Engineering processen dient ook aandacht besteed te worden aan het ontwikkelen van een assessmentmethodiek voor de Systems Engineering implementatie.
8.5.4 Procesondersteuning De procesondersteuning bestaat aan de ene kant uit het koppelen van bestaande initiatieven zoals RISNET, COINS en 3D bouwen aan de andere kant uit het in samenspraak met de sector te definiëren activiteiten zoals bijvoorbeeld RAMS handleiding en een gids voor het uitvoeren van functionele analyses. Voorts moet het ook duidelijk zijn hoe bestaande gereedschappen op het gebied van requirements management, configuratiemanagement en risicomanagement worden meegenomen
8.5.5 Medewerkers Bij de medewerkers staat de ontwikkeling van de competentieprofielen centraal.
8.5.6 Roadmap Afbeelding 9 geeft een voorbeeld van een roadmap. In overleg met relevante partijen wordt een roadmap opgesteld. Indien nodig kan ingezoomd worden op bepaalde aspecten waardoor onder de roadmap gedetailleerde roadmaps komen te hangen. Vervolgens worden actieplannen aan de roadmaps toegevoegd. De actieplannen sturen de activiteiten aan waarmee de doelstellingen in de roadmap worden gerealiseerd.
8.6 Plan van aanpak voor de programmacommissie Systems Engineering 8.6.1 Stappenplan De volgende stappen zijn te onderscheiden in de implementatie van Systems Engineering. 1. Afbakening van de Systems Engineering implementatie 2. Vaststellen van de rollen en verantwoordelijkheden voor de implementatie 3. Ontwikkelen van een Systems Engineering implementatiestrategie en een Systems Engineering implementatieplan
8.6.1.1 Afbakening van de Systems Engineering implementatie De volgende fundamentele vragen moeten beantwoord worden: ●
Welke doelgroepen worden onderscheiden?
●
Wat is de omvang van de implementatie? 37
Welke aspecten van proces en procesondersteuning worden geadresseerd?
8.6.1.2 Vaststellen van de rollen en verantwoordelijkheden voor de implementatie De programmacommissie moet aangeven op welke wijze zij het implementatieproces willen aansturen
Afbeelding 9: Voorbeeld van een roadmap
8.6.1.3 Ontwikkelen van een Systems Engineering implementatiestrategie en een Systems Engineering implementatieplan Met de uitkomsten van de eerste twee stappen geeft de programmacommissie de projectleider van het implementatietraject opdracht een strategie te bepalen en een plan van aanpak te beschrijven.
8.6.2 Actieplan Het is belangrijk dat de Systems Engineering implementatie een gezamenlijke actie is van de partijen in de GWW-sector. Vandaar dat draagvlakvorming een belangrijk aspect is van het implementatietraject. Het volgende actieplan wordt voorgesteld: Stap 1: Workshop voor de afbakening van de Systems Engineering implementatie Doelgroep, omvang implementatie
38
Duur: 1 dag Stap 2: Workshop voor het bepalen van de roadmap Stap 3: Vastleggen rollen en verantwoordelijkheden Stap 4: 'Kick off' bijeenkomst voor de definitie van de strategie en het schrijven van een implementatieplan.
8.7 Eindbeeld Het eindbeeld van het implementatietraject bestaat uit vier producten 5. Een architectuur waarmee aan de hand van wensen en behoeften van een organisatie in de GWW-sector een op maat gesneden Systems Engineering implementatie geleverd kan worden. Deze implementatie omvat procesbeschrijvingen, procesondersteuning en rollen van de spelers in het proces; 6. Een competentiehandboek met competentieprofielen van de verschillende rollen in het Systems Engineering proces; 7. Een methodiek om de kwaliteit van de Systems Engineering implementatie te meten en een databank met metingen van de kwaliteit van de implementatie bij verschillende organisaties. Met de gegevens uit de databank een optimale Systems Engineering implementatie voor een organisatie bepaald worden. 8. Een verzameling van relevante gegevens over het Systems Engineering proces (case studies, succes verhalen, enz.). De verzamelde gegevens kunnen gebruikt worden bij het uitdragen van het Systems Engineering gedachtegoed.
39
