leidraad voor system engineering binnen gww-sector
TRANSCRIPT
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 1/56
Lei Sses Egieeig ie e GWW-se
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 2/56
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 3/56
Lei Sses Egieeigie e GWW-se
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 4/56
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 5/56
InhoudSopGavE
voorWoord 4
LEESWIjzEr 6
1. SyStEmS EnGInEErInG 8
1.1 Achtergronden 8
1.2 Ssteemdenken 8
2. SyStEmS EnGInEErInG bInnEn GWW 11
2.1 Doelen 11
2.2 Leidende principes 12
2.3 Groeipad 13
3. dE ESSEntIE van dE WErkWIjzE 15
3.1 De klantvraag centraal stellen 15
3.2 Levenscclus opmaliseren 16
3.3 Iteraef speciceren 16
3.4 Top-down ontwikkelen en boom-up realiseren 17
3.5 Veriëren en valideren 18
4. procESStappEn 20
4.1 Fasering 20
4.2 Ontwikkelfase 21
4.3 Realisaefase 26
4.4 Vericae & validae 26
5. LEvEnScycLuSbEnadErInG 28
5.1 De levenscclusbenadering in processen 28
5.2 RAMS 29
5.3 Value Engineering 30
5.4 Life Ccle Cost 31
5.5 Asset Management 32
6. projEctmanaGEmEnt 33
6.1 Samenhang van de processen 33
6.2 Interdisciplinaire projectaanpak 34
6.3 Risicomanagement 356.4 Work Breakdown Structure 37
7. rELatIE opdrachtGEvEr opdrachtnEmEr 39
7.1 Koppelpunten 39
7.2 Vraagspecicae 43
8. handrEIkInG 46
bEGrIppEnLIjSt 48
coLofon 51
3
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 6/56
SamEn dE rIchtInG bEpaLEn
April 2007 verscheen de eerste Leidraad Sstems Engineering; het resultaat van een krachten-bundeling van Rijkswaterstaat, ProRail, Bouwend Nederland en NLingenieurs (voorheen ONRI). Wat
later schoof ook de Vereniging van Waterbouwers aan bij dit vier-parjenoverleg. Het verschijnen
van de Leidraad bleef niet onopgemerkt. De uitgave legde de basis voor een gemeenschappelijke
taal in de GWW-sector (Grond-, Weg- en Waterbouwsector) en smuleerde een nieuwe werkwijze
die het bouwproces eciënter en doelmager laat verlopen. Parjen namen het iniaef om
Sstems Engineering te implementeren in hun organisae en de werkwijzen beter op elkaar af
te stemmen. Duidelijk is dat de vraagspecicae op het koppelpunt tussen opdrachtgever en
opdrachtnemer meer en meer wordt toegepast en een uniformere opzet hee. Wel blij het een
uitdaging om meer oplossingsvrijheid te creëren en het ssteemdenken te bevorderen.
crEatIEvE opLoSSInGEn
Sstems Engineering staat niet op zichzelf maar past binnen de brede vernieuwing die plaatsvindt
binnen de GWW-sector. Opdrachtgevers concentreren zich meer en meer op het speciceren van
een probleemstelling en het inkopen van producten en diensten. Opdrachtnemers komen met
creaeve oplossingen en pakken steeds meer de integrale verantwoordelijkheid voor het ontwerpen
en bouwen. De vernieuwing vraagt ondermeer om transparane, klantgericht en expliciet werken. De
principes, methoden en technieken van Sstems Engineering dragen hier uitstekend aan bij.
ErvarInGEn En InzIchtEn
De afgelopen jaren is ink wat ervaring opgedaan met het toepassen van Sstems Engineering binnen
de GWW-sector. Daarbij zijn er diverse successen behaald, maar blijkt het toepassen van SstemsEngineering ook een proces van ontwikkeling en voortschrijdend inzicht. De ervaringen, inzichten
en suggeses van de afgelopen jaren wilden we delen met iedereen die aan de slag is of gaat met
Sstems Engineering. We hebben dan ook goed geluisterd naar de opmerkingen, onduidelijkheden
en knelpunten die zijn aangedragen door gebruikers van de Leidraad. Dit alles leidde tot deze nieuwe
versie. Daarin werken we ook de aansluing op het projectmanagement verder uit. Verder besteden
we aandacht aan de vraag hoe ver je moet gaan met Sstems Engineering. Het blijkt namelijk dat te
rigide interpretae van afspraken kan leiden tot bureaucrae. En dat is nu juist níet de bedoeling van
Sstems Engineering.
Overigens waren heel wat reaces opbouwend. Zo noemt men de manier waarop we Sstems
Engineering binnen de GWW-sector invullen bijzonder. Waar het in het buitenland vaak de
opdrachtgever is die voorschrij hoe de aannemer moet werken, is er hier ruimte voor eigen invulling
en geven we alleen de richng aan. En zelfs die richng bepalen we samen. Sstems Engineering is
dan ook een zoektocht naar gezamenlijk belang.
rIchtLIjnEn
Ook deze tweede versie van de Leidraad wil nadrukkelijk géén ‘kookboek’ zijn. Het biedt geen
recept dat, wanneer het ingrediënt voor ingrediënt wordt opgevolgd, een project volgens Sstems
Engineering-standaard oplevert. Wat het dan wél is? Een uitgave die een eenduidig beleid biedt
en randvoorwaarden creëert voor toepassing van Sstems Engineering bij infrastructurele werken.
Het gee kaders, zegt iets over hoe parjen met elkaar omgaan en laat zien welke stappen nodig
zijn binnen een Sstems Engineering-project. De Leidraad vraagt van de lezer dat deze de principes
van Sstems Engineering doorgrondt, om deze vervolgens op creaeve wijze te vertalen naar de
eigen bedrijfsprocessen en daarmee naar de aanpak van projecten. Hiervoor bieden we enkele
handreikingen.
voorWoord
4
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 7/56
ImpuLS
Deze Leidraad is het resultaat van theorie én prakjk, ideeën én ervaringen. Wie deze Leidraadopenslaat, vindt handvaen om Sstems Engineering te vertalen naar eigen projecten om zo op snelle
en transparante wijze werken te realiseren die aantoonbaar aan de klantvraag voldoen en minder
faalkosten hebben. We willen hiermee een nieuwe impuls geven aan de cultuuromslag naar integraal
bouwen. Zodat Sstems Engineering, nog meer dan nu het geval is, een gedeeld gedachtegoed wordt
en een vanzelfsprekend onderdeel is van de manier van werken. Oewel: dat Sstems Engineering bij
iedereen die bouwt in de GWW-sector ‘in de genen’ komt!
“Systems Engineering is een werkinstrument voor
opdrachtgever en opdrachtnemer. Daarom is het
belangrijk de gezamenlijke ervaringen te benuen
bij een verdere ontwikkeling naar eciënte
werkprocessen.”
Bert Keijts, Rijkswaterstaat
“Systems Engineering toont het belang van een
goed ontwerp; dit is bepalend over de gehele
levensduur van het systeem. Systems Engineering
maakt het mogelijk om hier doelmag en beheerst
invulling aan te geven.”
Ed Nijpels, NLingenieurs
“Systems Engineering bevordert de samenwerking
binnen de bouwketen omdat er gewerkt wordt aan
één taal en het zorgt voor een standaardisering
van de gehanteerde instrumenten.”
Elco Brinkman, Bouwend Nederland
“Het ontwikkelen en realiseren van complexeoplossingen op het snijvlak van infrastructuur,
veiligheid en polieke ambies maakt Systems
Engineering tot een noodzakelijke ontwikkeling
voor ProRail.”
Patrick Buck, ProRail
“De klant gee ons via Systems Engineering
de ruimte om met creaeve en innovaeve
oplossingen te komen en tegelijk de faalkosten te
reduceren.”
Frank Verhoeven, Vereniging van Waterbouwers
5
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 8/56
de Lei is ese ieee eewee ie ee is i e eeiig e
ieig ee i e GWW-se. dee Lei ie es e wee eSses Egieeig. veel egie lie we i ie e. v wie ee egi
g wil ee, ie e egielis e i ee ige is. hiei gee we
e egi wee wele eie we ee i ee Lei.
poSItIonErInG
Bestond de eerste versie van de Leidraad nog uit een managementdeel en een technisch deel,
de huidige Leidraad is één geheel. Ook zijn er, afgezien van de begrippenlijst, geen bijlagen
opgenomen in deze uitgave. De Leidraad is door de samenwerkende parjen geposioneerd als
richnggevend document voor de werkwijze binnen de GWW-sector. De praksche uitwerking
daarvan moet matchen met de ‘eigen’ bedrijfsprocessen van de gebruiker en wordt dan ook niet
voorgeschreven in bijlagen. Wel bieden Rijkswaterstaat, ProRail, Bouwend Nederland, NLingenieurs
en de Vereniging van Waterbouwers een handreiking voor deze toepassing in de eigen prakjk in
het afsluitende hoofdstuk. Bovendien plaatsen de organisaes op de website www.leidraadse.nl
regelmag publicaes die met de onderwerpen in de Leidraad samenhangen. Op deze website
kunt u zich ook laten inspireren door voorbeeldprojecten.
Deze tweede versie van de Leidraad is wederom geen handboek of werkinstruce. Het gee een
globaal overzicht van de werkwijze bij de toepassing van Sstems Engineering in de sector. In
de tekst zijn Do’s en Don’ts opgenomen. Dit zijn praksche instruces voor projeceams bij het
toepassen van Sstems Engineering. Voor gedetailleerdere informae over Sstems Engineering in
generieke zin verwijzen we graag naar het handboek van INCOSE (versie 3.0).
Inhoud hoofdStukkEn
In hoofdstuk 1 Systems Engineering leest u meer over het ontstaan van Sstems Engineering.
Ook vindt u hier een denie en lichten we het ssteemdenken verder toe. Hoofdstuk 2 Systems
Engineering binnen GWW beschrij kort het hoe en waarom van Sstems Engineering binnen de
GWW-sector en beschrij de beoogde doelen. Ook gaan we hier verder in op de negen leidende
principes en de ambies van de parjen bij het implementeren van deze werkwijze. In hoofdstuk
3 De essene van de werkwijze leest u de uitwerking van enkele essenële kenmerken bij de
werkwijze volgens Sstems Engineering. Onderwerpen die daarbij aan de orde komen zijn: de
klantvraag centraal stellen, de levenscclus opmaliseren, iteraef speciceren en tot slot veriëren
en valideren.Een ssteem doorloopt in de levenscclus diverse fasen. In hoofdstuk 4 Processtappen leest
u alles over de fasering van projecten. Het hoofdstuk gaat in op de processtappen die met
Sstems Engineering worden doorlopen en schenkt hierbij veel aandacht aan de ontwikkel- en
realisaefase. Hoofdstuk 5 Levenscyclusbenadering beschrij dat Sstems Engineering zich
richt op de klantbehoeen gedurende de gehele levenscclus. Dit hoofdstuk gaat over de
levenscclusbenadering en diverse begrippen die bijdragen aan een goede analse van de
levenscclus: RAMS, Value Engineering, Life Ccle Cost (LCC) en Asset Management. Hoofdstuk
6 Projectmanagement laat zien dat projectmanagement en Sstems Engineering een sterke
LEESWIjzEr
6
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 9/56
samenhang kennen, maar dat er ook duidelijke verschillen zijn. We maken hier duidelijk hoe
Sstems Engineering kan bijdragen aan de beheersing van de projectprocessen en procesrisico´s.Ook laten we zien hoe de werkwijze doorwerkt in het projeceam. Toepassing van Sstems
Engineering stelt voorwaarden aan de manier waarop opdrachtgever en opdrachtnemer met
elkaar omgaan. Hoofdstuk 7 Relae opdrachtgever – opdrachtnemer gaat hierop in en toont hoe
dit ook doorwerkt in de contracten. Daarbij besteden we extra aandacht aan de vraagspecicae.
In hoofdstuk 8 Handreiking leest u tot slot enkele ps voor het toepassen van Sstems Engineering
binnen uw eigen organisae.
7
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 10/56
1.1 achtErGrondEnGESchIEdEnIS
Sstems Engineering is voor het eerst toegepast in de telefoniesector als methode om operabiliteit
tussen de verschillende delen van het telefoonssteem te realiseren. Tijdens de Tweede Wereldoorlog
was het vooral Bell Labs die Sstems Engineering toepaste bij complexe telefoniesstemen.
In de jaren vijig van de twingste eeuw nam de meer algemene toepassing van Sstems
Engineering een vlucht. De werkwijze werd parallel verder ontwikkeld in de lucht- en ruimtevaart,
in de defensie-industrie (Boeing, Lockheed, Rockwell) en in de commerciële sector (AT&T). Zo
ontwikkelde Sstems Engineering zich tot een methode om steeds complexer wordende (R&D-)
problemen het hoofd te kunnen bieden.
IncoSE
In 1990 richen een aantal bedrijven en overheidsinstellingen in de Verenigde Staten het eerste
professionele plaorm voor Sstems Engineering op: ‘the Naonal Council on Sstems Engineering’
(NCOSE). NCOSE had de taak om Sstems Engineering verder te ontwikkelen en opgedane kennis
uit te dragen. De groeiende internaonale belangstelling voor Sstems Engineering zorgde ervoor
dat in 1995 de naam veranderde in ‘the Internaonal Council on Sstems Engineering’ (INCOSE).
Inmiddels bevonden de afdelingen zich ook in landen buiten de VS. Sinds 1995 wordt Sstems
Engineering wereldwijd aan een groot aantal universiteiten gedoceerd. In 1996 ontstond deNederlandse afdeling (INCOSE-NL).
dEfInItIE SyStEmS EnGInEErInG
INCOSE hanteert de volgende denie van Sstems Engineering:
‘An interdisciplinar approach and means to enable the realizaon of successful sstems. Sstems
Engineering considers both the business and the technical needs of all customers with the goal of
providing a qualit product that meets the user needs.’
Vrij vertaald betre het een interdisciplinaire benadering, die bijdraagt aan het ontwikkelen en
realiseren van succesvolle sstemen. Met Sstems Engineering willen we niet alleen de technische,
maar ook de bedrijfsdoelen van de klanten (stakeholders) nastreven. Dit met als doel het bieden
van een kwaliteitsproduct dat in de gebruikersbehoee voorziet.
1.2 SyStEEmdEnkEn‘Een ssteem is een, aankelijk van het gestelde doel, binnen de totale werkelijkheid te onder-
scheiden verzameling elementen, die onderlinge relaes hebben’ [In ’t Veld, 1986: ‘Analse van
organisaeproblemen’]. Een ssteem maakt aljd deel uit van een groter geheel en moet gewenste
doelen realiseren binnen een veranderlijke omgeving. Vanuit deze benadering kijken we ook naar
complexe problemen en mogelijke oplossingen. Het ssteem benaderen we daarbij van buiten
naar binnen. Ssteemdenken volgens Sstems Engineering biedt een structuur waarbinnen we
een project navolgbaar en aantoonbaar kunnen ontwikkelen, realiseren en beheren. We kunnen
het ssteem en de omgeving vanuit verschillende invalshoeken benaderen. Daarbij staan diverse
aandachtspunten centraal, die in deze paragraaf verder worden uitgewerkt.
SyStEmS EnGInEErInG
8
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 11/56
mEEr dan tEchnIEk
Sstemen gaan niet alleen over techniek, maar ook over mensen en procedures. Sstemen hebben
een funce, ze worden gebruikt, moeten bediend worden en hebben impact op mensen in hun
omgeving. Een voorbeeld: het venlaessteem in een tunnel moet uiteraard de juiste hoeveel
kubieke meters lucht verplaatsen. Daarnaast hee het ssteem echter impact op zaken als devluchtwegen van reizigers, de bediening vanuit een centrale en de vergunningenprocedures van
bijvoorbeeld de brandweer. Met dit alles moet rekening worden gehouden bij het ontwikkelen van
het venlaessteem.
SyStEm of SyStEmS
Een ssteem staat niet op zichzelf, maar maakt deel uit van een groter geheel. Hoe we een ssteem
zien en deniëren, is aankelijk van de belangen en verantwoordelijkheden van de waarnemer.
Hoe deze het ssteem beschouwt, noemen we het ‘Sstem of Interest’. Welk ssteem het Sstem
of Interest is, kan dus per waarnemer verschillen. Het grotere geheel waar het ssteem deel van
uitmaakt noemen we het ‘Sstem of Sstems’.
Figuur 1.1 gee als voorbeeld het mobiliteitssteem. Als Sstem of Interest is hier het staonssteem
weergegeven. Het staonssteem maakt deel uit van een groter geheel dat zelfstandig kan
funconeren, in dit voorbeeld het spoorvervoerssteem (het Sstem of Sstems). Op zichzelf
bestaat het staonssteem weer uit verschillende deelsstemen en ssteemelementen.
Dit betekent ook dat Sstems Engineering op verschillende niveaus opmalisaes kent. Nu
opmaliseren we nog vaak op projectniveau binnen een Sstem of Interest (staonssteem). Dat
wil niet zeggen dat deze opmalisae ook opmaal is gezien vanuit het perspecef van het Sstem
of Sstems (spoorvervoerssteem).
MOBILITEITSYSTEEM
SPOORVERVOERSYSTEEM
Figuur 1.1
SYSTEEM SYSTEEM ELEMENT SYSTEM OF SYSTEMS SYSTEM OF INTEREST
STATIONSYSTEEM
SAMENHANG SYSTEMEN
LUCHT
VERVOER
SYSTEEM
WATER
VERVOER
SYSTEEM
WEG
VERVOER
SYSTEEM
ONDERHOUD
SYSTEEM
TREIN
SYSTEEM
SPOOR
NETWERKSYSTEEM
ENERGIE
SYSTEEM
VERKEER
REGELSYSTEEM
CATERING &
SERVICE
SYSTEEM
PERSONEEL
REIS
INFORMATIE
SYSTEEM
PASSAGIER
INSTAP
SYSTEEM
KAARTVERKOOPSYSTEEM
DEEL-
SYSTEEM A
DEEL-
SYSTEEM B
SYSTEEM
ELEMENT C
9
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 12/56
ItEratIEf procES
De complexiteit van een probleemstelling en de gelaagdheid van sstemen vragen om een iteraeve
werkwijze bij de ontwikkeling van een ssteem. Het probleem is meestal niet in één keer in een
oplossing te vaen. Ontwerpkeuzes leiden telkens weer tot een nadere analse van het probleem
en een detailuitwerking van de oplossing. Dit iteraeve proces leidt tot steeds gedetailleerderespecicaes van het ssteem.
LEvEnScycLuS
Elk ssteem doorloopt een levenscclus van concept, via ontwikkeling, realisae, gebruik en
onderhoud tot sloop. Tijdens het ontwikkelen van sstemen onderschat men al snel de benodigde
inspanning voor onderhoud, vernieuwing en sloop. Een focus op één fase zorgt veelal voor
subopmalisae. Zo lijkt het soms goedkoper om geverfde leuningen op een viaduct te bouwen.
Maar het kan over de gehele levenscclus voordeliger blijken om roestvrij staal te gebruiken. Dit
is bijvoorbeeld het geval als hiermee onderhoudswerkzaamheden aan de geverfde leuningen,
waarbij kostbare wegafsluingen noodzakelijk zijn, worden voorkomen.
De levenscclus van een ssteem mag niet verward worden met het begrip levensduur. De
levensduur is gekoppeld aan het gebruik van het ssteem. Daarbij onderscheiden we verschillende
levensduren zoals: economische, technische, funconele en maatschappelijke. Per deelssteem of
ssteemelement kan de levensduur verschillen.
IntErdIScIpLInaIr
Om tot een werkend ssteem te komen, is het integreren van civiele, verkeerstechnische,
elektrotechnische en andere vakdisciplines noodzakelijk. Vaak worden projecten naar vakdisciplines
opgedeeld. Het gevaar daarbij is dat de samenhang van het ssteem onderbelicht blij. Een
interdisciplinaire aanpak van projecten is dus gewenst. Het is hierbij van belang om een ssteem
niet alleen te beschouwen vanuit een decomposie in deelsstemen en ssteemelementen, maar
om op belangrijke eigenschappen ook dwarsdoorsneden van het ssteem te maken. Daarmee
komen vanuit één perspecef alle relaes tussen de deelsstemen en ssteemelementen in beeld,
denk bijvoorbeeld aan de interne veiligheid van het ssteem. Een uitsnede van het ssteem vanuit
een dergelijk perspecef noemen we een aspectssteem. Aspectsstemen dragen bij aan het
integrale funconeren van het ssteem.
vaardIGhEdEn
Tot slot vereist ssteemdenken de benodigde vaardigheden. Analsch vermogen en expliciet
gestructureerd werken zijn cruciaal. Daarnaast vraagt ssteemdenken om de nodige creaviteit en
het vermogen om het ssteem vanuit verschillende invalshoeken en in samenhang te beschouwen.
10
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 13/56
de lse i e wse eege i 2008 11,4 e e e (: uSp
meg csl). bi ee e € 55 il (b&u e GWW) eee i geee
€ 6,2 il lse ele g.
he ig isele ee is i e wee ie ee lge e, ee
se gel e elges ie e w e eel we. de igig
e se is s eleee, se wie elge ssee e leee e
ee e lse e eee.
de wse s eiges ie sl. Iiels i eeee iiee ges ie i
see esee. z i e iese ee gesle e isieeesig,
we e eseige.
2.1 doELEnHet implementeren van Sstems Engineering binnen de GWW-sector is een gemeenschappelijk
iniaef van Rijkswaterstaat, ProRail, Bouwend Nederland, NLingenieurs en de Vereniging van
Waterbouwers (het ‘vier-parjenoverleg’). De parjen introduceren daarmee een werkwijze voor
de totstandkoming van infrastructurele projecten. Niet als eenmalige hpe, maar als structurele
diepgewortelde werkwijze gericht op de te bereiken doelstellingen en op nut en noodzaak.
Samengevat zijn de doelen die we met Sstems Engineering willen bereiken:
• Doelmagheid: voorzien in de behoee van de klant, binnen maatschappelijk
verantwoorde kosten.
• Doeltreendheid: eciënt terugdringen van de faalkosten en beter benuen van de
beschikbare resources.
• Transparane: aantoonbaar en beheerst leveren wat met de klant is afgesproken.
poSItIonErInG LEIdraad
De Leidraad richt zich op alle medewerkers in de GWW-sector, die op enigerlei wijze betrokken zijn
bij infrastructurele werken voor weg, water en spoor bij Rijkswaterstaat en ProRail. Dit zijn zowel
opdrachtgevers als opdrachtnemers. Aan beide kanten gaat het om mensen in verschillende funces,
zoals projectmanagers, ontwikkelaars, omgevingsmanagers, contractmanagers, projecngenieurs,werkvoorbereiders en controllers.
De Leidraad biedt geen standaardset methodes en technieken, en kan dan ook niet als kookboek
gebruikt worden. Wel wil de Leidraad een eenduidig beleid, kaders en randvoorwaarden creëren
voor toepassing van Sstems Engineering bij infrastructurele werken. De Leidraad geldt voor
projecten van Rijkswaterstaat en ProRail, maar kan ook sectorbreed gebruikt worden. Vandaar dat
we spreken van Sstems Engineering binnen de GWW-sector.
SyStEmS EnGInEErInG bInnEn GWW
11
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 14/56
2.2 LEIdEndE prIncIpESVoor het gezamenlijk implementeren van Sstems Engineering is een aantal uitgangspunten
vastgesteld door het vier-parjenoverleg. Deze uitgangspunten zijn richnggevend bij de
samenwerking binnen de GWW-sector. Ze geven aan wat de betrokken parjen van elkaar mogen
verwachten bij het werken volgens Sstems Engineering.
• Klantvraag centraal. Niet de techniek, maar de werkelijke behoee van de klant staat
centraal. Waarvoor is het ssteem bedoeld? Wat moet het ssteem kunnen? Met
klanten bedoelen we hierbij nadrukkelijk alle stakeholders die met het ssteem te
maken krijgen en niet alleen de betalende klant. Alle processtappen binnen Sstems
Engineering moeten gericht zijn op het voorzien in de behoee van deze klant.
Rijkswaterstaat en ProRail moeten expliciet borgen dat de uitvraag aan marktparjen
in deze oorspronkelijke klantvraag voorziet. Een contract dient dan ook door de
opdrachtgever te zijn geverieerd en gevalideerd aan de klantvraag van het project.
• Systeemdenken. Het ssteemdenken richt zich op de waarde voor de klant en
achterhaalt de vraag achter de vraag. Deze denkwijze kan leiden tot andere antwoorden
op klantvragen dan we gewend waren. Moo bij het ssteemdenken is dat het geheel
meer is dan de som der delen. Het ssteemdenken benadrukt het perspecef van de
totale levenscclus, van concept tot sloop. Knippen in een ssteem leiden aljd tot
verliezen. Bij knippen worden relaes doorbroken en ontstaan interfaces die beheerst
moeten worden. Het is dan ook van belang dat alle parjen in de sector projecten vanuit
het ssteemdenken benaderen.
• Transparane. We ontwikkelen transparant en traceerbaar. Dat betekent dat we
vastleggen welke keuzes, om welke reden zijn gemaakt. Denk daarbij bijvoorbeeld
aan ontwerpvarianten. Dit betekent dat expliciet aangetoond wordt dat het ssteem
voldoet aan de vraag. Hier zijn diverse methodes voor. In een contractsituae moetenopdrachtgever en opdrachtnemer overeenstemming bereiken over de te gebruiken
methodes van aantonen en vastleggen. Hierbij hanteren we een risicogestuurde
benadering.
• Eciency. Sstems Engineering is niet bedoeld om onnodig papierwerk te introduceren
en de kosten te vergroten. Integendeel: Sstems Engineering maakt het mogelijk
specicaes, bewijsmateriaal, cercaten en standaarden slim te hergebruiken.
Sstems Engineering omvat een palet aan methodes en technieken die kunnen
worden toegepast. Ieder project dient daarbij een verstandige keuze te maken uit het
beschikbare palet.
• Beste prijs-kwaliteitverhouding. Met Sstems Engineering koersen we op de oplossing
met de beste prijs-kwaliteitverhouding, die het probleem oplost binnen de gestelderandvoorwaarden. Prijsduiken en aanbesteden op basis van alleen de laagste prijs is
dan ook niet wenselijk.
• Balans ontwerpvrijheid en contractuele afspraken. Bij elke probleemstelling
behoort een zekere oplossingsruimte. Ontwerpvrijheid is gewenst om meer van de
creaviteit van de marktparjen te kunnen proteren. Alleen zo zijn we in staat om
de prijs-prestaeverhouding van een ssteem te maximaliseren. In de prakjk varieert
de oplossingsruimte in contracten nog aanzienlijk. De ontwerpvrijheid van een
opdrachtnemer moet in balans zijn met de contractuele afspraken. Opdrachtgever
en opdrachtnemer moeten een eenduidig beeld hebben van de beschikbare
oplossingsruimte. De opdrachtgever is ervoor verantwoordelijk dat de gegeven
oplossingsruimte past binnen de klantvraag. De opdrachtnemer moet ervoor zorgen
dat zijn aanbieding past binnen de oplossingsruimte.
12
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 15/56
• Vericae & validae. Deze termen kennen vele denies, maar internaonaal is er
geen eenduidig standpunt. De meest gangbare interpretae is dat vericae de vraag
beantwoordt of we het goed hebben gedaan. Validae beantwoordt de vraag of het
goede gedaan is. Wij willen in deze Leidraad geen discussie voeren over de precieze
denie van vericae & validae. Wel willen we gebruikmaken van de mogelijkhedendie deze beide methodes bieden bij het aantonen of het ssteem voldoet. In de Leidraad
benaderen we vericae & validae dan ook als één geheel.
• Afstemming met projectmanagement. Sstems Engineering en projectmanagement-
methodieken als Prince2, Projectmag Werken en IPM vullen elkaar goed aan.
Projectmanagementmethodieken concentreren zich met name op de besturing van
een project, terwijl Sstems Engineering focust op het ontwikkelen en realiseren van
de inhoud van een ssteem. Ook zijn er overlappen, zoals conguraemanagement en
risicomanagement. De inrichng van deze processen vereist een zorgvuldige afstemming
tussen projectmanagement en Sstems Engineering.
• Openheid. Vanwege het iteraeve karakter is Sstems Engineering gebaat bij open
communicae. Opdrachtgever en opdrachtnemer moeten dit voor ogen houden
bij besluiten, achtergrondinformae, ssteemkeuzes en risico’s. De parjen dienen
alle informae te delen die noodzakelijk is voor een goede interpretae van de
probleemstelling en onderbouwing van de oplossing.
2.3 GroEIpadcuLtuurvErandErInG
De implementae van Sstems Engineering is een intensief verandertraject. Het toepassen van
deze werkwijze vraagt om een cultuurverandering. Zo moet de opdrachtgever al in een vroeg
stadium vertellen wat hij wil, waar hij vroeger alleen het denieve ontwerp hoefde goed te
keuren. Vericae & validae is daarbij niet alleen een verantwoordelijkheid van de aannemer.
ProRail of Rijkswaterstaat moet zelf aantonen dat de oplossingsruimte past bij de doelstellingen van
het project. Het streven naar de beste prijs-prestaeverhouding vraagt om het bewust toepassen
van Sstems Engineering en het werken met methodes en technieken als Value Engineering en
variantenanalses. Zo’n analse is voor de klant een investering die zich uiteindelijk terugbetaalt.
Dit gebeurt niet alleen op korte termijn, maar binnen de gehele levenscclus. Dat alles vraagt om
een cultuurverandering; men moet het belang zien van zaken die in de toekomst geld besparen.
De nieuwe aanpak van vericae & validae zorgt ervoor dat de aannemer niet meer kan
vertrouwen op het toezicht door de opdrachtgever, maar zelf moet aantonen dat het gerealiseerde
werk aan de specicaes voldoet. Dat betekent dat hij na contractering niet direct aan de slag
gaat met het ontwerp, maar eerst een eigen analse start. Dit om de eisen te checken op een juiste interpretae en met een slim ontwerp en door bouwfasering mogelijk voordeel te behalen.
Hiermee kan bijvoorbeeld meerwerk in een latere fase worden voorkomen.
13
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 16/56
ambItIE
De afgelopen jaren paste men Sstems Engineering vooral toe bij individuele projecten. Het
opmaliseren van sstemen over projecten heen, laat staan in een hele bedrijfsketen, is nog
nauwelijks aan bod gekomen. De focus ligt vooralsnog op het doelmag en beheerst realiseren
van projecten. Om de groeimogelijkheden weer te geven is het CMMI-model (Capabilit MaturitModel Integraon) geadopteerd, dat is ontwikkeld door het Carnegie Mellon Soware Engineering
Instute (www.sei.cmu.edu/cmmi/). Het model beschrij vijf niveaus en bewees zich in de prakjk
als een natuurlijk groeimodel bij de implementae van veranderprocessen, zoals de toepassing van
Sstems Engineering. De hier afgebeelde tabel is een beknopte weergave van het CMMI-model. Per
niveau is aangegeven op welke processen de nadruk ligt.
Het verandertempo in de bouwsector blijkt niet overal gelijk. Een koplopergroep die bestaat uit
Rijkswaterstaat, ProRail, enkele aannemers en ingenieursbureaus hee de ambie om binnen twee
jaar CMMI-level 3 te bereiken. De gehele sector zou zich binnen vijf jaar op dit niveau moeten
bevinden.
N iveau Focus ProcesgebiedeN
5 Connue procesverbetering Proces wijzigingsmanagement
Voorkomen van defects
Technologisch wijzigingsmanagement
4 Kwantaef management Kwantaef projectmanagement
Systeem kwaliteitsmanagement
Performance van de organisaeprocessen
3 Processtandaardisae Vericae & Validae
Risicomanagement
Eisenontwikkeling en ontwerpafwegingen
2 Basisprojectmanagement (Sub)contractmanagement
Conguraemanagement
Eisenmanagement
1 Inieel
Figuur 2.1
cMMi-Model
14
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 17/56
I i s eele we ee l esseële eee e wewie lges
Sses Egieeig ie e GWW-se. alleees is e el selle e
lg. aslie g we i e leeslslise. velges s e iee
seiees el, wi we slie e -w wiele e -
elisee ee elie. t sl g we ee i e eiëe e liee.
3.1 dE kLantvraaG cEntraaL StELLEnDe sstemen die binnen de GWW-sector worden ontwikkeld kennen doorgaans uiteenlopende
stakeholders, zowel betalende als niet-betalende. Deze stakeholders stellen elk hun eigen
voorwaarden aan het te ontwikkelen ssteem. Binnen deze Leidraad zien we de klant als de
verzameling van stakeholders, terwijl we de klantvraag zien als de verzameling van behoeen en
randvoorwaarden van deze stakeholders (klant).
Het startpunt voor een project binnen de GWW-sector is een analse van problemen en kansen
gerelateerd aan de klantvraag. Deze klantvraag is gericht op het door de betalende klant
beschouwde ssteem, zijn ‘Sstem of Interest’, en op het beoogde gebruik van dat ssteem, zijn
iniële behoee. De klantvraag staat centraal bij het toepassen van Sstems Engineering: de klant
bepaalt wat het probleem is, welke oplossingsruimte wordt gegeven en wanneer een oplossing
voldoet. Zo wordt via Sstems Engineering de opmale oplossing voor het probleem gecreëerd
binnen de gegeven oplossingsruimte. Bepalend voor de oplossingsruimte zijn bijvoorbeeld: fsieke
begrenzing, normen en richtlijnen alsmede beschikbare jd en beschikbaar budget.
kLant EISEn SpEcIfIcatIE
De eerstvolgende stap is het speciceren van de klanteisen. Hierbij behoort een stakeholderanalse:
welke stakeholders zijn er en wat zijn hun belangen en behoeen? Dit resulteert in een helder
en gestructureerd overzicht van de benodigde funconaliteiten, de eisen per stakeholder, de
beschikbare oplossingsruimte en een beschrijving van het Sstem of Interest van de klant. Dit
wordt vastgelegd in de Klant Eisen Specicae (zie ook guur 3.1). De Klant Eisen Specicae vormt
de input voor het verdere proces van ssteemontwikkeling.
Van belang is dat de Klant Eisen Specicae connu beheerd wordt jdens het ontwikkelen vanhet ssteem. Klanteisen kunnen immers wijzigen of worden aangevuld op basis van zaken als
ontwerpkeuzes, veranderende wetgeving of een poliek klimaat.
Alle stappen binnen Sstems Engineering zijn er vervolgens op gericht om aan te tonen dat er
gewerkt wordt aan de opmale uitwerking van het ssteem op basis van de gedenieerde Klant
Eisen Specicae.
SPECIFICEREN KLANTEISEN
SPECIFICEREN
KLANT EISEN
SPECIFICATIE
BEHOEFTEN
STAKEHOLDERS
Figuur 3.1
dE ESSEntIE van dE WErkWIjzE
15
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 18/56
d!
Slee e lisee e ssee sis e lg i lle
e i e ee. di el e ls ele eel e ele
l i e el selle e lg (e ‘w’s i i e’-iie).
Ee eel is e ele eeligsiei e wliei ieige e ees ise leise i e e.
3.2 LEvEnScycLuS optImaLISErEnEen ssteem doorloopt jdens een levenscclus meerdere fasen. Sstems Engineering is gericht op
het opmaliseren van een ssteem over de gehele levenscclus. De behoee van de klant staat bij
al deze fasen centraal.
De opmalisae van de levenscclus komt op twee manieren aan bod. In de eerste plaats in de
manier waarop de levenscclusafwegingen expliciet in de ontwikkel- en realisaefase worden
meegenomen. Dit betekent niet alleen opmaliseren naar bouwjden en bouwkosten, maar ook
opmaliseren naar gebruiks-, onderhouds- en sloopkosten. In de tweede plaats komt dit naar
voren doordat we de werkwijze van Sstems Engineering gedurende alle fasen van de levenscclus
toepassen. Het transparant en traceerbaar uitvoeren van de ontwikkel- en realisaefase maakt het
mogelijk om in de gebruiksfase nieuwe ontwikkelingen binnen en buiten het ssteem te onderkennen
en te verwerken. En als dat nodig is voor ssteemaanpassingen, dan is een onderbouwing van de
oorspronkelijke ontwerp- en bouwkeuzes beschikbaar.
3.3 ItEratIEf SpEcIfIcErEnOm in de klantbehoee te voorzien, moet het ssteem een aantal funces vervullen. Uit deze
funces en de randvoorwaarden van de stakeholders volgen de ssteemeisen. Binnen de gegeven
oplossingsruimte zijn meerdere ontwerpkeuzes mogelijk om aan deze eisen te voldoen.
De procesgang binnen Sstems Engineering gaat uit van een iterae tussen funces, eisen en
oplossingen. Door het vastleggen van eisen bepaal je binnen welke oplossingsruimte het ssteem
moet funconeren. Ontwerpkeuzes bepalen hoe het ssteem die funces vervult en welke
oplossingsruimte benut wordt. Dit leidt weer tot afgeleide funces en nadere eisen aan de verdere
ontwikkeling van het ssteem. In guur 3.2 is het iteraeve proces van speciceren weergegeven.
conSEquEntIES
Bij elke stap in de ssteemontwikkeling dwingt het samenspel van funces, eisen en oplossingen
ertoe na te denken over het ‘waarom’ van de ontwerpkeuze en de consequenes voor het vervolg.
Funces, eisen en oplossingen worden vastgelegd in specicaes. Dit noemen we het specicerenvan het ssteem.
Het specicaeproces kent aljd een specicae van de vraag en de oplossingsruimte als input en
resulteert in een specicae van de uitgewerkte oplossing als output. Deze output dient vervolgens
weer als input voor de volgende stap in de ontwikkelfase. Het aantal iteraes dat wordt doorlopen
in het specicaeproces hangt af van het gewenste detailniveau van de input en de output.
16
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 19/56
3.4 topdoWn ontWIkkELEn En bottomup rEaLISErEnIn de GWW-sector hebben we doorgaans met complexe sstemen te maken. Daardoor valt de
totale uitwerking van het ssteem in al zijn ssteemelementen niet in één ontwikkelslag te vaen.
Het iteraeve proces van speciceren herhaalt zich dan ook op meerdere detailniveaus, waarbij
het ontwerp van een ssteem wordt ontleed in deelsstemen en ssteemelementen waaraan
nadere, afgeleide eisen worden gesteld. Figuur 3.3 gee deze top-down benadering weer als
een neergaande lijn in de ontwikkelfase van het ssteem. Het detailniveau van een specicae
moet passen bij het niveau van de besluitvormingsfase waarin het project verkeert. In de eerste
versie van de Leidraad beschreven we de deelsstemen en ssteemelementen als subsstemen,
componenten en elementen. Dat suggereerde een standaardindeling in vier niveaus, terwijl in de
prakjk het aantal niveaus aankelijk is van de complexiteit van het ssteem.
IntEGrErEn
Uiteindelijk dienen alle deelsstemen en ssteemelementen in elkaar te passen en worden ze
geïntegreerd tot het totale ssteem. Met deze integrae dient in de ontwikkelfase al rekening
te worden gehouden; de feitelijke integrae vindt plaats in de realisaefase. Deze boom-up
benadering van de realisaefase is in guur 3.3 weergegeven als opgaande lijn. Zo ontstaat het
integrale V-model als vereenvoudigde weergave van de totale totstandkoming van een ssteem.
Het V-model is een van de mogelijke benaderingen. Daarnaast bestaan diverse andere modellen
die toepasbaar zijn, zoals prototping, het spiraalmodel, en het watervalmodel. Welk model we
kiezen, is in wezen niet zo relevant; het belangrijkste is dat het toegepaste model helpt bij het
begrijpen en beheersen van het ssteem.
SPECIFICEREN
I N P U
T
SPECIFICATIE
SPECIFICATIE
O U T P U
T
ITERATIEF SPECIFICATIEPROCES 1
Figuur 3.2
17
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 20/56
Figuur 3.3 toont aan:
• Top-down ontwikkelen: de ontwikkelfase leidt tot steeds gedetailleerdere specicaes.
• Boom-up realiseren: de realisaefase leidt tot een steeds verder geïntegreerd
ssteem.
3.5 vErIfIËrEn En vaLIdErEnDe begrippen veriëren en valideren beschrijven alle acviteiten die nodig zijn om objecef en
expliciet te kunnen aantonen dat de oplossing voldoet aan de eisen en behoeen van de klant en
daarmee past binnen de oplossingsruimte. Vericae is een check of het juist gebouwd is, validae
is een check of het juiste gebouwd is. Figuur 3.4 toont het belang van het regelmag controleren
met het beoogde gebruik in het achterhoofd.
In de huidige prakjk is het moeilijk om een harde scheiding aan te brengen tussen de acviteiten
voor vericae en die voor validae. Bovendien worden resultaten die verkregen zijn door
vericae soms ook gebruikt voor validae. Daarom behandelen we vericae & validae in de
Leidraad als duo. Een goede toepassing van Sstems Engineering vraagt erom dat de acviteiten
en verantwoordelijkheden voor vericae & validae per ssteem en per project expliciet worden
vastgelegd. Hierbij behoort ook de benodigde nauwkeurigheid in de bewijsvoering.
SPECIFICEREN REALISEREN
V-MODEL: TOP-DOWN VS BOTTOM-UP
Figuur 3.3
D E T A I L L E R E N
D E T A I L L E R E N
I N T E
G R E
R E N
I N T E
G R E
R E N
ONTWIKKELFASE REALISATIEFASE
DE SCHOMMEL
Figuur 3.4
WAT DE KLANT HADVERWOORD
HOE DIT WERDGEÏNTERPRETEERD
HOE HET WERDONTWORPEN
WAT WERDUITGEVOERD
HOE DIT WERDGECORRIGEERD DE DOCUMENTATIE DE KLANT-
BEHOEFTE
?
18
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 21/56
op ELk nIvEau
Veriëren en valideren gebeurt in het iteraeve specicaeproces op elk detailniveau en in
alle fasen van de levenscclus (zie ook guur 3.5). Dit maakt het mogelijk foueve keuzes jdig
te onderkennen en waar mogelijk te voorkomen. Hierbij mag de doelmagheid van veriërenen valideren niet uit het oog worden verloren. Daarom is in elke fase een gedegen vericae &
validaestrategie van belang.
d!
veiëe e liee e l i e egse si e ssee-
wielig e we ges. o ls e gee se ee sie
is, ee ees geeiee e geliee we sis e leise
e e sseeeise.
VERIFICATIE EN VALIDATIE IN V-MODELFiguur 3.5
VERIFIËREN / VALIDEREN
SPECIFICEREN REALISEREN
ONTWIKKELFASE REALISATIEFASE
19
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 22/56
Ee ssee l i e leesls esillee se. di s gee ee geeiee
esiig e seig ee. he g ee i e esse ie we
le i e wielse e elisese. veie & lie is i lle esse
elg; e ieie ie ie ig i e i i s.
4.1 faSErInGVerschillende normen beschrijven de levenscclus die een ssteem doorloopt, zoals de internaonale
standaard voor Sstems Engineering ISO 15288 en de Spoorwegnorm EN 50126.
Generiek herkennen wij de volgende fasen:
• De concepase waarin we (nieuwe) behoeen van stakeholders inventariseren en
mogelijkheden beoordelen. De eerste klanteisen en oplossingsrichng worden hier
bepaald. De concepase kan leiden tot het iniaef voor het ontwikkelen en realiseren
van een ssteem.
• De ontwikkelfase waarin we een ssteem speciceren dat voldoet aan de klanteisen.
Aan het eind van de ontwikkelfase ligt er een (startklaar) ontwerp voor het gehele
ssteem.
• De realisaefase waarin we het ssteem vervaardigen en beproeven. Ssteemelementen
en deelsstemen worden geïntegreerd tot één geheel.
• De gebruiksfase is de periode waarin het ssteem wordt geëxploiteerd. Hier vinden de
acviteiten plaats die nodig zijn om het ssteem te gebruiken zoals beoogd.
• De beheer- en onderhoudsfase is de periode waarin we de ondersteunende acviteiten
uitvoeren, die noodzakelijk zijn om het ssteem in werking te houden.
• De sloopfase is bedoeld om een ssteem met bijbehorende operaonele diensten en
funces buiten werking te stellen en te verwijderen.
Bij het doorlopen van de fasen vinden overdrachtsmomenten tussen betrokken parjen plaats.
Het is hierbij van belang transparant de benodigde informae over te dragen. Omdat op
overdrachtsmomenten informaeverlies kan optreden, is het verstandig om te voorkomen dat
de fasering en overdracht gelijklopen. Dit om te voorkomen dat subopmalisae telkens binnen
de fase plaatsvindt, waarbij de verantwoordelijkheid voor de gehele keten uit het oog wordt
verloren (het ‘over de schung-eect’). Het expliciete karakter van Sstems Engineering voorkomtinformaeverlies bij overdracht.
INFORMATIEOVERDRACHT IN LEVENSCYCLUSFiguur 4.1
CONCEPT ONTWIKKELFASE REALISATIEFASE SLOOPGEBRUIKSFASEONDERHOUD / VERNIEUWINGCONCEPTFASE ONTWIKKELFASE REALISATIEFASE SLOOPFASEGEBRUIKSFASEONDERHOUD / VERNIEUWING
procESStappEn
20
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 23/56
d!
zg eliiee iee. Ee iee es we ie ls
e i e ee ls el eee. oe ie sse e
es e geele leesls ee ssee is ee we e
sesl wee e Sses Egieeig.
4.2 ontWIkkELfaSEHet ontwikkelen van een ssteem kan worden opgevat als een denk-, werk- en besluitproces,
waarbij informae wordt verzameld en bewerkt. De ontwikkelfase is iteraef, doelgericht en
probleemoplossend, waarbij funces en eisen worden geanalseerd en de oplossing steeds
gedetailleerder wordt gespeciceerd. Een gelaagde top-down benadering is noodzakelijk omdat
het ontwerpprobleem vaak niet in één stap is op te lossen. Opeenvolgende keuzes brengen de
ontwerper steeds dichter bij de uiteindelijke oplossing. De behoee van de klant bij de start van de
ontwikkelfase wordt in een aantal stappen omgezet naar een uitvoeringsgereed ontwerp.
dEtaILnIvEauHet proces van speciceren herhaalt zich totdat het detailniveau is bereikt dat de risico’s voldoende
dekt om tot realisae van het ssteem over te gaan. Het detailniveau van de input en de output kan
verschillen, aankelijk van de besluitvormingsfase waarin het project zich bevindt. Het verdelen
van het specicaeproces in verschillende detailniveaus maakt het overzichtelijker en beter
beheersbaar. In de GWW-sector gebruiken we regelmag onderstaande begrippencombinaes om
detailniveau in de ontwikkelfase aan te duiden:
• Schetsontwerp Voorlopig ontwerp Denief ontwerp Uitvoeringsontwerp
• Funconeel ontwerp Ruimtelijk ontwerp Construcef ontwerp
In de prakjk wordt vaak boom-up gewerkt; men begint bij het construcef ontwerp en kijkt
welke eisen daarbij passen. De kunst is echter om van grof naar jn te werken en daarbij connu de
interace tussen funces, eisen en oplossingen goed te bewaken.
Elk detailniveau kent een specicae van de oplossingsruimte als ‘input’ en een specicae van de
oplossing als ‘output’. Deze output kent bepaalde marges die de nieuwe oplossingsruimte vormen,
als input voor het volgende detailniveau.
I N P U T
SPECIFICATIE
SPECIFICATIE
O U T P U T
DETAILNIVEAUS SPECIFICEREN
Figuur 4.2
I N P U T
SPECIFICATIE
O U T P U T
21
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 24/56
Op elk detailniveau is dus een zekere oplossingsruimte gedenieerd. Op elk niveau worden keuzes
vastgelegd ofwel ontwerpen gemaakt. Op elk detailniveau kent het uitgewerkte ontwerp een
zekere marge die de begrenzing van het ontwerp bepaalt. Figuur 4.3 gee weer dat het ontwerp
van de oplossing en bijbehorende marge binnen de gegeven oplossingsruimte dient te passen.
Dit principe geldt op elk detailniveau, waarbij de oplossingsruimte telkens bepaald wordt door demarge van het ontwerp op het bovenliggende niveau (en dus steeds kleiner wordt).
d!
besi l ele e ieli e lssigsie i ee seie e
gee ele . Ee se eise is gelei eee gee
weees; i eliie.
SpEcIfIcErEn
Het speciceren is een iteraef proces met een aantal generieke stappen die onaankelijk zijn van
het detailniveau:
• Analseren (probleem ontleden en oplossingsruimte benoemen).
• Structureren en alloceren (overzicht creëren).
• Ontwerpen (keuzes vastleggen en oplossing uitwerken).
Bij elkaar vormen deze stappen het specicaeproces van de ontwikkelfase. Figuur 4.4 gee dit
generieke proces weer. Daarbij vindt connue vericae & validae plaats om te borgen dat het
proces de gewenste output oplevert.
OPLOSSINGSRUIMTE MARGE ONTWERP ONTWERP OPLOSSING
ONTWERP VS OPLOSSINGSRUIMTE
Figuur 4.3
OUTPUT
SPECIFICEREN
INPUT
SPECIFICATIE
Probleem +oplossingsruimte
Oplossing +marge
SPECIFICATIE
VERIFIËREN / VALIDEREN
ITERATIEF SPECIFICATIEPROCES 2Figuur 4.4
ONTWERPEN
STRUCTURERENEN
ALLOCEREN
ANALYSEREN
22
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 25/56
anaLySErEn
Het doel van het analseproces is onder meer het doorgronden van de vraag achter de vraag: Welke
informae is nodig om een verdiepingsslag te kunnen maken? Wat zijn de krische of risicovolle
eisen? Welke eisen zijn conicterend of kostenbepalend? (Zie guur 4.5)
De input die een ontwerper ontvangt is vaak onvolledig en niet gedetailleerd genoeg voor eenverdiepingsslag in de uitwerking van de oplossing. Dit komt doordat deze input het resultaat beschrij
van keuzes in een eerdere fase op een hoger detailniveau. Dat maakt een verdere analse van het
probleem en de oplossingsruimte noodzakelijk. Het analseren richt zich in eerste instane op de
vraag of de vereiste informae ook beschikbaar is. Als vereiste gegevens ontbreken, vraagt dit om
het formuleren van uitgangspunten. De verkregen informae vormt vervolgens het startpunt voor
het uitvoeren van een ssteemanalse en het opstellen van nadere ssteemeisen. Voorbeelden van
methodieken voor een ssteemanalse zijn een procesanalse, funce-analse of life ccle analse.
Het doel van de ssteemanalse is het vertalen van de behoee en oplossingsruimte naar SMART-
geformuleerde vereisten voor de verdere ontwikkeling van het ssteem. Hierbij worden eisen waar
nodig doorvertaald naar gedetailleerdere eisen. Tijdens deze analse komen ook beperkingen aan
bod; deze vormen samen met de ssteemeisen de grenzen van de oplossingsruimte. De relae
tussen de eisen wordt vaak weergegeven in een Requirements Breakdown Structure (RBS), ook
wel eisenboom genoemd. De RBS toont de samenhang tussen de eisen, gestructureerd naar de
verschillende detailniveaus. Een eis is aljd traceerbaar tot een eis op een hoger detailniveau.
StructurErEn En aLLocErEn
Naarmate het probleem in complexiteit toeneemt, wordt het moeilijker voor de individuele
ontwerper het gehele ontwerpveld af te dekken. Vaak moeten meerdere disciplines of parjen
een bijdrage leveren aan het totale ssteem. Een gecoördineerde bijdrage van alle parjen vraagt
om het decomponeren van het ssteem. Hierbij deelt men het ssteem op in de objecten waaruit
het totale ssteem is opgebouwd: de deelsstemen en ssteemelementen. Het decomponeren
kan plaatsvinden volgens verschillende dimensies, bijvoorbeeld: funconeel, construcef of
geograsch. Daarbij kunnen we gebruikmaken van diverse structuren, zoals de Sstem Breakdown
Structure (SBS, ook wel objectenboom genoemd). De SBS is een structuur die alle te ontwerpen,
bouwen, onderhouden en slopen objecten in een hiërarchische indeling weergee (zie guur 4.6).
KRITISCHE EIS
CONFLICTERENDE EISEN
KOSTENBEPALENDE EISEN
EISEN ANALYSE
Figuur 4.5
KLANTEISEN
S T A K E H OL DE R A
EIS A1
EIS A2
EIS A3
S T A K E
H OL DE R B
S T A K E H OL DE R C
S T A K E H OL DE R
n
EIS B1
EIS B2
EIS C1
EIS C2
EIS n1
EIS n2
23
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 26/56
We kunnen de eisen en informae vanuit de eerdergenoemde analse koppelen aan de
deelsstemen in de SBS. Je kunt zowel eisen als funces alloceren aan objecten. Figuur 4.7 gee
weer dat door het alloceren van eisen er per deelssteem of ssteemelement een specicae
ontstaat van de behoee en de oplossingsruimte.
D E C O M P O S
I T I E
I N T E G R A T I E
SYSTEM BREAKDOWN STRUCTURE
Figuur 4.6
1
SYSTEEM
1.2
SYSTEEM
ELEMENT
1.1.1
SYSTEEM
ELEMENT
1.1.2
SYSTEEM
ELEMENT
1.3.1
SYSTEEM
ELEMENT
1.3.2
SYSTEEM
ELEMENT
1.3
DEELSYSTEEM
1.1
DEELSYSTEEM
SPECIFICATIESYSTEEMELEMENT 1.1.1
SPECIFICATIESYSTEEMELEMENT 1.2
S Y S T E E M E I S E N
FUNCTIE A
FUNCTIE C
ASPECT X
RAAKVLAK 1
FUNCTIE B
EIS A2
EIS A1
EIS A3
EIS C1
EIS B1
EIS C2
EIS X1
EIS R1.1
EIS R1.2
1
SYSTEEM
1.2
SYSTEEM
ELEMENT
1.1.1
SYSTEEM
ELEMENT
1.1.2
SYSTEEM
ELEMENT
1.3.1
SYSTEEM
ELEMENT
1.3.2
SYSTEEM
ELEMENT
1.3
DEELSYSTEEM
1.1
DEELSYSTEEM
ALLOCATIE
Figuur 4.7
24
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 27/56
bEhEErSEn van compLExItEIt
Voor het managen van taken en acviteiten wordt ook vaak gebruikgemaakt van de Work
Breakdown Structure (WBS). Deze biedt een structuur voor alle acviteiten die we voor een project
moeten doorlopen.
De genoemde structuren ondersteunen de top-down benadering van complexe sstemen. Zehelpen bij het beheersen van de complexiteit van een ssteem. Hoewel het decomponeren van
het ssteem zorgt voor betere beheersbaarheid, leidt de opdeling tot raakvlakken tussen de
objecten en/of processen die op hun beurt weer beheerst moeten worden. Het is belangrijk om de
samenhang van het ssteem zorgvuldig te bewaken en de integraliteit niet uit het oog te verliezen.
Met aspectsstemen beschouwen we de intrinsieke eigenschappen van het ssteem, dwars door
alle deelsstemen en ssteemelementen heen. Het werken met aspectsstemen helpt om te
borgen dat het ssteem als integraal geheel goed funconeert.
d’!
he is ie e eelig leie ee els igewiel e e
eiels e eee ewil i e eeesei ie e gee. desies i eel ei e eëe e leiei e
eeese.
ontWErpEn
Ontwerpen beschouwen we als het creaeve proces om tot de opmale oplossing te komen.
Bekijken we het ontwerpproces, dan zien we dat het een grote verscheidenheid aan acviteiten
omvat: van ideevorming tot schetsen, van berekenen tot tekenen en van begroten tot besluiten.
Als we het ontwerpproces verdelen in een aantal logisch geordende, iteraeve stappen, wordt het
overzichtelijker. In deze Leidraad onderscheiden we daarbij de volgende stappen:
• Het genereren van haalbare varianten.
• Het kiezen van de opmale variant.
• Het verder uitwerken van de gekozen variant.
Met het genereren van opes en varianten willen we de verschillende oplossingsmogelijkheden
voor een ssteem bepalen. Dit kan bijvoorbeeld door het organiseren van brainstormsessies.
Om vanuit de mogelijke varianten de opmale oplossing van het beschouwde object te kiezen,
beoordelen we de varianten op basis van de eisen. Daarnaast kunnen ook andere criteria een rol
spelen bij de beoordeling, zoals kosten, planning en risico’s. De eecten van de varianten worden
ten opzichte van de eisen en de vastgestelde beoordelingscriteria berekend en vergeleken met
behulp van bijvoorbeeld een scoringsmatrix of trade-o matrix. Daarbij krijgen de verschillende
beoordelingscriteria een wegingsfactor. De variant die het beste scoort, wordt uiteindelijk gekozen
als oplossing voor het ssteem.Bij het verder uitwerken van de gekozen variant wordt de oplossing nader gespeciceerd en
gedimensioneerd. Dit resulteert in een uiteindelijke specicae van de oplossing. Deze specicae
kan bestaan uit een set van tekeningen, ssteemspecicaes, onderbouwingen van de afwegingen
en marges op ontwerpkeuzes. Op basis hiervan kan worden aangetoond dat invulling is gegeven
aan de funces en gestelde eisen binnen de gegeven oplossingsruimte.
25
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 28/56
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 29/56
Vericae & validae in ontwikkelfase:
• Analse (o.a. haalbaarheidsanalse, kosten-batenanalse)
• Berekening (o.a. sterkteberekeningen)
• Audit van bestaande kwaliteitssstemen en -processen (o.a. Technical Inspecon
Services)• Demonstrae (o.a. presentae van de funconaliteiten van een bestaand ssteem)
• Documentbeoordelingen (o.a. documennspeces, reviews, toetsen, ontwerpateliers)
• Modellering (o.a. prestaemodellen van beschikbaarheid, verkeersmodellen)
• Simulaes (o.a. dienstregelingsimulae)
• Referene (o.a. gebruik van gecerceerde producten)
Vericae & validae in realisaefase en gebruiksfase:
• Keuren (o.a. bouwstoenkeuring, ingangs- en uitgangscontroles)
• Testen (o.a. haalbaarheidstesten, FIT, FAT, SIT, SAT)
o Factor Integraon Test (o.a. hdraulische en mechanische installaes integraal
testen)
o Factor Acceptance Test (o.a. cameratesten in fabrieksopstelling)
o Site Integraon Test (o.a. interacetesten tussen installae- en besturingssstemen)
o Site Acceptance Test (o.a. calamiteitenoefeningen in bijzijn van hulpdiensten)
• Meng (o.a. luchtsnelheidmengen in tunnels, kalenderen van heipalen)
• Monitoring (o.a. zengen, monitoring van draaiuren t.b.v. opmale vervanging)
• Schouw (o.a. visuele opname van projectlocae)
• Inspeces (o.a. Arbo-inspeces, pompkelderinspeces)
Alle genoemde V&V-methodes kunnen alleen gebruikt worden als duidelijk is volgens welke
criteria geverieerd en gevalideerd moet worden. Dit is nodig voor de juiste nauwkeurigheid van
de bewijsvoering. Het detailniveau van de benodigde V&V-methode is risicogestuurd.
d!
bee e ie eel v&v-ieie ie gei i e le
seiee eise. Ee eelig gee eelssee g gee wee
ssee. bw v&v-eie i ie ge e lee ssee g
wee ls i e l eel ws.
concrEtE afSprakEn
Om overzicht te houden op de V&V-acviteiten worden de V&V-plannen en -rapporten
samengevoegd in een V&V-dossier. Dit dossier groeit jdens het vorderen van de levenscclusvan het ssteem. Aan het einde van elke levenscclusfase is het V&V-dossier onderdeel van de
overdrachtsinformae. Het is voor alle betrokkenen belangrijk dat vanaf het begin concrete
afspraken bestaan over de acviteiten die behoren bij vericae & validae.
Opdrachtgever en opdrachtnemer moeten het eens zijn over de manier waarop wordt
aangetoond dat aan het contract wordt voldaan en over de V&V-documenten die ter acceptae
worden aangeboden. De bijbehorende inspanning hoort in verhouding te staan tot het niveau
van de overgedragen verantwoordelijkheden. Kostenbepalende V&V-acviteiten moeten vóór
opdrachtverlening zijn afgesproken.
Tijdens het proces kan op basis van risico’s geconcludeerd worden dat uitgebreider bewijsmateriaal
nodig is dan in eerste instane werd gedacht. De resultaten van een risicoanalse kunnen hiertoe
aanleiding geven. Een voorbeeld is de verborgen-gebrekenverzekering, waarbij de verzekeraar
extra inspanning vereist in de vorm van V&V-acviteiten. Dit om de kans op verborgen gebreken te
verkleinen en hiermee het risicoproel te verlagen.
27
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 30/56
Sses Egieeig i i e leee geee e geele leesls. d
se lle esse lise e e leesls ee ssee: e leesls-
eeig. zeeei e w e geee e geele leesls g geee is ie
geli. v ee geege lse i ee esillee ees e eiee
esi. I i s g we i ee l egie ie elg i ee
gee lse e leesls ee ssee. di i eeelges: ramS, vle
Egieeig, Lie cle cs e asse mgee.
5.1 dE LEvEnScycLuSbEnadErInG In procESSEnIn projecten ligt vaak de nadruk op processen in de ontwikkelfase en de realisaefase. Bij sstemen
met een lange gebruiksduur doorloopt men deze processen jdens de gebruiksfase meerdere
malen.
Dit is in guur 5.1 schemasch weergegeven met kleine V’s in de gebruiksfase. Het opnieuw
doorlopen van het specicaeproces jdens de gebruiksfase betekent dus niet dat de ontwikkelfase
weer blanco aanvangt. Wanneer in de gebruiksfase aanpassingen aan het ssteem nodig zijn, biedt
het voordelen als in de ontwikkel- en realisaefase al volgens Sstems Engineering is gewerkt. De
aanpassing blij dan beperkt tot een wijziging op de oorspronkelijke specicae.
Toelichng op guur 5.1:
• Bij de aanleg van het ssteem doorlopen we de processen van speciceren en realiseren
voor de eerste maal. Dit betre de levenscclusfasen: concept, ontwikkeling en
realisae.
• Als het ssteem in gebruik is, is onderhoud nodig. Hiervoor moeten we de processen van
speciceren en realiseren deels opnieuw doorlopen om te beoordelen of het ssteem
nog aan de eisen voldoet en om eventuele afwijkingen te corrigeren.
V-MODEL EN LEVENSCYCLUSFiguur 5.1
CONCEPTFASE ONTWIKKELFASE REALISATIEFASE SLOOPFASEGEBRUIKSFASE
ONDERHOUD / VERNIEUWING
LEvEnScycLuSbEnadErInG
28
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 31/56
• Gedurende de levensduur verandert de behoee van de klant, wat bijvoorbeeld invloed
hee op de gevraagde prestaes van het ssteem. Dit leidt tot aanpassingen op het
ssteem, zoals het vervangen van ssteemelementen of het toevoegen van nieuwe
funconaliteiten. We doorlopen opnieuw, maar dit keer gedeeltelijk, de ontwikkel-
en realisaefase om de aanpassingen te speciceren en tot stand te brengen. Ditvernieuwen of verbeteren kan meerdere malen voorkomen in de levenscclus van een
ssteem.
• De levenscclus van een ssteem eindigt met de sloop. Bij complexe sstemen
kan nadere specicae van de sloopacviteiten noodzakelijk zijn. Bij een gedegen
levenscclusbenadering zijn bij de oorspronkelijke specicaes de eisen voor de
sloopfase al zo goed mogelijk meegenomen.
confIGuratIEmanaGEmEnt
Belangrijk element bij de levenscclusbenadering is het integraal beheersen van de scope in alle
projecasen, ook wel conguraemanagement genoemd. Conguraemanagement maakt gebruik
van mijlpalen en baselines. Elke mijlpaal in de totstandkoming van het ssteem wordt afgesloten
met een gedenieerde set specicaes. Deze vormen een momentopname ofwel baseline van het
ssteem. Ook in de gebruiksfase is het gestructureerd en jdig bijhouden van wijzigingen esseneel
voor het blijvend monitoren van het funconeren van het ssteem.
5.2 ramSRAMS staat voor de samenhang tussen de aspecten: betrouwbaarheid (reliabilit), beschikbaarheid
(availabilit), onderhoudbaarheid (maintainabilit) en veiligheid (safet). Aan de hand van deze
vier aspecten is voor elk ssteem de gewenste kwaliteit van de primaire prestae te beschrijven,
te bepalen en te monitoren. Het beschrijven van RAMS-prestaes in eisen is gebruikelijk voor
infrastructuursstemen. Bij het spoorvervoerssteem zijn ze volgens de EN 50126 zelfs verplicht.
Verschillende analsemethodieken zijn geschikt om de prestaes op de RAMS-aspecten te bepalen
of aan te tonen. Dit zijn bijvoorbeeld een faalkansanalse, een foutenboom of een hazard-analse.
RAMS-analses maken inzichtelijk binnen welke beperkingen de funce(s) van het ssteem vervuld
moet(en) worden gedurende de levenscclus.
Figuur 5.2 toont de samenhang tussen de RAMS-aspecten. Elk afzonderlijk aspect zegt iets over
de prestaes van een ssteem, maar alleen in onderlinge samenhang bepalen ze daadwerkelijk de
kwaliteit van het funconeren van het ssteem. Het werken met eisen op RAMS-aspecten dwingt
ertoe om na te denken over hoe een ssteem in de gebruiksfase zo goed mogelijk kan funconeren.
BESCHIKBAARHEID
VEILIGHEID
ONDERHOUDBAARHEIDBETROUWBAARHEID
RAMS
Figuur 5.2
29
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 32/56
faLEn
Het falen van een ssteem wordt door twee zaken gekenmerkt: de frequene waarmee storingen
optreden en de duur van de storing. Overigens betekent een storing niet aljd dat het ssteem faalt.
Mogelijk kunnen andere onderdelen de funce van het kapoe onderdeel (jdelijk) overnemen.
De faalfrequene bepaalt de betrouwbaarheid van het ssteem; de faalfrequene en faalduursamen bepalen de beschikbaarheid. Onderhoudswerkzaamheden beïnvloeden zowel faalduur als
faalfrequene. Onderhoudswerkzaamheden kunnen storingen wegnemen of de kans op storingen
verminderen. Onderhoud kan op het moment van de werkzaamheden echter de beschikbaarheid
van het ssteem verminderen.
vEILIGhEId
Het aspect veiligheid staat in nauwe relae tot alle bovengenoemde RAMS-aspecten. Storingen,
al dan niet door externe oorzaak, kunnen veiligheidsrisico’s opleveren voor gebruikers van het
ssteem en voor personeel dat met het ssteem werkt. Maar ook het uitvoeren van onderhoud
terwijl het ssteem in bedrijf is, kan veiligheidsrisico’s veroorzaken. Bij te grote veiligheidsrisico’s
moet het ssteem jdelijk worden afgesloten voor gebruikers of personeel.
normEn
Voor veel sstemen zijn RAMS-eisen vastgelegd in wet- en regelgeving. Voorbeelden hiervan zijn:
de Wet op de waterkering, de Machinerichtlijn, de Tunnelwet en de service level agreements
(SLA’s) voor netwerken.
Voor het toepassen van RAMS zijn internaonale normen beschikbaar. Voor mechanische
en technische veiligheidssstemen is er de IEC 61508, voor spoorvervoersstemen wordt
gebruikgemaakt van de EN 50126. De hand-out RAMS/LCC analse van ProRail licht de toepassing
van RAMS bij spoorvervoersstemen verder toe. De Leidraad RAMS van Rijkswaterstaat gaat in op
de toepassing van RAMS bij sstemen binnen het hoofdwegennet, het hoofdvaarwegennet en het
hoofdwaterssteem.
5.3 vaLuE EnGInEErInGValue Engineering is een sstemasche, muldisciplinaire benadering om de waarde van een
ssteem over de gehele levenscclus te opmaliseren. Dit met behulp van funceanalse en
creaeve technieken. Met het begrip ‘waarde’ bedoelen we de hoeveelheid funconaliteit, afgezet
tegen de lifeccle-kosten. Value Engineering wil deze waarde voor de klant zo groot mogelijk maken.
De methodiek van Value Engineering ondersteunt Sstems Engineering op de volgende gebieden:
• Het verhelderen en aanscherpen van eisen. Bij het opstellen van eisen is het niet direct
mogelijk om vast te stellen wat de consequenes zijn voor de waarde. Als een oplossingin beeld is, wordt de waarde voor de klant tastbaarder. Pas dan wordt zichtbaar wat
de consequenes zijn voor de kosten en de prestae van het ssteem, over de gehele
levenscclus bezien. Vervolgens kan de vraag gesteld worden of een funce wel zo veel
geld waard is, of er funces ontbreken en of de prestaes voldoende zijn. Aanvullende
eisen kunnen bijvoorbeeld betrekking hebben op exibiliteit en uitbreidbaarheid.
• De communicae met en tussen stakeholders. Bij Value Engineering worden acviteiten
met verschillende disciplines en stakeholders doorlopen. Zo ontstaat een beter
begrip van elkaars eisen en behoeen, de samenhang hiertussen en de onderlinge
aankelijkheden. Dit maakt het tot een nug instrument om de klantvraag in kaart te
brengen.
30
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 33/56
• Het onderbouwen van formele besluitvorming. Value Engineering ondersteunt de
besluitvorming door:
o Een bevesging van het feit dat de belangrijkste alternaeven nader zijn bekeken
o Een goede afweging in de keuze van opes en varianten
o Expliciete onderbouwing van ontwerpkeuzes door de afweging op basis van deprijs-prestaeverhouding
• Als drijfveer voor innovae. De gezamenlijke en muldisciplinaire aanpak levert
oplossingen op die anders niet in beeld zouden komen.
Value Engineering is toepasbaar op ieder detailniveau in de ontwikkel- en realisaefase. Hierbij
hee de inzet van het instrument elke keer een andere focus en toepassing. Aan het begin van het
ontwerp zal deze meer gericht zijn op het vormgeven van eisen; in een later stadium wordt meer
gefocust op opmalisae en beheersing.
5.4 LIfE cycLE coStEen Life Ccle Cost-analse (LCC-analse) is een methode om de totale levensccluskosten te bepalen
door de verschillende geldstromen inzichtelijk te maken. Een neo contante waardeberekening
is een bekend middel om de levensccluskosten in beeld te brengen. Bij LCC worden naast de
ontwerp- en uitvoeringskosten ook berekend: onderhoudskosten (prevenef en correcef),
operaonele kosten (bediening, procesbewaking, kosten voor energie etc.), kosten voor inspeces
en kosten voor sloop of vervanging. Desgewenst kunnen de levensccluskosten per funconaliteit
of deelssteem worden bepaald.
Een LCC-analse is al van belang bij de afweging om wel of niet een project op te starten vóór de
aanleg, vervanging of aanpassing van een ssteem. Zo kan de LCC bijdragen aan een maatschappelijke
kosten-batenanalse (MKBA).
contInu
Een LCC-analse helpt om in de ontwikkelfase de juiste afwegingen te maken voor opmalisae
van het ssteem over de gehele levenscclus. Zo kan de behoee per saldo op de goedkoopste
wijze worden ingevuld. Een LCC-analse is echter geen eenmalige exercie. Net als RAMS en Value
Engineering moeten we LCC connu meenemen bij het doorlopen van de processtappen volgens
de Sstems Engineering-werkwijze. Een LCC-analse kan nodig zijn bij:
• De beginfase van een project. Om de verwachte levensccluskosten te bepalen en te
voorkomen dat projecten worden uitgevoerd waarvan de onderhoudskosten uiteindelijk
niet betaald kunnen worden.
• Ter ondersteuning van de besluitvorming in een project. Om helder te krijgen wat deinvloed van toegevoegde funconaliteiten en eisen is op de levensccluskosten en te
ontdekken welke varianten – vanuit de levensccluskosten beschouwd – interessant
zijn.
• De verdere uitwerking van het ontwerp. Om greep te houden op de levensccluskosten
van ontwerpkeuzes.
• De beheer- en onderhoudsfase. Om de opmale onderhoudsstrategie te bepalen.
• Een contractsituae. Voor de opdrachtgever: om een afweging van levensccluskosten
mee te nemen in de kwaliteitsbeoordeling van aanbiedingen.
Binnen Rijkswaterstaat en ProRail wordt gewerkt aan het verder professionaliseren en uniformeren
van de toepassing van LCC-analses. Binnen Rijkswaterstaat is hiervoor onlangs een projectgroep
opgericht. ProRail hee dit uitgewerkt in de hand-out RAMS/LCC analse.
31
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 34/56
5.5 aSSEt manaGEmEnt‘Asset Management staat voor de acviteiten waarmee een organisae uitvoering gee aan het
opmaal beheren van de assets en de daarmee verbonden prestaes, risico’s en investeringen
gedurende de gehele levenscclus, met als doel het realiseren van het strategische bedrijfsplan ende doelstellingen van de organisae.’ Dit staat te lezen in de internaonaal erkende norm PAS 55
van het Brish Standards Instuon (BSI).
aSSEtS
De betekenis van de term ‘asset’ is kapitaal of bezit. Voor de GWW-sector zijn assets de middelen
waarmee de infrastructuur in Nederland wordt vormgegeven. In de PAS 55 wordt onderscheid
gemaakt naar fsieke en non-fsieke assets. Fsieke assets zijn de primaire producemiddelen,
zoals objecten en machines. Non-fsieke assets zijn medewerkers, informae, nanciën en
maatschappelijke factoren.
zorGvuLdIGE afWEGInGHet opmaal beheren van de assets of sstemen is complex en vraagt een zorgvuldige afweging
tussen prestaes, risico’s en investeringen gedurende de levenscclus van sstemen. Daarbij
bestaan er soms tegenstrijdige belangen in de afwegingen, bijvoorbeeld bij korte versus lange
termijn, kosten versus prestaes, prevenef onderhoud versus ongepland falen en bouwkosten
versus onderhoudskosten. Door Asset Management sstemasch en integraal toe te passen, worden
deze afwegingen transparant en inzichtelijk. Asset Management focust vooral op de gebruiks- en
onderhoudsfase van sstemen, terwijl het zwaartepunt bij Sstems Engineering ligt in de ontwikkel-
en realisaefase. Beide hebben echter hetzelfde doel: het opmaliseren van sstemen gedurende
de levenscclus door het sturen op de waarde van de sstemen en hun funces voor de klant.
ErvarInG En kEnnIS
Bij Asset Management binnen de GWW-sector draait het om het afwegen van kosten en risico’s
tegen de door de netwerken en objecten (assets) te leveren prestaes (service) zoals die in de
beleidsdoelstellingen zijn verwoord. Als de assets met behulp van Sstems Engineering tot stand
zijn gebracht, versterkt dit het Asset Management. Omgekeerd levert Asset Management ervaring
en kennis waarmee we de klanteisen voor het ssteem beter kunnen bepalen.
32
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 35/56
de esse i Sses Egieeig e ie i egee ee ee see
seg e ss el e el. t i e ielie esille. I i s
g we ie i. vee lie we e e Sses Egieeig ige e eeesig
e eesse e e eisi’s.
6.1 SamEnhanG van dE procESSEnEen projectmanager stuurt op het evenwicht tussen jd, geld en kwaliteit met de risicobeheersing
als bepalende factor. Zo kan hij verantwoording aeggen aan zijn opdrachtgever en stakeholders.
Voor projectmanagement zijn diverse modellen ontwikkeld, zoals Prince2, IPM en Projectmag
Werken. Deze modellen funconeren prima in combinae met Sstems Engineering.
tooLS
Sstems Engineering en projectmanagement overlappen elkaar deels, maar zijn zeker niet
hetzelfde. Sstems Engineering richt zich op de doelmagheid van het te ontwikkelen ssteem en
alle daarvoor benodigde acviteiten en hulpmiddelen. De werkwijze volgens Sstems Engineering
biedt de nodige tools (methodes en technieken) om het projectmanagement te ondersteunen bij
een risicogestuurde aanpak binnen de kaders van jd, geld en kwaliteit. Een projectmanager hee
dan ook belang bij het werken volgens Sstems Engineering en moet aansturen op de toepassing
van de juiste tools. Een voorbeeld van een geschikte tool is een contextdiagram. Zo’n diagram
wordt toegepast op de omgeving van het ssteem en brengt de externe raakvlakken gestructureerd
in beeld. Dit is noodzakelijk om de juiste ssteemeisen boven tafel te krijgen en het ondersteunt
de afstemming die plaatsvindt tussen projeceam en stakeholders over de projectscope en
kostenconsequenes van omgevingsinvloeden.
ISo 15288: IntErnatIonaLE norm voor SyStEmS EnGInEErInG
De uitwerking van de werkwijze volgens Sstems Engineering binnen de GWW-sector sluit aan bij
de technische processen uit de ISO 15288. Naast de technische processen beschrij de ISO 15288
ook andere processen, waaronder de projectprocessen: projectplanning, projectbeoordeling,
projectbeheersing, besluitvorming, risicobeheersing, conguraebeheer en informaebeheer.
Volgens de ISO 15288 worden deze projectprocessen in de levenscclus gebruikt om projectplannenop te zeen en te beheren, de tot dan toe behaalde resultaten en de voortgang ten opzichte van de
plannen te beoordelen, en de uitvoering van het project tot aan de voltooiing te bewaken.
Deze projectprocessen hebben een directe relae en interace met de technische processen,
oewel met de inhoud van het project. De gevraagde kwaliteit wordt uitgedrukt in funces, eisen
en ontwerp. Keuzes daarin hebben directe invloed op de projectacviteiten, -kosten, -planning
en -risico’s. Andersom zijn projectbesluiten bepalend voor de oplossingsruimte binnen het
specicaeproces.
Sstems Engineering helpt ons ook om projectprocessen op een sstemasche en expliciete wijze
in samenhang te beheersen. Bij het toepassen van werkpakketmanagement en WBS’en worden
bijvoorbeeld alle projectacviteiten gestructureerd opgedeeld in werkpakkeen waartussen de
raakvlakken expliciet worden beheerst.
projEctmanaGEmEnt
33
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 36/56
doELmatIGE I nzEt
Sstems Engineering kan beschouwd worden als een ‘gereedschapskist’ voor een sstemasche
aanpak van een project. Met Sstems Engineering wordt op een zeker abstraceniveau in
elk project dezelfde taal gesproken en worden dezelfde generieke processtappen doorlopen.
Daaronder zien we echter de projectspecieke verschillen. Sstems Engineering ter ondersteuningvan projectmanagement werkt alleen als aan het toepassen van de methodes en technieken een
zorgvuldige afweging voorafgaat. De mate waarin het ‘gereedschap’ op een nuge en eciënte
manier ingezet kan worden is niet aljd hetzelfde. Als voorbeeld: een procesmodel voor het bepalen
van de funconaliteiten komt beter tot zijn recht bij het ontwikkelen van dnamische sstemen
dan bij het ontwikkelen van stasche sstemen. De werkwijze volgens Sstems Engineering kan in
de basis dus op elk project binnen de GWW-sector worden toegepast; methodes en technieken
moeten echter wel doelmag worden ingezet.
d!
v ee l sse e ege e e seilise. ze i ee
esges i ie e g sl sse egee e eie,e e e eiselies ee e ss els l ie
elel see.
6.2 IntErdIScIpLInaIrE projEctaanpakHet werken volgens Sstems Engineering leidt tot een interdisciplinaire aanpak van het project. De
harmonie tussen de technische processen en de projectprocessen is een bepalende succesfactor
over alle projecasen heen, ongeacht de structuur van de projectorganisae en het toegepaste
projectmanagementmodel. Het sstemasche, integrale en levenscclusgeoriënteerd denken en
het expliciet en transparant werken dringt door in alle lagen van een projeceam. Elk projeceamlid
stuurt op dezelfde doelen vanuit zijn eigen perspecef. Het opdelen van een project in vakdisciplines
gaat vaak ten koste van de integraliteit van een project. Vanuit het projectmanagement is daarom
speciek aandacht nodig voor de belangrijkste aspectsstemen, bijvoorbeeld door het aanstellen
van een veiligheidsmanager.
IntEGraaL projEct manaGEmEnt
Als voorbeeld voor een interdisciplinaire projectaanpak wordt hier het model van Integraal
Project Management (IPM) gebruikt, zoals dat binnen Rijkswaterstaat wordt gehanteerd voor de
aansturing van een projectorganisae. Dit model is nader uitgewerkt in de ‘ Werkwijzer Aanleg’ van
Rijkswaterstaat. In het model onderkennen we de volgende projectonderdelen:
• Projectmanagement• Omgevingsmanagement
• Technisch Management
• Contractmanagement
• Projectbeheersing
Figuur 6.1 gee weer hoe Sstems Engineering geposioneerd kan worden binnen IPM.
34
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 37/56
InvLoEd
Figuur 6.1 laat zien dat Sstems Engineering invloed hee op alle genoemde projectonderdelen.
De processtappen van Sstems Engineering kunnen we niet los zien van bijvoorbeeld de
afstemmingsprocessen met omgevingsparjen, de afwegingsprocessen voor marktbenadering en
de verantwoordingsprocessen naar de opdrachtgever. Voor het e ciënt kunnen toepassen van
Sstems Engineering is het sturen op de integraliteit van al deze processen, met een eenduidige
‘mindset’ van alle betrokkenen, esseneel. Hiermee voorkomen we subopmalisae binnen de
levenscclus van het ssteem. De projectmanager is verantwoordelijk voor de opmalisae binnen
de levenscclus van zijn Sstem of Interest en moet dus aansturen op de juiste toepassing van Sstems
Engineering binnen zijn team. Dit principe is toepasbaar voor ieder projectmanagementmodel.
d’!
he is ie e eelig we Sses Egieeig-ieie gisee
islie e eee Sses Egieeig-seilise. Sses
Egieeig is ee iegl e e ieeee e ie ige; ewewie e ee i i e le e.
6.3 rISIcomanaGEmEntSturen op risico’s is een belangrijk onderdeel van elk projectmanagementmodel. Sstems Engineering
helpt om risico’s gestructureerd aan het licht te brengen en te beheersen. Ondanks een gestructureerde
werkwijze is niet alles vooraf vast te leggen. We hebben aljd te maken met onzekerheden; de
omstandigheden zijn nooit voor honderd procent bekend en kunnen gaandeweg veranderen. Naarmate
een project een langere doorloopjd en/of een complexere omgeving kent is de kans op veranderingen
groter. Onzekerheden worden binnen een project tastbaar gemaakt door ze te vertalen naar risico’s. Het
omgaan met risico’s is een esseneel onderdeel van Sstems Engineering. Onzekerheden worden vaak
geassocieerd met ongewenste gevolgen en veiligheidsrisico’s, maar kunnen ook posieve gevolgen
hebben. Denk daarbij bijvoorbeeld aan een dalende prijs van grondstoen.
OMGEVING MARKT
OPDRACHTGEVER
RELATIE SYSTEMS ENGENEERING EN INTEGRAAL PROJECT MANAGEMENT
Figuur 6.1
SYSTEMS ENGENEERING
PROJECTMANAGEMENT
PROJECTBEHEERSING
TECHNISCH
MANAGEMENT
CONTRACT-
MANAGEMENT
OMGEVINGS-
MANAGEMENT
35
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 38/56
Bij risicomanagement zijn diverse zaken van belang:
• In welke mate kan ik onzekerheden vertalen naar expliciete risico’s?
• Wat zijn de gevolgen voor de projectbeheersing: jd, geld, kwaliteit?
• Welke risico’s zijn acceptabel?
• Hoe maak ik gebruik van de oplossingsruimte tussen kans en gevolg (prevenevebeheersmaatregelen versus correceve beheersmaatregelen)?
• Hoe ver moet ik doorgaan met speciceren om voldoende zekerheid te creëren voor de
volgende fase in het project?
• Welke risico’s behoren bij de opdrachtgever, welke risico’s behoren bij de opdrachtnemer?
Welke risico’s worden gedeeld?
Het omgaan met risico’s vraagt om een werkwijze die verankerd is in alle projectacviteiten over
de gehele levenscclus. Risicomanagement staat centraal in de projectsturing en beheerst het
spanningsveld tussen kwaliteit, jd en geld. Dit is weergegeven in guur 6.2.
Risicomanagement hoort onderdeel te zijn van het dagelijks handelen in een project. Bij het
toepassen van Sstems Engineering is dit niet anders. Oewel: risicomanagement en Sstems
Engineering kunnen we niet los van elkaar zien. Bij alle processtappen in deze Leidraad speelt
de risicobenadering een bepalende rol. Risico’s kunnen bijvoorbeeld bepalen hoe gedetailleerd
specicaes worden uitgewerkt, welke vericae & validaemethodes worden toegepast en of
een RAMS-analse moet worden uitgevoerd.
vaStLEGGEn bIj rISIcomanaGEmEnt
Bij faseovergangen in projecten worden specieke risicoanalses toegepast. Dit ter ondersteuning
van de besluitvorming. Is een fase afgerond, dan wordt vastgelegd welke risico’s nog niet zijn
afgedekt en hoe deze – eventueel in een volgende fase – wel (gedeeltelijk) zijn af te dekken. Er zijn
meerdere methodes om risicomanagement toe te passen. Een veelgebruikte methode binnen de
GWW-sector is RISMAN. Van risico’s leggen we minimaal vast:
• De gewenste/ongewenste gebeurtenis
• De kans van optreden
• De gevolgen (voor-/nadelen) van de gebeurtenis
o Uitgedrukt in geld
o Uitgedrukt in kwaliteit
• De beheersmaatregel
• De relae met de eisen
STAKEHOLDERS OPDRACHTNEMERSOPDRACHTGEVER
RISICOMANAGEMENT
Figuur 6.2
GELD
KWALITEIT
TIJD
RISICOMANAGEMENT
36
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 39/56
Bij het toepassen van Sstems Engineering is het zaak de relae zichtbaar te maken tussen de
projectrisico’s en de Sstems Engineering-acviteiten. Maak bijvoorbeeld expliciet op basis
van welke risico’s een specicae nader wordt gedetailleerd, welke risico’s een rol spelen in de
werkpakkeen uit de WBS en welke SE-methodieken fungeren als risicobeheersingsmaatregel.
d!
hig e geg e i e ee ee gei i e we
lgige eweseles. Wees l e e e eeee
i ee e. de isi’s ee lle e ele i.
6.4 Work brEakdoWn StructurEDe Work Breakdown Structure (WBS), ook wel acviteitenboom genoemd, gee een structuur
voor het managen van een project. De WBS wordt hier gedenieerd als de hiërarchische
opdeling van het project in werkpakkeen. De WBS beschrij alle werkzaamheden die verricht
moeten worden om het beoogde projectresultaat te behalen. Het doel van een WBS is het werk
verdelen in beheersbare werkpakkeen (WP), die apart ingepland, begroot of uitbesteed kunnen
worden. De werkpakkeen worden toegewezen aan een verantwoordelijke persoon, discipline
of organisae. De decomposie van de WBS bestaat uit werkpakkeen met een set gerelateerde
werkpakketacviteiten. De werkpakkeen zijn daarbij een clustering van werkpakketacviteiten
die samen een logisch geheel vormen op basis van bijvoorbeeld:
• De projecasering (concept-, ontwikkel-, realisae- of gebruiksfase)
• Het ssteemontwerp (bepaalt de benodigde werkzaamheden voor een object)
• De geograsche indeling (op basis van plaats)
• De (project)planning (op basis van jd)
• De aansturing van een organisae (disciplines en afdelingen)
WErkpakkEtactIvItEIt
Een werkpakketacviteit is een samenvoeging van een object uit de Sstem Breakdown Structure
(SBS) en een acviteit. Voorbeelden hiervan zijn: het ontwerpen van een landhoofd, het testen
van installaes of het fabriceren van een sluisdeur. Verder worden de relevante ssteemeisen,
benodigde informae en risico’s gekoppeld aan de werkpakketacviteit. Dit geheel vormt de basis
voor de werkpakketbeschrijving. Omdat een werkpakket een clustering van logisch samenhangende
acviteiten bevat, vinden betalingen of vergoedingen in een contractsituae dikwijls plaats op
basis van de werkpakkeen. De indeling van de WBS is aankelijk van het Sstem of Interest van
de betreende organisae en kan dus per opdrachtgever en opdrachtnemer verschillen.
37
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 40/56
d’!
he is ie e eelig ls gee i ee WbS iee esse
ee ee e eiëe. Si llee esse w ig
is e eeese le sse e esse e w isi’s
we ee.
WERKPAKKETBESCHRIJVING
ONDERHOUDBAARHEID WERKPAKKET 1.2WERKPAKKET 1.1
ONDERHOUDBAARHEIDOBJECTEN (uit de SBS)ONDERHOUDBAARHEIDEISEN, INFORMATIE,RISICO’S ETC.
ONDERHOUDBAARHEIDACTIVITEIT (t.b.v. project)
WORK BREAKDOWN STRUCTUREFiguur 6.3
WERKPAKKETACTIVITEIT 1.1.1 WERKPAKKETACTIVITEIT 1.1.2
ONDERHOUDBAARHEIDWERKPAKKET 1
38
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 41/56
Geee e leesls ee ssee ge pril e riswes iese
ee ee eel e eige weee e e . de essig
Sses Egieeig i is eli e gee e eeig
e e geeee . Sses Egieeig sel ee wel e ige we
e wie w e e el g i sies. he ieee e
leeslsgeiëeee e Sses Egieeig eeis ee geege seweig
sse ee e. di s l ie e e wee e Sses Egieeig
e ele sse gee e ee ee e e i we e
e pril e riswes.
De momenten waarop het proces over en weer gaat tussen opdrachtgever en opdrachtnemer
noemen we hier de ‘koppelpunten’. Koppelpunten worden soms ook ‘ontkoppelpunten’ genoemd.
Wij geven de voorkeur aan ‘koppelpunten’ omdat dit de gewenste samenwerking benadrukt.
7.1 koppELpuntEnBij projecten zijn doorgaans meerdere parjen betrokken die elk verantwoordelijk zijn
voor het doorlopen van een fase of processtap in de levenscclus. Dit kunnen verschillende
organisaeonderdelen zijn, zoals de beleidsafdeling jdens de planvorming en een wegendistrict
van Rijkswaterstaat jdens de gebruiksfase. Vaak worden ook externe parjen ingezet voor het
uitvoeren van projectwerkzaamheden, bijvoorbeeld aannemers, onderaannemers, ingenieurs- en
adviesbureaus en leveranciers.
Het werken met Sstems Engineering stelt eisen aan de samenwerking tussen de betrokken parjen
jdens het doorlopen van de levenscclus. Dit geldt speciek bij de koppelpunten in het proces.
Een koppelpunt moet gezien worden als een overdrachtsmoment jdens een interacef proces
met gedeelde verantwoordelijkheden. Op de koppelpunten moeten overdracht, terugkoppeling
en afstemming tussen de parjen goed geregeld worden. Koppelpunten worden gekenmerkt
door een jdsspanne waarbinnen de overdracht plaatsvindt, een product waarin de inhoudelijke
overdrachtsgegevens worden vastgelegd en een afstemmingsproces tussen de parjen.
koppELpuntEn In contractSItuatIESDeze paragraaf richt zich op de koppelpunten tussen verschillende organisaes in contractsituaes,
oewel tussen opdrachtgever en opdrachtnemer. Een koppelpunt kan gevisualiseerd worden met
behulp van een zogenaamde ‘knip’ in het V-model; guur 7.1. Met ‘knip’ wordt hier bedoeld de
scheidslijn tussen verantwoordelijkheid van opdrachtgever en opdrachtnemer. Daar waar de knip
de proceslijnen uit het V-model kruist, is een koppelpunt van toepassing.
rELatIE opdrachtGEvEr opdrachtnEmEr
39
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 42/56
Het verloop van de knip kan per project verschillen, aankelijk van de inkoopstrategie van de
opdrachtgevende parj. In het weergegeven voorbeeld is sprake van een opdrachtnemer in de
vorm van een aannemer aan wie een deel van de ontwikkelfase en de totale realisaefase is
uitbesteed (oewel Design & Construct). In het geval van een ingenieursbureau kan er bijvoorbeeld
voor gekozen worden om één laag in de ontwikkelfase uit te besteden.
afStEmmInG noodzakELIjk
Het koppelpunt uit het voorbeeld van guur 7.2 wordt gemarkeerd door een vraagspecicae van
de opdrachtgever en een aanbodspecicae van de opdrachtnemer. Het iteraeve karakter van
Sstems Engineering maakt afstemming tussen de specicaeprocessen van opdrachtgever en
opdrachtnemer noodzakelijk. Dit betekent dat de opdrachtgever de vraagspecicae niet ‘over de
schu ng’ kan gooien, en dat de opdrachtnemer het iteraeve specicaeproces voort moet zeen.
De aanbodspecicae moet voldoen aan de gevraagde kwaliteit en geboden oplossingsruimte uit
de vraagspecicae.
V-MODEL MET KNIP OPDRACHTGEVER - OPDRACHTNEMERFiguur 7.1
O N T W
I K K E L E N
VERNIEUWEN
= MOGELIJKE KNIP
R E A L I S E R E NVERIFIËREN /
VALIDEREN O P D R
A C H T G E V E
R
O P D R
A C H T
N E M E R
CONCEPT ONTWIKKELFASE REALISATIEFASE SLOOPGEBRUIKSFASEONDERHOUD / VERNIEUWING
SPECIFICERENVRAAG
SPECIFICATIE
AANBOD
SPECIFICATIE
VERIFIËREN / VALIDEREN
VRAAGSPECIFICATIE VS AANBODSPECIFICATIE 1Figuur 7.2
ONTWERPEN
STRUCTURERENEN
ALLOCEREN
ANALYSEREN
O P D R A C H T G E V E R
O P D
R A C H T N E M
E R
40
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 43/56
opEn communIcatIE
De ontwikkeling van een ssteem is een interacef proces met gedeelde verantwoordelijkheden.
Dat vergt een open communicae tussen contractpartners. Bij het werken met Sstems Engineering
is het belangrijk dat elke parj bijjds díe informae beschikbaar stelt die van belang is voor het
koppelpunt. Tijdens de aanbestedingsprocedure van contracten kan hiervoor bijvoorbeeld eendialoogfase worden ingericht.
Producten die de mogelijke koppelpunten tussen opdrachtgever en opdrachtnemer markeren zijn
bijvoorbeeld:
• De vraagspecicae
De vraagspecicae is een belangrijk onderdeel van het contract tussen opdrachtgever
en opdrachtnemer. De vraagspecicae beschrij de ‘uitvraag’ van de opdrachtgever.
Het document legt de verantwoordelijkheden, scope, oplossingsruimte en eisen vast.
• De aanbodspecicae
De aanbodspecicae beschrij de ‘aanbieding’ van de opdrachtnemer. Dit document
legt de geboden oplossing (het ontwerp inclusief de marge) en bijbehorende
specicaes vast. De aanbodspecicae toont aan dat de geboden oplossing voldoet
aan de gevraagde kwaliteit en past binnen de geboden oplossingsruimte.
• Op- en aeverdossier
In het op- en aeverdossier wordt de relevante informae over het gerealiseerde
ssteem opgenomen. Dit betre ook informae voor de volgende fase van het ssteem
vanuit de levenscclusbenadering. Denk daarbij aan de planning van beheer- en
onderhoudswerkzaamheden.
• V&V-dossier opdrachtnemer
Het V&V-dossier bevat alle resultaten van vericae & validae-acviteiten die door
de opdrachtnemer zijn uitgevoerd. Daarmee toont de opdrachtnemer aan conform
vraag én aanbod te hebben gewerkt. Over de momenten en methodes van vericae
& validae moeten de parjen het eens zijn. Op basis van risico’s kan de opdrachtgever
V&V-methodes voorschrijven in de vraagspecicae of kan de opdrachtnemer V&V-
methodes opnemen in de aanbodspecicae. Vóór gunning moet helder zijn welke
inspanning nodig is voor vericae & validae. Voor onderdelen die niet risicovol
lijken en qua inspanning niet bepalend zijn voor de opdrachtsom, kunnen na gunning
gezamenlijk de V&V-methodes worden vastgesteld.
• Integrale planning
De opdrachtnemer neemt jdelijk (een deel van) het ssteem over van de opdrachtgever.
De geplande acviteiten van de opdrachtnemer dienen in de planning van het totale
ssteem van de opdrachtgever te passen. De opdrachtgever kan hiermee andereacviteiten, gerelateerd aan het ssteem, plannen en uitzeen.
• Risicodossier
Aan het ssteem (of project) zijn risico’s gekoppeld. Een duidelijk en compleet beeld
van de risico’s is van groot belang op het moment van contracteren. Kennis rondom de
risico’s hoort daarom met elkaar gedeeld te worden.
• Baselines
De baselines zijn momentopnames waarbij de status van een project op een bepaald
moment wordt vastgelegd. Deze baseline is de referene voor het vervolg van het
project. De betrokken parjen maken samen afspraken over de momenten en de
inhoud van de baselines.
41
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 44/56
• Achtergrondinformae
Dit is de documentae van het voorgaande proces van de opdrachtgever, zoals
bijvoorbeeld de Klant Eisen Specicae of het V&V-dossier van de opdrachtgever.
Vrijgave hiervan biedt de opdrachtnemer de mogelijkheid om een beter beeld te krijgen
van de keuzes die gemaakt zijn door de opdrachtgever. Dit helpt om de vraagspecicae juist te interpreteren en voorkomt ineciënte discussies.
De opdrachtgever kan de opdrachtnemer in een contract voorschrijven hoe en wat te doen met
deze producten. Ook kan de opdrachtnemer voorstellen doen in een inlichngen- of dialoogfase.
In ieder geval moet men samen overeenstemming bereiken over inhoud en vorm van het product
per koppelpunt.
d!
o e ele ee gee e ee se ees
e e e e ieee isi’s eee. Leg se eliie
iggse s e e ieliee g ie i gels e wel eslie ig i ee e e.
GEïntEGrEErdE contractEn
ProRail en Rijkswaterstaat gebruiken bij voorkeur geïntegreerde contracten om de vragen aan de
markt te formuleren en de interace tussen opdrachtgever en opdrachtnemer vorm te geven.
Dit zijn contracten waarop de UAV-GC van toepassing is en waarbij de opdrachtnemer, naast de
uitvoering, een deel van de ontwikkelfase voor zijn rekening neemt. Welk deel dat is, hangt af van
de specieke situae rond het project en de inkoopstrategie. In de basisovereenkomst kunnen
afspraken over de koppelpunten worden opgenomen. De opdrachtgever bepaalt in eerste instane
welke koppelpunten op welke wijze in de contractdocumenten worden ondergebracht. In tweede
instane kunnen de betrokken parjen jdens de contractering met elkaar vaststellen hoe het
afstemmingproces rondom koppelpunten wordt ingericht.
dE dIaLooG
Tijdens de aanbestedingsprocedure van een contract kan tussen opdrachtgever en opdrachtnemer
een dialoog ontstaan. Deze gaat onder andere over de eisen, interpretae van eisen,
ontwerpuitgangspunten, ontwerpkeuzes en V&V-methodes. Vanuit het iteraeve proces gezien is
deze dialoog gewenst, zo niet een voorwaarde om Sstems Engineering goed te kunnen toepassen.
Deze dialoog biedt de opdrachtnemer input voor de aanbodspecicae. Na contractering kan
de dialoog worden voortgezet door de projeceams van opdrachtgever en opdrachtnemer. Een
voorbeeld hiervan is het (technisch) overleg tussen de projeceams. Hierin staan zaken centraalals: de interpretae van eisen, het toepassen van V&V-methodes en mogelijke beheersmaatregelen
voor risico’s.
d’!
he is ie e eelig iise isssies e elgei i e weg
s. uie i ee isssies ig; e is ee elgi e
e legge e ielie ilg sse gee e ee.
42
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 45/56
7.2 vraaGSpEcIfIcatIEIn de UAV-GC gebruiken we de term ‘vraagsprecicae’ om de uitvraag van een opdrachtgever
aan een opdrachtnemer te duiden. De opdrachtnemer stelt zijn aanbieding op, op basis van de
vraagspecicae. In termen van Sstems Engineering vormt de vraagspecicae de output van
het specicaeproces van de opdrachtgever en de input voor het specicaeproces van deopdrachtnemer. Figuur 7.2 gee weer hoe de vraagspecicae de scheidslijn beschrij tussen
de verantwoordelijkheden van een opdrachtgever en een opdrachtnemer. De vraagspecicae
beschrij de gevraagde kwaliteit en de oplossingsruimte in het kader van een contract en gee aan
hoe de verantwoordelijkheden omtrent de koppelpunten zijn geregeld.
vErzamELInG SpEcIfIcatIES
Het Sstem of Interest van een opdrachtnemer wordt bepaald door de vraagspecicae. De
vraagspecicae beschrij die deelsstemen en ssteemelementen die de opdrachtgever aan de
betreende opdrachtnemer uitbesteedt. Het is dus een verzameling specicaes die in de meeste
gevallen niet gelijk is aan het totale Sstem of Interest van de opdrachtgever. Het specicaeproces
van de opdrachtnemer leidt dan ook tot een ‘eigen’ specicae van het ssteem, die de basis is voor
zijn aanbieding. Dit noemen we de aanbodspecicae. De aanbodspecicae bevat onder andere
het ontwerp van de opdrachtnemer met bijbehorende marges. Een gedegen vericae & validae
van de aanbodspecicae van de opdrachtnemer aan de vraagspecicae van de opdrachtgever is
noodzakelijk. Dit om zeker te weten dat aan de vraag van de opdrachtgever wordt voldaan en dat
de marge op het ontwerp van de opdrachtnemer past binnen de oplossingsruimte. Figuur 7.3 gee
dit principe weer.
Het is mogelijk dat het specicaeproces van de opdrachtnemer, na sluiten contract, leidt tot nieuwe
inzichten en wijzigingsvoorstellen. Worden deze voorstellen geaccepteerd door de opdrachtgever,
dan leidt dit tot een contractwijziging en dus tot een aangepaste vraagspecicae. In de UAV-GC is
namelijk geregeld dat de vraagspecicae aljd vóór de aanbieding gaat.
Figuur 7.3
VRAAGSPECIFICATIE
OPLOSSINGSRUIMTE
AANBODSPECIFICATIE
MARGE ONTWERP
VRAAGSPECIFICATIE VS AANBODSPECIFICATIE 2
O P D R A
C H T
G E V E R
O P D R A
C H T N E M E R
VERIFIËREN / VALIDEREN
43
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 46/56
Na gunning vervolgt de opdrachtnemer het specicaeproces tot aan het detailniveau van een
uitvoeringsgereed ontwerp. Door het detailleren van zijn specicaes kan hij ervoor kiezen
gedecomponeerde deelsstemen en ssteemelementen op dezelfde wijze uit te besteden aan
onderliggende opdrachtnemers.
d!
besw e iil e il ge ls ee e e
lssigsie. Gee ee ee e geliei ie e
esie ge e le lssig e iee. beeel elges
e ese is-wlieieig ie e gesele es.
StandaardEn
Rijkswaterstaat en ProRail kennen de nodige formats en instruces voor het opstellen van een
vraagspecicae bij een UAV-GC-contract. Hierin wordt de vraagspecicae gesplitst in twee delen,
te weten: deel 1 ‘eisen’ en deel 2 ‘proces’.
Deze opsplitsing in twee delen kunnen we zien als een indeling in het wat (eisendeel) en hoe
(procesdeel). Hiernaast is het voor de helderheid van de uitvraag belangrijk om ook het ‘waarom’,
oewel de projectdoelstellingen, goed te beschrijven in het contract. Het inleidende hoofdstuk in
het eisendeel biedt hier het beste ruimte voor.
vraaGSpEcIfIcatIE EISEndEEL
De vraagspecicae eisendeel wordt opgebouwd op basis van de ssteemeisen die van toepassing
zijn op de scope van het contract. Een vraagspecicae omvat meestal meerdere sstemen en/of
deelsstemen.
Een vraagspecicae eisendeel bevat ten minste de volgende informae:
• Ssteembeschrijving (doelstelling, ssteemdenie en aakening scope/
ssteembegrenzing)
• Bindende en informaeve documenten
• Funconele eisen
• Aspecteisen
• Raakvlakeisen
• Informae bij de eisen (waaronder de voorgeschreven vericae & validaemethodes)
• Begrippen- en denielijsten
normEn En rIchtLIjnEnDe ervaring leert dat de mate waarin Normen en Richtlijnen in de eisen moeten worden
voorgeschreven een veel voorkomend discussiepunt is binnen projecten. We hebben het hierbij
over de zogenaamde bindende en informaeve documenten. Opgemerkt dient te worden dat ook
de informaeve documenten niet vrijblijvend zijn. Opdrachtgever dient er daarom voor te zorgen
dat de informaeve documenten juist en consistent zijn. De vraagspecicae eisendeel bevat een
opsomming van de bindende en informaeve documenten. Deze opsomming is projectspeciek
en wordt bepaald door de objecten, eisen en V&V-methodes uit de vraagspecicae. Normen en
Richtlijnen kunnen een belangrijke rol vervullen bij het afdekken van V&V-methoden.
Daarnaast kunnen ook meer generieke productstandaarden van toepassing zijn bij de ontwikkeling
van het ssteem. Dit zijn bijvoorbeeld Normen en Richtlijnen die pas bij nadere detaillering van het
ontwerp in beeld komen. Het is niet de bedoeling alle mogelijk van toepassing zijnde Normen en
Richtlijnen als bindend of informaef op te nemen in de vraagspecicae.
44
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 47/56
Op deze wijze vervullen de Normen en Richtlijnen een belangrijke rol bij het deniëren van de
scope en het beheersen van risico’s. Het juist toepassen van Normen en Richtlijnen leidt tot een
gedenieerde kwaliteit van betreende objecten.
vraaGSpEcIfIcatIE procESdEEL
In het procesdeel van de vraagspecicae staan de eisen beschreven die worden gesteld aan
de processen voor de verdere ontwikkeling en realisae van het ssteem (de hoe-eisen). In de
vraagspecicae procesdeel worden de proceseisen gegroepeerd in werkpakkeen, opgebouwd
op basis van de WBS van de opdrachtgever. ProRail en Rijkswaterstaat delen het procesdeel in op
basis van het Integraal Project Managementmodel (IPM), bestaande uit de volgende processen:
• Projectmanagement
• Omgevingsmanagement
• Technisch management
• Contractmanagement
• Projectbeheersing (risico-, plannings- en nancieel management)
WErkpakkEttEn
Voor ieder van deze werkpakkeen uit de vraagspecicae procesdeel beschrij de opdrachtgever
de doelstellingen en welke input/output in termen van informae en producten van belang is.
Daarnaast kan de opdrachtgever aangeven welke acviteiten minimaal verwacht worden.
De indeling van werkpakkeen in de vraagspecicae procesdeel kan anders zijn dan de indeling
van de werkpakkeen zoals de opdrachtnemer die gebruikt voor de aansturing van zijn project.
De betalingen of vergoedingen van een project zijn vaak gebaseerd op de werkpakkeen van de
opdrachtnemer.
WErkWIjzEbESchrIjvInGEn
ProRail en Rijkswaterstaat hanteren instruces, die werkwijzebeschrijvingen worden genoemd. Deze
bevaen de gangbare regels voor het opstellen van een vraagspecicae volgens de methodiek van
Sstems Engineering, gebaseerd op prakjkervaringen. Het doel daarvan is om meer eenduidigheid
te creëren in de vraagspecicaes die binnen de GWW-sector op de markt worden gebracht. Deze
werkwijzebeschrijvingen zijn te vinden op www.leidraadse.nl.
d!
Wees sise, wel ie ee ls i esillee e.
Wees see e e s i e esillee se e i
s ie i el iew e ‘seiewiel’ i. hegei egee eele e s se e. di el we i wel
gee ls ee.
45
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 48/56
dee eiewe Lei Sses Egieeig eëe e we e essig
Sses Egieeig ie e GWW-se. he ses es e esi e ege
leiee iies. v ee geege ieig ee wewie i e eige gise is
ee ee elslg ig i elei ee essig. dee slg is eli
e eisesse ee gise e ee e ele gise iiieel
e. hewel e ee ie e isee ee Lei is, e we ie eele
sggeses e iee esse Sses Egieeig i w gise.
zorG voor draaGvLak In dE orGanISatIE.
Invoeren van de werkwijze vraagt om draagvlak en betrokkenheid in de organisae. We hebben
het dan zowel over commitment bij het hoger management als de overtuiging bij medewerkers
dat Sstems Engineering ergens toe bijdraagt. Voorwaarde bij het inrichten van de werkwijze is dat
deze wordt gedragen door de direce van een organisae. De betrokkenheid van het management
kan vergroot worden door uit te leggen hoe Sstems Engineering geld kan opleveren. Toon met
succesvolle prakjkvoorbeelden aan hoeveel er bespaard kan worden op projecten. Eén treend
voorbeeld is vaak overtuigender dan een uitgebreid rapport.
Leg bij de overige medewerkers de nadruk op de problemaek die met Sstems Engineering valt op
te lossen. Daarbij gaat het niet om de term Sstems Engineering, het gaat erom dat u laat zien wat
de toepassing van deze werkwijze kan oplossen en opleveren.
zorG voor ondErLEGdE mEdEWErkErS.
Medewerkers die met Sstems Engineering aan de slag gaan, behoren ook daadwerkelijk te weten
wat er van ze wordt verwacht. Zorg dus dat mensen beslagen ten ijs komen. Bijvoorbeeld door ze
cursussen te laten volgen die de theorie en prakjk van Sstems Engineering belichten. Daarbij is
het goed om zowel succesvolle als minder succesvolle voorbeelden aan te halen, zodat zowel de
succesmogelijkheden als valkuilen van de werkwijze worden belicht. Overigens verzorgen de meeste
brancheorganisaes voorlichng en opleidingsprogramma’s voor de aangesloten organisaes.
Het handboek Sstems Engineering van INCOSE: ‘Sstems Engineering Handbook’ (versie 3.0, juni
2006) biedt informae voor toepassing van de werkwijze op praksch niveau. Ook zijn op www.
leidraadse.nl publicaes te vinden die meer inzicht bieden in onderdelen van Sstems Engineering.Verder vindt u hier informae over Sstems Engineering-cursussen, voorbeeldprojecten en een
generiek stappenplan voor parjen die met Sstems Engineering aan de slag willen.
rIcht EEn ondErStEunEnd tEam In.
Sstems Engineering gaat eecever met gedegen begeleiding. Een ondersteunend team kan
een grote rol spelen bij het begeleiden van projecten die Sstems Engineering toepassen. Veel
organisaes hebben dit overigens al ingericht. ProRail hee bijvoorbeeld het suppoream; dit team
coacht medewerkers om Sstems Engineering te vertalen naar hun projecten. Bij Rijkswaterstaat
bestaat het Kennisveld Sstems Engineering; dit organisaeonderdeel begeleidt projecten bij een
juiste vertaling van Sstems Engineering naar het project. NLingenieurs hee het expertnetwerk
Sstems Engineering. Ook de meeste bouwbedrijven kennen ondersteunende teams.
handrEIkInG
46
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 49/56
Daarbij is het goed als in de uiteenlopende overlegsituaes aljd iemand aanwezig is die een Sstems
Engineering-insteek hee. Het verdient aanbeveling een extra persoon aan het projeceam toe te
voegen, bijvoorbeeld een bouwprocesmanager, die Sstems Engineering telkens expliciet op de
agenda zet.
Start mEt EEn pILotprojEct.
Natuurlijk kan het geen kwaad om elementen van Sstems Engineering stapsgewijs in meerdere
of alle projecten te integreren. Maar wie écht de voordelen wil ondervinden, doet er goed aan er
in minimaal één project volledig voor te gaan. Zorg voor een pilotproject waarin volledig volgens
de Sstems Engineering-aanpak wordt gewerkt. Zorg dat hier medewerkers aan de slag gaan die
overtuigd zijn van de mogelijkheden van de werkwijze. En zorg dat het ondersteunende team het
project begeleidt. De in dit project opgedane ervaring kan worden meegenomen in overige Sstems
Engineering-projecten in de organisae.
zorG dat advIEzEn nIEt vrIjbLIjvEnd zIjn.
Wanneer een organisae Sstems Engineering serieus neemt en een ondersteunend team of een
werkgroep hiermee aan de slag gaat, is het zaak dat dit team ook zeggenschap hee. Dat betekent
dat adviezen van deze parj in meer of mindere mate bindend zijn. Het team moet kunnen ingrijpen
in contracten en de planning als dat vanuit het oogpunt van Sstems Engineering noodzakelijk is.
InvEntarISEEr procESSEn En procEdurES En StEm dEzE af op dE
SyStEmS EnGInEErInGSyStEmatIEk.
Bij het toepassen van Sstems Engineering is het raadzaam eerst te inventariseren welke
bedrijfsprocessen en -procedures worden beïnvloed door Sstems Engineering. Kijk vervolgens hoe
deze afgestemd kunnen worden op de processtappen binnen Sstems Engineering. Uiteraard kan
ter ondersteuning van dit traject ICT worden ingezet. ICT-programma’s mogen echter niet leidend
worden, maar moeten de Sstems Engineering-gedachte ondersteunen.
pak dE mEESt krItISchE procESSEn aLS EErStE aan.
Dit zijn processen waarvan duidelijk is dat Sstems Engineering veel meerwaarde kan hebben. Pak
daarbij in eerste instane díe processen op waarbij u de kans van slagen ook groot acht. Het verschilt
van organisae tot organisae welke processen dit zijn; voor de een kan dit de planvorming zijn,
voor de ander het tenderproces of bijvoorbeeld het contracteren van onderaannemers.
LEEr van ELkaar.
Voorkom dat iedere organisae opnieuw het wiel moet uitvinden. Binnen branches en over
de branchegrenzen heen kan van elkaar geleerd worden. Bijvoorbeeld door best pracces metelkaar te delen, maar ook door de leerpunten te delen van hoe het juist níet moet. Dit kan binnen
brancheorganisaes maar ook vercaal, binnen een project, waarbij de verschillende parjen de
opgedane Sstems Engineering-kennis met elkaar delen.
47
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 50/56
Hieronder een overzicht van in de uitgave gebruikte begrippen, met de denie van het begrip
zoals die voor deze Leidraad geldt.
• Aanbodspecicae Aanbiedingsdocument dat de geboden oplossing met de
oplossingsmarge en bijbehorende eisen vastlegt.
• Acviteitenboom (= Work Breakdown Structure), zie WBS.
• Aspect Specieke eigenschap van het te ontwikkelen ssteem.
• Aspecteis De beschrijving van de gevraagde prestae van een product of dienst
aangaande een aspect.
• Aspectsysteem Een dwarsdoorsnede van het ssteem vanuit één perspecef.
• Asset Management De acviteiten waarmee een organisae uitvoering gee aan
het opmaal beheren van de assets en de daarmee verbonden prestaes, risico’s en
investeringen gedurende de gehele levenscclus, met als doel het realiseren van het
strategische bedrijfsplan en de doelstellingen van de organisae. [PAS 55 – Brish
Standards Instuon (BSI)]
• Baseline Formeel ‘bevroren’ status van een product die dient als referene voor verdere
werkzaamheden.
• Beheer Het gepland en nancieel verantwoord treen van maatregelen en acviteiten
waarmee de funce van een ssteem beschikbaar blij.
• Beschikbaarheid (= Availability) De waarschijnlijkheid dat de vereiste funce op een
gegeven willekeurig moment kan worden uitgevoerd onder gegeven omstandigheden.
• Betrouwbaarheid (= Reliability) De waarschijnlijkheid dat de vereiste funce wordt
uitgevoerd onder gegeven omstandigheden gedurende een bepaald jdsinterval.
• Boomstructuur Een hiërarchisch gestructureerde verzameling gelijksoorge grootheden
volgens de regel ‘is onderdeel van’ of ‘is afgeleid van’.
• Congurae Funconele en materiële eigenschappen van een product, zoals
omschreven in technische documentae en gerealiseerd in het product. [ISO 10007]
• Conguraemanagement De technische en organisatorische acviteiten voor het
idenceren, beheersen, verantwoorden van de status en het auditen van conguraes.
[ISO 10007]
• Decomponeren Het proces waarin het hoger gelegen detailniveau wordt opgedeeld in
meer gedetailleerde afgeleide eisen, funces en bijbehorende objecten.
• Eis Beschrijving van de gevraagde eigenschap van het te leveren product of de te leveren
dienst.• Eisenboom (= Requirements Breakdown Structure), zie RBS.
• Faalkosten Alle kosten die voor het eindproduct zijn gemaakt, ontstaan door vermijdbaar
tekortschieten. [SBR]
• Funce Beoogde werking en verrichng van een product of dienst. [Van Dale]
• Funceanalyse Proces dat op complete wijze de funces en hun relaes idenceert
en beschrij, en deze funces sstemasch karakteriseert, classiceert en evalueert.
[gebaseerd op: ISO/DIS 21351-2001]
• Funconele eis De beschrijving van een gevraagde prestae of condie aangaande de
primaire funce van een product.
• Gebruiksfase Tijdsbestek tussen oplevering en sloop waarin een ssteem zijn funce
vervult.
bEGrIppEnLIjSt
48
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 51/56
• Integraal Project Management Projectmanagementmodel dat de besturing van
processen binnen een project beschrij, de samenhang daartussen en de relaes met
de projectomgeving.
• Klant Verzameling van stakeholders die een belang hebben in de ontwikkeling van
een ssteem. Hierbij wordt onderscheid gemaakt tussen betalende en niet-betalendestakeholders.
• Klantvraag Verzameling van behoeen en randvoorwaarden van de stakeholders
(klant).
• Klant Eisen Specicae Document dat de klanteisen speciceert in een overzicht van de
benodigde funconaliteiten, de eisen per stakeholder, de beschikbare oplossingsruimte
en een beschrijving van het Sstem of Interest van de klant. (In Engelse literatuur CRS,
Customer Requirements Specicaon, genoemd)
• Koppelpunt Moment in de levenscclus van een ssteem waarop het proces over en
weer gaat tussen opdrachtgever en opdrachtnemer.
• Levenscyclus (= Life Ccle) De evolue in de jd van een ssteem van probleem tot sloop.
• Object Een afzonderlijk idenceerbaar onderdeel van een fsiek geheel.
• Objectenboom (= Sstem Breakdown Structure), zie SBS.
• Onderhoud Acviteiten die worden uitgevoerd met het doel de funces van een ssteem
gedurende de gebruiksduur op het vereiste kwaliteitsniveau in stand te houden.
• Onderhoudbaarheid De waarschijnlijkheid dat de acviteiten voor acef onderhoud
kunnen worden uitgevoerd binnen de hiervoor vastgestelde jden onder gegeven
omstandigheden teneinde de vereiste funce te kunnen (blijven) uitvoeren.
• Ontwerp De in documenten vastgelegde uitwerking van de oplossing van een ssteem.
• Ontwerpen Het creaeve proces om tot de opmale uitwerking van de oplossing te
komen.
• Ontwerpproces De verzameling van acviteiten om te komen tot de opmale uitwerking
van de oplossing.
• Ontwerpvrijheid De mate waarin verschillende keuzes nog mogelijk zijn binnen het
proces van ontwerpen.
• Opes Mogelijke oplossingsrichngen.
• PAS 55 Publicl Available Specicaon 55, normaef van het Brish Standards
Instuon (BSI) die handvaen aanreikt voor opmaal management van fsieke assets
en infrastructuur.
• Proces Verzameling van onderling gerelateerde of op elkaar inwerkende acviteiten die
input vertalen naar output. [gebaseerd op: EN-ISO 9000:2005]
• Projectmanagement Het op zo’n manier organiseren en managen van middelen dat
een project wordt voltooid binnen de gedenieerde scope en afgesproken planning enbudget.
• Projectscope Het totaal van producten en diensten dat in het kader van een project
dient te worden geleverd.
• Raakvlak De funconele en fsieke eigenschappen die dienen te bestaan voor het in
samenhang funconeren van delen op een gemeenschappelijke grens.
• RBS Requirements Breakdown Structure, hiërarchische eisenstructuur van het ssteem,
ook ‘eisenboom’ genoemd.
• Risico Niet-geplande ongewenste of gewenste gebeurtenis met een bepaalde kans van
optreden.
• SMART Acroniem van Speciek, Meetbaar, Acceptabel, Realissch en Tijdsgebonden.
• SBS Sstem Breakdown Structure, hiërarchische objectstructuur van het ssteem, ook
‘objectenboom’ genoemd.
49
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 52/56
• Scope Zie projectscope.
• Sloop Acviteiten gericht op het ontmantelen van een ssteem dat zijn funce niet
meer hoe te vervullen of kan vervullen.
• Specicae Een document met daarin de verzameling geordende eisen en beschrijving
van de beschikbare oplossingsruimte dan wel de gekozen oplossing met deoplossingsmarge die gelden voor een ssteem (product of dienst).
• Speciceren Het proces om middels interace tussen analseren, structureren &
alloceren en ontwerpen te komen tot de vastlegging van de eisen en de beschikbare
oplossingsruimte dan wel de gekozen oplossing met de oplossingsmarge.
• Stakeholder Een parj die een recht hee in of belang hee bij een ssteem
(belanghebbende).
• Systeem Een, aankelijk van het gestelde doel, binnen de totale werkelijkheid te
onderscheiden verzameling elementen, die onderlinge relaes hebben. [In ’t Veld,
1986: ‘Analse van organisaeproblemen’]
• Systeemdenken Benadering of denkwijze waarbij complexe problemen en mogelijke
oplossingen vanuit het groter geheel en gestructureerd worden beschouwd.
• Systeemelement De kleinste eenheden van een ssteem, waarbij de interne opbouw en
relaes niet meer beschouwd worden.
• System of Interest Ssteem vanuit het perspecef van één waarnemer.
• System of Systems Het grotere geheel van sstemen dat weer zelfstandig kan
funconeren.
• Systems Engineering De interdisciplinaire aanpak en de middelen die nodig zijn om de
realisae van succesvolle sstemen mogelijk te maken. (gebaseerd op: INCOSE)
• Trade-o matrix Tabel om varianten onderling te vergelijken op hoogste waarde.
• UAV-GC Uniforme Administraeve Voorwaarden voor geïntegreerde contractvormen.
• Uitvoering Het proces van realisae van het ontwerp.
• Value Engineering Sstemasche, muldisciplinaire benadering om met behulp van
funceanalse- en creaeve technieken de waarde van een ssteem, over de gehele
levensduur, te opmaliseren.
• Varianten Uitgewerkte mogelijke oplossingen.
• Veiligheid De mate waarin iemand (of iets) is gevrijwaard van (de eecten van)
gevaarlijke situaes.
• Vericae & validaemethode Middel voor het aantonen dat de oplossing voldoet aan
de eisen en behoeen van de klant en daarmee past binnen de oplossingsruimte met
behulp van objecef bewijs.
• Veriëren en valideren Alle acviteiten die nodig zijn om objecef en expliciet te
kunnen aantonen dat de oplossing voldoet aan de eisen en behoeen van de klant endaarmee past binnen de oplossingsruimte.
• Vier-parjen-overleg Stuurgroep van vertegenwoordigers van Bouwend Nederland,
NLingenieurs (voorheen ONRI), Vereniging van Waterbouwers, Rijkswaterstaat en
ProRail die de implementae van Sstems Engineering binnen de GWW-sector
smuleren en afstemmen.
• Vraagspecicae Contractdocument waarin de uitvraag van een opdrachtgever aan
een opdrachtnemer wordt geuit. De vraagspecicae bestaat uit een deel 1 Eisendeel
en een deel 2 Procesdeel.
• Waarde De hoeveelheid funconaliteit, afgezet tegen de lifeccle-kosten.
• WbS Work Breakdown Structure, hiërarchische opdeling van een project in
werkpakkeen, ook ‘acviteitenboom’ genoemd.
• Werkpakket Set van samenhangende acviteiten voor een of meerdere objecten met
gedenieerde input en output.
50
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 53/56
Deze vernieuwde Leidraad voor Sstems Engineering binnen de GWW-Sector is opgesteld door
ProRail en Rijkswaterstaat in nauwe samenwerking met de brancheverenigingen BouwendNederland, NLingenieurs (voorheen ONRI) en de Vereniging van Waterbouwers (voorheen
VBKO). De eerste versie van de Leidraad Sstems Engineering werd gepubliceerd in april 2007; de
Engelstalige versie, met enkele aanpassingen op het origineel, volgde in mei 2008. De voorliggende
versie 2.0 is ocieel gedateerd op 27 november 2009.
WERKGROEP LEIDRAAD SySTEMS ENGINEERING
Goos de Boer (Boskalis; Vereniging van Waterbouwers)
Hans Bruinsma (Grontmij; NLingenieurs)
Erik Elich (ProRail)
Bart van Luling (Rijkswaterstaat)
Gerrit Wemeijer (Mobilis; Bouwend Nederland)
Met dank aan alle workshopdeelnemers: ‘Strategische workshop vericae & validae’,
‘Workshopdag Leidraad Sstems Engineering’ en ‘Workshop Do’s en Don’ts’.
MET DANK VOOR DE KRITISCHE BLIK VAN
Tufail Ghauharali (namens INCOSE-NL)
Hennes de Ridder (namens TU Del)
Karel Veenvliet (namens Universiteit Twente)
Arjan Visser (namens CROW)
REDACTIE
Miranda van Ark, MVA Communicae, Den Haag
VORMGEVING
GOfor Design, Den Haag
coLofon
51
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 54/56
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 55/56
7/26/2019 Leidraad Voor System Engineering Binnen GWW-sector
http://slidepdf.com/reader/full/leidraad-voor-system-engineering-binnen-gww-sector 56/56