Dictaat CT3061 Compleet - V2012

CT3061
Systems Engineering Ontwerpproject 3
Collegedictaat CT3061
Februari 2012
Prof.dr.ir. H.A.J. de Ridder

Dr. R. Schoenmaker
Technische Universiteit Delft

Faculteit Civiele Techniek en Geowetenschappen
Sectie Bouwprocessen
Dit collegedictaat is uitsluitend voor gebruik aan de Faculteit Civiele Techniek en

Geowetenschappen van de Technische Universiteit Delft. Er kunnen geen rechten aan de
inhoud worden ontleend.
CT1061
CT3061
Inhoudsopgave
1 Inleiding ........................................................................................ 1
1.1 Waarom aandacht voor Systems Engineering? ..................................... 1
1.2 Didactisch model................................................................................ 4
1.3 Afbakening ........................................................................................ 5
1.4 Onderwijsvorm .................................................................................. 5
2 Groepswerk: problemen en beheersprincipes ............................... 7
2.1 Algemeen .......................................................................................... 7
2.2 Grootte van ontwerpteams ................................................................. 7
2.3 Opdelen van groepswerk .................................................................... 8
2.4 Gevraagde rollen ............................................................................... 8
2.5 Decompositie (ontleding) en cordinatie (sturing) .............................. 11
2.6 Organisatie en informatie ................................................................. 12
2.7 De vier organisatorische aspecten verbonden: productie- en
organisatie-as ............................................................................... 13
2.8 Raakvlakkenbeheer .......................................................................... 15
3 Systems Engineering: een eerste verkenning ............................. 17
3.1 Waarde en kosten van een systeem .................................................. 17
3.2 De gebruikelijke en herkenbare schaalniveaus .................................... 17
3.3 Systeemtheoretische schaalniveaus ................................................... 19
3.4 Het sturen van de ontwikkeling en exploitatie van systemen ............... 19
3.5 De dimensies van Systems Engineering in de Civiele Techniek ............. 20
4 De factor tijd en planning in Systems Engineering ..................... 23
4.1 Algemeen ........................................................................................ 23
4.2 De kosten en baten van een project .................................................. 23
4.3 Concurrent Engineering .................................................................... 24
4.4 Waarde en kosten in de tijd .............................................................. 25
4.5 Planning .......................................................................................... 27
4.6 Onzekerheid, invloed en primaatschap............................................... 29
5 Engineeringproces ....................................................................... 33
5.1 Algemeen ........................................................................................ 33
5.2 Ontwerpproces ................................................................................ 33
5.3 Realisatieproces ............................................................................... 44
6 Systeemtheorie en complexiteit .................................................. 49
6.1 Algemeen ........................................................................................ 49
6.2 Systeem en haar elementen ............................................................. 49
6.3 Subsystemen, aspectsystemen en fasesystemen ................................ 53
6.4 Toestand, proces en gedrag ............................................................. 55
6.5 Complexiteit .................................................................................... 56
7 Decompositie ............................................................................... 61
7.1. Algemeen ....................................................................................... 61
7.2. Doel van decomponeren .................................................................. 61
7.3. Systeemtheoretische aspecten van decompositie ............................... 62
7.4. Decompositiemethoden voor de ontwikkeling van complexe systemen 65
8 Cordinatie van de ontwikkelingsopgave (sturing) .................... 75
8.1 Algemeen ........................................................................................ 75
1
CT1061
8.2 Besturingsmodel .............................................................................. 75

8.3 Meta-besturingsconcepten ................................................................ 76
8.4 Voorwaarden voor effectieve besturing .............................................. 79
9 Doel, model en besturingsvariteit ............................................. 81
9.1 Algemeen ........................................................................................ 81
9.2 Doel ................................................................................................ 81
9.3 Model van het bestuurd systeem ....................................................... 84
9.4 Besturingsvariteit ........................................................................... 87
10 Informatie ................................................................................... 89
10.1 Algemeen ....................................................................................... 89
10.2 Informatie en beslissen ................................................................... 89
10.3 Onzekerheid van informatie ............................................................. 89
10.4 Distribueren en ophalen van informatie ............................................ 91
10.5 Verwerken van informatie ................................................................ 93
10.6 Informatie en communicatie ............................................................ 94
10.7 Relaties, informatievoorziening en sturing ......................................... 95
11 Organisatie .................................................................................. 99
11.1 Algemeen ....................................................................................... 99
11.2 Organisatiestructuur ........................................................................ 99
11.3 De technische disciplines in de Civiele techniek ............................... 100
11.4 De disjunctie van element en discipline ........................................... 101
11.5 Intra-, mono-, inter-, multi en extradisciplinair werken ..................... 102
11.6 Relatieschema en organisatieschema .............................................. 103
11.7 De disciplinaire inbreng ................................................................. 105
11.8 Organisatieculturen ....................................................................... 105
11.9 De stap naar productontwikkeling .................................................. 106
12 Bijlage A: De decompositieregel ............................................... 109
13 Bijlage B: Ekofisk Barrier .......................................................... 119
14 Bijlage C: Systems Engineering in de bouw .............................. 127
15 Referenties ................................................................................ 131
CT3061
1 Inleiding
1.1 Waarom aandacht voor Systems Engineering?
We leven in een exponentile tijd. De wereld verandert steeds sneller. Dat
geldt niet alleen voor onze samenleving met veranderende wensen en eisen
maar ook voor het klimaat, de omgeving, het milieu, de technologie, de
regelgeving, de financieel economische condities en de beschikbaarheid en
prijzen van grondstoffen. Dit heeft grote consequenties voor bouwwerken en
de gebouwde omgeving in het algemeen. Daar waar de bouw zich nu
concentreert op moeilijk veranderbare bouwwerken met lange levensduren, zal
het niet lang meer duren dat bouwwerken veel adaptiever zullen zijn aan
veranderende omstandigheden.
We komen langzamerhand in een tijd dat de functionele levensduur van
bouwwerken veel korter gaat worden dan de technische levensduur. We weten
allemaal waar dat toe leidt. Zeer veel sloop en renovatiewerk zonder enige
systematiek en hergebruik filosofie. Niet voor niets is de bouw de meest
vervuilende sector. Tegenover de bijdrage aan het bruto nationaal product van
11 % staan verschillende slechte prestaties:
Bijdrage aan
Bijdrage aan
Bijdrage aan
Bijdrage aan
Faalkosten
de totale hoeveelheid afval:

het totale verkeer:
energiegebruik t.g.v. gebruik bouwwerken:
energiegebruik t.g.v. grondstoffen gebruik:
35 %
25 %
35 %
12%
10 %
De belangrijkste oorzaak is de top down ambachtelijke werkwijze waarbij elke

keer voor een nieuwe bouwwerk het wiel wordt uitgevonden en er nauwelijks
gennoveerd wordt. De industrialisatie in de bouwwereld zit op een veel te laag
niveau. Het beperkt zich tot de bouwmaterialen, de kleinste bouwelementen
zoals tegels, bakstenen en staalprofielen en de bouwcomponenten zoals
radiatoren, gipsplaten, kozijnen, damwanden, en dakplaten.
Dit kan niet zo blijven. Er zijn diverse ontwikkelingen gaande die proberen van
de bouwsector een meer volwassen bedrijfstak te maken. In de eerste plaats
is er het door de TU Delft ontwikkelde Living Building Concept, dat een
marktstrategie is waarbij de bouwsector aan productontwikkeling werkt
waarmee bouwwerken up to date en fit for purpose kunnen worden gehouden
met state of the art technologie.
Daarmee wordt een relatie gelegd tussen de veranderende wereld en de
veranderende bouwwerken. Dit heeft grote gevolgen voor de benaderingswijze
van de engineering van bouwwerken. Immers het gaat niet meer om die
eenmalige unieke constructie maar om een grote hoeveelheid elementen en
componenten die tezamen een bouwwerk vormen dat moet meebewegen met
de wereld. Al die elementen en componenten hebben verschillende
eigenschappen karakteristieken en vooral levensduren. Er geldt bovendien dat
het geheel meer is dan de som der delen. Het Living Building Concept geeft
een uitwerking voor de bouwsector van het in de normale wereld opkomende
CT1061
cradle to cradle beginsel, waarbij hoogwaardig hergebruik van materialen en

componenten meer regel dan uitzondering is.
Andere bewegingen zijn conceptueel bouwen en slim bouwen, die een
onmisbaar onderdeel vormen van het Living Building Concept. Alle drie
concepten berusten op een systeemtheoretische grondslag met een complete
n-dimensionale digitalisering van de bouwwerken.
Bovengenoemde ontwikkelingen zullen een grote invloed hebben op de
ontwerpende ingenieurs. Zij zullen veel dynamischer moeten denken en de
stand van zaken op elk moment moeten weten. Dat alles heeft betrekking op
systemen met toenemende complexiteit die dienen te functioneren in een
omgeving met toenemende gecompliceerdheid en veranderlijkheid. Een
gedegen kennis van zowel de engineeringsprocessen als van de
systeemtheorie is essentieel.
In dit dictaat worden de elementaire beginselen van Systems Engineering
behandeld, die door onze sectie als onontbeerlijke bagage wordt beschouwd
van de Delftse BSc Civiele Techniek. Met name in de Construction
Management and Engineering (CME) master is er gelegenheid deze kennis te
verdiepen.
Het ziet er naar uit dat het niet meer geaccepteerd wordt dat grote projecten
vanzelfsprekend
worden
geassocieerd
met
projectmanagement,
uitvoeringstechniek en contractuele verwikkelingen. Zij blijven langer in ons
geheugen gegrift naarmate de overschrijding van budget en/of planning groter
was. Een studie van Morris [1] op dit punt is, ondanks het feit dat vrijwel alle
projecten ooit tot een einde komen, verre van bemoedigend. In zijn studie
karakteriseert Morris grote projecten als those undertakings which are
essential to the development of society but which are poorly understood and
too often inadequately managed. Als hoofdredenen voor overschrijdingen tot
wel 700% onderscheidt hij de volgende categorien:
Onderschatting (complexiteit, moeilijkheidsgraad, technische

ontwikkeling, omvang, etc.)
Veranderingen (omvang, scope, functie, tijdschema, etc.)
Financiering (inflatie, rente, solvabiliteit, etc.)
Management (cordinatie, middelen, sancties, etc.)
Contracten (ondeugdelijke specificaties, overlap, gaten, risicodekking,
etc.)
Ook meer recente werk van Flyvbjerg et al. [2] bevestigt het beeld dat het mis
is met de beheersing van grote projecten, zonder overigens aan te geven waar
het precies aan ligt.
Het hoofddoel van dit vak is dan ook het verschaffen van inzicht in de wijze
hoe het ontwerpen engineeringproces voor complexe civieltechnische
systemen in een gecompliceerde omgeving kan worden georganiseerd. Hiertoe
wordt onder meer ingegaan op het primaire proces, de decompositie, de
cordinatie, de organisatie, de informatie en de besluitvorming.
CT3061
Tot slot zij nog vermeld dat Systems Engineering eigenlijk een containerbegrip
is van verschillende engineering-soorten. In ieder geval horen de volgende
engineeringssoorten daarbij:
Value Engineering - waarbij wordt geoptimaliseerd naar de waarde;
Cost engineering - gericht op het bepalen van de kosten;
Concurrent Engineering - gericht op het gelijktijdig uitvoeren van
ontwerp en realisatie;
Collaborative engineering - gericht op samenwerking binnen
engineering-teams;
Risk engineering - gericht op het beheersen van de risicos;
Civil engineering - als inhoudelijk discipline;
Reverse Engineering - het uit elkaar halen van een bestaand ontwerp
met het oog op eigen herontwerp.
Het vak Systems Engineering: Ontwerpproject 3 is het derde vak van de
ontwerplijn binnen de BSc-opleiding Civiele Techniek van de sectie Integraal
Ontwerpen van de afdeling Bouw. De ontwerplijn in de Bachelor-opleiding
heeft als centrale themas:
e
Van functie naar vorm ( 1 jaar);
e
Integraal werken op verschillende schaalniveaus (2 jaar);
e
Complexe systemen in gecompliceerde omgeving (3 jaar).
1.1.1
Toelichting de themas per studiejaar:
1e jaar: Inleiding Ontwerpen in de Civiele Techniek, Ontwerpproject

1 (CT1061) waarin:
Behandelen van basisbegrippen, waarbij de kaders worden geschetst
waarbinnen een civieltechnisch project zich beweegt.
Aanreiken van methodieken om - voor een civieltechnisch probleem gestructureerd oplossingsconcepten te vinden, tegen elkaar af te wegen,
uit te werken en te beschrijven.
Ontwikkelen van een vorm in een context. De ontwerpaspecten
functionaliteit en omgeving staan daarbij centraal; met de overige
ontwerpaspecten (techniek, economie en uitvoering) wordt globaal
rekening gehouden.
Behandelen van elementaire, economische principes rondom een project
met bijbehorende meet- en evaluatiemethoden.
Bijbrengen en toetsen van een aantal basisvaardigheden zoals
samenwerken met aandacht voor individuele bijdragen, vergaderen,
informatie verwerven en verwerken, een plan van aanpak maken, tekenen,
presenteren en rapporteren.
2e jaar: Integraal Ontwerpen in de Civiele Techniek, Ontwerpproject
2 (CT2061) waarin:
Oplossen van een civieltechnisch probleem, integraal werkend van grof
naar fijn. Uitgaande van een initiatief tot het oplossen van het probleem
worden de volgende fasen doorlopen: haalbaarheid, voorontwerp, definitief
ontwerp en detailontwerp.
Beschouwen van de gehele levenscyclus (ontwikkeling, exploitatie,
verwijdering),
rekening
gehouden
met
alle
ontwerpaspecten
3
CT1061
(functionaliteit, techniek, omgeving, economie, uitvoering), en werken op

drie schaalniveaus (systeem, component, element).
Behandelen van de grondslagen voor een investeringsbeoordeling met
daarbij behorende evaluatietechnieken, alsmede kwantitatieve analyses van
ruimtelijke en ecologische effecten, mitigerende maatregelen en
compensatiemogelijkheden.
De economie van projecten aan de orde komt met o.a. financiering,
bronnen, kosten-batenanalyse (KBA) en projectevaluatiemethodes. Op
beperkte schaal worden risicos genventariseerd.
Werken op drie schaalniveaus (systeem, component, element).
3e jaar: Systems Engineering, Ontwerpproject 3 (CT3061) waarin:

Een civieltechnisch ontwerp wordt uitgewerkt tot een voorlopig ontwerp.
Drie procesbenaderingen worden gevolgd:
1. Het leveren van een individuele, monodisciplinaire bijdrage aan een
multidisciplinair werkende subgroep.
2. Het werken volgens de principes van het interdisciplinair cordineren van
multidisciplinaire clusters met behoud van de relaties (raakvlakken).
3. Het extra disciplinair aansturen op centrale doelen.
Beheersen - bij de uitwerking - van de initieel vastgestelde waarde (en
daarvan afgeleid de prestatie) van het gehele systeem alsmede de kosten,
beide gerekend over de gehele levenscyclus, gedurende het ontwerpwerk
en dus doorlopend gekwantificeerd. Daarvoor wordt een totaal model
gemaakt dat het gedrag van het systeem in zijn omgeving beschrijft op elk
gewenst schaalniveau.
Decomponeren
van
de
ontwerpopgave
met
behulp
van
systeemtheoretische beginselen op een zodanige wijze dat de complexiteit
wordt gereduceerd en continue cordinatie mogelijk wordt.
Beschrijven en beheersen van de raakvlakken.
Kwantitatief omgaan met zeker- en onzekerheden, en kwaliteitsaspecten.
Belastingen en de weerstand daartegen worden op systeemniveau bepaald
en vertaald naar lagere schaalniveaus. Aandacht wordt besteed aan het
kiezen van de systeemgrens en het definiren van de relevante omgeving.
1.2 Didactisch model

Het vak CT3061 is een vervolg op de vakken CT1061 en CT1210 uit het eerste
en CT2061 uit het tweede jaar. Daar waar CT1061 zich bezig houdt met de
overgang van functie naar vorm, CT1210 met de organisatie van het bouwen,
het doel van het vak CT2061 het aanreiken is van de eerste beginselen van
integraal ontwerpen, houdt CT3061 zich bezig met raakvlakkenbeheer.
Als rode draad binnen het vak fungeert het werken aan een complex project in
een grote groep.
De ontwerpopgave zal met behulp van systeemtheoretische beginselen
worden gedecomponeerd op een zodanige wijze dat de complexiteit wordt
gereduceerd en continue cordinatie mogelijk wordt. Er worden
semiautonoom werkende subgroepen gevormd, waarbij de groep als geheel
verantwoordelijk is voor het gedrag van het gehele systeem. Daarbij dienen
4
CT3061
de raakvlakken tussen de subgroepen te worden beschreven en te worden

beheerst.
1.3 Afbakening
De stof in dit dictaat wordt bewust beperkt tot het ontwerpen en uitvoeren van
eenmalig bouwwerken met een vast doel en een vaste lange levensduur.
Het vaste doel is wel omgeven door onzekerheden. Deze onzekerheden
worden hier dus niet als kansen en als regulier fenomeen beschouwd, maar als
bedreigingen en als te bestrijden verstoringen. De onzekerheden en de daarbij
behorende risicos, ontstaan in dit 3e jaarsvak dus als perceptieproblemen
rondom het doel en de manier waarop het proces wordt ingericht.
1.3.1
Een partij met veel spelers
Bij de totstandkoming van een bouwwerk zijn zeer veel partijen betrokken.
Deze spelers komen allemaal fragmentarisch en meestal na elkaar in het
proces aan bod. We onderscheiden twee soorten spelers waarmee het
bestuderen van de bouwsector eenvoudiger wordt. Dat zijn:
Waarde consumenten die genteresseerd zijn in waarde voor geld (value for
money). Zij consumeren de waarde van een bouwwerk en betalen daar een
prijs voor.
Waard producenten, die genteresseerd zijn in geld voor waarde (money for
value). Zij produceren de waarde en vragen daar een prijs voor.
De invloed van al deze partijen in een contractuele, regulerende of een

participerende setting, op de manier waarop je het engineeringsproces inricht
is groot. Een eerste aanzet wordt gegeven in het 2e jaars ontwerpvak
(CT2061).
In dit dictaat wordt dit onderscheid niet gemaakt. Er wordt aangenomen dat,
dat wat ontwikkeld dient te worden, weliswaar met onzekerheden, vaststaat.
Het nu al meenemen van partijen met de daarbij behorende effecten, zou het
nodeloos ingewikkeld maken. In de verschillende masters wordt hier nader op
ingegaan.
1.4 Onderwijsvorm
Groepen van studenten werken in stappen aan een ontwerpopdracht. Daarbij
wordt ondersteuning gegeven in de vorm van aanreiken van kennis en
methodieken in colleges in de eerste drie weken en in verplichte instructies
tijdens gehele duur van het project over zeven kalenderwerken (semester 2:
onderwijsperiode 3).
Per week wordt in het algemeen het volgende stramien gehanteerd:
1.
Hoorcollege waarin de stof, de opdracht(en) en de resultaten worden
aangereikt respectievelijk teruggekoppeld (eerste drie weken);
2.
Verplichte instructiebijeenkomst waarin de groep met de begeleider
overlegt over de voortgang en de te hanteren methodieken;
5
CT1061
3.
Zelfstandige bijeenkomsten in de groep (zonder begeleider) waarin
zaken worden uitgewerkt.
Alle werkzaamheden worden ondersteund met digitaal studiemateriaal.
Zie verder voor de precieze opzet van het vak de vigerende Studiewijzer en de
beschrijving van de ontwerpcasus. (verkrijgbaar via Blackboard.)
CT3061
2 Groepswerk: problemen en beheersprincipes

2.1 Algemeen
Het individueel werken aan een ontwerpopgave is zoals bekend al niet
eenvoudig. Dat komt voornamelijk door het feit dat er cyclisch gewerkt wordt
aan een continu veranderende opgave. Immers een te ontwerpen bouwwerk
wordt van grof naar fijn uitgewerkt en gedetailleerd. Het bouwwerk zelf
verandert niet of nauwelijks, maar de elementen en componenten van dat
bouwwerk wel.
Met meerdere mensen werken aan een ontwerpopgave is nog aanzienlijk
moeilijker. De belangrijkste uitdaging is de wijze waarop je een cyclisch proces
opdeelt in een aantal parallelle, cyclische deelprocessen. Met andere woorden:
hoe laat je een aantal mensen werken aan een gemeenschappelijk doel,
waarbij je ze genoeg ruimte geeft om te zoeken en vooral veranderingen aan
te brengen, zonder dat doel in gevaar te brengen. Veranderingen aanbrengen
bij groepswerk is in strijd met wat er vaak in groepswerk wordt gedaan:
afspraken maken, zaken dichttimmeren en iedereen vooral aan de afspraken
houden. In het ontwerpwerk is dat onmogelijk omdat er zo moeilijk is
sluitende afspraken te maken zijn over zaken die nog niet helemaal of erger
helemaal niet zijn uitgezocht. In dit hoofdstuk wordt in grote lijnen geschetst
wat er met ontwerpwerk in groepen aan de hand is, waar de moeilijkheden
zitten en hoe je groepswerk inricht.
2.2 Grootte van ontwerpteams

Er wordt zelden door n ontwerper alleen gewerkt aan een ontwerpopgave.
Als je geluk hebt, lukt het met een paar mensen, doch meestal moet je
werken in een groot team. Om een idee te geven is in onderstaande tabel
globaal de grootte van de ontwerpgroep bepaald als functie van de
projectgrootte.
Tabel 2.1: Grootte van ontwerpteams
projectgrootte
in mln. Euros
1000
100
10
manjaren ontwerp
250
25
2.5
0.25
pers
manj
pers
manj
pers
manj
pers
manw
orintatie
33
17
1.7
0.17
haalbaarheid
67
33
3.3
0.3
1.5
voorontwerp
100
50
10
5.0
0.5
2.5
definitief ontwerp
133
67
13
6.7
0.7
3.5
detaillering
167
83
17
8.3
0.8
CT1061
Uitgangspunten daarbij zijn dat:

Alle vijf ontwerpfasen (orintatie, haalbaarheid, voorontwerp, definitief
ontwerp, detaillering) worden bestreken;
Elke fase een half jaar duurt;
Een ingenieur gemiddeld 120.000,- per jaar kost;
Er een lineaire toename van personeel in de tijd is;
De ontwerpkosten ca. 5% van de totale projectkosten bedragen.
2.3 Opdelen van groepswerk

Groepswerk is onmogelijk als men er niet in slaagt om het totale werk redelijk
te verdelen. Daarvan is iedereen overtuigd. Iedereen kent ook de twee
uitersten waarin het werken in een groep kan plaatsvinden: het ene uiterste is
de sterke leider die alle touwtjes in handen heeft en houdt, die alles wil en
moet weten, die daartoe het hele overzicht moet hebben en alle beslissingen
neemt. Het andere uiterste is de volledig gedemocratiseerde groep die alles
samen doet, samen deelt, samenwerkt en samen de beslissingen neemt.
Beide uitersten zijn in deze tijd niet meer mogelijk. Niet alleen zijn de
ontwerpopgaven te complex (intern) en te gecompliceerd (extern) om door
n leider te kunnen worden overzien, maar ook zullen in een innig
georganiseerd en gedemocratiseerd samenwerkingsverband de inhoudelijk
competente mensen het afleggen tegen handige manipulators. Er moeten dus
tussenwegen worden gevonden die het mogelijk maken om efficint en
effectief in groepen te kunnen werken.
Naast een goede inhoudelijke rolverdeling, die aansluit bij de juiste
decompositie (zie hoofdstuk 7) moet ook rekening gehouden met de
persoonlijke talenten en natuurlijke rollen die de verschillende mensen
hebben. Voor meer inzicht in de natuurlijke rollen van mensen en hoe daar in
teamverband mee omgegaan kan worden, wordt verwezen naar rollen die
Belbin [3] onderscheidt.
Naast de inhoudelijke rollen, natuurlijke rollen is het ook van belang in een
ontwerpproces bewust bepaalde gevraagde rollen op zich te nemen. Daarover
gaat paragraaf 2.4.
2.4 Gevraagde rollen

Het is van belang om in een groep het beste uit mensen te halen. Zeker in
ontwerpgroepen dienen de mensen vooral goed na te denken voordat ze wat
doen. Volgens De Bono [4, 5] is de verdediging van ons ego de voornaamste
belemmering voor ons denken en de oorzaak van vele denkfouten. De Bono
introduceerde de zes verschillende hoeden die je kunt opzetten om een rol te
spelen. In ontwerpwerk is het noodzakelijk om verschillende hoeden op te
zetten of, met andere woorden, verschillende rollen te spelen. Op die manier
wordt de ontwerpopgave van verschillende kanten belicht en is de kans op een
adequaat ontwerp het grootst. De voordelen van het opzetten van
verschillende denkpetten zijn:
8
CT3061
Het spelen van duidelijk gedefinieerde rollen

Het richten van de aandacht op een bepaald aspect van het ontwerp
Het praktische gemak om personen te kunnen aanspreken op een bepaalde
rol die zij spelen en te vragen om bijvoorbeeld een andere rol te spelen
De mogelijkheid om de regels van het spel vast te leggen
De Bono onderscheidt zes fundamenteel verschillende denkhoeden die hij met

kleuren weergeeft en die ieder een bepaalde rol symboliseren:
De Witte Hoed
Omdat wit eigenlijk geen kleur is, is deze denkrichting gebaseerd op
objectiviteit en neutraliteit. De witte denkhoed is geconcentreerd op feiten en
laat de interpretatie voor wat het is. De vragen die hij/zij zich stelt zijn er op
gericht om te weten of het feit waarschijnlijkheid, aanname of veronderstelling
is. Zijn er berhaupt wel feiten? De witte denkhoed houdt zich bezig met de
vraag hoe waar een feit is en schuwt het inzetten van taalkundige
spitsvondigheden niet. Wat te denken van het volgende spectrum van
waarschijnlijkheden over een willekeurig fenomeen:
Altijd waar
Meestal waar
In 50 % van de gevallen waar
Vaak waar
Soms waar
Zo nu en dan waar
Zelden waar
Nooit waar
Het kan niet waar zijn (tegenstrijdigheid)
De Rode Hoed
Rood is de kleur van de emoties. De rode hoed symboliseert het emotionele
standpunt. Als zodanig verleent het gevoelsoordelen en emoties een legitieme
status in een project. De rode hoed-denker is in staat de gevoelens van
anderen te peilen. Voor projectwerk is de rode denkhoed nodig voor het
inbrengen van vermoedens, intutie, nuchterheid, smaak en esthetisch gevoel.
Bij de rode hoed-denker worden de gevoelens niet gerechtvaardigd of voorzien
van een logische basis.
De Zwarte Hoed
De zwarte hoed wordt geassocieerd met somberheid en negativisme. De
zwarte denkhoed is logisch negatief. Hij is niet emotioneel. Negatief denken en
kijken is alleen toegestaan als het gefundeerd wordt. Hij/zij vestigt de
aandacht op alles wat verkeerd, onjuist of gebrekkig is, of op het feit dat iets
niet strookt met praktijkervaring of algemeen aanvaarde principes of kennis.
De zwarte denkhoed is onmisbaar voor projecten en behoedt een team vaak
voor missers en uitglijders. Een belangrijke voorwaarde is dat het denkproces
nooit mag beginnen met de zwarte denkhoed. Dan wordt namelijk alles in de
kiem gesmoord.
De Gele Hoed
Geel is een zonnige kleur en symboliseert optimisme, hoop en vooral een
positieve manier van denken. De functie van de gele hoed in een project is
9
CT1061
constructief denken en de raderen in beweging brengen. Er wordt

voornamelijk geconcentreerd op de voordelen. Er moet uiteraard opgepast
worden dat optimisme niet ontaardt in dwaasheid. Zo zijn er mensen die hun
leven inrichten op het vroeg of laat winnen van een hoofdprijs in de loterij of
het ter zijner tijd verkrijgen van een erfenis. Ook hoop zal uiteindelijk moeten
resulteren in een logisch onderbouwd optimisme. En optimisme zal op de een
of andere manier omgezet moet worden in realisme. De gele denkhoed brengt
de bal aan het rollen door het doen van voorstellen en suggesties. Het gaat
altijd gepaard met in de toekomst proberen te kijken met de best mogelijke
scenarios. Geel denken is speculatief en gericht op het opsporen van kansen.
Daarom houdt de gele denker zich bezig met de effectiviteit van de
besluitvorming. Geel denken moet niet worden verward met creatief denken.
Ook
de
gele
denkhoed
gebruikt
een
classificatie
van
de
waarschijnlijkheidsgraad van een fenomeen, die enigszins lijkt op die van de
witte denkhoed:
Het is bewezen
Heel waarschijnlijk op grond van onze ervaring en de beschikbare kennis
Grote kans; 50% kans
Niet meer dan mogelijk; Niet erg waarschijnlijk
De Groene Hoed
Groen is de kleur van vegetatie op vruchtbare grond en symboliseert daarom
creativiteit, met nieuwe inzichten en denkbeelden. Groen denken betekent het
anders en nieuw benaderen van problemen. Dat gaat gepaard met nieuwe
waarnemingen, nieuwe ideen en concepten. Het groene denken vindt plaats
in veranderingen en gaat gepaard met varianten en alternatieven. Een
belangrijk kenmerk is het lateraal denken, dat mensen in staat stelt van het
ene naar het andere patroon over te springen. Daardoor ontstaan nieuwe
inzichten.
In plaats van te beoordelen is de groene denker aan het bewegen. Hij/zij
gebruikt ideen en concepten om in beweging te komen en bewandelt daar
niet-betreden paden voor. Een belangrijke functie van het groene denken is
provocatie, om mensen uit ingeslepen patronen te verlossen.
Het zal duidelijk zijn dat groen denken vooral aan de start van een project
dient plaats te vinden en dient te worden gefaciliteerd.
De Blauwe Hoed
Blauw is een koele kleur en wordt geassocieerd met de blauwe hemel, die alles
overkoepelt. De blauwe hoed vertegenwoordigt het dirigeren en organiseren
van het denkproces, inclusief het denken van de andere hoeden. De blauwe
denkers houden zich niet zozeer met het onderwerp bezig, als met het stellen
van de juiste vragen, het definiren van het probleem, het vaststellen van de
taken, de instructies voor het denken.
Het blauwe denken kan worden beschouwd als de softwareprovider voor het
proces, de verschaffer van de choreografie, alsmede de stapsgewijze
benadering om een probleem op te lossen.
De blauwe denkhoed geeft overzicht, vat alles altijd samen en leidt tot
rapportage. Een leider is een blauwe denker, zorgt daarmee voor discipline en
controleert daarmee het proces van begin tot eind. Voor het ontwerp van
systemen is het blauwe denken van begin tot het eind noodzakelijk en
aanwezig. Zonder blauw komt er niets tot stand.
10
CT3061
2.5 Decompositie (ontleding) en cordinatie (sturing)

In de meeste literatuur wordt, bij het organiseren van complexe
ontwerpproblemen, gewag gemaakt van het verband tussen de begrippen
decompositie (ontleding) en cordinatie (sturing). In feite is het zo dat de
decompositie van een ontwerpopgave zodanig plaats dient te vinden, dat
cordinatie makkelijk wordt gemaakt. Decompositie (zie hoofdstuk 7) kan op
verschillende manieren. Vaak wordt er alleen een opsplitsing in taken
gemaakt. Dat wordt dan een work breakdown genoemd. Voor de complexe
werken wordt dit erg ingewikkeld. De beste methode is om de opgave, dat is
het te ontwikkelen object met de corresponderende taken, te ontleden en te
verdelen in deelobjecten met corresponderende deeltaken. Omdat elke
methode van ontleding een sturingsprobleem tot gevolg heeft, zijn
decompositie en cordinatie sterk aan elkaar gerelateerd. Toch is het niet
eenvoudig om die relatie te doorgronden. Zoals reeds eerder gezegd dient
decompositie de cordinatie te vergemakkelijken. Verdeel je het werk in te
grote stukken dan heeft de centrale cordinator het relatief makkelijk, maar
moet er binnen de grote brokken weer flink gecordineerd worden. Verdeel je
het werk in te kleine stukken, dan wordt de centrale cordinator zwaar belast
en is er binnen de brokken weinig cordinatiewerk nodig.
Decompositie en cordinatie hebben dus te maken met de autonomie van de
verschillende delen van de organisatie. In feite gaat het om het
bewerkstelligen van een reductie van de totale complexiteit. Dit wordt bereikt
door een slimme decompositie. Het begrip complexiteit wordt behandeld in
paragraaf 6.3. In figuur 2.1 Staan de vier mogelijkheden voor reductie van
complexiteit.
Figuur 2.1: Reductie van complexiteit - verticale as gaat over de delen, horizontale
as gaat over de relaties tussen de delen
Uit de figuur valt op te maken dat het reduceren van complexiteit op vier
verschillende manieren kan:
Gecompliceerde opsplitsing in complexe delen: dit is een traditionele
aanpak waarbij de totale taak wordt opgesplitst in deeltaken. Eigenlijk is dit
is een manier om de complexiteit te vergroten. Immers, de deeltaken lopen
door elkaar heen. Het beheersen van al die deeltaken vergt veel
cordinatie;
11
CT1061
Gecompliceerde opdeling in eenvoudige delen. Dit is de traditionele

opsplitsing in vakdisciplines, waarbij ook veel cordinatieproblemen
bestaan. We praten hier over eenvoudige delen, omdat er binnen de
vakdisciplines makkelijk kan worden gecommuniceerd. Als je aan
onderdelen werkt heb je wel verschillende vakdisciplines nodig. Dat houdt
het geheel het dus complex;
Eenvoudige opsplitsing in complexe delen: het model dat werd gebruikt
voor de Stormvloedkering in de Oosterschelde. Omdat dit project zo groot
was, werden er 12 complexe onderdelen benoemd die weinig relaties met
elkaar hadden. Deze decompositie staat dicht bij het ideale model. Het
enige probleem is de grootte en dus de complexiteit van de onderdelen;
Eenvoudige opsplitsing in eenvoudige delen. Dit is het ideaal model. In
feite is dit het Oosterschelde model, maar dan in twee lagen. De complexe
delen worden op hun beurt weer opgeknipt in eenvoudige delen;
In hoofdstukken 5 en 6 wordt verder ingegaan op de theoretische
achtergronden.
2.6 Organisatie en informatie

Decompositie en cordinatie hangen samen met organisatie en informatie. Een
goede decompositie leidt tot een goede cordinatie, hetgeen weer leidt tot een
goede informatie-uitwisseling. In zon geval spreek je van een goede
organisatie.
Op grond hiervan staan decompositie, cordinatie, organisatie en informatie
dus centraal in het beheersen van een ontwerpopgave. Dit is schematisch
weergegeven in figuur 4.2.
Figuur 2.2: Beheersing van een ontwerpopgave
De twee belangrijkste aspecten van een organisatie zijn autonomie en

cordinatie . Iedere organisatie bestaat uit een aantal autonoom opererende
werkgroepen die onderling worden gecordineerd. Die cordinatie is alleen
mogelijk als er informatie wordt uitgewisseld. Informatie en organisatie zijn
sterk met elkaar verbonden als gevolg van de kwaliteit van beide. Hoe beter
de kwaliteit van de organisatie, des te beter zal de informatieoverdracht
plaatsvinden en des te minder zullen de inspanningen hoeven te zijn voor het
processen (verwerken van de informatie). Dit kan worden genterpreteerd als
communicatie-inspanning.
12
CT3061
In de communicatietheorie wordt informatie geassocieerd met de mate van

vrijheid die men heeft in het maken van boodschappen. Als een informatiebron
niet is gekarakteriseerd door een hoge mate van willekeurige keuzes dan
stelt men dat de situatie in hoge mate georganiseerd is. In wat simpeler
bewoordingen kan er worden gesteld dat in een goede organisatie de
informatievoorziening optimaal is en er weinig overbodige informatie wordt
uitgewisseld.
In een slechte organisatie daarentegen wordt er veel overbodige informatie
gegenereerd.
In de hoofdstukken 7 en 8 wordt hier verder op ingegaan.
2.7 De vier organisatorische

productie- en organisatie-as
aspecten
verbonden:
Vaak wordt bij het groepsmatig ontwerpen het integreren als grootste
moeilijkheid gezien. Indien dat moeilijk is komt dat door een onjuiste
beheersingsstrategie. Meestal begint dat met een onjuiste decompositie,
waardoor er vanzelf een cordinatieprobleem ontstaat, en als gevolg daarvan
grote informatiestromen en een overspannen (of geen) organisatie.
Het gaat dus in eerste instantie om de uiteenrafeling van een project. Hoe
beter dat geschiedt, hoe minder problemen er zijn met de integratie van de
stukken tot een geheel.
Op grond van deze gedachte en met hetgeen we nu globaal in kaart hebben
gebracht, kunnen we rondom de vier organisatorische aspecten zowel een
organisatie as schetsen als een productie-as. In figuur 2.3 is de organisatie-as
geschetst.
Figuur 2.3: Organisatie-as
13
CT1061
Te zien valt dat het conceptueel systeem met de daarbij behorende taak wordt
verdeeld in deel systemen en deeltaken.
In figuur 2.4 is de productie as getekend.
Figuur 2.4: Productie-as
Te zien valt dat de input (geld, tijd, informatie) wordt omgezet in output (het
systeem).
De twee assen kunnen eenvoudig worden samengevoegd.
Figuur 2.5: Organisatie- en productie-as
Hier kan nu de koppeling worden gemaakt met de eerder gespecificeerde

projectinput, die in eerste instantie bestaat uit tijd en geld. Voor dat geld
wordt materiaal, materieel, energie en informatie ingekocht. De tijd is nodig
voor het transformatieproces. De output is een civieltechnisch systeem dat
werkt en dat tevens is voorzien van een gebruiksvoorschrift. Voor wat betreft
het systeem en de taak zijn twee zaken van belang die reeds eerder aan de
orde zijn gekomen:
De fase waarin het project zich bevindt
Het schaalniveau waarop wordt geopereerd
Wat betreft het systeem en de daarmee corresponderende deeltaak zullen wij
verder in dit dictaat een aansluiting trachten te zoeken bij de kleinst denkbare
werkeenheid: de monodisciplinaire taak.
14
CT3061
De kern van Systems Engineering is eigenlijk dat de projectleider op elk

moment en op elk gewenst schaalniveau weet waar het project staat in de
productie-as:
Hoe staat de input ervoor
Hoe staat de output ervoor
De organisatie as is slechts een hulpmiddel om dat voor elkaar te krijgen.
2.8 Raakvlakkenbeheer
Hoe je ook organiseert en decomponeert, de ontwerpende ingenieur krijgt
altijd te maken met allerlei raakvlakken. Een raakvlak is een omstandigheid,
manier of plaats waar zaken tezamen komen en elkaar benvloeden.
Raakvlakken vereisen afstemmen, cordinatie. Er zijn, zoals uit voorgaande
blijkt, verschillende soorten raakvlakken:
Tussen objecten - systemen, deelsystemen, elementen, componenten;
Tussen werkdisciplines civiele techniek, waterbouw, elektrotechniek;
Tussen (project-, levenscyclus)fasen ontwerp, realisatie, gebruik;
Tussen ontwerpcriteria kosten, waarden, nut, esthetica, overlast;
In feite komt het beheersen van de ontwerpopgave neer op het minimaliseren
van de raakvlakken zodat zo efficint en effectief mogelijk kan worden voldaan
aan de wensen en eisen van de opdrachtgever.
15
CT1061
16
CT3061
3 Systems Engineering: een eerste verkenning

3.1 Waarde en kosten van een systeem
Bij bouwwerken in de civiele techniek gaat het in principe om de waarde die
een bouwwerk heeft versus de kosten die daarvoor nodig zijn. De waarde
komt eruit en betekent een lust of een last voor verschillende
belanghebbenden, die iets met het systeem te maken hebben. De kosten zijn
nodig om het systeem te ontwikkelen, te onderhouden en te exploiteren
(figuur 3.1).
Figuur 3.1: Waarde en kostenstroom van een systeem
Er zijn drie soorten waarden:

Belevingswaarde, die te maken heeft met vorm, luxe, afwerking, kleur,
materialen, ruimtelijkheid, etc.
Functionele waarde, die te maken heeft met capaciteit zoals aantal autos,
vierkante meters , kubieke meters, tonnen per seconde, aantal stoelen, etc.
Technische waarde, die te maken heeft met betrouwbaarheid,
beschikbaarheid, emissies, energiegebruik, klimaat, etc.
Er zijn drie soorten kosten:
Ontwikkeling-, herontwikkeling- en sloopkosten
Onderhoudskosten
Beheerkosten
Duidelijk is dat er relaties zijn tussen deze zes grootheden en dat een System
Engineer deze zes grootheden, met de onderlinge relaties over de gehele
levensduur, dient te kennen en te beheersen. De System Engineer kijkt naar
de stroom: de waardestroom en de geldstroom.
3.2 De gebruikelijke en herkenbare schaalniveaus

In de normale consumentenmarkt zijn de zes hierboven genoemde grootheden
bekend. Als je een auto wil aanschaffen kun je een catalogus vragen, maar
ook een proefrit. Alle gegevens over onderhoud en inruilwaarde zijn bekend.
Als consument koop je een specifiek product met specifieke kenmerken en
accessoires, maar dat specifieke product is wel samengesteld uit standaard
17
CT1061
producten. Dit is weergegeven in figuur 3.2 waarbij vijf niveaus zijn

aangegeven:
Het eerste en laagste niveau is de verzameling van bottom-up ontwikkelde,
algemeen verkrijgbare standaard producten van de toeleveranciers
(banden, velgen, accus, motoren, bodemplaten, dashboardmeters,
stuurwielen, versnellingsbakken, etc.).
Het tweede niveau is een bottom-up ontwikkeld, aanbiederspecifiek (merk)
type, dat verkrijgbaar is in een groot aantal variaties.
Het derde niveau is de unieke klantspecifieke auto met unieke accessoires
en een unieke financile regeling, inclusief een inruil en een korting deal.
Maatwerk dus.
Het vierde niveau is de oplossingsruimte die de koper heeft gecreerd na
zijn orintatiefase. Deze oplossingsruimte wordt top down ontwikkeld
vanuit het probleem van de koper, in samenhang met wat hij bij
verschillende aanbieders in de etalage ziet.
Het vijfde en hoogste niveau is het probleem van de koper.
Figuur 3.2: Gebruikelijke schaalniveaus
Een ruime definitie van Systems Engineering omvat alle niveaus. SE is dan
onder te verdelen in:
Een top down gecontroleerd proces van probleem naar oplossingsruimte,
waarmee direct gekocht kan worden uit beschikbare merken en typen.
Een bottom-up gecontroleerd proces van standaard producten, via
aanbiederspecifieke producten naar klantspecifieke oplossingen.
In de bouw is er nog nauwelijks sprake van aanbiederspecifieke producten of
productfamilies die eindgebruikers uit catalogi kunnen kopen. Minder dan 1%
van de bedrijven is daarmee bezig. Maar het komt wel op.
In deze syllabus wordt SE daarom alleen als de top down benadering tot de
algemeen verkrijgbare standaard componenten behandeld.
18
CT3061
3.3 Systeemtheoretische schaalniveaus

Vooruitlopend op hoofdstuk 6 kunnen een groot aantal schaalniveaus voor
systemen worden onderscheiden. Voor het gemak zijn de twee uitersten van
schaalniveaus voor een Civieltechnisch systeem als volgt gedefinieerd:
Het laagste schaalniveau is gelijk aan het niveau van standaard
verkrijgbare producten zoals bakstenen, heipalen, staalprofielen,
voorgespannen betonliggers etc.
Het hoogste schaalniveau is gelijk aan de omgeving waarin het
civieltechnische systeem wordt geplaatst.
Tussen deze schaalniveaus bevinden zich verschillende schaalniveaus. Het
aantal is afhankelijk van de grootte van het systeem. Voor de
Stormvloedkering in de Nieuwe Waterweg kunnen vrij eenvoudig 6
schaalniveaus worden bedacht tussen de twee uitersten (figuur 3.3):
Figuur 3.3: Schaalniveaus Stormvloedkering Nieuwe Waterweg
3.4 Het sturen van de ontwikkeling en exploitatie van

systemen
De kern van Systems Engineering is, dat het gedrag van een systeem op elk te
kiezen schaalniveau, op elk te kiezen moment in de ontwerplevensduur
bekend moet zijn. Het gedrag wordt beschreven met de twee
basisgrootheden: waarde en kosten.
19
CT1061
Duidelijk zal zijn dat dit niet meevalt. Immers, er zijn veel subsystemen,
componenten en elementen in een systeem met verschillende onderlinge
relaties. De sturende System Engineer, die aan het hoofd staat van een
organisatie die het systeem ontwikkelt en / of beheert, dient dus in staat te
zijn om, op elk moment, de actuele staat van alle elementen te aggregeren tot
de topinformatie ten aanzien van de waarde van het systeem versus de
kosten. Dit moet dan ook nog uitgesplitst zijn naar de diverse stakeholders.
Het betreft niet alleen de geprognotiseerde waarde en kosten, maar ook de
actuele waarde en kosten.
De opgave van de controlerend System Engineer (ook wel System Integrator)
is schematisch weergegeven in figuur 3.4.
Figuur 3.4: Opgave van de System Integrator
3.5 De dimensies van Systems Engineering in de Civiele

Techniek
Voor het ontwikkelen en de exploitatie van complexe civieltechnische systemen
zijn diverse soorten engineering nodig. Deze bestaan naast de technische
basis engineering, die minstens bestaat uit: (1) Civil Engineering, (2)
Mechanical Engineering, (3) Electrical Engineering.
Overige vormen zijn (figuur 3.5):
Environmental Engineering (effecten op milieu en klimaat)
Concurrent Engineering (versnellen door overlap verschillende fasen)
Collaborative Engineering (samenwerken in groepen)
Value Engineering (optimaliseren waarde versus kosten)
Cost Engineering (ontwerpen van bekostiging)
Financial Engineering (ontwerpen van financiering)
20
CT3061
Figuur 3.5: Systems Engineering
21
CT1061
22
CT3061
4 De factor tijd en planning in Systems

Engineering
4.1 Algemeen
Over het algemeen wordt gezegd dat tijd geld is. Dat is zeker in de
professionele wereld waar. Dat wordt dan verdedigd met de stelling dat je
geld verliest als je slordig met de tijd omgaat. Geld is dan kosten. Geld is
echter ook waarde. Waarde genereert over het algemeen inkomsten. Dat geldt
zeker voor de private bouw met directe inkomsten uit verkoop of verhuur,
maar eigenlijk ook in de publieke bouw, met indirecte inkomsten uit de
gefaciliteerde bedrijvigheid. De civieltechnische werken maken de
basisactiviteiten van mensen (wonen, werken, recreren, verbinden en opslag)
mogelijk. Hier krijgt de overheid inkomsten uit door allerlei belastingen en
heffingen. De civieltechnische werken zorgen dus indirect voor inkomsten.
Bij civieltechnische werken is er dus altijd sprake van kosten en baten. Omdat
de kosten voor de baten gaan en het geld in de tijd genomen niet hetzelfde is,
speelt tijd een zeer belangrijke rol in het ontwikkelen van systemen en zelfs in
de relatie tussen ontwerp en uitvoering.
In dit hoofdstuk wordt nader ingegaan op de factor tijd in projecten en hoe de
activiteiten in de tijd worden gezet.
4.2 De kosten en baten van een project

Een civieltechnisch project kent, zoals in het vorige hoofdstuk is behandeld,
drie soorten kosten. Daar staat een stroom van baten tegenover die voortkomt
uit de drie soorten waarden.
Deze inkomsten en uitgaven zijn schematisch weergegeven in figuur 4.1.
Opgemerkt wordt dat stichtingskosten zowel de initile stichtingskosten
betreffen, als renovatiekosten tijdens de levensduur.
Figuur 4.1: Kosten en inkomsten van een project

23
CT1061
Bijna alle bouwwerken hebben een onbepaalde levensduur. Meestal staan ze

langer dan de ontwerplevensduur en ze staan zeker langer dan de
aangenomen economische levensduur.
Bouwwerken worden meestal gesloopt als ze hun functie kwijtraken. De
esthetische waarde en de technische waarde wordt vaak opgekrikt als er nog
sprake is van een functionele waarde.
Er is vanaf de start van een bouwwerk sprake van een kasstroom. Die
kasstroom wordt meestal in vier grootheden gegeven als functie van de tijd
(zie figuur 4.2):
De cumulatieve baten
De cumulatieve kosten
De gedisconteerde kasstroom
De netto contante waarde aan het begin van het project
Figuur 4.2: Cumulatieve kosten en opbrengsten in de tijd
4.3 Concurrent Engineering

Concurrent Engineering houdt in dat de latere fasen van het ontwerpproces
overlappen met de vroege fasen van de realisatie. Het doel is de ontwerpen
realisatietijd worden te verkorten en daarmee eerder inkomsten te genereren,
hetgeen een zeer groot effect heeft op de kasstroom. De terugverdientijd (zie
figuur 4.2) zal worden verkort.
Het creren van overlappen van ontwerp en realisatie wordt zelden gedaan
voor het gehele systeem, maar vooral op onderdelen. De kunst is dan om het
betreffende onderdeel te isoleren (met een minimum aan raakvlakken!) van de
rest van het systeem zodanig, dat de ontwerpvrijheid van de rest van het
systeem nauwelijks wordt aangetast. Dit betekent dat de raakvlakken van het
onderdeel dat wordt gemaakt, worden gefixeerd. Voor complexe projecten in
24
CT3061
de civiele techniek gaat dit lang niet altijd goed. De grootte van de winst die
wordt behaald met de overlap wordt vaak overtroffen door de grootte van de
extra kosten, die nodig zijn om het effect van verkeerd gefixeerde raakvlakken
te niet te doen.
4.4 Waarde en kosten in de tijd

Door de veranderende wereld, de niet complete kennis en de onmogelijkheid
om in de toekomst te kijken, is het beeld van het gedrag (waarde versus
kosten) van het te ontwikkelen systeem nooit 100% correct. De waarde van
het systeem gaat achteruit en de kosten lopen op. De snelheid waarmee dit
gebeurt is gevarieerd. Voor elektronische apparatuur (mobiele telefoons) is de
snelheid waarmee de belevingswaarde terugloopt vele malen sneller dan voor
onderdelen van civiele infrastructuur. (Of speelt nauwelijks een rol, vb. bij
kademuren in havens.)
Voor wat betreft de waarde loopt de belevingswaarde het snelst terug door de
veranderende smaak van de gebruikers. Dan volgt de functionele waarde door
veranderend gebruik, vooral door veranderende technologie en regelgeving.
Tenslotte volgt de technische waarde, door degradatie van het materiaal door
veroudering, vermoeiing, slijtage en ook regelgeving en voortschrijdende
technologie. Vooral dat laatste is interessant, omdat de drie waarden van
bouwwerken in feite meer relatief zijn dan absoluut. Als er iets beter op de
markt is, dan is het bestaande al snel verouderd. Daar hebben bouwwerken
met hun relatief lange levensduur dus last van. Denk maar eens aan de
ontwikkeling van installaties in bouwwerken.
Deze teruglopende waarde in de tijd is schematische geschetst in figuur 4.3.
Figuur 4.3: Teruglopende waarde
25
CT1061
Voor wat betreft de kosten kan worden gesteld, dat er continu ingrepen in het
bouwwerk plaatsvinden om het aan te passen aan veranderende
omstandigheden. Op grond van het voorgaande over de waardeontwikkeling in
de tijd, valt eenvoudig in te zien dat de kosten in de tijd oplopen, doch in ieder
geval onvoorspelbaar zijn. Ze worden voornamelijk opgelegd door invloeden
van buitenaf, de mate van belasting en de beslissingen van de eigenaar (figuur
4.4).
Figuur 4.4: Oplopende kosten
De teruglopende waarde en de kosten van al dan niet gedane ingrepen maken

dat de netto kasstroom van systemen op den duur afvlakt en zelfs negatief
kan worden. Eigenlijk zou het nooit zover moeten komen dat deze stroom
negatief wordt, omdat het object/systeem ook nog eens gesloopt moet
worden, hetgeen ook geld kost. De kosten daarvan zijn nu nog relatief gering,
maar zal zeker in de toekomst duurder worden.
Het effect van de teruglopende waarde en de oplopende kosten op de
opbrengsten is geschetst in figuur 4.5.
26
CT3061
Figuur 4.5: Afvlakkende kasstroom door teruglopende waarde en oplopende kosten
Het is voor een ontwerper zeer moeilijk om deze curves in zijn ontwerpproces
te bepalen. Het is wel zo dat als hij/zij stuurt op waarde en kosten, hetgeen
zonder meer noodzakelijk is, hij/zij wel moet beseffen dat dit speelt. Meestal
resulteert dit in een af te spreken economische levensduur, waarbinnen de
waardeontwikkeling en kostenontwikkeling min of meer kan worden voorspeld.
De economische levensduur kan sterk variren, maar is meestal 35 jaar. Dit
moet niet worden verward met de technische levensduur die soms wel
honderd jaar is. Het is dus gebruikelijk om het systeem voor lange duur te
ontwerpen, waarbij vooral materialen waar je niet meer bij kan een lange
levensduur hebben. De functie en de techniek zijn dan min of meer verzekerd
voor de te overziene omstandigheden. Het is dan ook gebruikelijk om, voor
wat betreft de opbrengsten, korter naar de inkomsten- en uitgavenkant te
kijken.
4.5 Planning
Voor de ontwerper is het essentieel een goede planning te maken van het
totale ontwikkelingstraject, dat bestaat uit het ontwerp en de realisatie (zie
hoofdstuk 5). Beide processen zijn verschillend van karakter, maar
onlosmakelijk met elkaar verbonden. Het gaat erom dat uitvoeringskennis in
het ontwerpwerk wordt betrokken en het ontwerp uitvoerbaar is. Gezien de
overschrijdingen in kosten en tijd bij grote complexe projecten mankeert hier
nog wel wat aan.
Het ontwerpproces is een zoekproces en het uitvoeringsproces is een
selectieproces. Kenmerken van beide processen zijn gegeven in tabel 4.1.
27
CT1061
Tabel 4.1: Ontwerpproces vs uitvoeringsproces
Ontwerp
Gericht op veranderen
Clusteren op relaties
Niet te veel mensen
Geen extreme tijdsdruk
Geen competitie
Trial and error
Realisatie
Gericht op gefixeerd houden
Clusteren op gelijkvormigheid
Veel mensen
Extreme tijdsdruk werkt
Wel competitie
Alles in een keer goed
Voor complexe systemen is het noodzakelijk om het werk te decomponeren en

de delen te cordineren (zie de hoofdstukken 7 en 8) . Dat gaat er vooral om
het systeem te besturen op de waarde en de kosten. Maar we hebben ook
gezien dat tijd geld is. Er moet dus ook gecordineerd worden op planning van
de activiteiten.
De planning van het ontwikkelingsproces van een complex systeem is
gebaseerd op de status van de onderdelen. Het gaat dan om het specificeren
van die onderdelen.
Bij die onderdelen gaat het om het vastleggen van de achtereenvolgende
keuzes:
Bepalen van de ontwerpbasis (ruimte, omgeving etc.)
Bepalen van de belastingen
Globale dimensionering
Uitvoeringsaspecten
Detail-dimensionering met tekeningen
Uitvoeringsplan
Specificaties
Dit resulteert in een ontwerpplanning die voor de ontwerpleider zeer belangrijk
is. De ontwerpleider controleert met de planning zowel de tijd als de
schaalniveaus waarop door de mensen wordt gewerkt. Een schematisch
voorbeeld van een ontwerpplanning is geschetst in figuur 4.6.
Figuur 4.6: Ontwerpplanning
28
CT3061
Vaak worden ontwerpplanningen op verschillende schalen gemaakt. Voor het

gehele systeem, voor subsystemen, voor componenten en voor elementen.
Het is van groot belang om een ontwerpplanning niet te krap te maken. Er
moet wel enige druk zijn om op te schieten, maar geen overmatige druk. Als
dat het geval is worden fouten gemaakt en wordt het zoekproces ernstig
verstoord.
De ontwerpleider dient in de gaten te houden wat de voortgang is van de
diverse ontwerpteams. Als er ergens stagnatie optreedt, benvloedt dat vroeg
of laat het gehele ontwerpproces. Daarom schuift hij / zij met capaciteit.
Achterblijvende teams worden zo snel mogelijk bijgestaan in hun taak. Dat is
lastig te regelen, omdat ontwerpers zich snel identificeren met hun taak en
hechten aan het onderdeel wat zij aan het ontwikkelen zijn. Toch zal de
ontwerpleider moeten ingrijpen. Een ontwerpteam komt wat dat betreft alleen
tot resultaten als er sterke leiders zijn.
Een uitvoeringsplanning is anders van aard. (zie het vak CT3980.) Daar gaat
het om de volgende processen:
Werkvoorbereiding
Bestelling en productie van de onderdelen
Aanvoer van de onderdelen
Aggregatie van de onderdelen
Beproeving van onderdelen en het systeem
Bij het opstellen van deze planning gaat het veel meer om de logistiek en het
omgaan met verstoringen in de aanvoer, met materieel en het weer. Ook hier
gaat het erom dat er buffers worden ingebouwd bij de afhankelijke processen.
De primaire zorg is dat er niet gewacht wordt op anderen.
Het is de taak van de ontwerpleider en dus ook het gehele ontwerpteam om
zowel een ontwerpplanning te maken voor hun eigen werk, en een
uitvoeringsplanning te maken voor het werk van anderen.
4.6 Onzekerheid, invloed en primaatschap

Bij een ontwikkelingsproces is bij het begin de onzekerheid over de
ontwikkelingsopgave het grootst en de invloed van de beslissingen ook het
grootst (zie figuur 4.8).
29
CT1061
Figuur 4.7: Onzekerheid en invloed
Beslissingen nemen onder grote onzekerheid is gevaarlijk. Om blunders te

voorkomen probeert de ontwerpleider zoveel mogelijk en op zon hoog
mogelijk niveau inzicht te krijgen in het gedrag van het te ontwikkelen
systeem. Het werk concentreert zich op de zogenaamde witte vlekken en de
raakvlakken. Onvermijdelijk worden er inschattingsfouten gemaakt, die
verderop in dit dictaat worden besproken. Op grond van een groot aantal
gegevens, kan globaal de volgende figuur worden geschetst. De figuur laat
iets zien over de voorspelde en werkelijke kosten, als de te bereiken waarde is
gefixeerd (figuur 4.9) [2].
Figuur 4.8: Voorspelde en werkelijke kosten bij een vaste waarde
Het geschetste verloop resulteert in een diagram, waarin de invloed op en de

bijdrage tot de totale kosten van zowel ontwerpwerk als uitvoeringswerk wordt
gegeven (tabel 4.2).
30
CT3061
Tabel 4.2: Invloed en bijdrage kosten
Op grond hiervan kan worden geconcludeerd, dat de ontwerper absoluut de

leider is van een ontwikkelingsproces. Helaas blijkt dat in de praktijk vaak het
tegengestelde het geval. Vooral bij de zogenaamde gentegreerde Design &
Construct contracten, waarin zowel ontwerp als uitvoeringswerk bij een
aannemende partij worden ondergebracht, zien we vaak dat het primaatschap
ligt bij de uitvoerend aannemer, die dan de leider is en een ingenieursbureau
als onderaannemer wordt ingeschakeld.
Dit is bijzonder eigenaardig. Want het is juist het realisatieproces dat het minst
belangrijk is in de drie hoofdprocessen: (1) Ontwerp, (2) realisatie en (3)
beheer en onderhoud.
In het volgende hoofdstuk wordt nader ingegaan op ontwerp en realisatie.
31
CT1061
32
CT3061
5 Engineeringproces
5.1 Algemeen
In dit hoofdstuk wordt het engineeringproces grondstoffelijk beschreven. Het
gaat over mijlpalen en fasen en wat er tijdens die fasen gebeurt. Hoe die
fasen in detail worden ingericht komt verderop in dit dictaat aan de orde.
Het ontwerpen en realiseren van een oplossing voor een probleem noemen we
een ontwikkelingsproces. Een ontwikkelingsproces is geen lineair proces. Het is
een zoekproces dat door vele interne en externe factoren wordt benvloed.
Zelfs als men denkt het proces volledig onder controle te hebben, kunnen zich
onverwachte gebeurtenissen voordoen die roet in het eten gooien en een
heroverweging noodzakelijk maken over zaken die men allang dacht te kunnen
fixeren. Het ontwikkelingsproces is derhalve een continue terugkoppeling of
men enerzijds nog wel met de goede dingen bezig is en anderzijds nog goed
met de dingen bezig is.
Voor een nadere verkenning van het
ontwikkelingsproces is het handig om het ontwikkelingsproces te verdelen in
twee hoofdprocessen: (1) het ontwerpproces en (2) het realisatieproces.
Deze twee processen hebben veel met elkaar te maken, maar zijn eigenlijk
ook zeer verschillend van karakter.
5.2 Ontwerpproces
Het ontwerpproces is een proces dat beheerst wordt door het criterium of men
nog wel bezig is met de goede dingen. Het is een cyclisch proces dat loopt van
de eerste probleemverkenning tot aan het hebben van een oplossing op
papier. Zoals bekend (zie CT1061) kent het ontwerpproces 5 fasen (zie figuur
5.1) die telkens even zovele mijlpalen opleveren:
33
CT1061
Figuur 5.1: Ontwerpproces
5.2.1
Analyse: van probleem naar oplossingsruimte
De analyse start met het probleem en eindigt met de oplossingsruimte. Zoals

bekend is een probleem gedefinieerd als het ongewenste aan een bestaande
situatie. Het is zaak om dat goed in kaart te brengen. Dat begint uiteraard met
het stellen van de zogenaamde reporters questions:
Wat is er aan de hand, wat zijn de belangrijkste kenmerken van de
situatie?
Waarom is de toestand ongewenst?
Wie zijn de probleemhebbers en wie zijn de mensen die gebaat zijn met
het voortduren van de bestaande toestand?
Waar speelt het probleem zich af?
Wanneer is het begonnen een probleem te worden en wanneer zou het
opgelost moeten zijn?
Welke middelen zijn beschikbaar om het probleem op te lossen?
Hoe zou het probleem opgelost kunnen worden?
Typische gereedschappen voor de analyse zijn (zie CT1061):
(1) functieanalyse, (2) procesanalyse, (3) zeefanalyse, (4) potential surface
analyse, (5) risico analyse, (6) waarde analyse, (7) indelingsanalyse, etc.
De antwoorden op bovenstaande vragen leiden tot het vaststellen van de
oplossingsruimte. De oplossingsruimte wordt opgespannen door enerzijds de
waarde-as en anderzijds de kosten-as (zie figuur 5.2).
34
CT3061
Figuur 5.2: Schematische weergaven van een oplossingsruimte
In de traditionele projectmanagement literatuur wordt niet gesproken over een

oplossingsruimte. Daar heeft men het voornamelijk over de zogenaamde Triple
constraint (zie figuur 5.3):
Figuur 5.3: Triple constraint
Deze Triple constraint wordt opgespannen door drie assen: (1) kwaliteitsas,
(2) tijdas en (3) geld-as. De constraint wordt gevormd door een norm te
stellen op de drie assen:
Prestatienorm t.a.v. kwaliteit
Tijdschema als norm v.w.b. de tijd
Budget als norm voor de te maken kosten
35
CT1061
Duidelijk is dat het hier over een punt gaat en geen ruimte. De projectleider
moet de kwaliteitsprestatie halen binnen het tijdschema en binnen het budget.
Dit beeld is wel wat verouderd. Duidelijk is dat in een ontwikkelingsproces met
perceptieproblemen en de daarbij gepaard gaande onzekerheden het op zijn
minst naef is om een vast doel als punt te definiren. Dit is de reden dat de
tijd niet als een aparte dimensie wordt gezien, maar meer gezien wordt als
een belangrijke variabele, die invloed heeft op zowel waarde als op kosten. Er
kan worden gespeeld met de tijd. Deelopleveringen, versnellen, vertragen,
buffers inbouwen, langer denken over korter doen of andersom. De tijd wordt
eigenlijk de grootste variabele van de moderne projectleider. Niet in de laatste
plaats door de tijdswaarde van het geld.
Terug naar de twee assen van de oplossingsruimte uit figuur 5.2.
De waarde-as bestaat minimaal uit drie sub-waarde-assen:
(1) belevingswaarde, (2) functionele waarde en (3) technische waarde.
Deze drie sub-assen bestaan weer uit een aantal sub-sub-assen:
Voor de belevingswaarde kan onderscheiden worden:
De esthetische waarde,
De ruimtelijke waarde,
De luxe- of afwerkingswaarde
Voor de functionele waarde kunnen meestal meerdere capaciteiten
worden onderscheiden:
Opslagcapaciteit
Doorvoercapaciteit
Transportcapaciteit
Voor de technische waarde kunnen meerdere dimensies worden
onderscheiden:
Energiegebruik
Onderhoudsgevoeligheid
Betrouwbaarheid
Beschikbaarheid
Het is nu zaak om op de diverse waarde assen de oplossingsruimte te
definiren. Een ruimte wordt begrensd door een onder- en een bovengrens. In
figuur 5.4 is schematisch een waarde-as geschetst waarop de begrenzingen
zijn aangegeven.
36
CT3061
Figuur 5.4: Waardebegrenzingen
De ondergrens per waarde-dimensie (waarde-as) wordt gegeven door de

eisen. Eisen zijn criteria waaraan de oplossing minimaal moet voldoen. Eisen
zijn intern en worden door de probleemhebber gesteld. Eisen zijn meetbaar en
eenduidig. Een eis is een ondergrens. Een eis wordt gehaald door er boven te
zitten. Het is voor een ontwerper niet doenlijk een systeem te ontwerpen dat
precies aan een eis voldoet.
Een eenvoudig voorbeeld is de eis om aan de Olympische Spelen mee te doen
met 100 meter hardlopen voor dames. De eis is 10.5 s. In geen enkele
kwalificatiewedstrijd is er een loopster die precies 10.5000000 s probeert te
lopen! Of sterker: als ze sneller is op het laatste moment een beetje zal
inhouden!
Een ander voorbeeld is de Stormvloedkering in de Nieuwe Waterweg. Een van
de afgeleide eisen was een toegestane faalkans van 10^-6 tijdens keren. Het
is ondoenlijk om het systeem zodanig te ontwerpen dat precies aan deze
faalkans voldaan kan worden. Door modellering en overdimensionering is de
werkelijke faalkans minstens een factor 10 kleiner.
De bovengrens per waarde-dimensie (waarde-as) wordt gegeven door de
randvoorwaarden. Een oplossing moet aan randvoorwaarden voldoen.
Randvoorwaarden zijn extern en worden door de omgeving opgelegd. Er zijn
verschillende soorten randvoorwaarden:
Natuurrandvoorwaarden: bv. windklimaat, golfklimaat, stromingen,
neerslag, grondwater, getijwerking, etc.
Juridische randvoorwaarden: bv. aanbestedingsrecht, vergunning,
eigendomsrecht, milieu-eisen, etc.
Maatschappelijke randvoorwaarden: bv. procedures, plannen, etc.
Financieel economische randvoorwaarden: bv. markt, beschikbaarheid van
materiaal materieel, kapitaal en
Omgevingsrandvoorwaarden: bv. grond, vervuiling, zichtlijnen, rooilijnen,
hoogtebeperkingen, geluidsbeperkingen, overlastregels, etc.
37
CT1061
Binnen deze onder- en bovengrenzen wordt vaak een extra beperking

aangebracht om bewust de oplossingsruimte te verkleinen. Dit wordt gedaan
om het zoekproces te versnellen. Deze extra beperking is intern en wordt
gerealiseerd door het formuleren van uitgangspunten. Een voorbeeld maakt
dat duidelijk. Door als uitgangspunt te nemen dat een gebouw van baksteen
gemaakt moet worden, wordt uitgesloten dat het van beton, natuursteen,
kalkzandsteen, staal, hout, plastic, glas of grond gemaakt dient te worden.
Het effect van een uitgangspunt is geschetst in figuur 5.5.
Figuur 5.5: Effect van uitgangspunten op de waarde-as
De kosten-as wordt aan de bovenkant begrensd door het beschikbare budget.

Dat budget moet de kosten dekken voor zowel de ontwikkeling, de
instandhouding en het beheer over de ontwerplevensduur van het gehele
systeem.
In tegenstelling tot de waardecomponenten (belevingswaarde, functionele
waarde en technische waarde) zijn de kosten wel lineair optelbaar. Uiteraard
moeten de kosten wel in de tijd worden verrekend (discontovoet, zie dictaat
CT2061).
Aan de onderkant wordt de kosten-as begrensd door de raming. Bij een
raming worden de ervaringscijfers van kosten voor andere, soortgelijke,
projecten gebruikt. Perceptie speelt een belangrijke rol bij het interpreteren
van ervaringscijfers. We weten dat het beeld dat wordt gevormd over de
werkelijkheid niet klopt. Het is:
Subjectief i.p.v. objectief (persoonsgebonden)
Relatief i.p.v. absoluut (modelgebonden)
Partieel i.p.v. geheel (doelgebonden)
Dit wordt nog verergerd door het gegeven dat we in de toekomst moeten
kijken. Het effect van perceptie is dat we de kosten altijd onderschatten. Elke
raming die wordt geaccepteerd is derhalve een ondergrens. Het is wel
raadzaam deze ondergrens ook werkelijk vast te stellen. In de praktijk komt
het wel eens voor dat aanbieders met een prijs lagere prijs komen als ze daar
bepaalde redenen voor hebben. Indien dat wordt geaccepteerd betekent dat
meestal moeilijkheden in het project (zie CT 5981).
38
CT3061
De oplossingsruimte kan nu schematisch worden geschetst in de twee

onderscheiden assen (zie figuur 5.6).
Figuur 5.6: Schematische weergave van de oplossingsruimte
Er ontbreken nog twee belangrijke begrippen die betrekking hebben op het

interpreteren van de oplossingsruimte.
Het eerste begrip is de wens. Wensen worden geuit in de waarde as. Wensen
hebben de gedaante van:
Zoveel mogelijk
Zo min mogelijk
De wensen vallen binnen de grenzen die op de waarde as zijn bepaald door de
eisen, de randvoorwaarden en de uitgangspunten.
De mate waarin aan de wensen tegemoet wordt gekomen bepaald de ligging
van een mogelijke oplossing op de waarde as. Dit is geschetst in figuur 5.7.
Figuur 5.7: Waardebegrenzingen en varianten
39
CT1061
Te zien valt dat variant 2 beter is dan variant 1 omdat hij beter op de wensen
scoort. Beide varianten vallen wel binnen de oplossingsruimte. Te zien valt ook
dat variant 3 beter op de wensen scoort maar buiten de oplossingsruimte valt.
Het tweede ontbrekende begrip is het begrip aanname. Zonder aannamen is
een ontwerptaak bijna niet te beginnen. Immers, we weten niet alles en zullen
toch enige kennis van de ontwerpopgave moeten opbouwen. Dat kan alleen
door aannamen te doen, die overigens later op juistheid dienen te worden
geverifieerd. De aannamen dienen wel zo realistisch mogelijk te zijn. Er wordt
wel gesteld dat de kwaliteit van de ontwerper recht evenredig is met de
kwaliteit van de aannamen.
Voorbeeld Stormvloedkering Nieuwe Waterweg:
Eisen:
1.
2.
3.
4.
Reductie MHW Rotterdam

Reductie MHW Dordrecht
Doorvaartopening
Ontwerplevensduur
Randvoorwaarden:
1. Locatie Maassluis
2. Translatiegolf
3. Effect op stroomsnelheid
(bij open kering)
Budget:
+/- 3 km
10-4
5%
Dfl 1.6 mld
Wensen:
5.2.2
1.60 m
0.60 m
360 * 17 m
100 jaar
1. Minimum scheepvaarthinder
tijdens de bouw
2. Onderhoudsvriendelijk
Synthese
Met de synthese worden varianten ontwikkeld. Ook hier staan een groot aantal
middelen ter beschikking (zie CT1061): (1) brainstorm, (2) morfologische
methode, (3) attribute listing, (4) combinatieve methode, etc..
Het is niet de bedoeling dat tijdens deze fase al precies in de oplossingsruimte
wordt gebleven met de varianten. Dat laat mogelijke interessante varianten of
combinaties van varianten buiten beschouwing.
Tijdens deze fase gaat het er om min of meer werkende varianten te creren.
De variabelen zijn: dimensies, orintatie, materialen, structuur en vorm.
5.2.3
Simulatie
De simulatiefase is uiterst belangrijk omdat het gedrag van de meestbelovende varianten moet worden onderzocht. Voor simuleren zijn modellen
nodig. De principes van modelgebruik worden behandeld in hoofdstuk 9.
In de simulatie fase wordt gekeken hoe de varianten scoren op de diverse
waarde-assen en op de kosten-as. De score is een prestatie.
Dit is een definitie: De score van een concept of een systeem, in zowel de
waarde als de kosten, is de prestatie van dat concept of systeem.
40
CT3061
De uitkomst van de simulatie van de varianten is schematisch geschetst in

figuur 5.8. Met opzet zijn er cirkeltjes getekend, omdat het werkelijke gedrag
in deze fase nog niet nauwkeurig kan worden bepaald. Er is dus nog behoorlijk
veel onzekerheid.
Figuur 5.8: Simulatie van het gedrag van n variant in de verschillende waarde assen
en de kosten as
5.2.4
Evaluatie
In de evaluatiefase wordt, op basis van de uitkomst van de simulatie, de

voorkeursvariant bepaald die de beste verhouding heeft tussen de totale
waarde die er uit komt en de kosten die erin moeten worden gestopt. De
grootste moeilijkheid is het proberen te sommeren van de prestaties op de
verschillende waarde-assen. Het meest geigende gereedschap is de Multi
Criteria Evaluatie (MCE, zie CT1061). Hiermee kunnen de wegingsfactoren
worden bepaald van de waarde-assen onderling. De producten van de
wegingsfactoren en de scores worden gesommeerd. Deze sommatie is dan de
totaalwaarde.
Met de MCE worden de varianten in de ruimte gezet die opgespannen wordt
door de waarde-as en de kosten-as (figuur 5.9).
41
CT1061
Figuur 5.9 Uitkomst evaluatie: prestaties van de varianten
Met de uitkomst van de Multi Criteria Evaluatie wordt een rangorde verkregen
van de varianten. Het belangrijkste is dat met de evaluatie ook de varianten
afvallen die buiten de oplossingsruimte vallen. Dat zijn varianten die of niet
voldoen aan de eisen, of niet voldoen aan de randvoorwaarden, of niet
voldoen aan de uitgangspunten, of niet voldoen aan het budget.
5.2.5
Beslissen
De uitkomst van de evaluatie kan niet zomaar 1 op 1 worden gebruikt voor

een beslissing ten aanzien van de kiezen variant. Met de rangorde komen ook
weer nieuwe factoren naar boven. Vooral bij een gelijkblijvend nut is het maar
de vraag welke variant gekozen dient te worden (zie figuur 5.10).
Figuur 5.10: Twee verschillende varianten met ongeveer gelijke waarde-kosten

verhouding
42
CT3061
In een dergelijk geval kan op waarde-effectiviteit worden gekozen of op

kosteneffectiviteit. Bij een keuze op waarde-effectiviteit wordt de variant met
de grootste waarde gekozen. Bij een keuze op kosteneffectiviteit wordt de
variant gekozen met de laagste kosten.
Met de beslissing is de conceptoplossing bekend en kan de oplossing nader
gespecificeerd worden. De specificatie is op dat moment gelijk aan de
prestatie met de daarbij behorende vorm, materiaalkeuze, orintatie,
structuur, etc. (zie figuur 5.11).
Figuur 5.11: De overgang van prestatie naar specificatie
Bij de specificatie hoort dus uitdrukkelijk een set tekeningen. Bij de beslissing
voor een bepaalde oplossing, zijn de structuur en de prestaties van het
systeem met zijn sub-systemen, componenten en elementen grondstoffelijk
bekend. In tegenstelling tot wat velen denken hoeft het systeem op de lagere
schaalniveaus niet ontdekt te worden. Als er bijvoorbeeld een brug in concept
wordt getekend, dan zit alles er al op en aan. Het is alleen nog niet
uitgewerkt.
De specificatie gaat door totdat een uitwerkingsniveau is bereikt waarop
producten en diensten in de markt kunnen worden gekocht.
Bij de verdere specificatie naar de lagere schaalniveaus dient continu getoetst
te worden of de oplossing geldig is ofwel of de specificatie nog steeds valt in
de oplossingsruimte. Dit continue proces wordt validatie genoemd.
Het kan in sommige gevallen voorkomen dat een conceptoplossing tijdens het
verdere specificatieproces buiten de oplossingsruimte terecht komt. Als het
niet anders kan en de conceptoplossing voor de probleemhebber nog steeds
aantrekkelijk is kan de oplossingsruimte worden vergroot.
Het specificatieproces is schematische weergegeven in figuur 5.12.
43
CT1061
Figuur 5.12: Specificatieproces
5.3 Realisatieproces
Het realisatieproces omvat alle inspanningen en activiteiten om de
gespecificeerde oplossing op papier te realiseren. Het realisatieproces omvat
verschillende deelprocessen. In de meeste literatuur wordt ten aanzien van de
bouwprojecten de volgende activiteiten onderscheiden:
Werkvoorbereiding
Inkopen
Produceren (prefab + in situ)
Assembleren
Beproeven
Tijdens de werkvoorbereiding worden naast de specifieke werkzaamheden als
de bouwterreininrichting met de bijbehorende logistieke plannen, ook de
specificaties gemaakt voor de inkoop. Als het goed is sluiten deze specificaties
aan op in de markt bekende en gegarandeerde producten. Daarmee wordt de
assemblage een beheersbaar proces dat voornamelijk een logistiek karakter
heeft.
Helaas is dit laatste nog niet het geval. De inkoop in de bouw is in hoofdzaak
het inkopen van capaciteit en vakmanschap die wordt geleverd door
onderaannemers. Dat betekent vaak dat de sub-systemen, componenten en
elementen in het werk worden gebracht, behandeld en gemaakt.
5.3.1
De specificatie
Zoals gezegd is de specificatie een verzameling eigenschappen,

karakteristieken en hoedanigheden van een te realiseren systeem met al zijn
onderdelen, met de daarbij behorende tekeningen. Het is de bedoeling dat het
systeem conform deze specificaties wordt gerealiseerd. Maar onderdelen
kunnen en zullen nooit precies op een specificatie worden geleverd. Een
voorbeeld: Op de verpakking van een geproduceerde spaarlamp staat dat hij
10.000 uren moet functioneren, bij normaal gebruik. De fabriek komt in
44
CT3061
principe in moeilijkheden als deze 10.000 uren niet worden gehaald . De

ontwerpafdeling komt met een specificatie van 10500 uren, met een tolerantie
van 500 uren. Het productieproces moet nu zodanig worden ingericht dat die
10500 gemiddeld wordt gerealiseerd en dat alle lampen die uit de fabriek
komen binnen de tolerantie vallen. Ook in de bouwsector worden specificaties
voorzien van een tolerantie band.
Dat leidt tot de definitie van tolerantie: de toelaatbare afwijking van een
bepaalde hoedanigheid, eigenschap of karakteristiek van een te maken object,
is zonder dat de bijdrage van het object tot het geheel wordt aangetast
De tolerantie op een waarde-as is geschetst in figuur 5.13.
Figuur 5.13: Toleranties
Toleranties zijn nodig om de afwijkingen in het productieproces te beheersen.

In de bouw kennen we de vier productieafwijkingen:
Afwijkingen in maat en materiaaleigenschappen
Deformaties (vervormingen)
Leveringsdatum
Prijs
Duidelijk is dat er afwijkingen zijn ten opzichte van zowel de waarde
(afwijkingen en deformaties), als de kosten (leveringsdatum en prijs). In
hoofdstuk 7 zien we dat dit sturingsproblemen geeft ten aanzien van
effectiviteit en efficintie.
Het verband tussen de te verwachten afwijkingen en toleranties wordt bepaald
door het creren van buffers in zowel het bouwwerk, het tijdschema en de
budget. Die buffers worden aangebracht in strekte, stijfheid, passingruimte,
etc. Zowel het aantal als de grootte van de buffers is een kwestie van geld. Dit
is het grootste probleem van engineering. Dit is vooral een kwestie van
ervaring.
De begrippen specificatie, toleranties, buffers en afwijkingen zijn schematisch
45
CT1061
Figuur 5.14: Specificaties, toleranties, buffers en afwijkingen
5.3.2
Verificatie en eventuele validatie
Het is de bedoeling dat tijdens alle uitvoeringsprocessen continu wordt

getoetst of het gerealiseerde bouwwerk aan de specificaties voldoet. In feite
wordt gecontroleerd of de uitvoering aan het ontwerp voldoet. In de meeste
gevallen is dat wel zo. Het hangt overigens wel van de kwaliteit van het
ontwerp af. Als er nog enkele onzekerheden zijn ten aanzien van het ontwerp
terwijl de uitvoering al is begonnen, kan er nog wel eens wat mislopen.
5.3.3
Verificatie en afkeur bij serieproductie
Bij de productie wordt er altijd gekeurd. Dat kan op verschillende manieren,

maar gebeurd bijna altijd steekproefsgewijs. Door de keuring wordt de
statistische verdeling van de serie in gunstige zin verstoord (zie dictaat
probabilistisch ontwerpen, CT4130). Stel dat een bepaalde serieproductie een
normale verdeling heeft en een tweezijdige symmetrische tolerantie. Dan is
het logisch dat de verwachtingswaarde van de productie op het
specificatiepunt wordt gezet (zie figuur 5.16). Het gearceerde oppervlak geeft
dan aan wat de kans is dat er een onacceptabele productie plaatsvindt, met de
improvisatiegevolgen van dien.
Met een afkeur- (tolerantie-)grens waarboven wordt afgekeurd, kan worden
bereikt dat de kans op onacceptabele productie aanzienlijk wordt verkleind.
46
CT3061
Figuur 5.16: Invloed van keuring op statistische verdeling
5.3.4
Verificatie van onderdelen en verificatie van het systeem
Tijdens het realisatieproces worden de onderdelen geverifieerd aan de

specificaties. In principe lijkt daarmee het systeem als geheel geverifieerd,
omdat het hele systeem al met de volledige specificatie vastligt, dus inclusief
de relaties tussen de elementen. Dat is echter niet het geval. Juist in het
aggregeren van de elementen tot een geheel kunnen fouten worden gemaakt.
Daarom dienen op verschillende aggregatieniveaus verificaties plaats te
vinden. Dat kan heel goed, omdat tijdens het ontwerpproces de specificaties
op die verschillende aggregatieniveaus zijn vastgelegd.
De verificaties kunnen niet altijd op werkelijke schaalgrootte plaatsvinden. Het
is bijvoorbeeld ondoenlijk om een stortbed, dat is uitgerekend op een
bepaalde faalkans gegeven bepaalde belastingen, op die faalkans te testen.
Het zal doorgaans lang wachten betekenen totdat die extreme
belastingsituatie zich voordoet. Het volstaat in dit geval om de modelresultaten
te combineren met een controle van het stortproces, aangevuld met een
diktemeting (in- en uitpeiling) van de steengradering die is aangebracht.
Om het gehele systeem te verifiren is het dus noodzakelijk om zowel een
verificatie op de delen te doen als een verificatie op de aggregatie.
Onderscheid dient dan te worden gemaakt op parallelle en seriesystemen of
combinaties daarvan. Het gaat dan altijd om aansluitingen, verbindingen,
overlappen, etc.
Voor de definities van validatie en verificatie, zie bijlage C.
47
CT1061
48
CT3061
6 Systeemtheorie en complexiteit
6.1
Algemeen
Systeemtheorie is een van de basistheorien voor systems engineering. In dit

hoofdstuk worden de basisbegrippen behandeld. Het gaat alleen over de
begrippen die voor het engineeringproces belangrijk zijn. Voor degene die
meer willen weten over systemen en systeem leer zijn er honderden titels
beschikbaar. Dit hoofdstuk kan voor hen worden beschouwd als een
trefwoordenboek voor verder zoeken.
6.2
Systeem en haar elementen
6.2.1
Systeem
In de wereld om ons heen komen objecten voor, die in een zodanige relatie
met elkaar staan, dat zij samen min of meer een zelfstandig geheel vormen.
Dat geheel wordt een Systeem genoemd [6]. De meest eenvoudige definitie
van een systeem is:
Een systeem is een verzameling elementen met een verzameling

onderlinge relaties die samen een gentegreerd geheel vormen.
Vanuit deze definitie gaan we het systeem verder exploreren en definiren.
6.2.2
Element
Een element is het kleinste onderdeel van een systeem dat relevant is
voor het doel van het systeem.
Dit lijkt in eerste instantie een vreemde definitie: waarom niet gewoon zeggen
dat een element het kleinste te onderscheiden onderdeel van een systeem is?
Dat werkt niet omdat er geen eind is aan de kleinheid der dingen. Er zijn geen
kleinste deeltjes. We kennen nu al aardig wat kleine deeltjes maar de kleinste
krijgen we nooit te pakken. Een behoorlijk klein deeltje zoals we dat wel
kennen bijvoorbeeld een atoom is niet relevant voor het doel van de systemen
die in dit dictaat worden behandeld. Het kleinste onderdeel wat er wel toe
doet is bijvoorbeeld een bout of een moer.
6.2.3
Inhoud
De inhoud van een systeem is de verzameling elementen.

6.2.4
Eigenschappen
Alle elementen van een systeem hebben specifieke eigenschappen. Dit is een
belangrijk begrip. Wiskundig gezien bestaan er identieke elementen, die dus
49
CT1061
identieke eigenschappen hebben. In werkelijkheid bestaat er geen gelijkheid.

Ook op het oog identieke elementen zijn niet aan elkaar gelijk. De
eigenschappen verschillen dus onderling.
6.2.5
Relaties
Ieder element van het systeem heeft per definitie een relatie met alle andere
elementen van het systeem. Die relaties kunnen direct zijn (met een direct
raakvlak) of indirect via een hoger schaalniveau.
De relaties kunnen sterk of zwak zijn. Elementen en hun relaties zijn
schematisch weergegeven in figuur 6.1.
Figuur 6.1: Elementen en de onderlinge relaties
Het hebben van een relatie met een ander element betekent dat dit element
de eigenschappen van dat andere element kan benvloeden.
6.2.6
Coherentie
De verzameling relaties bepalen de coherentie van een systeem. Een systeem

is volledig coherent in het geval dat elk element een directe relatie heeft met
ieder ander element.
6.2.7
Systeemgrens
De systeemgrens vormt de scheiding tussen het systeem en de wereld

rondom het systeem.
Een systeemgrens in de context van Systems Engineering wordt meestal als
volgt gekozen:
Als de systeemgrens te klein wordt gekozen, vereenvoudigt het systeem, maar
wordt de relatie van het systeem met de omgeving ingewikkeld.
Als de systeemgrens te groot wordt gekozen, vereenvoudigt de relatie van het
systeem met de omgeving, maar wordt het systeem zelf erg ingewikkeld.
50
CT3061
Het kiezen van de systeemgrens is een uiterst belangrijke activiteit en verdient

daarom veel aandacht. De meest gebruikelijke strategie bij het kiezen van een
systeemgrens is dat:
de interne coherentie wordt gemaximaliseerd, dat betekent het
maximaliseren van het aantal relaties binnen de systeemgrens.
de externe coherentie wordt geminimaliseerd, dat betekent het
minimaliseren van de relaties tussen enerzijds de elementen binnen het
systeem en anderzijds de elementen buiten het systeem.
Het kiezen van een systeemgrens is schematisch weergegeven in figuur 6.2.
Figuur 6.2: Het kiezen van een systeemgrens
51
CT1061
6.2.8
Structuur
De structuur van een systeem is de totale verzameling relaties.

Dit kan eenvoudig worden ingezien met een voorbeeld. Een bouwwerk heeft
zeer veel elementen. Die elementen hebben bijvoorbeeld een geometrische
relatie en een sterkte (krachtsoverdrachts-) relatie. Beide deelverzamelingen
relaties bepalen voor een groot gedeelte het skelet van het bouwwerk. De
structuur van een systeem is schematisch geschetst in figuur 6.3.
Figuur 6.3: Structuur van een systeem
6.2.9
Omgeving
De omgeving van een systeem wordt gevormd door die elementen van
het universum, die de eigenschappen van de elementen van het
systeem benvloeden of omgekeerd, worden benvloed door het
systeem.
Op grond van deze definitie en de definitie van structuur, is er dus zowel een
interne structuur als een externe structuur. Daarvan kan weer worden afgeleid
of er sprake is van een open of gesloten systeem:
In een open systeem hebben de omgevingselementen een relatie met de
elementen van het systeem.
In een gesloten systeem heeft de inhoud van het systeem geen relatie met de
omgeving van het systeem.
52
CT3061
6.3
Subsystemen, aspectsystemen en fasesystemen
6.3.1
Algemeen
Om een scherper inzicht te krijgen in een systeem is het handig om te kijken

naar deelsystemen.. Een systeem bestaat uit elementen en relaties. Bovendien
bestaat een systeem in de tijd en kan als functie van de tijd verschillende
gedaanten hebben. Een derde belangrijke parameter voor de beschrijving van
het systeem heeft dus betrekking op de tijd.
We kunnen dan ook op drie manieren deelsystemen proberen te ontwaren. Er
wordt dan min of meer vanzelf uitgekomen op een onderscheid binnen het
systeem in subsystemen, aspectsystemen en fasesystemen.
6.3.2
Subsysteem
Een subsysteem is een deelverzameling van de elementen in het systeem,

waarbij alle oorspronkelijke relaties tussen deze elementen onveranderd
behouden blijven (zie figuur 6.4). Als een subsysteem een uitgesproken functie
heeft, spreken we van een component.
Figuur 6.4: Subsysteem
Een voorbeeld:
Wanneer we een gebouw als een systeem beschouwen dan zijn subsystemen
o.a. een verdieping, een kamer, een trappenhuis, de waterleiding, het
elektrische net en het telefoonnet (als er bij het subsysteem sprake is van een
uitgesproken functie, bijv. het trappenhuis, dan noemt men dat trappenhuis
een component).
6.3.3
Aspectsysteem
Een aspectsysteem is een deelverzameling van de relaties in het systeem,

waarbij alle elementen onveranderd behouden blijven. Het verband tussen
subsysteem en aspectsysteem is gegeven in figuur 6.5.
53
CT1061
Figuur 6.5: Het verband tussen een subsysteem en een aspectsysteem
Een voorbeeld:
Het esthetische uiterlijk van het gebouw is een aspectsysteem, evenals de
kleuren. Dit is het domein van de architect. De civiele ingenieur kijkt naar
andere aspectsystemen zoals: gewicht, sterkte, stabiliteit, afmetingen. De
bedrijfskundige zal o.a. naar het logistieke aspectsysteem kijken. Heel
belangrijke aspectsystemen zijn bijvoorbeeld onderhoudskosten, operationele
kosten en stichtingskosten.
6.3.4
Fasesysteem
Een fasesysteem is een opsplitsing van het systeem in de tijd met een begin
en een eind: wanneer begint men met het beschouwen van een systeem en
over welke tijdsspanne (tijdhorizon) beschouwt men het systeem.
Een voorbeeld:
In de civiele techniek zijn fasesystemen heel belangrijk. Bijvoorbeeld een
beweegbare brug die vier fasen kent:
1.
2.
3.
4.
Gesloten
Openend
Geopend
Sluitend
De vier fasen kennen vier verschillende belastinggevallen die tot verschillende

systemen leiden.
Voor de Stormvloedkering in de Nieuwe Waterweg zijn er vijf fasesystemen
met totaal verschillende belastingen en systemen:
1.
2.
3.
4.
5.
54
Parkeerstand
Sluitend
Kerend
Spuiend
Openend
CT3061
6.4
Toestand, proces en gedrag
6.4.1
Algemeen
Naast de tot nu toe behandelde begrippen om een systeem te beschrijven, is

het van groot belang om ook na te denken over het doel van een systeem. Het
gaat er dus niet alleen om wat een systeem is, maar ook waarom het wat is
en wanneer het wat is. Voor een verdere bestudering van systemen in die
zin, zijn begrippen als toestand, proces en gedrag belangrijk.
6.4.2
Toestand (state)
De toestand van een systeem op een bepaald tijdstip wordt

gedefinieerd door de waarden van de eigenschappen op dat tijdstip in
het systeem.
Wanneer de waarde van een eigenschap van een element verandert,
verandert de toestand van het systeem. In een dergelijk geval spreekt men
van een gebeurtenis (event). Wanneer een gebeurtenis een andere
gebeurtenis tot gevolg heeft, spreekt men van een activiteit (activity). De
relaties tussen de elementen kunnen ook veranderen. In dat geval is sprake
van een veranderende structuur van het systeem.
Het kan zelfs voorkomen dat een aantal elementen uit het systeem verdwijnt
of vervangen wordt. Dan verandert dus ook de inhoud en daarmee de
structuur, want ook een aantal relaties verandert. In zulke gevallen van een
veranderende inhoud en structuur moet men voor een beschrijving van de
toestand dus niet alleen een overzicht geven van de waarden van de
eigenschappen, maar ook van de inhoud en de structuur op dat tijdstip (fase).
6.4.3
Proces (process)
Een proces is een serie van samenhangende acties in de tijd,

waardoor een eigenschap van een element verandert (plaats, stand,
vorm, afmeting, functie, of enig ander kenmerk).
6.4.4
Gedrag (behaviour)
Het gedrag van het systeem is de wijze waarop het systeem reageert
op bepaalde in- en uitwendige omstandigheden, op bepaalde invoeren
en op de veranderingen daarin.
Men onderscheidt verschillende soorten gedrag:
Statisch systeemgedrag: Het uitgangssignaal op een bepaald tijdstip wordt
bepaald door de grootte van het ingangssignaal op dat tijdstip.
Voorbeelden van systemen die een statisch gedrag vertonen zijn: een dijk,
een generator en een gebouw. Het verleden (de historie) heeft geen
invloed op het systeemgedrag.
55
CT1061
Dynamisch systeemgedrag: Het uitgangssignaal op een bepaald tijdstip is

niet alleen afhankelijk van de grootte van het ingangssignaal, maar
bovendien van het verloop van dat ingangssignaal over de voorgaande
tijdsperiode. Voorbeelden van systemen met een dynamisch gedrag zijn:
een rivier, een sociaal systeem zoals een gezin, een maatschappij, een
bouw- of ontwerpteam. Het gedrag van het systeem wordt mede bepaald
door de toestand van het systeem in het verleden.
Deterministisch gedrag: Indien het gedrag van het systeem berekend of
exact voorspeld kan worden is het een deterministisch systeem.
Stochastisch gedrag: Bij een stochastisch systeem is de input in het
systeem toevalsafhankelijk. Voor wat betreft stochastisch gedrag kunnen
er twee soorten worden onderscheiden:
1. steady state stochastisch gedrag, waarbij de kans van
optreden van de input niet verandert
2. transient stochastisch gedrag, waarbij de kans van optreden
van de input wel verandert
Een voorbeeld van een transient stochastisch dynamisch systeem is gegeven

in bijlage B: The Ekofisk Protective Barrier.
6.5
Complexiteit
6.5.1
Een maat voor complexiteit
Om een wiskundige maatstaf voor complexiteit vast te stellen is het handig om

een systeem op onderdelen nader te beschouwen. We kijken of er sprake is
van een eenvoudige decompositie in complexe onderdelen. Slechts dan kan er
een soort formule uitrollen.
Beschouw een systeem S als een geheel en laten subsystemen de delen zijn.
Na een eerste decompositiestap komen we uit op subsystemen S1, S2, S3, S4,
etc. De volgende decompositie stap geeft dan voor S1: S11, S12, S13 en
voor S2: S21, S22, S23, etc. In de laatste decompositie stap houdt men de
elementen over: E1, E2, etc.
Dit decompositiebeeld is geschetst in figuur 6.6.
Figuur 6.6: Decompositie
Als C de complexiteit van een subsysteem is en R staat voor de relaties tussen

de subsystemen, dan kan de complexiteit van het totale systeem beschreven
worden met de volgende formule:
56
CT3061
C(S)
= R(S1,S2) + C(S1) + C(S2)

= R(S1,S2) + R(S11,S12) + R(S21,S22,S23) + C(S11) +C(S12) +
C(S21) + C(S22) + C(S23)
Door de complexiteit van de elementen af te trekken van de totale

complexiteit ontstaat de volgende vergelijking:
C(S) - C(E1) - C(E2) - .. - C(En) =
R(S1,S2) + R(S11,S12) + R(S21,S22,S23) + + R(E1,E2) +
R(E1,E3) + R(E2,E3).
Complexiteit wordt in deze vergelijking bepaald door de complexiteit van het
element, het aantal elementen en alle relaties tussen alle subsystemen per
decompositie stap tot op element niveau.
Dit is niet voldoende want een gemetselde muur van 1.000.000 stenen is niet
complex. Er is maar n decompositie stap en men is gelijk op elementniveau.
Bij een fiets zijn er vele decompositie stappen tot op elementniveau en vele
verschillende elementen en relaties.
Geconcludeerd kan dan ook worden (met als voorbeeld een muur versus een
fiets) dat complexiteit bepaald wordt door:
Complexiteit van het element:
Elementen op zich kunnen heel complexe systemen zijn, bijv. een steen
bekijken tot op moleculair niveau. Het aantal decompositie stappen van het
totale systeem tot op element niveau wordt bepaald door de complexiteit
op element niveau. Dit betekent dat op elementniveau eigenschappen en /
of hun relaties het doel van het te onderzoeken systeem niet benvloeden.
Diversiteit in elementen:
Bij een muur zijn alle elementen (stenen) hetzelfde, terwijl bij een fiets
bijna alle elementen anders zijn.
Diversiteit in relaties, de aard of de soort relatie:
Bij een muur zijn alle relaties gelijk (voeg) terwijl bij een fiets bijna alle
relaties per decompositiestap anders zijn.
Complexiteit van een relatie:
Bij een muur is de voeg een eenvoudige relatie (verbinden en sterkte). Bij
een fiets zijn de relaties ingewikkelder doordat niet alleen sterkte en
verbinding, maar ook passing en beweging in de ruimste zin van het
woord er bij horen: as + kogellagers.
Het aantal decompositie stappen om tot element niveau te komen (dit
bepaalt impliciet het aantal relaties en de diversiteit in relaties).
Bij een muur heeft men n decompositie stap, terwijl een fiets tussen de 5
en 6 stappen nodig heeft.
57
CT1061
Tabel 6.1: Complexiteit muur versus fiets
Op grond van deze analyse kan worden gesteld dat de complexiteit van een
systeem wordt bepaald door vijf parameters die in tabel 6.2 zijn gegeven.
Tabel 6.2: Mate van complexiteit elementen
6.5.2
De invloed van complexiteit
In het ontwerpproces heeft complexiteit betrekking op zowel de ontwerper als

op de conceptoplossing. Complexiteit voor de ontwerper is subjectief, want
iedereen kijkt op een andere manier naar een ontwerpopgave. En het is
relatief, omdat het wordt bepaald door ervaring, kennis, kunde van de
ontwerper, doel van de oplossing, etc. De individuele perceptie en benadering
van een complex probleem speelt een belangrijke rol in het complexe
ontwerpproces.
De invloed van complexiteit op het ontwerpproces kan aan de hand van
onderstaand voorbeeld worden gellustreerd. Een ontwerper moet een systeem
ontwerpen dat bestaat uit een groot aantal elementen. Deze elementen
moeten aan een groot aantal eisen, wensen, randvoorwaarden en
uitgangspunten voldoen. De kans dat er een systeem bestaat dat aan al deze
criteria optimaal tegemoet komt, is verwaarloosbaar klein. De ontwerpstrategie
is om te proberen om aan zoveel mogelijk criteria tegelijkertijd te voldoen.
Omdat de ontwerper niet in staat is om tegelijkertijd aan alle elementen te
werken, zal hij het systeem opdelen in subsystemen en deze subsystemen,
bestaande uit de elementen en de daarbij behorende criteria, iteratief
proberen op te lossen.
Voor een verdere illustratie beschouwen we een systeem opgebouwd uit
slechts twee elementen.
58
CT3061
Twee elementen hebben een wederzijdse relatie, als ze aan n bepaald

criterium moeten voldoen, zie figuur 6.7.
Figuur 6.7: Wederzijdse relatie tussen de elementen
Wanneer een van de elementen wordt veranderd om aan een volgend criteria
te voldoen, moet de ontwerper vanwege de relatie ook het andere element
veranderen. In het geval dat er veel relaties zijn, moet de ontwerper vaak
opnieuw beginnen, wat dan tot een iteratief ontwerpproces leidt. Wat het ook
nog eens lastig maakt, is dat er een hirarchie in criteria is. Met andere
woorden, de criteria zijn niet allemaal even belangrijk. In het geval dat de
relaties niet complex zijn, is het evident dat de opeenvolgende oplossingen
beter aan de eisen voldoen. Het is duidelijk dat als er geen relaties zijn, de
oplossingen in n keer volledig aan de criteria voldoen. Bij een complex
systeem is het noodzakelijk om door vele iteraties tot een oplossing te komen.
In het algemeen zullen ontwerpers die werken aan een deel (subsysteem) van
een complex ontwerpprobleem, oplossingen ontwikkelen die voldoen aan de
criteria voor het subsysteem. Dit zal echter ten koste gaan van de oplossingen
die ontwikkeld worden voor andere subsystemen. Dit komt omdat het
makkelijker is om met eenvoudige oplossingen te komen. Het geheel is echter
altijd meer dan de som der delen, zodat deze methode er nooit toe zal leiden
dat aan alle eisen criteria wordt voldaan. Indien ontwerpers proberen om op
deze manier aan alle criteria tegelijkertijd te voldoen, zal dit eindigen in een
chaos.
Om toch tot bevredigende oplossingen te komen zal er dus slim moeten
worden gedecomponeerd, hetgeen in de volgende hoofdstukken wordt
behandeld.
Het ontwerpproces is moeilijk omdat:
Er veel criteria en er dus veel relaties en ook veel aspectsystemen zijn;
De criteria niet allemaal even belangrijk zijn;
Er een altijd sprake is van een conceptoplossing die bestaat uit vele en
diverse elementen met vele diverse en ingewikkelde relaties.
6.5.3
Andere factoren van belang
Uit het voorgaande is duidelijk dat de structuur en de inhoud van een systeem
bepalend zijn voor de complexiteit. Naast deze twee grootheden worden er in
59
CT1061
de literatuur ook nog andere grootheden genoemd die een rol spelen in de
complexiteit. De meest genoemde factoren worden hier globaal besproken.
Voorspelbaarheid
Voorspelbaarheid wordt veel genoemd als een factor voor complexiteit. De
redenering is dat als het gedrag van een systeem onvoorspelbaar is, het
systeem complex is. Dat komt vaak voor met niet-lineaire systemen of met de
tijd veranderende systemen, of met systemen waarvan de omgeving
veranderd.
Opsplitsbaarheid
Als een systeem makkelijk is op te splitsen in min of meer onafhankelijke
deelsystemen, is het niet complex. Deze factor is eigenlijk dezelfde als de al
eerder gegeven structuur als een van de bepalende factoren van complexiteit.
Immers als er een sterke structuur is, en er dus veel en sterke relaties bestaan
tussen de elementen dan kunnen die elementen moeilijk worden losgekoppeld.
Dom organiseren
Dit is een categorie waarbij de complexiteit wordt vergroot door de aanpak
zelf. Een lijstje van toppers is:
Denken dat alles met alles samen hangt. Daardoor is het bijna onmogelijk
om iets te organiseren en te delegeren;
Denken dat alles belangrijk is. Daardoor wordt er ook niets verwaarloosd of
uit fase onderzocht. Het werken is dan bijna onmogelijk geworden;
Het aantal betrokkenen wordt gemaximaliseerd. Dit gebeurt vaak door
bijvoorbeeld te veel specialisten of toekomstige klanten bij het
ontwerpproces te betrekken. Overdaad schaadt!
Maximaliseren van de functionaliteit ofwel er zo veel mogelijk instoppen
(moet aan alles kunnen voldoen). Dan kan er ook veel mis gaan. Dit wordt
snel onoverzichtelijk;
Teveel besturen en te weinig vrijheid op de werkvloer. Vaak weten de
lagere echelons meer dan de hogere kaders en is een zekere mate van
bestuurlijke ongehoorzaamheid vaak een voorwaarde voor succes. Denk
maar eens aan de verlammende kracht van stiptheidsacties!
Teveel aandacht voor n aspect, dat ook wel eens suboptimaliseren wordt
genoemd (zie CT1061!). Dit komt zeer vaak voor. Voorbeelden zijn: te veel
nadruk op kosten, automatisering, product, vakdiscipline, korte termijn,
milieu, etc.
De basisstrategie voor het omgaan met complexiteit is het reduceren van
complexiteit. Maar die reductie komt zelden voort uit het wijzigen van de
structuur of de inhoud van een systeem. De enige manier om reductie van
complexiteit te bewerkstelligen, is het systeem op een slimme manier op te
splitsen. Hier wordt later op ingegaan.
60
CT3061
7 Decompositie
7.1.
Algemeen
Zoals we al hebben gezien, is een ontwerpopgave complex en gecompliceerd.

Aan onderling gekoppelde of zelfs conflicterende eisen, wensen en
randvoorwaarden moet gelijktijdig worden voldaan door een complex systeem
bestaande uit een groot aantal elementen.
In dit hoofdstuk wordt behandeld hoe we deze opgave hanteerbaar kunnen
maken. Dat kan door het te ontwikkelen systeem als concept eerst op te delen
in overzienbare delen en vervolgens de deeloplossingen weer aan elkaar te
plakken. Daarbij mag uiteraard het inzicht in de werking van de totale
oplossing (het gedrag) niet verloren gaan. Het idee om te decomponeren is
ontstaan vanuit het besef dat een mens niet in staat is gelijktijdig alle
noodzakelijke handelingen, om een bepaald doel te bereiken, uit te voeren. Er
zijn vele vormen van decompositie. De oudste vorm is de planning waarin
activiteiten in de tijd worden geordend. Voorts kwam in de oude ambachten
een decompositie naar discipline en specialisme vaak voor. Dat zien we nog
steeds in de bouwsector, die in wezen ook nog ambachtelijk werkt. De
industrialisatie is er in de bouwsector alleen tot op componentniveau.
Tegenwoordig wordt ook vaak een opsplitsing gehanteerd die is gemaakt op
basis van locaties, informatie, productiviteit, klanten of markten.
In dit hoofdstuk wordt hoofdzakelijk ingegaan op de meest voor de hand
liggende methoden voor het decomponeren van een ontwerp /
ontwikkelingsopgave. Derhalve bevat dit hoofdstuk geen algemene
verhandeling over decompositiemethoden, maar is het meer het beschrijven
van specifieke toepassingen.
7.2.
Doel van decomponeren
Doel van een decompositie voor een ontwikkelingsproces is het opdelen van
een systeemconcept in deelsysteemconcepten. Dit om de complexiteit van het
systeemconcept te reduceren en aldus het ontwikkelingsproces voor groepen
van ingenieurs te faciliteren.
In
zijn algemeenheid kan decompositie toegepast worden om:

De complexiteit te verminderen
Te optimaliseren naar beschikbare specialismen
Tijd te besparen door parallel aan verschillende deelsystemen te werken
Het werk te verdelen
Het werk te plannen
Kortom: door decompositie kunnen complexe problemen worden opgelost

terwijl gelijktijdig economische rationalisatie wordt bereikt.
Opgemerkt wordt dat het doel van decompositie niet is de kleinste elementen
te identificeren waaruit een systeem is opgebouwd. Het gaat er veel meer om
de juiste clusters van elementen te definiren. Clusters bestaan uit
deelsystemen, die op hun beurt weer bestaan uit elementen met hun relaties.
61
CT1061
Een goede decompositie leidt tot op de beschikbare middelen afgestemde

clusters.
7.3.
Systeemtheoretische aspecten van decompositie
Vanuit de systeemtheorie kan worden gesteld dat decompositie per definitie

het opsplitsen van een systeem in deelsystemen is . In hoofdstuk 6 zijn de drie
mogelijke deelsystemen al benoemd: (1) subsystemen, (2) aspectsystemen en
(3) fasesystemen.
De hoofdwet van de systeemtheorie luidt dat het geheel meer is dan de som
der delen. Het verschil tussen het geheel en de afzonderlijke delen is gelijk
aan de relaties.
Op grond hiervan kan worden gesteld dat het er bij decompositie niet alleen
om gaat de deelsystemen te formeren, maar dat ook de relaties tussen de
deelsystemen een belangrijke rol spelen. De aard van die relaties geeft een
indicatie over de manier waarop de deelsystemen gebruikt kunnen worden:
Relaties sub sub: deze relaties gaat over interacties en communicatie.
Relaties aspect aspect: deze relatie gaat over het systeemgedrag en de
cordinatie.
Relaties fase fase: deze relatie gaat over de volgorde in het gebruik van
het systeem en de daarbij behorende kenmerken en overgangen.
Relaties sub aspect: deze relatie gaat over wat belangrijk is bij welk
onderdeel.
Relaties sub fase: deze relatie gaat over welke dingen op welk tijdstip in
actie moeten komen.
Relaties aspect fase: deze relatie gaat over wat op welk tijdstip van
belang is.
In de figuren 7.1, 7.2, 7.3 en 7.4 zijn tweedimensionale voorstellingen
gegeven van de relaties tussen de verschillende deelsystemen van een
systeem.
62
CT3061
Figuur 7.1: Relatiediagram tussen subsystemen (LET OP: asymmetrisch).
Belangrijk is te beseffen dat er zowel eenzijdige als tweezijdige relaties

bestaan. De relatiematrices kunnen dus zowel symmetrisch als asymmetrisch
zijn. Dit geldt dus voor de matrix sub systeem / subsysteem en voor de matrix
aspect systeem / aspectsysteem.
Figuur 7.2: Relatiediagram aspect systeem / aspectsysteem.
Later zal blijken dat er voorkeur is om de aspectsystemen zo onafhankelijk

mogelijk te formeren. Helaas is dat niet altijd mogelijk. Er zal altijd wel een
relatie zijn tussen de aspectsystemen. Voor de hand liggende voorbeelden van
afhankelijke aspectsystemen zijn:
Sterkte en stijfheid: als je iets sterker maakt wordt het meestal ook stijver.
Stichtingskosten en onderhoudskosten: als je minder onderhoud wilt
betekent dat vaak een grotere investering aan het begin.
63
CT1061
Figuur 7.3: Relatiediagram tussen aspecten subsystemen.
Uiteraard heeft niet elk aspectsysteem een relatie met een subsysteem (b.v.
niet elk subsysteem behoeft onderhoud).
Figuur 7.4: Relatiediagram tussen het fasensysteem en respectievelijk de subsystemen

en de aspectsystemen.
Opmerking:
Niet ieder subsysteem, noch ieder aspectsysteem speelt een rol in elke fase
(b.v. geen onderhoud tijdens de constructiefase).
64
CT3061
7.4.
Decompositiemethoden voor de ontwikkeling van

complexe systemen
7.4.1. Algemeen
Met een systematische decompositie op grond van de mogelijke relaties,
kunnen de organisatorische knelpunten gemodelleerd worden als een pad in
de driedimensionale ruimte tussen de sub-, de aspecten de fasesystemen.
Helaas leidt deze benadering niet zonder meer tot een eenduidige en ideale
decompositiestrategie
die
resulteert
in
optimale
clusters.
De
decompositiestrategie is namelijk onderworpen aan twee tegenstrijdige
belangen:
Enerzijds is het belangrijk om het systeem onder te verdelen in een groot
aantal deelsystemen om een simultane ontwikkeling mogelijk te maken en
de ontwikkelingstijd te beperken (economische rationaliteit).
Anderzijds is het noodzakelijk om het aantal deelsystemen te beperken om
het geheel te kunnen cordineren.
Verder wordt de decompositie gedomineerd door twee zaken:

De autonomie van de deelsystemen, wat erop neerkomt dat het mogelijk
moet zijn een beperkte tijd met een deelsysteem te werken zonder dat
continu het gehele systeem in de gaten moet worden gehouden.
Het brein van de ontwikkelaars en de ontwerpers, wat erop neerkomt dat
ontwerpers een maximale span of control aankunnen. (Gesteld kan
worden dat een leider maximaal 6 10 ondergeschikten met
hooggekwalificeerde taken kan leiden.).
De decompositieopgave komt eigenlijk neer op het clusteren van de kleinste
elementen met de daarbij behorende relaties van het systeemconcept.
Het verband tussen een top down decompositie en een bottom up clustering is
schematisch geschetst in figuur 7.5.
Figuur 7.5: Top down decompositie van system tot subsysteem en bottom up clustering
van elementen tot subsystemen.
65
CT1061
7.4.2. Het clusteren van de ontwerpvariabelen

De essentie van ontwerpwerk is aanpassing. Een goed ontwerpproces is
mogelijk als het aanpassingsgericht is, zelforganiserend is opgezet en
oplossingen produceert voor een probleem, zelfs in een veranderende context.
Vanuit de systeemtheoretische kant van een ontwikkelingsproces wordt een
ontwerpopgave bepaald door de ontwerpvariabelen, die potentile misfits
zijn tussen een oplossing en een probleem. De ontwerpopgave is zeer
schematisch weergegeven in figuur 7.6.
Figuur 7.6: Schematische weergave van de ontwerpopgave.
De ontwerpvariabelen zijn met elkaar verbonden door causale relaties. Het is

niet moeilijk in te zien dat bijvoorbeeld voor infrastructuur, variabelen ten
aanzien van veiligheid een relatie hebben met variabelen ten aanzien van
capaciteit en geometrie.
Dus de verzameling ontwerpvariabelen kan worden gerepresenteerd als
geschetst in figuur 7.7, waarin zowel de variabelen als de relaties tussen de
variabelen worden getoond.
Figuur 7.7: Grafische weergave van misfits (variabelen) tussen probleem en

oplossing.
Omdat de variabelen onderling met elkaar zijn verbonden, kunnen ze niet

onafhankelijk van elkaar worden aangepast. Toch moeten we zien te proberen
of er wel mogelijkheden zijn om de variabelen min of meer onafhankelijk van
66
CT3061
elkaar aan te passen. Het lijkt in eerste instantie vruchtbaar om de variabelen

te benaderen met behulp van de verzamelingenleer.
Veronderstel m variabelen: xixm
De verzameling variabelen is dan als volgt gedefinieerd:
Xi M (voor i = 1 tot m)
Deze variabelen kunnen elkaar versterken, met elkaar conflicteren of
onafhankelijk van elkaar zijn. Dit betekent dat de variabelen onderlinge relaties
hebben. De verzameling relaties wordt hier L genoemd. L bevat de
eendimensionale, van een teken voorziene en niet van richting voorziene
relaties tussen de elementen van verzameling M. Elke relatie verbindt precies
twee variabelen.
De verzamelingen M en L vormen samen een lineaire graaf: G (M,L). Een
voorbeeld van zon graaf is al geschetst in figuur 7.7.
Voor een goede decompositie is het noodzakelijk dat de graaf G(M,L) een
nauwkeurig beeld geeft van het gedrag van de variabelen. Immers, het doel
van het ontwerpwerk is dat zo goed mogelijk aan die variabelen wordt
voldaan. Voor een nauwkeurig beeld moet de graaf G(M,L) aan drie formele
voorwaarden voldoen (zie bijlage A):
Verzameling L moet alle interacties tussen de variabelen beschrijven.
Omdat de elementen van L de correlatie tussen twee variabelen
representeren, zullen hogere orde correlaties moeten worden vermeden.
Dit betekent dat elk paar variabelen onafhankelijk moet zijn van de staat
van andere variabelen. De enige manier om dat te bereiken is door de
variabelen zo specifiek mogelijk te maken.
Zelfs de correlatie tussen twee variabelen moet zo klein mogelijk zijn. Dit
betekent dat een poging gedaan moet worden de variabelen zo
onafhankelijk mogelijk te maken.
De variabelen moeten een zekere symmetrie laten zien. Dit betekent dat de
omvang van alle oplossingen die aan een bepaalde variabele voldoen,
ongeveer gelijk is voor iedere variabele. Met andere woorden, alle
variabelen moeten ongeveer vergelijkbaar zijn in omvang en betekenis.
De vraag is nu hoe de verzameling M op een juiste en slimme manier te
decomponeren in een aantal deelverzamelingen. Het zal duidelijk zijn dat de
verzameling L daar een belangrijke rol in speelt. De ontwerper staat dan voor
de volgende opdracht. Hij beschikt over een verzameling variabelen M. Hij wil
die verzameling bijvoorbeeld verdelen in twee deelverzamelingen, waarbij hij
de bovengenoemde regels in acht wenst te nemen. Op die manier is het
ontwerpwerk namelijk cordineerbaar.
Allereerst is het daarvoor nodig om de verkenning van het begrip complexiteit
uit hoofdstuk 6 nader te beschouwen. Op grond daarvan kan gesteld worden
dat als de elementen naderen tot nul, de complexiteit van een systeem gelijk
is aan de som van de relaties.
67
CT1061
Eenzelfde redenering kan worden gevolgd ten aanzien van het gedrag van een
systeem, en dus ook ten aanzien van het systeemgedrag als de enige en
integrale variabele. Indien de elementen naderen tot nul is het totale
systeemgedrag, en dus de integrale variabele, gelijk aan de som van de
relaties.
Op grond hiervan kan worden gesteld dat een deelverzameling relaties (dat is
gedefinieerd als een aspectsysteem) dus een deelverzameling variabelen is.
Nu zijn we dan waar we moeten zijn: Een min of meer onafhankelijke
aanpassing van de ontwerpvariabelen kunnen we realiseren door
aspectsystemen op een slimme manier te kiezen:
Zo specifiek mogelijk
Zo onafhankelijk mogelijk
Zo veel mogelijk van gelijke scope en belang
Het eerste en derde criterium is duidelijk. Het tweede criterium vereist een
nadere verkenning. Immers, onafhankelijkheid is in eerste instantie ver te
zoeken vanwege de relaties tussen de variabelen.
De sleutel tot het formeren van min of meer onafhankelijke clusters van
variabelen ligt in het gegeven dat niet alle variabelen even sterk met elkaar
zijn gerelateerd. Dat maakt het mogelijk om redelijk onafhankelijke clusters te
maken.
De nearly decomposition rule van Simon [7] is een decompositie methode
die dit bewerkstelligt. De regel komt erop neer dat het korte termijngedrag
van deelsystemen wordt bepaald door de interne coherentie van het
beschouwde deelsysteem (intra-relaties), terwijl het lange termijngedrag
wordt bepaald door de coherentie tussen de deelsystemen (inter-relaties).
Dit betekent dat de ontwerper voor een bepaalde korte periode zijn aandacht
geheel aan een deelsysteem kan wijden, zonder dat hij de rest van het
systeem in de gaten hoeft te houden. De rest van het systeem zal alleen op de
lange termijn iets ondervinden van het gesoleerde korte termijnwerk aan een
bepaald deelsysteem.
Hiermee is een ontwerper in staat om met een aspectsysteem, gedurende een
relatief korte periode, het systeemgedrag op een relevant aspect te beheersen
en te sturen. Het lange termijngedrag van het systeem kan alleen worden
gestuurd en beheerst met alle aspectsystemen in samenhang. Dit
sturingsmechanisme is geschetst in figuur 7.8.
68
CT3061
Figuur 7.8: Complexe sturing, korte termijn sturing en lange termijn sturing op
ontwerpvariabelen.
Volgens de bijna decompositieregel moet het systeem worden

gedecomponeerd in subsystemen, zodanig dat het aantal relaties binnen elk
subsysteem wordt gemaximaliseerd en het aantal relaties tussen de
subsystemen wordt geminimaliseerd.
Dit is beschreven in bijlage A.
Het resultaat van een dergelijk clustering is geschetst in figuur 7.9.
Figuur 7.9: Een voorbeeld van een clustering van variabelen die resulteert in
deelverzamelingen van variabelen (aspect systemen).
Voor een adequate sturing is het noodzakelijk dat de aspectsystemen ook

zodanig worden geformeerd dat ze:
Kwantificeerbaar zijn
Lineair zijn
Voor civieltechnische systemen kunnen de volgende aspectsystemen worden
bedacht, die kwantificeerbaar en lineair zijn en tezamen het gedrag van het
systeem weergeven:
Capaciteiten en deelcapaciteiten zoals afvoer in m3/s, snelheid in m/s,
aantal passagiers, aantal te schutten schepen per uur, hijsvermogen, etc.
Sterkte zoals een opneembaar moment of een opneembare kracht
Stijfheid zoals de verplaatsing per kN, de doorbuiging bij de grootste aslast
69
CT1061
Stabiliteit van een bodembescherming of een constructie

Geometrie zoals uitgedrukt in tolerantieruimte, toleranties, deformaties,
maatafwijkingen
Energiegebruik
Emissies van NOx, CO2, stank, fijnstof, etc.
7.4.3. Het clusteren van elementen (decompositie naar
subsystemen)
Na de decompositie van de ontwerpopgave, die resulteert in een centrale
sturing op aspectsystemen (zie figuur 7.8), rijst de vraag of het systeem als
zodanig te sturen is. Het antwoord luidt ontkennend. Het aansturen van het
werk aan de elementen zou een bovenmenselijke inspanning eisen. Het
ophalen van de informatie en het distribueren van invloed is voor de centrale
ontwerpleiding niet te doen. In te zien valt dat het aantal elementen ook dient
te worden geclusterd.
Voor het clusteren van de elementen geldt ook de nearly decomposition rule
van Simon. Ook hier is de semi-autonomie van werken maatgevend. Clusters
van elementen (subsystemen) dienen zodanig te worden geformeerd dat er
binnen de cluster een beperkte periode kan worden gewerkt zonder dat er
rekening hoeft te worden gehouden met het gehele systeem. Op de lange
termijn daarentegen dienen de clusters wel met elkaar rekening te houden.
Dit principe is geschetst in figuur 7.10.
Figuur 7.10: Voorbeeld van een clustering van elementen
Een voorbeeld van het clusteren van elementen volgens deze methode is
gegeven in bijlage A.
7.4.4. Het resultaat van de decompositie: reductie van complexiteit
De complexiteit van de ontwerpopgave, met de vele elementen van het
systeem en de vele ontwerpvariabelen die niet alleen de relaties tussen de
elementen weergeven, maar ook nog onderlinge relaties hebben, is
70
CT3061
Figuur 7.11: Complexiteit van de ontwerpopgave.
Na de twee decomposities is de ontwerpopgave substantieel vereenvoudigd.

Niet alleen kan het ontwerpwerk worden verdeeld, ook het gedrag van het
totale systeem is te allen tijde beheersbaar en stuurbaar. Er gaat geen
informatie verloren!
Het nieuwe beeld is geschetst in figuur 7.12.
Figuur 7.12: De vereenvoudigde ontwerpopgave na de clustering van variabelen en

elementen.
Duidelijk is dat, gegeven de systeemtheorie en gegeven de ontwerptheorie, de

bovengenoemde twee clusteringen de enige methoden zijn om een complexe
ontwerpopgave tot een goed einde te brengen. Het enige nadeel is dat deze
methode moeilijk te begrijpen is en als zodanig te ver af staat van de huidige
71
CT1061
bouwpraktijk. Toch is dit concept toegepast op een erg groot en complex

werk: Ekofisk Protective Barrier (zie bijlage B). De reden was dat dit de enige
mogelijkheid bleek om te overleven met het project, vanwege de beperkte tijd
en de enorme risicos.
In de volgende paragraaf zal worden aangetoond dat de bovenbeschreven
decomposities in schril contrast staan met de huidige decompositiemethoden
in de bouwsector.
7.4.5. Huidige decomposities in de bouwsector
Een van de meest voorkomende decomposities in de bouw is de decompositie
volgens disciplines. De totale taak, dus niet het totale systeem, wordt verdeeld
in deeltaken. Voor civiele techniek betekent dat meestal de volgende clusters:
Grondwerk
Heiwerk
Betonwerk
Staalwerk
Natte werken
Mechanische werken
Elektrotechnische werken
Het zal duidelijk zijn dat de aanvangscomplexiteit, zoals die geschetst is in
figuur 7.11, met een dergelijke decompositie aanmerkelijk wordt vergroot. Dit
is geschetst in figuur 7.13.
Figuur 7.13: Het effect van een decompositie van taken naar verschillende disciplines.
Geconcludeerd kan worden dat de positie van de projectmanager niet

benijdenswaardig is. Uiteraard komt hij/zij er uiteindelijk wel uit, maar vraag
72
CT3061
niet tegen welke inspanningen en welke kosten. Omdat dit het meest
voorkomende model is in de bouwsector en de allerergste soort van
decompositie is die men zich kan voorstellen, wordt elke andere vorm van
decompositie als weldadig ervaren, mits hij makkelijk is en eenvoudig te
begrijpen.
Een andere decompositie die meer en meer voorkomt in de bouwsector, is het
lineair decomponeren van de overgang van functie naar vorm. Uitgangspunt is
dat het ontwerpwerk neerkomt op het beschrijven van een functie en dat daar
dan een vorm bij dient te worden gezocht. Op zich is dat al discutabel, omdat
het genereren van een enkele functie meestal niet genoeg is om een probleem
op te lossen. Ontwerpvariabelen zijn meeromvattend dan alleen een functie.
Wat te denken van een criterium als CO2 -uitstoot of energiegebruik.
Verder is de decomponeerbaarheid discutabel. Dat komt omdat de relaties een
cruciale rol spelen in een systeem. De geluiddichtheid van een vloer, wanden,
ramen en plafond kunnen perfect zijn, maar een geluidslek in een kleine
verbinding kan alles teniet doen. Het gaat om de relaties!
Dit zogenaamde Hamburger model wordt met succes gebruikt door de
integraal ontwerpers. Met succes, omdat het oneindig veel beter is dan de
traditionele decompositie op disciplines. Het principe van het Hamburger
model is geschetst in figuur 7.14, een voorbeeld in figuur 7.15.
Figuur 7.14: Het Hamburger model: het principe
73
CT1061
Figuur 7.15: Het Hamburger model: geschikt om functionele dingen te maken, maar
niet geschikt om systemen te ontwikkelen.
Hoewel dit decompositiemodel oneindig veel beter is dan de decompositie in

disciplines, is het beeld te simpel. De reden is dat het geheel meer is dan de
som der delen. Dat geldt zeker voor functies. De functie van het geheel is
meer dan de som der deelfuncties. Het verschil uit zich in belevingswaarde en
technische waarde. Dat betekent dat er met deze methode een
restcomplexiteit blijft die uiteindelijk dient te worden opgelost.
74
CT3061
8 Cordinatie van de ontwikkelingsopgave

(sturing)
8.1
Algemeen
Volgens Mintzberg [8] zijn er twee factoren verreweg het belangrijkst voor het
succesvol organiseren van een werk. De eerste is de manier waarop het werk
wordt verdeeld, de tweede is de manier waarop het verdeelde werk wordt
gecordineerd. Beide factoren hebben zoals gezegd veel met elkaar te maken.
Het kunnen cordineren is een belangrijk uitgangspunt voor de manier waarop
we decomponeren. De gekozen decompositiemethode bepaalt de
cordinatiemogelijkheid. In hoofdstuk 7 is de verdeling van het werk reeds
behandeld. In dit hoofdstuk wordt ingegaan op hoe een en ander
gecordineerd moet worden.
Het cordinatiemodel wordt opgezet vanuit de in de bedrijfskunde ontwikkelde
besturingsmodellen van systemen. Deze modellen zijn zeer geschikt om ook de
besturing van ontwerpprocessen mee te beschrijven.
8.2
Besturingsmodel
Besturing wordt algemeen gedefinieerd als: elke vorm van gerichte invloed.
Het model bestaat in eerste instantie uit drie grootheden, die weergegeven
zijn in figuur 8.1: (1) een bestuurd systeem, (2) een omgeving en (3) een
bestuurder (lit. 8.2).
Figuur 8.1: Besturingsmodel
Het bestuurd systeem kan als een gedragsgenerator worden beschouwd, die
een gedrag vertoont dat een functie is van de besturingsingrepen van de
bestuurder. Hetzelfde geldt voor de omgeving. Als gevolg hiervan kunnen er
twee typen besturing worden onderscheiden:
Interne besturing die gericht is op benvloeding van het bestuurd systeem
Externe besturing die gericht is op de benvloeding van de omgeving
75
CT1061
Het zal duidelijk zijn dat beide typen besturing voor de civiel ingenieur van
groot belang zijn. Omdat het bestuurd systeem een relatie heeft met de
omgeving is het mogelijk om zowel het bestuurd systeem, als de omgeving
indirect te besturen.
In de figuur valt te zien dat besturen niet alleen invloed uitoefenen is, maar
ook betekent dat er informatie moet zijn.
8.3
Meta-besturingsconcepten
8.3.1
Metasturing
Voor een verdere uitdieping van de hirarchie in de besturingsmogelijkheden

is het meta-besturingsconcept handig. De term meta geeft hier aan dat het
concept van hogere orde is.
Metabesturing is gedefinieerd als besturing van de besturing. Je zou het ook
kunnen interpreteren als een verbetering van de bestuurder. Metabesturing
treedt in werking als de bestuurder buiten zijn competentie komt. In feite
komt er een metabestuurder die de bestuurder bestuurt. Dit is schematisch
Figuur 8.2: Metabesturing
De metabesturing beschikt evenals

sturingsmogelijkheden:
Interne routine metasturing
Interne adaptieve metasturing
Intern doel metasturing
Externe routine metasturing
Externe adaptieve metasturing
Extern doel metasturing
de
gewone
besturing
over
zes
De metabesturing kan op verschillende manieren plaatsvinden. Naast de in

figuur 8.2 aangegeven zuivere metasturing (take-over), komt ook nog wel
eens ondersteunende sturing (support) voor (zie figuur 8.3).
76
CT3061
Figuur 8.3: Ondersteunde sturing
8.3.2
Meta-metasturing
Een besturingssysteem stopt niet met het eerste meta-niveau. Duidelijk is dat
er meerdere meta-besturingsniveaus moeten zijn. Daarvoor zijn twee
indicaties. De eerste is het aantal decompositiestappen. Dit is dus een
kwantitatief gegeven. Als er een aantal aggregatieniveaus zijn, dan zullen daar
ongetwijfeld verschillende besturingsniveaus bij te verzinnen zijn. De tweede is
dat het denkbaar is, dat de aandacht per sturingsniveau op verschillende
aspecten is gericht. Dit is dus een kwalitatief gegeven. Bij een meta-metabesturingsconfiguratie wordt de metabestuurder weer bestuurd door een
meta-metabestuurder. Dit is weergegeven in figuur 8.4.
Figuur 8.4: Meta-metabesturing
8.3.3
Cordinatie en metabesturing
Cordinatie van ontwerpwerk heeft betrekking op het laten wijzigen van de

relevante elementen op een zodanige manier, dat er van een
gemeenschappelijk doel sprake is. In principe heeft de cordinatie betrekking
op zowel het handhaven van de relaties tussen de elementen (de structuur
van het systeem), als het bewaken van het doel. Het lijkt uiterst zinnig dit in
77
CT1061
twee stappen te doen. Deze twee stappen zijn dan eenvoudig in een metabesturingsconfiguratie te zetten. Op dergelijke wijze is er sprake van drie
besturingsniveaus:
Meta-metasturing: extern doel
Metasturing: interne / externe structuur en intern doel
Basisbesturing: interne / externe routine
Dit is weergegeven in tabel 8.1.
Tabel 8.1: Drie besturingsniveaus
8.3.4
Cordinatie en decompositie
Nu de verschillende meta-besturingscordinaties gekoppeld zijn aan een

cordinatie, kan tevens een koppeling worden gemaakt met de eerder
behandelde decompositie. Dat gaat overigens vrij eenvoudig. Er zijn twee
koppelingen, die schematisch zijn weergegeven in figuur 8.5.
Figuur 8.5: Cordinatie en decompositie
De twee koppelingen zijn:

Doelcordinatie: aspectsystemen
Structuurcordinatie: clusters van elementen
Duidelijk is dat de cordinatie primair gericht is op het systeem en de daarin te
onderscheiden deelsystemen. Dat is van groot belang, omdat dat de
cordinatie overzichtelijk maakt. Het systeem is stoffelijk, heeft elementen die
allemaal relaties en eigenschappen hebben. Dat kan allemaal in kaart gebracht
worden en het kan zelfs dynamisch beheerst worden.
78
CT3061
8.4
Voorwaarden voor effectieve besturing
8.4.1
Algemeen
Met het besturingsparadigma van figuur 8.1, kunnen de voorwaarden voor

effectieve besturing worden geformuleerd [9].
De bestuurder dient:
1. Een doel te formuleren met betrekking tot het bestuurd systeem
2. Een model te hebben van het bestuurd systeem
3. Over voldoende besturingsvariteit te beschikken
4. Informatie te hebben over de van invloed zijnde omgevingsparameters die
in het model van het systeem zijn gedentificeerd
5. Informatie te hebben over de relevante systeemparameters en dus de
toestand van het systeem
6. Voldoende informatieverwerkingscapaciteit te beschikken
De punten 1, 2 en 3 worden behandeld in hoofdstuk 9: Doel model en
besturingsvariteit. De punten 4, 5 en 6 komen aan de orde in hoofdstuk 10:
Informatie.
79
CT1061
80
CT3061
9 Doel, model en besturingsvariteit

9.1
Algemeen
Doel, model en besturingsvariteit zijn drie van de zes voorwaarden voor

effectieve besturing. Deze drie voorwaarden hangen sterk met elkaar samen
en worden dus in een hoofdstuk behandeld. In feite bevinden deze drie
voorwaarden zich tussen de vier essenties van het werken in groepen. Dit is
geschetst in figuur 9.1.
Figuur 9.1: Doel model en besturingsvariteit in het hart van de besturing
9.2
Doel
9.2.1
Functie van een doel
Gegeven de definitie van besturing, is het onmogelijk te sturen zonder doel.

Sturingsacties zijn erop gericht het systeemgedrag naar de vastgestelde
doelen te krijgen.
In de meeste gevallen hebben discussies over doelen een chaotisch karakter.
Het soms verbazingwekkend hoe snel de doelen kunnen worden aangepast.
Het grootste misverstand is meestal dat men denkt dat het systeem een doel
heeft. In feite wordt het doel van een systeem bepaalt door de belangen die
individuen of groepen van individuen hebben met betrekking tot het systeem.
Het doel is eigenlijk geen systeem eigenschap maar een modeleigenschap.
Het doel heeft eigenlijk twee functies:
Het doel is een criterium voor de effectiviteit van de besturing. Het doel
bepaalt het gewenste gedrag van het te ontwikkelen systeem. Een vergelijk
van het werkelijke gedrag van het systeem met het gewenste gedrag van
het systeem geeft inzicht in de effectiviteit van de besturing. Hoe kleiner
81
CT1061
het verschil des te effectiever de besturing.

Het doel is een criterium voor de kwaliteit van het modelleringproces. Het
doel geeft immers de richtlijn voor de keuzes die dienen te worden
gemaakt ten aanzien van de parameters en de relaties die in het model aan
de orde moeten komen. We spreken dus eigenlijk van een
doelgeorinteerde modellering.
9.2.2
Doel als input/output
Het doel kan in principe op veel manieren worden bereikt. Eigenlijk kan het
doel worden gedefinieerd als het arrangeren van input en output of -beter
gezegd- het arrangeren van combinaties van onderling afhankelijke input,
output en sturingsacties (zie figuur 9.2).
Figuur 9.2: Schematische weergave van een bestuurd systeem
De input van dit model start met de kosten. De kosten, i.c. stichtings-,
onderhouds- en beheerskosten, worden aangewend om de volgende
inputcomponenten aan te schaffen:
Energie
Materiaal
Materieel
Informatie
De output van dit model is uiteraard de waarde van het systeem uitgedrukt in
de reeds behandelde drie waardecomponenten (belevings-, functionele en
technische waarde)
Formeel gesproken bestaat het doelconcept uit combinaties van xi, ui, yi
voorzien van een voorkeursvolgorde, zoals bijvoorbeeld x1,y1 boven x2,y2.
Het is duidelijk dat er dus verschillende typen doelen zijn.
Voor een concreet doelconcept is het handig om vanuit de productie theorie
de noties ten aanzien van input en output nader te verkennen. De
bedrijfskunde stelt meestal normen ten aanzien van input en output. De input
is het budget en de output is de vastgestelde prestatie (specificatie) ten
aanzien van de waarde (zie hoofdstuk 5).
82
CT3061
9.2.3
Doel als het product van effectiviteit en efficintie
Er wordt in de meeste processen gestuurd op zowel effectiviteit als efficintie.

(zie figuur 9.3)
Figuur 9.3: Effectiviteit en efficintie
Er geldt:
Effectiviteit = P/PO
Efficientie = KO/K
Met:
P = werkelijke prestatie
PO = normprestatie
K = werkelijke kosten
KO = normkosten
Deze definities komen voor uit de reeds genoemde perceptieproblemen die
een belangrijke rol spelen in ontwikkelingsprocessen. De gevolgen van het feit
dat we de werkelijkheid subjectief, partieel en relatief waarnemen in plaats
van objectief, geheel en absoluut zijn dat:
De prestatie dus de waarde wordt overschat, hetgeen betekent dat als je

verschrikkelijk je best doet je nooit boven de je doel uit kan komen, maar
eigenlijk dat je per definitie onder je doel uitkomt. Daarom is de effectiviteit
P/PO < 1
De kosten worden onderschat. Het valt altijd tegen. Daarom is de
efficintie KO/K < 1
In de gangbare bedrijfskunde is het product van effectiviteit en efficintie is

gelijk aan de productiviteit. Dat kan ook voor een ontwikkelingsproject worden
toegepast. De productiviteit van het ontwikkelingsproces is mate waarin je aan
het doel voldoet.
Hoewel hier nog op terug wordt gekomen in dit hoofdstuk is het belangrijk om
het doel nog te definiren als de tolerantie ruimte rond de specificatie. (zie
hoofdstuk 5.)
83
CT1061
9.3
Model van het bestuurd systeem
9.3.1
Model-Systeem typologie
Voor de besturing van de ontwikkeling van systemen is het - zoals we de

vorige paragraaf hebben gezien - lastig om het werkelijk gedrag van het
systeem te vergelijken met het gewenste gedrag van het systeem. Dat kan
alleen met behulp van een model. Een dergelijk model beschrijft en voorspelt
het totale gedrag van het systeem en moet derhalve niet worden verward met
statische mechanica en materiaalmodellen van elementen en componenten
van het systeem (zie hoofdstuk 5).
Voor het maken van goed bruikbare besturingsmodellen is het noodzakelijk
een goed inzicht te hebben in model-systeem typologie [10].
Voor wat betreft de beschrijving van systemen worden er drie categorien
onderscheiden:
6. Concrete systemen, gedefinieerd als een geheel van concrete of empirische
entiteiten met onderlinge relaties.
7. Conceptuele systemen, gedefinieerd als een geheel van begrippen met
behulp waarvan de empirische werkelijke situatie is geclassificeerd en
beschreven.
8. Formele systemen, gedefinieerd als een vorm van een taal die symbolen
gebruikt waarmee de bovengenoemde begrippen worden beschreven.
Het is nuttig om op grond van deze categorien drie soorten entiteiten te
onderscheiden:
9. Concrete entiteiten, die corresponderen met dingen
10. Conceptuele entiteiten, die corresponderen met begrippen
11. Formele entiteiten, die corresponderen met symbolen
Omdat een model kan worden beschouwd als een systeem met een zeker
isomorfisme met een ander systeem, kunnen er ook drie soorten modellen
worden onderscheiden:
12. Concrete of empirische modellen
13. Conceptuele modellen
14. Formele modellen
Op grond hiervan kunnen negen model - systeemparen worden onderscheiden
die in het kort met een voorbeeld worden beschreven (zie tabel 9.1).
84
CT3061
Tabel 9.1: De verschillende model - systeemparen
Modellen
Concreet model van een concreet
systeem
Concreet model van een conceptueel
systeem
Concreet model van een formeel
systeem
Conceptueel model van een concreet

systeem
Conceptueel
model
van
een
conceptueel systeem
Conceptueel model van een formeel
systeem
Formeel model van een concreet
systeem
Formeel model van een conceptueel
systeem
Formeel model van een formeel
systeem
Voorbeeld
Het gedrag van staal onder trek
De piramide van Cheops as een
toepassing van de stereometrische
figuur piramide
Een temperatuurschaal als een
toepassing
van
de
formele
getallentheorie
Een relatiediagram als een model van
alle interrelaties tussen de elementen
van een systeem
De algebrasche representatie van
een cirkel
Een taalsysteem van de formele
logica
Een mathematisch model van een
economisch proces
De Euclidische ruimte
De vertaling van een formeel systeem
naar een ander
Op grond van de tabel kan worden vastgesteld dat voor een besturingsmodel
voor de ontwikkeling van civieltechnische systemen een tweetal model
systeem paren in aanmerking komen:
Een conceptueel model van een concreet systeem om het totale

systeemgedrag mee te beschrijven.
Een formeel model van een concreet systeem om het bovengenoemde
conceptueel model te ondersteunen en te vullen.
9.3.2
Functie van modellen
Zoals gezegd gaat het hierom een besturingsmodel. De functie is dus

besturen. Vanuit de modeltheorie worden voor wat betreft functies drie
soorten modellen onderscheiden:
Denkmodellen, die worden gebruikt om de perceptie van feiten en de
uitkomsten van experimenten te beheersen en te sturen. Er zijn drie sub
functies: (1) verkenning en heuristiek, (2) beschrijving en reductie, (3)
verklaring.
Operationele modellen, die worden gebruikt als gereedschap voor het
uitvoeren van operaties. De functie van operationele modellen zijn: (1) het
bewerken van feiten en materiaal en (2) formaliseren van onderzoek.
Overbruggingsmodellen, die worden gebruikt voor het toepassen van
abstracte theorien. Deze modellen overbruggen het gat tussen de theorie
en de empirische wereld en worden gebruikt om het gedrag van systemen
te simuleren.
85
CT1061
Gesteld kan worden dat voor het beheersen van ontwikkelingsopgave de

overbruggingsmodellen centraal staan die worden ondersteund door
operationele modellen
9.3.3
Typen modellen
In zijn algemeenheid onderscheiden we de volgende typen modellen:
Schaalmodellen, waarbij de relaties binnen het systeem instant blijven. Er

zijn schaalwetten en schaaleffecten bij het modelleren. Schaalmodellen
worden toegepast voor het begrijpen en verkennen van voornamelijk
concrete systemen.
Analogiemodellen, die zodanig worden ingericht dat het medium veranderd
is maar de structuur van het systeem hetzelfde blijft. De analogie verzekert
hier de isomorfie. Een speciale familie van analogiemodellen is de
verzameling cybernetische modellen. Deze modellen zijn gebaseerd op een
informatieprocessing medium. De operaties zijn isomorf, het gedrag is
analoog en de dynamische relatie is simulatie. Een andere familie is de
verzameling bionische modellen die de kennis van levende organismen
gebruikt voor de analyse en realisatie van systemen.
Ideaalmodellen, die zijn onderverdeeld in twee hoofdsoorten: (1) de
theoretische ideale modellen, die meestal betrekking hebben op gedachteexperimenten, reconstructies en hypothesen en (2) empirische
ideaalmodellen die meestal gesimplificeerde prototypes zijn. Het
belangrijkste principe is een gedealiseerde begrenzing. Een speciaal
ideaalmodel is de Black Box die tussen een open en gesloten systeem
instaat. Het open systeem is gemodelleerd door een gesloten systeem met
gesimplificeerde relaties met de omgeving (alleen input/output).
Structuurmodellen, die een kwalitatief beeld geven van de werkelijkheid
(bijvoorbeeld een uitvoeringsschema of een plattegrond). Een belangrijke
familie van structuurmodellen is de verzameling stroomdiagrammen, die
kunnen worden beschouwd als een hirarchisch schema van Black Box
modellen.
Mathematische modellen, die een theoretische afbeelding zijn van de
werkelijkheid.
De modellen die gebruikt worden voor het sturen van een

ontwikkelingsopgave
zijn
een
mengvorm
van
ideaalmodellen,
structuurmodellen en mathematische modellen.
9.3.4
Het maken van modellen
Voor wat betreft het maken van modellen dient het volgende in het oog te
worden gehouden:
86
De isomorfie tussen model en werkelijkheid dient altijd te worden

aangetoond. Het gaat dan voornamelijk over de geldigheid. In de praktijk
gaat op dit punt vaak wat mis.
Model en werkelijkheid dienen niet met elkaar te worden gedentificeerd.
Streef niet al te precieze modellen na in een vroege fase. Een snel overall
CT3061
inzicht is belangrijker dan of het model geheel en al geldig is. In het begin
van een project worden de belangrijkste beslissingen genomen.
Factoren die in een beginfase niet in het model worden meegenomen
dienen later wel te worden onderzocht. Meestal is dat een
gevoeligheidsonderzoek.
Een beperkt model heeft zowel voor- als nadelen. Een goed ingenieur is in
staat om een juist model te maken.
Modellen zijn nuttig maar mogen nooit direct worden gebruikt voor
beslissingen.
9.4
Besturingsvariteit
9.4.1
Algemeen
In vervolg op de doelsturing zoals behandeld in paragraaf 9.2 formule 9.1, kan

worden gesteld dat er verschillende stuurmogelijkheden zijn bij tegenvallende
productie. Deze mogelijkheden komen in de volgende paragrafen aan de orde.
9.4.2
Geen extra input
In dit specifieke geval zijn er twee stuurmogelijkheden beschikbaar om toch

tot een bevredigend resultaat te komen:
De eerste is het accepteren van een minder dan 100% oplossing. Eigenlijk is
dit een aanpassing van het doel. Dat mag beperkt omdat doelen:
Veranderen als functie van de tijd door veranderende omstandigheden
Nooit compleet zijn
Nooit expliciet zijn
De tweede stuurmogelijkheid komt te voorschijn bij het herschikken van het
rechterlid van vergelijking 9.1:
Prod = KO/PO x P/K
Te zien valt dat bij constante KO en PO de waarde van P/K dient te worden
verhoogd.
9.4.3
Geen reductie van de prestatie
In dit specifieke geval zijn er eveneens twee sturingsmogelijkheden

beschikbaar om het resultaat te accepteren:
De eerste is een verhoging van de waarde van P/K
De tweede is een extra input (K>KO)
9.4.4
Geen afwijking van het initile doel
In dit specifieke geval kan alleen worden besloten tot het verhogen van de
waarde van P/K.
87
CT1061
88
CT3061
10 Informatie
10.1 Algemeen
Sturen zonder informatie is onmogelijk. Informatie is essentieel. Er zijn echter
verschillende soorten informatie. Wie kent niet het onderscheid tussen
relevante en niet relevante informatie: het signaal en de ruis? In een ontwerpen uitvoeringsproces, en zeker in een samenwerkingsverband daarin, is
informatie zeer belangrijk. In dit hoofdstuk wordt ingegaan op een aantal
aspecten van informatie en informatie-uitwisseling.
10.2 Informatie en beslissen

Sturen is zoals gezegd in hoofdstuk 9 een vorm van gerichte benvloeding.
Benvloeding kan eigenlijk alleen als er beslissingen worden genomen. Voor
het nemen van beslissingen is informatie nodig. Beslissingen zijn noodzakelijk
om stappen te kunnen zetten in een ontwerp, het uitvoeringsproces en het
exploitatieproces. Een beslissing komt eigenlijk neer op een keuze uit
alternatieven. In de praktijk volstaat dit echter niet, omdat met een dergelijke
simpele voorstelling van zaken erg vaak verkeerde beslissingen genomen
zullen worden. Een beslissing kent daarom de volgende componenten:
Een keuze tussen alternatieven
Het trekken van de juiste conclusies uit vooronderstellingen
Een leerproces van zoeken, ontwikkeling en evaluatie
Een afspraak voor implementatie
Hoe zit het met de informatie rondom dit beslissen? Het klassieke
beslissingsmodel gaat uit van de homo economicus. Deze homo economicus:
Heeft de complete informatie rondom de beslissituatie
Kent alle alternatieven
Kent de situatie waarin hij zit
Weet precies welk voordeel elk alternatief geeft
Streeft naar maximalisatie van het voordeel
De werkelijkheid ziet er anders uit. Omdat de informatieverwerking in een
probleemoplossing proces tekort schiet geldt dat de beslisser:
Niet alle informatie heeft aangaande de beslissituatie
Niet alle alternatieven kent
Niet alle effecten van de alternatieven kent
Niet weet welk effect elk alternatief heeft
Niet in staat is een optimale beslissing te nemen, hooguit een bevredigende
10.3 Onzekerheid van informatie

Rondom het beslissingsproces zijn er onzekerheden. Voordat bepaald wordt
hoe daarmee omgegaan wordt, is het verstandig om de onzekerheid rond
89
CT1061
informatie te classificeren. De meeste literatuur onderscheidt drie soorten

onzekerheid:
Zekerheid. Dit is een bijzonder geval van onzekerheid, namelijk geen
onzekerheid. In dit geval is precies bekend wat er gaat komen, gerekend
binnen onze menselijke maat. Bijvoorbeeld de zon komt elke dag op en na
iedere zomer breekt een herfst aan.
Conditionele onzekerheid. In dit geval is bekend wat er verwacht kan
worden maar niet wat er werkelijk komt. Dit soort onzekerheid is meestal
voorzien van kansverdeling functies. In feite worden met kansverdeling
functies de onzekerheden weer zeker gemaakt.
Echte onzekerheid. In dit geval weet men niet of iets wel of niet gebeurt,
laat staan wat men krijgt. Het is onbekend. In feite weet men zelfs niets
van mogelijke gebeurtenissen.
In de ontwerper wereld komt men wel eens het begrip perceptionele
onzekerheid tegen. In dit geval had men kunnen weten wat er verwacht kan
worden, maar weet men het niet. Perceptionele onzekerheid ontstaat door
onderschatting, die wordt veroorzaakt doordat men op een bepaalde manier
tegen de zaak aankijkt. Ook hier zijn het weer de toegebonden,
persoonsgebonden en mode gebonden beperkingen die de onzekerheid
vergroten.
Er wordt in de praktijk van het beslissen verschillend omgegaan met deze
soorten onzekerheden:
De beslisser onder zekerheid kiest het alternatief c.q. neemt die actie die
hem maximaal voordeel geeft. Het bijbehorend gereedschap is operations
research. Het is in dit geval vrij eenvoudig om optimale oplossingen te
vinden.
De beslisser onder conditionele onzekerheid heeft het ook niet al te
moeilijk. Hij kiest voor die actie die hem maximaal verwacht voordeel geeft.
Dat laatste is eenvoudig te bepalen omdat de diverse kansverdelingen
zowel beschikbaar als getoetst zijn.
De beslisser onder perceptionele onzekerheid heeft het lastiger. Hij kan niet
optimaliseren op verwacht voordeel omdat er twijfel is over de interpretatie
van het materiaal, over het gehanteerde model en over het doel die de
beslissituatie beheerst. Naast het verwachte voordeel dient de beslisser ook
gevoeligheidsonderzoek te doen naar de perceptionele onvolkomenheden.
De beslisser onder onzekerheid heeft het moeilijkst. Er is bijna niets bekend
over de beslissituatie, terwijl er wel een beslissing dient te worden
genomen. Vaak wordt dan gebruik gemaakt van scenario denken. Een van
de meest gebruikte regels daarbij is de minimaxregel. Daarbij zijn twee
benaderingen te onderscheiden: In de pessimistische minimax kiest de
beslisser die actie die hem maximaal voordeel geeft in het slechtste
scenario. In de optimistische minimax kiest de beslisser die actie die hem
maximaal voordeel geeft in het meest optimistisch scenario.
Belangrijk is het om deze verschillende vormen als zodanig te herkennen. Een
van de ergste dingen die kunnen gebeuren is dat er gegoocheld wordt met
cijfers die nergens op slaan. Zo zie je vaak bij de kwantitatieve risicoanalyse
dat kansverdelingen voor het optreden van gebeurtenissen worden gegeven
die nergens op gebaseerd zijn. Maar met deze kansverdelingen worden dan
90
CT3061
wel zeer precieze berekeningen gemaakt die rechtstreeks worden gebruikt

voor beslissingen!
Als er niets bekend is kun je beter je toevlucht nemen tot de kwalitatieve
risicoanalyse. De uitkomsten daarvan zijn redelijk zacht, doch het voordeel is
dat je (en vooral anderen) het we(e)t(en) en dat aldus de kwaliteit van de
ondersteuning van de uiteindelijke beslissing bekend is.
In hoofdstuk 12 wordt ingegaan op drie vormen van risicomanagement die
gerelateerd zijn aan de verschillende onzekerheid classificaties van informatie.
10.4 Distribueren en ophalen van informatie
10.4.1 Algemeen
Voor sturing is het nodig om top down informatie te distribueren vanaf de
bestuurder en bottom-up informatie op te halen vanaf het bestuurd systeem.
Deze informatie is niet direct. Dat is in te zien met figuur 10.1, waarin de
bestuurder direct zou zijn verbonden met de werkers aan de kleinste
elementen.
Figuur 10.1: De mogelijke directe informatie-uitwisseling tussen bestuurder en

elementwerkers
Er zijn twee belangrijke tussenstations. Het eerste tussenstation is de staf van

de projectmanager, die de aspectsystemen (cordinatie) voor haar rekening
neemt. Het tweede tussenstation zijn de clusterleiders van de subsystemen.
Beide tussenstations worden hieronder apart besproken.
10.4.2 Informatievoorziening van de aspectsystemen
Zoals bekend verzorgen de gezamenlijke aspectsystemen de cordinatie van
de ontwerpopgave. Naar boven krijgt de projectleider gecomprimeerde
informatie over het actuele gedrag van het systeem waarmee hij beslissingen
kan nemen. Naar beneden dient het gewenste gedrag naar de clusterleiders te
worden gestuurd en het actuele gedrag te worden opgehaald.
91
CT1061
Distributie gewenst gedrag

Zoals reeds behandeld, wordt het gewenste gedrag qua informatie bepaald
door de oplossingsruimte en het aantal wensen op de verschillende waarde
assen.
Dit betekent dat de oplossingsruimte voor al het personeel eenduidig en
zonder ruis beschikbaar moet zijn. Dat geldt voor wat betreft de waarde voor:
De randvoorwaarden. Naast vergunningen en harde begrenzingen zijn hier
de natuurrandvoorwaarden, zoals de frequentieverdelingen van wind,
regen, sneeuw, golf, getij, stroom, temperatuur, vochtigheid, mist etc. het
belangrijkst. Het gaat ook om de kansverdelingen van gecombineerd
voorkomen met de daarbij behorende correlatiefuncties.
De eisen en de uitgangspunten.
De kosten. Hierbij geldt het voor het contant maken van de drie
kostenbestanddelen. Het gaat om het prijspeil op het tijdstip dat wordt
gekozen voor het contant maken van de budgeten
Ophalen actuele gedrag
Het ophalen van het actuele gedrag van de sub systemen uit de clusters is van
groot belang, omdat de projectleider dan in staat is het totale systeemgedrag
te bepalen. Er zijn twee zaken van belang:
Het gedrag van de subsystemen dient netto naar boven te worden
doorgegeven. Dat betekent dat het gedrag vrij moet zijn van reserves,
toeslagen, veiligheden etc.. Dit is van belang omdat deze zaken
verschillend liggen per discipline en er geaggregeerd dient te worden
Het gedrag van de sub systemen dient voorzien te zijn van een
gevoeligheidsonderzoek. Dit gevoeligheidsonderzoek dient betrekking te
hebben op de waarde-kostenverhouding van het subsysteem. Met dergelijk
informatie is de projectleider in staat om de juiste keuzes te maken als het
totale systeemgedrag niet aan de verwachtingen voldoet. Het kan
bijvoorbeeld zijn dat de totale sterkte van het systeem goedkoper kan
worden geregeld door een bepaald subsysteem.
10.4.3 Informatievoorziening van de clusters (subsystemen)
Binnen de clusters hebben we drie soorten informatiestromen:
De top down, op het uitoefenen van de gewenste invloed gerichte,

informatie van het clusterhoofd naar de elementen;
De bottom-up gerichte actuele informatie van de staat van de elementen

aan het clusterhoofd.;
De horizontale informatie uitwisseling tussen de elementen onderling.

Deze informatiestromen zijn geschetst in figuur 10.2.
92
CT3061
Figuur 10.2: Informatiestroom binnen het cluster
10.5 Verwerken van informatie

Voor het beheersbaar houden van een project is het essentieel dat er genoeg,
maar niet te veel informatie is. In dit licht is de wet van Conant nog steeds
actueel:
F = Fd +Fb + Fc + Fr
Met
F = de totale informatiecapaciteit
Fd = informatie die daadwerkelijk doorstroomt teneinde het proces te
doorlopen
Fb = informatieblokkering
Fc = informatie nodig voor cordinatie
Fr = ruis (overbodige informatie)
Ad Fd
Uiteraard is Fd de informatiecomponent waar het feitelijk om draait. Dit is te
beschouwen als de netto benodigde informatie.
Ad Fb
Voor wat betreft de blokkering is er onderscheid te maken in opzettelijke en
onopzettelijke blokkering. Opzettelijk blokkering treedt op als er grote
onderlinge competitie is. Onopzettelijke blokkering treedt op als men
overbelast is.
Ad Fc
De informatie benodigd voor cordinatie is groot als er sprake is van grote
complexe systemen en er in geval veel mensen bij het project zijn betrokken.
93
CT1061
Ad Fr
Dit soort informatie komt van minder competente medewerkers.
Vaak is het zo dat, als men geconfronteerd wordt met grote waarden voor Fb,
Fc en Fr, men het besluit neemt om de totale informatieverwerkingscapaciteit
te vergroten. Dat kan door meer mensen, meer faxen en meer computers in
het project te stoppen. Duidelijk zal zijn dat dit niet in alle gevallen handig is.
Immers, het is zeker te verwachten dat met dergelijke maatregelen Fc en Fb
ook zullen toenemen. Hier is dan sprake van verminderde meeropbrengst.
Veel effectiever is het om de totale informatieverwerkingscapaciteit te
reduceren door vooral de complexiteit te reduceren. Dat kan door een slimme
decompositie.
10.6 Informatie en communicatie

Communicatie wordt wel de belangrijkste kostenfactor genoemd in het
projectmanagement. Vreemd is dat in de communicatie veel mis gaat. Bij
communicatie laat iemand aan iemand anders iets weten. Er zijn zenders en
ontvangers. Datgene wat medegedeeld wordt is een uiting. Dikwijls heeft een
uiting meer dan n betekenis. Je zou ook kunnen zeggen dat er meerdere
boodschappen in een uiting kunnen zitten. Dat kan bedoeld en onbedoeld zijn.
Een aardig voorbeeld is de vraag: Hoeveel ambtenaren werken er in dit
gebouw?.
Hier kunnen vijf verschillende vragen achter zitten, die duidelijk kunnen
worden gemaakt door de klemtoon:
Klemtoon op hoeveel wil zeggen dat de belangstelling uitgaat naar het
aantal.
Klemtoon op ambtenaren veronderstelt ook een ander soort werkers.
Klemtoon op werken veronderstelt dat er ambtenaren zijn die niet
werken.
Klemtoon op dit veronderstelt ook een ander gebouw in de nabijheid
waarin ambtenaren werken.
Klemtoon op gebouw veronderstelt dat er ook ambtenaren buiten
werken.
Er zijn in het algemeen vier soorten boodschappen:
De referentiele boodschap; deze uiting verwijst naar bepaalde feiten,
verschijnselen of gebeurtenissen.
De expressionele boodschap; deze uiting geeft een beeld van de zender,
van zijn persoon, gevoelens, opvattingen, normen en waarden.
Relationele boodschappen; de uiting schept, bestendigt of verandert de
relatie tussen zender en ontvanger.
Appellerende boodschap; deze uiting doet een beroep op de ontvanger om
iets te doen of te laten.
Duidelijk is dat in een samenwerkingsverband alle vier soorten uitgebreid aan
bod komen. De kunst is deze boodschappen ook gescheiden en zakelijk over
94
CT3061
te brengen. Referentiele boodschappen geven aan wat er speelt en wat er

voorhanden is. Het is meestal een probleemstelling. Expressionele
boodschappen gaan over wat de zender wil. Hierin geven waard vragers en
waard gevers aan wat ze eigenlijk willen en waarom.
Relationele boodschappen geven aan wat de intenties zijn ten aanzien van de
samenwerking.
Dat
gaat
over
rollen,
taken,
bevoegdheden,
verantwoordelijkheden, contracten.
Appellerende boodschappen geven aan hoe de ene partij wil dat de andere
partij op bepaalde actuele gebeurtenissen reageert. Dit is meestal het geval bij
veranderingen (ontwerpwerk).
Tot slot worden nog de vijf voorwaarden
communicatie:
Het moet zakelijk zijn
Er moet aandacht zijn
De boodschap moet helder zijn
Degene die zendt moet geloofwaardig zijn
Er moet een goede timing zijn
In
gegeven
voor
effectieve
de praktijk wordt lang niet altijd aan deze voorwaarden voldaan:

Wat bedoeld is, is nog niet gezegd (zakelijk)
Wat gezegd is, is nog niet gehoord (aandacht)
Wat gehoord is, is nog niet begrepen (helder)
Wat begrepen is, is nog niet akkoord (geloofwaardig)
Wat akkoord is, is nog niet gedaan (timing)
Juist in samenwerkingsverbanden is niet alleen de interne communicatie,

zowel bij waard vragers als waard gevers, van belang, maar vooral ook de
communicatie tussen de samenwerkende partijen. Onderscheid naar het doel
van de communicatieschakel daarbij is als volgt mogelijk:
Unilateraal (informatie stroomt maar in n richting)
Bilateraal-routine (informatie in twee richtingen over routine zaken)
Bilateraal-dialoog (discussie over nog niet vaststaande zaken)
10.7 Relaties, informatievoorziening en sturing

Het zal duidelijk zijn dat het onderhouden van relaties, tijdens het
ontwerpwerk, met delen van een geheel een kwestie is van informatieuitwisseling. Hoe beter en geconcentreerder zender, boodschapper en
ontvanger bezig, zijn des te beter het resultaat van het ontwerpwerk zal zijn.
Het is van belang om de verschillende soorten van informatie-uitwisseling te
bespreken. Dat geschiedt aan de hand van figuur 7.1.
Uitgangspunt is dat er een voorontwerp op systeemniveau is en dat de
functies van de elementen vastliggen.
95
CT1061
Figuur 10.3: Decompositiediagram
Werken aan het element

Op het laagste werkniveau wordt er gewerkt aan de vorm van de elementen.
Dat gebeurt simultaan. Vorm betekent: plaats, orintatie, dimensies en
materiaal. De relaties met de andere elementen beperken zich uitsluitend tot
de elementen binnen het cluster. De relaties met andere elementen worden
als korte termijnrandvoorwaarden beschouwd.
De elementleider is verantwoordelijk voor het gedrag van zijn element. Dit
gedrag is meervoudig en heeft betrekking op meerdere aspecten, bijv. op de
technische, financile (waarde-kosten), sociaal-maatschappelijke. Het
technische gedrag wordt bepaald door twee zaken:
De belasting in de breedste zin van het woord op het element (krachten,
momenten, impuls, druk, straling, temperatuur)
De weerstand in de breedste zin van het woord (capaciteit, sterkte,
stijfheid, stabiliteit, gewicht, geometrie, onderhoud)
Het gedrag wordt gekwalificeerd met kwalificaties als betrouwbaar,
beschikbaar, veilig, en bereikbaar. Het gedrag wordt gekwantificeerd met
zaken als benodigde onderhoudsschemas, faalkansen en veiligheidsfactoren.
Het is de taak van de elementleider zowel de belasting, de weerstand als het
gedrag voortdurend in kaart te brengen. Dat gedrag wordt bepaald door
middel van vormgeving. Bij het vormgevingsproces wordt continu rekening
gehouden met de collegas van de andere elementen binnen de cluster. In
feite wordt er door de elementleider met interne routine en externe routine
gestuurd, waarbij de elementen binnen het cluster als de omgeving worden
beschouwd. Bij externe routine sturing wordt er tijdens het ontwerp sterker
met elkaar rekening gehouden en beter van elkaar gebruik gemaakt.
Wekelijks worden door iedere elementleider de drie belangrijkste zaken
(belasting, weerstand en gedrag) aan de clusterleider gerapporteerd waarbij
ook een schatting van de totale kosten (realisatie en exploitatie) wordt
gegeven. Voorts wordt een indicatie gegeven van de marginale meerkosten
96
CT3061
van gedragstoename. Uiteraard gaat al deze informatie gepaard met een

overzicht van wat zeker is en wat onzeker is.
Van groot belang is dat er niet in een belastingpunt wordt gewerkt, noch dat
er een enkelvoudige weerstand wordt gegeven. Er moet bij iedereen het
besef leven dat er in een veranderende omgeving wordt gewerkt, waar bijna
niets zeker is. Er moeten dus altijd bandbreedten en gevoeligheden worden
onderzocht.
Werken aan het cluster
Zoals bekend, zal het zo zijn dat er verschillende componenten (subsystemen
met een functie) deel uitmaken van een cluster (subsysteem). De clusterleider
weet dat de onderlinge relaties tussen de elementen binnen een cluster zijn
gehonoreerd en dat hij/zij daar niet naar hoeft te kijken. Wat wel gedaan moet
worden is op basis van de belasting, de weerstand en het gedrag van de
elementen de belasting, de weerstand en het gedrag van de componenten
bepalen. Vervolgens wordt hetzelfde gedaan indien mogelijk- voor het
cluster.
De clusterleider checkt of het gedrag overeenkomt met het geiste gedrag
(Pcluster = Po cluster). Indien dat niet het geval is wordt binnen het cluster
gekeken of er geschoven kan worden.
De twee stuurmogelijkheden binnen het cluster zijn:
Interne routine, waarbij vooral gekeken wordt naar verbetering van het
gedrag van de individuele elementen. Hierbij bepaalt de clusterleider,
mede aan de hand van de marginale meerkosten van gedragstoename,
welk element het gedrag moet aanpassen en welk element niet. Een deel
van deze sturing is ook dat er nog eens kritisch naar de belastingen wordt
gekeken, en dan met name naar de belastingcombinaties.
Intern adaptief, waarbij vooral gekeken wordt naar een betere structuur
tussen de elementen. In feite wordt gekeken naar een betere synergie
van elementen.
Binnen de clusters kan enige tijd autonoom worden gewerkt. Binnen een
bepaalde periode dienen de clusterleiders de belasting, de weerstand en het
gedrag van het cluster te rapporteren aan de projectleider. De duur van deze
periode is afhankelijk van de complexheid en de gevoeligheid van het systeem
op allerlei externe invloeden.
Uiteraard wordt in de rapportage onderscheid gemaakt tussen datgene wat
zeker is en datgene wat onzeker is.
Werken aan het systeem
Op systeemniveau wordt er gewerkt met aspectsystemen. De aspectsystemen
geven de weerstand van het systeem. De aspectsystemen worden
gekwantificeerd, dat wil zeggen dat ze n of meerdere dimensies hebben met
een waarde. Het is de bedoeling dat, naast de waarde van de aspectsystemen,
ook de marginale meerkosten voor een toename van de waarde van een
aspect worden gegeven. Alle clusters dienen deze informatie aan het centrale
niveau door te geven met de hierboven reeds besproken frequentie.
Op systeemniveau dient er een model te zijn (meestal een mathematisch
model) dat met al deze aspectsystemen wordt gevoed. Daarnaast wordt het
97
CT1061
systeem gevoed met de belasting en de kosten op systeemniveau. Het is de

taak van de projectmanager om de informatie van de clusters op een correcte
wijze in het systeemmodel te krijgen. Vervolgens wordt er gecheckt of de
normprestatie en de normkosten worden gehaald.
Indien dit het geval is wordt er niet gestuurd. Indien dit niet het geval is, wat
meestal geschiedt, wordt eerst bekeken welke aspectsystemen slecht scoren.
Vervolgens wordt bekeken welke clusters de laagste marginale meerkosten
hebben voor de slecht scorende aspectsystemen. Tenslotte wordt beslist welke
clusters in welke mate moeten bijdragen aan een verbetering van de
totaalprestatie.
Naast deze actieve sturing heeft de projectmanager ook nog een andere
belangrijke functie. Hij/zij draagt namelijk zorg voor de interactie van het
systeem met de omgeving. Dat geldt natuurlijk in zeer sterke mate voor de
belasting op, maar ook voor de weerstand en het gedrag van het systeem.
Vanwege deze functie is het altijd raadzaam om de belastingen risicoanalyse
altijd op centraal niveau (projectmanager) te houden.
Een derde belangrijke functie van de projectmanager, ten aanzien van
informatie en communicatie in een complex project, is projectgebonden
onderzoek. Dit betreft vaak mathematische en schaalmodellen die voor de
ondersteuning van het ontwerpwerk worden gebruikt. Van groot belang is dat
zoiets centraal gecordineerd wordt. Dit betekent dat modelonderzoek wel
vanuit de elementen en clusters genitieerd wordt, maar centraal in de
projectorganisatie op elkaar wordt afgestemd. Dit gebeurt om dubbel werk te
voorkomen.
98
CT3061
11 Organisatie
11.1 Algemeen
In de professionele wereld kunnen er twee soorten mensen worden
onderscheiden (zie figuur 11.1). Dit gebeurt ruwweg op grond van twee
variabelen, te weten de breedte van de kennis en de diepte ven de kennis.
Figuur 11.1: Verdeling mensen in professionele wereld
De eerste soort bestaat uit generalisten, die weinig weten van veel. De tweede
soort bestaat uit specialisten die veel weten van weinig. De eerste soort kom
je in het ontwerpwerk van complexe systemen soms tegen maar nooit lang. Zij
worden in eerste instantie aangesteld voor de cordinatie, doch verliezen vrij
snel aan geloofwaardigheid doordat zij niet ter zake kundig zijn en doordat ze
niet met de specialisten kunnen communiceren. Vaak zien we dan ook dat
specialisten in de leiding van het ontwerpwerk van complexe systemen
belanden. Ook dat gaat niet goed omdat zij zich meestal alleen op hun
specialisatie concentreren en vaak de hoofdzaken niet van bijzaken kunnen
onderscheiden. De cordinatie blijft qua manbezetting en het te eisen profiel
een probleem. Wat meestal geen probleem is, is het werk op de werkvloer, de
disciplinaire inbreng. In dit hoofdstuk wordt nader ingegaan op deze
problematiek en oplossingen daarvoor aangedragen. Het gaat dan over
structuur en cultuur van organisaties en de manier waarop mensen optimaal
ingezet kunnen worden met betrekking toto de totale opgave.
11.2 Organisatiestructuur
De meeste literatuur over organisaties heeft betrekking op bedrijven of
organen waarin veel mensen werken. Mintzberg [11] onderscheidt vijf
onderdelen van een organisatie (zie figuur 11.2).
99
CT1061
Figuur 11.2: Vijf onderdelen van een organisatie
1.
2.
3.
4.
5.
De uitvoerende kern
De strategische top
Het middenkader
De technostructuur
De ondersteunende diensten
Het aardige is dat in een zeker opzicht deze vijf onderdelen ook voor een
projectorganisatie kunnen worden onderscheiden
De uitvoerende kern bestaat uit mensen die het basis werk doen. Dit zijn
eigenlijk de werkers.
De strategische top in een project gaat over de projectdoelen en zorgt
ervoor dat de gehele organisatie zodanig wordt ingericht en bestuurd dat
de kans op het halen van die doelen zo groot mogelijk is.
Het middenkader dicht het gat tussen de strategische top en de werkers.
De technostructuur gaat over standaardisering. Dit zijn de accountants, de
bedrijfskundigen en kwaliteitcontroleurs. In de huidige Nederlandse
bouwwereld worden dit ook ten onrechte Systems engineers genoemd.
De ondersteunende diensten, die zorg dragen voor de administratie,
vergunningen, juridische zaken, onderzoek, ontwikkeling.
11.3 De technische disciplines in de Civiele techniek

In tegenstelling tot wat velen denken zijn er bij civieltechnische systemen vaak
veel verschillende technische disciplines nodig om het werk tot een goed einde
te brengen. Te noemen zijn:
Betonconstructies
Staalconstructies
Grondmechanica
Grondwatermechanica
Funderingstechniek
Baggertechniek en grondverzet
100
CT3061
Natte waterbouw
Droge waterbouw
Wegenbouw
Spoorwegbouw
Gezondheidstechniek
Elektrotechniek
Werktuigbouwkunde
Constructietechniek
Veiligheidskunde
Verwarmingstechniek
Bouwfysica
Daarboven komen de technische disciplines die zich met de cordinatie

bezighouden. Dat zijn:
Veiligheidskunde
Financial engineering
Planningstechniek
Ontwerpen
Inkopen
Daarbovenop komen nog de voor civiele techniek onontbeerlijke, niet
technische disciplines zoals:
Rechten
Bestuurskunde (openbare lichamen)
(Kwaliteits)management
Milieukunde
Geologie
Oceanografie
Meteorologie
Landmeetkunde
De bovengenoemde technische disciplines worden ingezet op werkvloerniveau.
Dit is logisch omdat daar het eigenlijke werk plaatsvindt. De mankracht is
uiteraard niet uniform verdeeld over de disciplines. Voor een groot betonwerk
zullen er veel betonconstructeurs worden ingezet en misschien een
staalconstructeur. Wat echter nooit voorkomt is dat een project volledig
monodisciplinair is, zoals alleen beton of staal.
11.4 De disjunctie van element en discipline

Een element is de kleinste relevante systeemeenheid en kan in die context
worden voorzien van een doel, een functie en uiteindelijk een vorm. Een
element is dus een stoffelijk ding. Dat is zeker niet het geval met een
discipline. Die heeft geen doel, geen functie, laat staan een vorm. Element en
discipline vallen dus niet samen. Omdat de uiteindelijk output van het
ontwerpwerk een systeem met componenten en elementen is staat het werk
aan elementen centraal. Het werk aan de elementen is de kleinste
werkeenheid die hirarchisch bijdraagt tot het gehele systeem.
101
CT1061
Voor de totstandkoming van een element zijn er in het algemeen meerdere

disciplines nodig. Neem bijvoorbeeld een kantine in een dierentuin. De
dierentuin is het systeem. Het voorzieningengebouw is een component en de
kantine is een element. Voor het ontwerp van die kantine is er niet alleen een
funderingsexpert
nodig
maar
ook
een
bouwkundige,
een
verwarmingsspecialist, een zonweringspecialist, een keukenspecialist, etc.
Voor de ontwikkeling van een element is er altijd een dominante discipline
nodig. Het is zonder meer handig om de vertegenwoordiger van die dominante
discipline de verantwoordelijke man/vrouw te maken. De andere disciplines
komen daaronder in de hirarchie. Het komt vaak voor dat voor een aantal
elementen slechts weinig inzet nodig is van een bepaalde discipline. Het is dan
niet raadzaam om de disciplinaire inbreng door een aantal mensen te laten
verzorgen die ieder een minimale bijdrage hebben. Het is veel beter om dan
de zeer speciale disciplinaire werkers aan verschillende elementen te laten
werken. Dit geeft in principe problemen. Immers de elementleider met de
sterkste persoonlijkheid slaagt er het meest in om deze werkers te binden. Het
is zaak dat de inzet van de multi-elementwerkers op een hoger chelon wordt
geregeld. Dat is in eerste instantie een taak voor de clusterleider, indien het
werk aan verschillende elementen binnen de cluster valt. In zon geval komt er
in de cluster een groep met specialisten te werken die op meerdere elementen
kunnen worden ingezet. Dit is geschetst in figuur 11.3.
Figuur 11.3: Werken in clusters
Een probleem ontstaat als de disciplinaire werkers aan elementen moeten

werken die in verschillende clusters vallen. Ook kunnen er geschillen ontstaan
over de inzet van de disciplinaire werkers. Voor grote complexe systemen
wordt disciplinaire inzet via een matrixorganisatiestructuur geregeld.
11.5 Intra-, mono-, inter-, multi en extradisciplinair

werken
Met het beschrijven van de disciplinaire inbreng is de decompositie van de
ontwerpopgave voltooid en kunnen de verschillende werkzaamheden op de
verschillende niveaus worden beschreven ten aanzien van het omgaan met de
102
CT3061
disciplines. De basis vormt het volledige decompositiediagram zoals geschetst

in figuur 11.4.
Figuur 11.4: Decompositiediagram
De mensen die daadwerkelijk hun bijdrage leveren aan de elementen zijn zelf
mono-disciplinair of ook wel intradisciplinair bezig.
Het werk aan een element vindt in principe multidisciplinair plaats, met
meestal een monodisciplinaire dominantie. Het wordt interdisciplinair
gecordineerd door de leider van het werk aan een element.
Het werk aan verschillende elementen vindt op korte termijn plaats binnen een
cluster.
Het werk binnen het cluster is multi-disciplinair en er wordt interdisciplinair
gecordineerd. Daarboven is er sprake van structurele cordinatie, die
gekenmerkt wordt door het in de gaten houden van de relaties tussen de
elementen onderling.
Het werk aan het systeem wordt extra-disciplinair gecordineerd. Dat betekent
dat op het niveau van de aspectsystemen de disciplines er niet meer toe doen.
Het gaat daar helemaal niet meer om disciplinaire inbreng, maar veel meer om
de output van het systeem in relatie tot de input.
Resumerend kan worden gesteld dat het met verschillende disciplines werken
(disciplinaire inbreng, het samenwerken en de verschillende vormen van
cordinatie) vooral op het laagste niveau goed dient te worden geregeld.
11.6 Relatieschema en organisatieschema

Bij het schetsen van een organisatiestructuur is het essentieel uit te gaan van
het relatieschema dat ontstaat uit de decompositie en de cordinatie van de
ontwerpopgave. Met het daaruit ontstane beeld van de informatievoorziening
kan een relatieschema worden geschetst. Dit is links in figuur 11.5
weergegeven.
103
CT1061
Figuur 11.5: Relatieschema en organisatieschema
Voor de vervaardiging van het organisatieschema zijn er een aantal

grondbeginselen:
Iedere functionaris heeft binnen het project op elk willekeurig tijdstip
slechts een baas.
Er wordt alleen een organisatielaag toegevoegd als er een bevoegdheid
wordt toegevoegd.
als er een organisatielaag wordt toegevoegd omdat de span of control te
groot is dan zal er een extra bevoegdheid dienen te worden gecreerd.
Het resultaat is rechts in figuur 11.5 aangegeven. Te zien valt dat er in
principe drie organisatorische lagen zijn (de lijnorganisatie):
De projectmanager (de strategische top) die verantwoordelijk is voor doel,
functie en vorm en bevoegd is om de interne structuur van het systeem te
wijzigen. Dat betekent dat hij bevoegd is doel functie en vorm van de
clusters te wijzigen.
De clustermanager (het middenkader), die verantwoordelijk is voor het
doel, functie en vorm van de in cluster aanwezige componenten en
bevoegd is de interne structuur van de cluster te wijzigen. Dat betekent dat
hij bevoegd is doel functie en vorm van de elementen te wijzigen.
De element manager (basis werkers), die verantwoordelijk is voor doel,
functie en vorm van een element en bevoegd is de structuur van het
element te wijzigen.
Naast de lijnfunctionarissen zijn er ook nog staffunctionarissen. Er worden vier
fundamenteel van elkaar verschillende staven onderscheiden, die allemaal
direct aan de projectmanager rapporteren:
Een staf (technostructuur) die het overall model maakt met de
aspectsystemen. Zij beheren de belastingen, het gedrag van het systeem
als geheel en de weerstand van het systeem tegen belastingen. Zij halen
de benodigde informatie op bij de clusters en distribueren de nieuwe
gegevens en de door te voeren aanpassingen.
Een staf (technostructuur) die zorg draagt voor de kwaliteit (QA/QC).
Een staf ( ondersteunende dienst) die zorg draagt voor de productie van
het project in tijd en geld.
Een staf (ondersteunende dienst) die zorg draagt voor de administratie en
het secretariaat.
104
CT3061
11.7 De disciplinaire inbreng

De disciplinaire inbreng kan niet direct in het organisatieschema worden
ondergebracht. Het kan overigens wel in een relatieschema worden
ondergebracht. Er zijn twee manieren om de inbreng (capaciteit uitgedrukt in
kwantiteit en kwaliteit) te regelen:
Inbreng disciplines met behulp van een matrix organisatie. De disciplinaire
werkers hebben dan een projectbaas die verantwoordelijk is voor de output
en een functionele baas die verantwoordelijk is voor de input.
Inbreng disciplines met behulp van netwerkorganisaties. De kennis en
kunde wordt dan regelrecht ingekocht (uren) van kleine gespecialiseerde
organisaties. Het voordeel is dat het flexibeler is dan een matrixorganisatie
en dat de ingehuurde werkkracht in het project maar een baas heeft.
11.8 Organisatieculturen
Cultuur in een organisatorische context kan worden beschouwd als een
verzameling geschreven en ongeschreven regels, die aangeeft welk gedrag er
van iemand verwacht, respectievelijk aangemoedigd en beloond wordt. In de
organisatiewereld onderscheidt men vier soorten culturen:
Machtscultuur, waarbij de beheersing plaatsvindt door op vitale plaatsen
sleutelfiguren neer te zetten die macht krijgen.
Rolcultuur, die wordt gekenmerkt door bureaucratie. De organisatie is
gebaseerd op zuilen (functies en specialismen). Mensen vervullen rollen die
in procedures vastgelegd zijn. Het is ordelijk. Correct gedrag wordt meer
gewaardeerd dan effectief gedrag.
Taakcultuur, die wordt gekenmerkt door pragmatisme. Alles moet wijken
voor het doel. Regels worden aangepast, werkers omgevormd. Gezag is er
alleen op basis van bekwaamheid.
Persoonscultuur, waarbij de organisatie georinteerd is op de mens. Komt
vaak voor in professionele organisaties. Leden benvloeden elkaar en er is
weinig hirarchie.
In de praktijk is er altijd een mengvorm. Zo wordt er voor organisaties wel de
volgende indeling gebruikt:
Reactieve organisatie, waarin een mengvorm van een machtscultuur en
een rolcultuur heerst.
Responsieve organisatie, waarin een mengvorm van een rolcultuur en een
taakcultuur heerst.
Crerende organisatie waarin een mengvorm van een taakcultuur en een
persoonscultuur heerst.
Bovenstaande drie organisatieculturen kunnen wat scherper in kaart worden
gebracht door de manier waarop de relevante organisatorische issues worden
ingevuld. Dit is schematisch weergegeven in tabel 11.1.
105
CT1061
Tabel 11.1: Organisatorische issues
Aspect
tijd
doel
planning
veranderingsmethode
management
structuur
orintatie
motivatie
communicatiemethode
leiderschapstijl
Reactieve
organisatie
verleden
overleven
rechtvaardig
bestraffend
schuldvraag
hirarchisch
egocentrisch
pijn vermijden
opgedrongen
dwingend
Responsieve
organisatie
heden
output
activiteiten
aanpassend
cordinatie
matrix
team
beloningen
feed back
sturend
Creatieve
organisatie
toekomst
creren
strategie
organisch
navigatie
netwerken
cultuur
bijdrage
feed through
inspirerend
Uit de tabel kan worden geconcludeerd dat de wijze van organisatie van
ontwerpwerk zoals in dit college behandeld een mengvorm is van een
responsieve en een crerende organisatievorm. Dit wordt gellustreerd in tabel
11.2:
Tabel 11.2: Responsieve en een crerende organisatievorm
Aspect
tijd
doel
Invulling
toekomst
output
Organisatievorm
crerend
responsief
planning
veranderingsmethode
management
structuur
orintatie
motivatie
communicatiemethode
leiderschapstijl
activiteiten
aanpassend
cordinerend
hirarchisch/matrix/netwerk
team
bijdrage
feed back/feed through
sturend/inspirerend
responsief
responsief
responsief
reactief/responsief/crerend
responsief
crerend
responsief/crerend
responsief/crerend
11.9 De stap naar productontwikkeling

Op een andere manier is er ook sprake van verschillende culturen. Dat verschil
heeft te maken met de aard van het te doorlopen proces. Dan spreken we
over: (1) een ontwerpcultuur met een overwegend crerende
organisatiecultuur, (2) een uitvoeringscultuur met een overwegend
responsieve organisatiecultuur en (3) exploitatiecultuur met een overwegend
reactieve organisatiecultuur.
Het verschil tussen ontwerpproces en uitvoeringsproces met de daarbij
behorende typische culturen is te zien in tabel 11.3.
106
CT3061
Tabel 11.3: Het verschil tussen een responsieve en een crerende organisatievorm
Ontwerp
gericht op veranderen
clusteren op relaties
niet te veel mensen
geen extreme tijdsdruk
geen competitie
trial and error
Realisatie
gericht op gefixeerd houden
clusteren op gelijkvormigheid
veel mensen
extreme tijdsdruk werkt
wel competitie
alles in een keer goed
Het gaat er echter wel om die processen met elkaar te verbinden. Een ontwerp
dat niet uitvoerbaar is geen ontwerp en een gerealiseerd bouwwerk dat niet
exploiteerbaar blijkt, is niet levensvatbaar.
Indien de relaties goed worden gelegd dan blijkt het ook goed mogelijk om
verschillende processen integraal te benaderen.
Het grootste probleem van de bouwcultuur is dat deze processen verschillend
worden benaderd en er geen directe koppelingen worden aangebracht.
Daardoor wordt er geen kennis vastgehouden en wordt het wiel elke keer
weer opnieuw uitgevonden.
Het gaat erom dat de exploitant terugkoppelt naar ontwerper en realisator en
dat de realisator terugkoppelt naar de ontwerper. Indien dat goed geregeld is
worden de eerste stappen gemaakt naar productontwikkeling.
Het niveau van productontwikkeling in de bouw ligt bij de subsystemen of
clusters. Een klantspecifieke oplossing wordt verkregen door een unieke
combinatie van subsystemen waarvan het gedrag wordt weergegeven door de
verzameling aspectsystemen. (zie figuur 11.6).
Figuur 11.6: Productniveau in sector
Bij productontwikkeling is het zoekproces wat rustiger en meer gecontroleerd.

Nieuwe systemen worden dan ontwikkeld op basis van bestaande systemen.
De organisatie wordt gevraagd om op verschillende schaalniveaus varianten te
ontwikkelen. Dat kan bovenin bij de subsystemen plaatsvinden, onderin bij de
elementen of er tussen in bij de sub sub systemen. Dit proces is geschetst in
figuur 11.7.
107
CT1061
Figuur 11.7: Productontwikkeling binnen een bedrijf
Duidelijk is dat de behandelde decompositie, cordinatie informatie en

organisatieprincipes ook bij productontwikkeling nodig zijn. Het enige verschil
is dat de kennis van de deelsystemen groter is en dat er nog meer parallel kan
worden gewerkt.
108
CT3061
12
Bijlage A: De decompositieregel
Voor de decompositie van systemen is de bijna-decompositieregel van Simon

[7] de enige die in aanmerking komt. De regel komt erop neer dat het korte
termijn gedrag van deelsystemen van het systeem wordt bepaald door de
interne coherentie van het beschouwde deelsysteem (intra-relaties), terwijl het
lange termijn gedrag wordt bepaald door de coherentie tussen de
deelsystemen (inter-relaties).
Dit betekent dat de ontwerper voor een bepaalde korte periode zijn aandacht
geheel aan een deelsysteem kan wijden zonder dat hij de rest van het systeem
in de gaten moet houden. De rest van het systeem zal alleen op de lange
termijn iets ondervinden van het korte termijn gesoleerde werk aan een
bepaald deelsysteem. In het vorige hoofdstuk hebben we gezien dat het lange
termijn gedrag van het gehele systeem uitstekend kan worden beheerst met
behulp van aspectsystemen.
Volgens de bijna decompositieregel moet het systeem worden
gedecomponeerd in subsystemen zodanig dat het aantal relaties binnen elk
sub-systeem wordt gemaximaliseerd en het aantal relaties tussen de
subsystemen wordt geminimaliseerd.
Een systeem kan worden weergegeven door een relatiematrix van elementen.
Om te beginnen heeft elk element een relatie met zichzelf. Sommige
elementen hebben een tweezijdige relatie en sommige elementen hebben een
eenzijdige relatie. De relatiematrix is vaak wel maar hoeft dus niet
symmetrisch te zijn. In figuur A.1 is een voorbeeld gegeven van een systeem
en de daarbij behorende relatiematrix.
Figuur A.1: Systeem met zijn relatiematrix (niet symmetrisch)
De decompositie geschiedt eigenlijk door rij-kolom permutaties. Daarbij dienen

de relaties in stand te blijven. Dat betekent dat als er een element in de
matrixrij wordt verplaatst dit ook in de kolom dient plaats te vinden. Aldus kan
de matrix worden bewerkt zonder dat de structuur van het systeem verloren
gaat. De bedoeling is het creren van blokken zodanig dat wordt voldaan aan
de decompositieregel. Er zijn verschillende decompositievormen.
De volledige decompositie
Als de relatiematrix A kan worden verdeeld in:
109
CT1061
zodat a12=0 en a21=0 dan is de matrix A volledig gedecomponeerd . Formeel

moeten dan alle blokken aij met i=j nul zijn. In dit speciale geval wordt het
systeem gedecomponeerd in volledig autonome subsystemen, die dus volledig
onafhankelijk van elkaar kunnen werken. Dit komt maar zelden voor.
Theoretisch kan de vraag gesteld worden of het wel mogelijk is dat er binnen
een systeem volledig autonome subsystemen te formeren zijn.
De hirarchische decompositie
Een andere - meer realistischere- decompositie is de zogenaamde
hirarchische decompositie. Dat is het geval als alle blokken boven de
diagonaal nul zijn. Dit is het zogenaamde driehoeksblok. Duidelijk is dat er dan
een minimaal aantal relaties tussen de blokken zijn. A is maximaal
gedecomponeerd als het aantal nullen in het driehoeksblok maximaal is.
De hirarchische decompositie wordt hieronder gellustreerd met een systeem

met zeven elementen. De gerichte graaf van dit eenvoudige systeem is
gegeven in figuur A.2.
Figuur A.2: Gerichte graaf van het systeem
Deze gerichte graaf kan worden weergegeven met behulp van een
relatiematrix A.
110
CT3061
De algemene gedachte van deze relatie matrix is:
De decompositie regel vereist een transformatie van matrix A naar de

volgende vorm:
Dit betekent dat er boven de diagonaal blokken met alleen nullen moeten
worden
gecreerd. Dit
resulteert
bijvoorbeeld
in
de
volgende
getransformeerde matrix:
111
CT1061
Het systeem dat op deze manier is gedecomponeerd is weergegeven in figuur

A.3.
Figuur A.3: Hirarchische decompositie van een systeem in sub-systemen
In de figuur is duidelijk te zien dat er aardig in geslaagd is te voldoen aan de

decompositieregel. Het aantal inter-relaties is 3 terwijl het aantal intra-relaties
12 is!
De praktische decompositie
Een andere meest realistische decompositie is de zogenaamde praktische
decompositie. Dat is het geval als er zich rondom de diagonaal veel enen
bevinden en verder van de diagonaal af weinig enen (relatief veel nullen).
Op die manier zijn clusters van elementen te formeren die maximale relaties
hebben met elkaar. Daarop kun je dan de organisatie inrichten. Om zoiets te
bereiken is vaak een kwestie van proberen. Daarbij is het onontbeerlijk om
ook gezond verstand te gebruiken. Het is handig om in plaats van enen en
nullen dikke zwarte punten te gebruiken. Visueel is dat overzichtelijker. Voor
112
CT3061
een symmetrische matrix is er een methode voor de rij-kolom permutaties. Bij

een symmetrische matrix behoeft alleen het gedeelte van de relatiematrix
onder de diagonaal te worden beschouwd. De methode (winkelhaakmethode)
is geschetst in figuur A.4:
Figuur A.4: De winkelhaakmethode (symmetrische matrix)
De methode bestaat uit de volgende stappen (zie figuur A.5):

Selecteer de rij die verplaatst moet worden.
Construeer de winkelhaak door de rij om te slaan om de diagonaal naar de
corresponderende kolom.
Beschouw de winkelhaak als een lint van elementjes die behouden moet
blijven bij verplaatsing.
Verplaats de rij naar de plek die gewenst wordt en construeer de
bijbehorende winkelhaak.
Schuif de andere rijen vervolgens op.
113
CT1061
114
CT3061
Figuur A.5: Praktische decompositie in stappen
Met behulp van deze methode kan vrij snel worden ingeschat welk effect een
bepaalde bewerking heeft op het streven zoveel mogelijk rondjes bij de
diagonaal te krijgen.
Verschillende relaties
In de vorige paragrafen wordt geen rekening gehouden met de sterkte van de
relaties. Dat is jammer omdat iedereen weet dat de sterkte van de relaties
behoorlijk kan variren. Het zou wenselijk zijn deze sterkte mee te nemen in
de decompositiemethode. Dat kan vooralsnog alleen grafisch. Het is vrij
eenvoudig om de sterkte van de relaties te laten corresponderen met de
grootte van de zwarte rondjes. Een voorbeeld hiervan is geschetst in figuur
A.6.
Figuur A.6: Relatiematrix met verschil in sterkte van de relaties

115
CT1061
Bij de decompositie methode gaat het er nu om zoveel mogelijk zwart

oppervlak bij de diagonaal te krijgen. Dat kan overigens uitstekend met de
winkelhaakmethode.
Voorbeeld: stormvloed kering in de Nieuwe Waterweg
Als voorbeeld is hier de clustering van de bouw van de stormvloed kering
Nieuwe Waterweg opgenomen zoals die werkelijk is uitgevoerd. Via
decompositie en clustering is men gekomen tot een zevental werkclusters. Op
deze wijze wordt het aantal relaties binnen de werkclusters gemaximaliseerd
en tussen de clusters geminimaliseerd. Vervolgens kan de organisatie worden
ingericht. Let op dat de matrix a-symmetrisch is.
Figuur A.7: Relatiematrix vr de clustering
Allereerst zijn de relaties zo dicht mogelijk bij de diagonaal gebracht. Daarna

zijn er drie mogelijke clusteringen gemaakt. In dit geval steeds 7 clusters; zie
figuren A.8, A.9 en A.10.
In de eerste clustering vind je de kerende wand (16) en het ballastsysteem
(19) bij elkaar in 1 groep; en de vakwerkarmen (17), het scharnier (15), de
scharnierfundatie (10); enz.
In de tweede clustering zijn de kerende wand (16), het ballastsysteem (19),
de vakwerkarmen (17) en het scharnier (15) bij elkaar gezet. De
scharnierfundatie (10) wordt apart beschouwd; enz.
In de derde clustering die uiteindelijk gekozen is - vind je de kerende wand
(16), het ballastsysteem (19) en de vakwerkarmen (17) bij elkaar in 1 groep;
het scharnier (15) en de scharnierfundatie (10) zitten in een andere groep;
enz.
116
CT3061
Figuur A.8: Eerste clustering
Figuur A.9: Tweede clustering
117
CT1061
Figuur A.10: Uiteindelijk clustering
118
13 Bijlage B: Ekofisk Barrier

THE TOP DOWN RISK MANAGEMENT SYSTEM OF THE OFFSHORE
OPERATIONS OF THE EKOFISK PROTECTIVE BARRIER
By dr Hennes A J de Ridder
Professor in Design and Construction Management, Faculty of Civil Engineering and Geosciences,
Delft University of Technology, The Netherlands.
ABSTRACT
INTRODUCTION
The Ekofisk Field in the centre of the North Sea is a very

important junction in the oil producing and transporting
North Sea network. In 1987, the wave loads on the
Ekofisk Installations had become unacceptable, due to a
significant seabed subsidence. In order to cope with the
increased wave loads, it was decided to build a Protective
Barrier around the central Ekofisk Storage Tank. This
barrier was to be installed in two separate half units,
which were to be brought to the Ekofisk Field in floating
condition. After installation, the two halves were to be
structurally connected.
The paper deals with the overall risk management of the
total offshore operations, including tow-out, installation,
coupling and completion. The operations were governed
by conflicting requirements with respect to relevant
aspects like stability, strength, stiffness, weight,
geometry and were perceived to be extremely risky due
to the marginal resistance against the expected load
cases. The operations were weather dependent, thus
dominated by changing stochastic boundary conditions.
Most of the processes were irreversible, non-linear, and
determined by a large number of variables. A top down
risk management system was developed for control
purposes. The system provided a continuous insight right
from the very start of the project till the end of the
project in the percentage of failure in the most relevant
failure modes as a function of tow out date. The system
allowed for strategic, tactical and operational
interventions in case critical criteria were exceeded. This
in particular makes that the approach even 10 years
after completion of the project is still a new
development in risk management and an interesting
basis of further research on control of the design,
construction and installation of complex Civil Engineering
and other Systems.
In 1987 it was necessary to elevate the decks supported

by steel jackets at the Ekofisk Field due to significant
seabed subsidence, which resulted in an increased wave
load [12]. A different solution however was required for
the central concrete bottom founded tank, supporting the
main field processing facilities. The solution adopted was
a bottom founded concrete protective barrier surrounding
the
existing
tank
structure.
The
Engineering,
Procurement, Construction and Installation contract for
the project was awarded to Peconor Ekofisk AF in
February 1988.
The Ekofisk Protective Barrier was, and still is, rather
unique. Firstly, it was the first offshore concrete
construction, which was not installed as a monolith.
Secondly, the shape of the construction is different from
all realised structures in this construction discipline.
Thirdly, the wave load on the structure during both the
constructional phase as well as the utilisation phase is
beyond the load on any other existing offshore structure.
The most significant characteristic of the project was the
available total development time with respect to the size
of the project. The Ekofisk Protective Barrier
was
completed in autumn 1989 [13].
THE CONCEPT AT THE START OF THE PROJECT
The concept of the Protective barrier was developed from
the basic requirement that the oil and gas producing
activities may not be disturbed. Two floating caissons, to
be towed to the Ekofisk field, placed on the seabed
around the tank and subsequently connected with each
other. A horizontal cross section of the Protective Barrier
and a side view is given in figure 1.
119
interlocking keys and in-situ concrete to be cast in the

remaining holes. This concept is sketched in figure 2.
Figure 2 Initial concept of the joint connection

THE PROBLEMS WITH
OFFSHORE COMPLETION
Dimensions:
Length outer wall 432 meters.
Width 15.5. meters.
External diameter 140 meters.
Height above seabed 106 meters.
Weight during tow-out from lfjorden to the Ekofisk field:
Weight without ballast, one half unit approx. 140,000 tons.
Solid ballast during tow-out approx. 52,000 tons.
Total weight, one half unit during tow-out 192,000 tons.
Total weight of the entire structure during tow-out including ballast
384,000 tons.
The concrete structure requires 105,000 cubic meters of concrete, 24,000
tons of reinforcement and 6,000 tons of prestressed steel.
Figure 1 Concept of the Ekofisk Protective barrier

The most critical phase was the connection of the two
barrier halves [14]. After installation on the seabed, the
two barrier halves had to provide enough strength and
stability to withstand the design wave condition during
joint connection works. The connection itself was to be
provided by key piles to be inserted in circular recesses in
120
INSTALLATION
AND
A few months after the start of the engineering, the

project was confronted with two unexpected events: (1)
the wave load model tests revealed that the wave loads
with the defined 10 years summer storm condition on the
uncoupled half units were twice as much as assumed and
(2) the soil condition at the eastern side of the central
tank was substantially worse than expected.
Due to the larger wave loads and given the defined soil
condition, the stability of the uncoupled barrier halves
was not ensured during the temporary offshore phase at
the offshore location. Stability could be improved by
increasing the amount of ballast. A larger amount of
ballast however would cause larger differential
penetration and settlements due to non-uniform soil
conditions. This would lead to horizontal fitting problems
(figure 3a). Due to the fitting problems, it was advisable
to limit the amount of ballast prior to joint connection
works. Unfortunately, the initial phasing of a reduced
ballast quantity would lead to larger built-in stresses due
to deformations after the connection works when the
balance of the ballast was added (figure 3b).
a.
b.
Figure 3 Geometrical problems and strength problems

associated with ballasting strategy
Confronted with the stability problem, the client decided
to change the summer storm-condition. Instead of a 10year return period, a 3-year return period was decided
upon for the governing wave condition. However, even
this wave condition proved to be too heavy to ensure
stability. Besides that, the tolerance problem remained.
In addition, model tests on floating behaviour resulted in
larger wave induced motions than assumed during the
floating position prior to installation of the second half
unit. In order to avoid clashes, the gap between the two
installed halves had to be enlarged. As result the amount
of concrete to be cast into the gap became larger. In
consequence, the necessary concreting time and
hardening time increased. As motions were not allowed
during the hardening time and periods without wave
action are hardly available in the North Sea, the offshore
operations became more difficult. This, together with
several related features as tolerances, clearances,
strength, fatigue, construction problems, etc. enforced a
change in the connection method from the key and key
pile concept into a steel plate and prepared box concept.
The enforced change took place approximately seven
months after the start of detailed engineering. At that
time the lowest keys were already constructed. The
changed joint concept is sketched in figure 4.
Figure 4 Changed concept of the joint connection

DESIGN APPROACH
Tolerances, stability and temporary strength during
installation
and
offshore
completion
revealed
contradictory requirements with respect to ballasting. On
the one hand the fitting problem would be less critical if
the amount of ballast prior to the connection is as less as
possible, on the other the stability of the uncoupled
halves and the strength of the joint would be less critical
if the maximum amount of ballast is achieved as soon as
possible. Right from the start, the design team was
confronted with critical choices at system level. Decisions
had to be made under a number of uncertainties. The
best way to attack the design dilemma was to describe
the total behaviour of the installation and subsequent
offshore completion with respect to the critical aspects in
a mathematical model of the system at the highest
abstraction level. In that way the relatively small amount
of knowledge at the start of the project could be used in
the most critical phase of the project (figure 5). This
makes that the approach followed still is advanced. Most
risk management systems are developed in later design
phases focussing on components and elements.
121
100 %
INFLUENCE ON
PROJECT
KNOWLEDGE
AVAILABLE
TIME
UNCERTAINTY
the processes on the probability of failure. The tolerance

model was developed for the temporary phase after
installation of both barrier halves and comprised
deformations, deviations, displacements and available
clearances of the two barrier halves with respect to each
other during the offshore operations.
Failure was defined as a misfit of at least one of the
construction parts. A result of a fitting simulation is given
in figure 6, showing the composite tolerance chart and
the 10000 simulations. The simulation model was able to
determine the relative contribution of the various
processes to the total failure. Hence it was simple to
detect the most critical processes, which made the
tolerance model a sophisticated coordination system. The
eventual result of the tolerance model given in probability
of failure as a function of on bottom weight of the half
units is given in figure 7.
100 %
SYSTEM LEVEL
COMPONENT LEVEL
ELEMENT LEVEL
TIME
Figure 5 Influence on design process, development of

knowledge and uncertainties as a function of
time and scale levels
Given the urgency and the main purpose, it was clear
that the risk management systems must be kept as
simple as possible and split up where possible. This
resulted in a tolerance model and a stability/ strengthmodel. Moreover it was important to develop the models
from rough to fine. Rough insight in the main aspects
and associated solutions at the early project phases was
recognised more important than fully validated models at
the end of the project.
Figure 6 Probability of failure with respect to tolerances

as a function of on bottom weight
PROBABILITY
OF FAILURE
10%
5%
CRITERION
TOLERANCE RISK MANAGEMENT SYSTEM

A detailed analysis of the fitting of the joint
constructions, which had to cope with deformations,
deviations; and displacements, concluded that a
deterministic approach would lead to unrealistic joint
dimensions. Due to the three-dimensional problem as a
function of the height, and the stochastically independent
processes, a Monte Carlo simulation model was adopted.
The simulation runs aimed at establishing the effects of
design variables, environmental boundary conditions and
122
1000
1200
1400
1600
1800
2000
2200
2400
ON BOTTEM WEIGHT
IN MN
Figure 7 Result of the tolerance risk management system
THE
STABILITY
AND
MANAGEMENT SYSTEM
STRENGTH
RISK
The dynamic model was built around the basic failure

functions for stability and strength. The purpose of the
coordination model was to visualise the critical items and,
given the failure criterion, to establish the optimal
sequence and the latest possible start date and to
determine the various process parameters. The basis of
the model was the offshore planning, which consisted of
two basic phases. The first was the uncoupled phase of
two barrier halves, with stability as failure mode. The
second was the connection phase. Wave action was
hardly allowed during this phase and strength was the
main failure mode.
A main part of the model was the wave climate, which
was important for the operations itself and also for the
waveloads. Wave information was available by existing
scatter diagrams of wave heights, wave directions and
wave periods. An autocorrelation function was
established using Ekofisk time series of waves over a
period of ten years. With this information the wave
climate was generated by simulation runs and compared
with actual time series.
In order to get insight in the wave loads on the barrier
halves, a series of model tests were conducted at SSPA
Goteborg. Unfortunately, only the most critical wave
direction was investigated. Therefore the wave load on
the barrier half units as function of incident wave
direction was determined using a diffraction model.
The resistance of the uncoupled barrier halves against
wave loads was a function of on bottom weight and soil
properties. Due to the "horse foot" shaped bottom slab,
the backward wave induced moments were the
governing wave loads. The results of the soil
investigation showed that the soil properties east of the
tank were substantially worse than the soil properties
west of the tank. The backward allowable overturning
moments were expressed in parameters of a Gaussian
distribution (figure 8).
Figure 8 Backward allowable moments on the barrier

halves
The allowable motions during the grouting operations of
the joint construction were zero. Any motion would have
a negative influence on the eventual quality of the
concrete. Due to this, a connection was made at the top
of the two barrier halves. However, this connection could
only take favourable summerstorm conditions. This was
the reason that contingency plans (differential ballasting)
and even emergency plans had to be developed for the
case that the operation for what reasons ever would be
get into wave conditions worse than the working
conditions agreed upon (figure 9).
Figure 9 Development of strength during the connection

works as a function of time
123
The offshore installation, from the placing of the barrier

halves on the seabed till the completion of the joint
construction, was rather risky. An indication of wave
induced moments on the barrier halves on one hand and
resistance moments on the other is given in figure 10.
JOINT
PROBABILITY OF FAILURE IN %
moment
60
connection
50
40
1%
strength/stability
load
west
30
WESTERN HALF
EASTERN HALF
CRITERION
1
10/6
1/7
20/7
10/8
1/9
20/9
east
TOW OUT DATE

10%
20
Figure 11 Probability of failure with respect to strength

and stability as a function of tow out date.
50%
10
June
tow out
July
Aug
Sept
Figure 10 Indication of resistance moments of the barrier

halves and wave induced moments on the
barrier halves during the temporary phases
offshore
As can be seen the safety against failure is marginal
during the connection works. As a consequence, the
success of the connection works was strongly dependant
of the reliability of the weather forecast. Therefore, also
the weather forecasting is incorporated in the simulation
model.
A Monte Carlo model was used to simulate 1000 offshore
completion works per run. Per simulation firstly the wave
climate was established. Then the activities with
associated weather windows were put in. After that
failure functions could be established per time step. For
each failure mode the number of failures was counted.
From these numbers the total probability of failure could
easily be determined. Several cases were investigated by
the model. Sensitivity analyses were carried out for
ballast strategies and delays.
A lot of interesting data could be established. For
instance total workability and total duration of the
installation operation, as a function of start date and
expressed in probability of exceedance. The main
outcome is the probability of failure of the main
components as a function of tow out date (figure 11).
124
CONCLUSIONS
The Ekofisk Protective Barrier project was a unique
project. The complexity and difficulty of
the project
were large due to a combination of non linear,
irreversible, mutually dependant processes around a risky
concept which was exposed to transient stochastic
loadings.
Conflicting design aspects for the offshore operation
made it necessary to develop a top down risk model
which could be used for control purposes and decision
making right from the beginning of the project.
For the development of the installation and offshore
completion of the Ekofisk Protective Barrier, two dynamic
risk models were developed from rough to fine,
accommodating operational, tactical and strategic
interventions during the operation.
The heart of the dynamic risk models consisted of a full
probabilistic Monte Carlo simulation of the total
procedure including both the environmental conditions
and taking into account a large number of influencing
variables.
The Dynamic Risk Models developed for the Ekofisk
Protective Barrier proved to be very worthy for the
control of complex design work and the subsequent
construction and installation. Although developed in
1990, the integrated and dynamic approach can be
considered as state of the art in top down Risk
Management of the design of complex systems.
REFERENCES
11. Croucher, T.M., Integrated Team Approach to the
Design, Construction, Stat Up and Operation of
the World's Most Modern Drilling Rig. Spe Drilling
and Completion, 1999. 14(3): p. 201-207.
12. Broughton, P. and K. Waargaard, The Ekofisk
Protective Barrier. Proceedings of the Institution
of Civil Engineers - Water, Maritime and Energy,
1992. 96(2): p. 103-119.
13. de Ridder, H.A.J. Design of th Installation and
Offshore Completion of the Ekofisk Barrier. in
Proceedings
of
the
Sixth
International
Conference on the Behaviour of Offshore
Structures. 1992. London.
125
14 Bijlage C: Systems Engineering in de bouw

Een kritische beschouwing van Systems Engineering in de bouw.
Deze bijlage is gebaseerd op: LEGOlisering in de bouw [15]
Nederland is het enige land in de wereld waar Systems Engineering (SE) in de
bouw wordt toegepast en door een paar publieke opdrachtgevers wordt
voorgeschreven. Oorspronkelijk komt SE uit de Amerikaanse defensie industrie
en de ruimtevaart. Het wordt gebruikt voor de engineering en de bouw van
prototypen.
INCOE, The International Council on Systems Engineering, definieert SE als:
An interdisciplinary approach and means to enable the realization of
successful systems. Systems Engineering considers both the business and
the technical needs of all customers with the goal of providing a quality
product that meets the user needs.[16]
Bij haar beschrijving van de onderliggende processen verwijst de INCOSE
veelvuldig naar de internationale norm ISO/IEC 15288 Systems and software
engineering [17]
Een belangrijk onderdeel van SE vormen de begrippen verificatie en validatie.
Tabel C.1: Validatie en verificatie
Algemeen
Specifiek
Validatie
Is dit het goede bouwwerk?
Voldoen aan wettelijk normen
Voldoen aan het voorziene gebruik
Verificatie
Is het bouwwerk goed?
Voldoen aan de specificaties
Algemene validatie
De eerste toets is of het product voldoet aan de wettelijke normen en
voorschriften ten aanzien van veiligheid en betrouwbaarheid. Hier wordt
getoetst of het product geldig is in de zin van: mag het worden verkocht en
kan het worden toegelaten? In de bouw worden deze aspecten getoetst aan
de normen, voorschriften en richtlijnen. Deze zijn er voor alle typen
bouwwerken
en
handelen
over
de
constructieve,
mechanische,
installatietechnische, fysische en chemische eigenschappen, hoedanigheden en
karakteristieken.
Specifieke verificatie
De tweede toets is of het te kopen product voldoet aan wat de leverancier
zegt aan te bieden. Deze toets kan worden opgevat als specifieke verificatie: is
het product goed en volgens de specificaties van de leverancier gemaakt?
Deze toetsing dient door de leverancier te worden geregeld en zal uitgevoerd
moeten worden door onafhankelijke certificeerders om te voorkomen dat de
slager speelt zijn eigen vlees keurt.
Specifieke validatie
De derde toets is of de klant het goede product koopt. De klant dient daarmee
vast te stellen of het product past in het door hem voorziene gebruik van dat
127
product. Je zou ook kunnen zeggen dat de klant moet nagaan of het in zijn
context past. Hij toetst daarmee of het product voor hem geldig is.
SE in de praktijk
In de praktijk kan SE beschouwd als een expliciete toetsingsmethode op
ontwerpwerk. Systems Engineering zoals het nu wordt toegepast is dan
eigenlijk kwaliteitszorg, in feite beperkt tot een validatie en verificatie
methodiek. Door de grote opdrachtgevers in de bouw is met medewerking van
de organisatie van raadgevende ingenieurs en de grote bouworganisatie
Bouwend Nederland SE geuniformeerd voor de gentregreerde contracten en
vastgelegd in de Leidraad Systems Engineering [18]. Op zich zeer zinnig als de
aannemers echt ontwerpvrijheid hebben: als klant wil je dan weten of je de
juiste spullen koopt en dat die spullen goed zijn.
Maar de aannemers hebben die ontwerpvrijheid niet. Omdat de klant in de
bouw (precies) definieert wat hij wil hebben, creert hij voor zichzelf het
probleem dat hij moet controleren of hij daadwerkelijk krijgt wat hij
gespecificeerd heeft. De klant wil enerzijds het goede bouwwerk hebben
(validatie) en anderzijds zeker weten dat het bouwwerk goed is (verificatie).
Deze twee acties vallen samen omdat alles draait om de specificatie van de
klant. De klant gaat er namelijk vanuit dat zijn specificaties tot zowel het
goede bouwwerk als een goed bouwwerk leiden. Ten aanzien van het eerste
mag er van worden uitgegaan dat de klant zijn eigen specificaties niet hoeft te
valideren. Hij hoeft zich niet af te vragen of zijn eigen specificaties wel leiden
tot een voor hem nuttig bouwwerk. Dan blijven er twee toetsen over. De
eerste is dat de klant zich er bij het opstellen van de specificaties van moet
overtuigen dat het gerealiseerde bouwwerk voldoet aan de wettelijke normen
en voorschriften. Dat is de algemene validatie. De tweede toets is dat hij moet
controleren of het door de aannemer gerealiseerde bouwwerk voldoet aan zijn
specificaties. Dat is de specifieke verificatie.
Als het gaat om algemene validatie zullen de door de klant ingeschakelde
adviseurs meestal wel in staat zijn de bouwwerken volgens de algemeen
gangbare normen en voorschriften te ontwerpen. Maar wie is in staat dat te
controleren? De algemene validatie van de uitvoering komt zo neer op een
specifieke verificatie. Voor de specifieke verificatie vertrouwt de klant meestal
op zijn meest dominante adviseur. Die wordt door alle partijen in staat geacht
om wat hij ontworpen heeft, ook door een aannemer te laten maken. De
adviseur houdt toezicht en zorgt ervoor dat de aannemer alles precies volgens
de tekeningen en specificaties maakt.
In de gentegreerde contractvormen is een en ander niet anders geregeld
maar wel ingewikkelder. De aannemer moet heel veel in het werk stellen om
zijn precontractuele besteksontwerp (de aanbieding) min of meer te laten
samenvallen met het door de klant gemaakte besteksontwerp, dat alleen is
vastgelegd in functionele specificaties. In de perceptie van de mensen in de
huidige bouwsector maakt de aannemer in die gentegreerde contracten een
eigen ontwerp. Tevens heeft men daarbij afgesproken dat de aannemer zijn
het ontwerp zelf valideert of verifieert. De sector heeft hiervoor Systems
Engineering afgesproken: een door de klant voorgeschreven manier van
verifiren en valideren waarbij inderdaad geen verschil tussen die totaal
verschillende toetsingen wordt gemaakt [18]. Met Systems Engineering wordt
het zogenaamde ontwerpwerk teruggebracht tot een kwaliteitszorg-exercitie.

Een controle aan de hand van papieren moet duidelijk maken of het door de
klant ontworpen bouwwerk, zoals beschreven in functionele specificaties c.q.
outputspecificaties, goed is gereproduceerd in de door de aannemer gemaakte
tekeningen en - later - of de aannemer het conform
deze tekeningen heeft gerealiseerd.
Omdat de klant zelf uitmaakt wat goed voor hem is en dat ook nog eens
volledig en in detail specificeert, is een verificatie voldoende. Volgens
bovenstaande definities is validatie dan dus niet nodig. SE is dus niets anders
dan gewone kwaliteitscontrole. SE gaat uit van een bij de klant reeds bekend
bouwwerk waarvan de specificaties dus ook bekend zijn. De aannemers
krijgen alleen deze specificaties die outputspecificaties worden genoemd. SE is
erop gericht dat het bouwwerk, dat de aannemer levert en specificeert, te
toetsen aan de outputspecificaties van de klant.
129
15 Referenties
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
Morris, P.W.G., The Management of Projects, 1994, London: Thomas

Telford.
Flyvbjerg B., Bruzelius N., and R. W., Megaprojects and risk: An
anatomy of ambition, 2008, Cambridge: Cambridge University Press.
Belbin, R.M., Management Teams: Why They Succeed Or Fail, 2010:
Butterworth-Heinemann.
Bono, E.D., Lateral thinking: creativity step by step, 1973: Harper &
Row.
Bono, E.D., Six Thinking Hats, 2008: Penguin Group.
Hanken, A.F.G. and H.A. Reuven, Inleiding tot de systeemleer, 1976,
Leiden: Stenfert Kroese.
Simon, H.A., The Architecture of Complexity. Proceedings of the
American Philosophical Society, 1962. 106(6).
Mintzberg, H., The Structuring of Organizations, 1979, Englewood
Cliffs, N.J.,: Prentice Hall.
Leeuw, A.C.J., Bedrijfskundig management;:primair proces, strategie
en organisatie, 2002, Assen: van Gorcum.
Leeuw, A.C.J., Besturen van veranderingsprocessen, 1994, Assen: van
Gorcum.
Mintzberg, H., Structure in fives: designing effective organizations,
1994, Englewood Cliffs: Prentice Hall.
Croucher, T.M., Integrated Team Approach to the Design,
Construction, Stat Up and Operation of the World's Most Modern
Drilling Rig. Spe Drilling and Completion, 1999. 14(3): p. 201-207.
Broughton, P. and K. Waargaard, The Ekofisk Protective Barrier.
Proceedings of the Institution of Civil Engineers - Water, Maritime and
Energy, 1992. 96(2): p. 103-119.
de Ridder, H.A.J. Design of th Installation and Offshore Completion of
the Ekofisk Barrier. in Proceedings of the Sixth International
Conference on the Behaviour of Offshore Structures. 1992. London.
de Ridder, H.A.J., LEGOlisering van de bouw, 2011: MGMC.
INCOSE. INCOSE Systems Engineering Handbook v3.2.2. 2010 [cited
2012 Jan. 2012]; Available from: http://www.incose.org.
ISO/IEC, ISO/IEC 15288:2008, Systems and software engineering
System life cycle processes, 2008, International Organization for
Standardization: Geneve.
Werkgroep Leidraad Systems Engineering, Leidraad voor Systems
Engineering binnen de GWW-sector., 2009.
131

Dictaat CT3061 Compleet - V2012

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Dictaat CT3061 Compleet - V2012

Uploaded by

Copyright:

Available Formats

CT3061

Systems Engineering Ontwerpproject 3

Prof.dr.ir. H.A.J. de Ridder

Technische Universiteit Delft

Dit collegedictaat is uitsluitend voor gebruik aan de Faculteit Civiele Techniek en

Systems Engineering Ontwerpproject 3

8.2 Besturingsmodel .............................................................................. 75

Systems Engineering Ontwerpproject 3

de totale hoeveelheid afval:

De belangrijkste oorzaak is de top down ambachtelijke werkwijze waarbij elke

cradle to cradle beginsel, waarbij hoogwaardig hergebruik van materialen en

Onderschatting (complexiteit, moeilijkheidsgraad, technische

Systems Engineering Ontwerpproject 3

Toelichting de themas per studiejaar:

1e jaar: Inleiding Ontwerpen in de Civiele Techniek, Ontwerpproject

(functionaliteit, techniek, omgeving, economie, uitvoering), en werken op

3e jaar: Systems Engineering, Ontwerpproject 3 (CT3061) waarin:

1.2 Didactisch model

Systems Engineering Ontwerpproject 3

de raakvlakken tussen de subgroepen te worden beschreven en te worden

Een partij met veel spelers

De invloed van al deze partijen in een contractuele, regulerende of een

Systems Engineering Ontwerpproject 3

2 Groepswerk: problemen en beheersprincipes

2.2 Grootte van ontwerpteams

Uitgangspunten daarbij zijn dat:

2.3 Opdelen van groepswerk

2.4 Gevraagde rollen

Systems Engineering Ontwerpproject 3

Het spelen van duidelijk gedefinieerde rollen

De Bono onderscheidt zes fundamenteel verschillende denkhoeden die hij met

constructief denken en de raderen in beweging brengen. Er wordt

Systems Engineering Ontwerpproject 3

2.5 Decompositie (ontleding) en cordinatie (sturing)

Gecompliceerde opdeling in eenvoudige delen. Dit is de traditionele

2.6 Organisatie en informatie

Figuur 2.2: Beheersing van een ontwerpopgave

De twee belangrijkste aspecten van een organisatie zijn autonomie en

Systems Engineering Ontwerpproject 3

In de communicatietheorie wordt informatie geassocieerd met de mate van

2.7 De vier organisatorische

Figuur 2.3: Organisatie-as

Figuur 2.4: Productie-as

Figuur 2.5: Organisatie- en productie-as

Hier kan nu de koppeling worden gemaakt met de eerder gespecificeerde

Systems Engineering Ontwerpproject 3

De kern van Systems Engineering is eigenlijk dat de projectleider op elk

Systems Engineering Ontwerpproject 3

3 Systems Engineering: een eerste verkenning

Figuur 3.1: Waarde en kostenstroom van een systeem

Er zijn drie soorten waarden:

3.2 De gebruikelijke en herkenbare schaalniveaus

producten. Dit is weergegeven in figuur 3.2 waarbij vijf niveaus zijn

Figuur 3.2: Gebruikelijke schaalniveaus

Systems Engineering Ontwerpproject 3

3.3 Systeemtheoretische schaalniveaus

Figuur 3.3: Schaalniveaus Stormvloedkering Nieuwe Waterweg

3.4 Het sturen van de ontwikkeling en exploitatie van

Figuur 3.4: Opgave van de System Integrator

3.5 De dimensies van Systems Engineering in de Civiele

Systems Engineering Ontwerpproject 3

Figuur 3.5: Systems Engineering

Systems Engineering Ontwerpproject 3

4 De factor tijd en planning in Systems