Dictaat CT3061 Compleet - V2012

7/25/2019 Dictaat CT3061 Compleet - V2012

http://slidepdf.com/reader/full/dictaat-ct3061-compleet-v2012 1/135

CT3061 Systems Engineering – Ontwerpproject 3

Collegedictaat CT3061Systems Engineering – Ontwerpproject 3

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




1

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 coördinatie (sturing) .............................. 11

2.6 Organisatie en informatie ................................................................. 12

2.7

De vier organisatorische aspecten verbonden: productie- enorganisatie-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

Coördinatie van de ontwikkelingsopgave (sturing) .................... 75

8.1 Algemeen ........................................................................................ 75



CT1061

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

8.3 Meta-besturingsconcepten ................................................................ 76

8.4 Voorwaarden voor effectieve besturing .............................................. 79

9

Doel, model en besturingsvariëteit ............................................. 81

9.1 Algemeen ........................................................................................ 81

9.2 Doel ................................................................................................ 81

9.3 Model van het bestuurd systeem ....................................................... 84

9.4 Besturingsvariëteit ........................................................................... 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




1

1

Inleiding

1.1

Waarom aandacht voor Systems Engineering?

We leven in een exponentiële 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 vanbouwwerken 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 de totale hoeveelheid afval: 35 %

• Bijdrage aan het totale verkeer: 25 %

• Bijdrage aan energiegebruik t.g.v. gebruik bouwwerken: 35 %

• Bijdrage aan energiegebruik t.g.v. grondstoffen gebruik: 12%

•

Faalkosten 10 %

De belangrijkste oorzaak is de top down ambachtelijke werkwijze waarbij elke

keer voor een nieuwe bouwwerk het wiel wordt uitgevonden en er nauwelijks

geïnnoveerd 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

2

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 drieconcepten 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 categorieën:

•

Onderschatting (complexiteit, moeilijkheidsgraad, technische

ontwikkeling, omvang, etc.)

• Veranderingen (omvang, scope, functie, tijdschema, etc.)

•

Financiering (inflatie, rente, solvabiliteit, etc.)

• Management (coördinatie, 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

coördinatie, de organisatie, de informatie en de besluitvorming.




3

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 risico’s;

• 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 deontwerplijn binnen de BSc-opleiding Civiele Techniek van de sectie “Integraal

Ontwerpen” van de afdeling “Bouw”. De ontwerplijn in de Bachelor-opleiding

heeft als centrale thema’s:

• Van functie naar vorm ( 1e jaar);

• Integraal werken op verschillende schaalniveaus (2e jaar);

• Complexe systemen in gecompliceerde omgeving (3e jaar).

1.1.1 Toelichting de thema’s 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, Ontwerpproject2 (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



CT1061

4

(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 vanruimtelijke 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 risico’s geïnventariseerd.

• 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 coördineren 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 complexiteitwordt gereduceerd en continue coördinatie 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 definiëren van de relevante omgeving.

1.2 Didactisch model

Het vak CT3061 is een vervolg op de vakken CT1061 en CT1210 uit het eersteen 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 coördinatie mogelijk wordt. Er worden

semiautonoom werkende subgroepen gevormd, waarbij de groep als geheelverantwoordelijk is voor het gedrag van het gehele systeem. Daarbij dienen




5

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 risico’s, 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 spelersBij 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 geïnteresseerd zijn in waarde voor geld (value for

money). Zij consumeren de waarde van een bouwwerk en betalen daar een

prijs voor.

• Waard producenten, die geïnteresseerd 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;



CT1061

6

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.)




7

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

projectgroottein mln. Euro’s

1000 100 10 1

manjaren ontwerp 250 25 2.5 0.25

pers manj pers manj pers manj pers manw

oriëntatie 33 17 3 1.7 1 0.17 1 1

haalbaarheid 67 33 7 3.3 1 0.3 1 1.5

voorontwerp 100 50 10 5.0 1 0.5 1 2.5

definitief ontwerp 133 67 13 6.7 1 0.7 1 3.5

detaillering 167 83 17 8.3 2 0.8 1 4



CT1061

8

Uitgangspunten daarbij zijn dat:

• Alle vijf ontwerpfasen (oriëntatie, 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 efficiënt 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 vanverschillende denkpetten zijn:




9

• 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 HoedOmdat 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 HoedRood 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, intuïtie, nuchterheid, smaak en esthetisch gevoel.

Bij de rode hoed-denker worden de gevoelens niet gerechtvaardigd of voorzien

van een logische basis.

De Zwarte HoedDe 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 eenpositieve manier van denken. De functie van de gele hoed in een project is



CT1061

10

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 ofhet 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

scenario’s. 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 HoedGroen 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 ideeën 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 hetene 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 ideeën 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 allesoverkoepelt. 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 definiëren 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.




11

2.5 Decompositie (ontleding) en coördinatie (sturing)

In de meeste literatuur wordt, bij het organiseren van complexe

ontwerpproblemen, gewag gemaakt van het verband tussen de begrippendecompositie (ontleding) en coördinatie (sturing). In feite is het zo dat de

decompositie van een ontwerpopgave zodanig plaats dient te vinden, dat

coördinatie 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 coördinatie sterk aan elkaar gerelateerd. Toch is het niet

eenvoudig om die relatie te doorgronden. Zoals reeds eerder gezegd dientdecompositie de coördinatie te vergemakkelijken. Verdeel je het werk in te

grote stukken dan heeft de centrale coördinator het relatief makkelijk, maar

moet er binnen de grote brokken weer flink gecoördineerd worden. Verdeel je

het werk in te kleine stukken, dan wordt de centrale coördinator zwaar belast

en is er binnen de brokken weinig coördinatiewerk nodig.

Decompositie en coördinatie 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

coördinatie;



CT1061

12

•

Gecompliceerde opdeling in eenvoudige delen. Dit is de traditionele

opsplitsing in vakdisciplines, waarbij ook veel coördinatieproblemen

bestaan. We praten hier over eenvoudige delen, omdat er binnen de

vakdisciplines makkelijk kan worden gecommuniceerd. Als je aanonderdelen 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 coördinatie hangen samen met organisatie en informatie. Een

goede decompositie leidt tot een goede coördinatie, hetgeen weer leidt tot een

goede informatie-uitwisseling. In zo’n geval spreek je van een goede

organisatie.

Op grond hiervan staan decompositie, coördinatie, 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

coördinatie . Iedere organisatie bestaat uit een aantal autonoom opererende

werkgroepen die onderling worden gecoördineerd. Die coördinatie 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 geïnterpreteerd alscommunicatie-inspanning.




13

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 danstelt 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 aspecten verbonden:productie- en organisatie-as

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 coördinatieprobleem 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



CT1061

14

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 (hetsysteem).

De twee assen kunnen eenvoudig worden samengevoegd.

Figuur 2.5: Organisatie- en productie-as

Hier kan nu de koppeling worden gemaakt met de eerder gespecificeerdeprojectinput, 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.




15

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 beïnvloeden.

Raakvlakken vereisen afstemmen, coördinatie. 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 efficiënt en effectief mogelijk kan worden voldaan

aan de wensen en eisen van de opdrachtgever.



CT1061

16




17

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 auto’s,

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 SystemEngineer 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



CT1061

18

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, accu’s, 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 financiële regeling, inclusief een inruil en een korting deal.

Maatwerk dus.

•

Het vierde niveau is de oplossingsruimte die de koper heeft gecreëerd na

zijn oriëntatiefase. 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.




19

3.3 Systeemtheoretische schaalniveaus

Vooruitlopend op hoofdstuk 6 kunnen een groot aantal schaalniveaus voor

systemen worden onderscheiden. Voor het gemak zijn de twee uitersten vanschaalniveaus 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 vansystemen

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 tweebasisgrootheden: waarde en kosten.



CT1061

20

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 tezijn 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 CivieleTechniek

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)




21

Figuur 3.5: Systems Engineering



CT1061

22




23

4

De factor tijd en planning in SystemsEngineering

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, recreëren, verbinden en opslag)

mogelijk. Hier krijgt de overheid inkomsten uit door allerlei belastingen enheffingen. 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 initiële stichtingskosten

betreffen, als renovatiekosten tijdens de levensduur.

Figuur 4.1: Kosten en inkomsten van een project



CT1061

24

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. Deesthetische 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 creëren 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 hetonderdeel dat wordt gemaakt, worden gefixeerd. Voor complexe projecten in




25

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



CT1061

26

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 iedergeval 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 deopbrengsten is geschetst in figuur 4.5.




27

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 variëren, maar is meestal 35 jaar. Dit

moet niet worden verward met de technische levensduur die soms welhonderd 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.



CT1061

28

Tabel 4.1: Ontwerpproces vs uitvoeringsproces

Ontwerp Realisatie

Gericht op veranderen Gericht op gefixeerd houdenClusteren op relaties Clusteren op gelijkvormigheid

Niet te veel mensen Veel mensen

Geen extreme tijdsdruk Extreme tijdsdruk werkt

Geen competitie Wel competitie

Trial and error Alles in een keer goed

Voor complexe systemen is het noodzakelijk om het werk te decomponeren en

de delen te coördineren (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 gecoördineerd 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




29

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. Ermoet 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, beïnvloedt 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 hetgrootst (zie figuur 4.8).



CT1061

30

Figuur 4.7: Onzekerheid en invloed

Beslissingen nemen onder grote onzekerheid is gevaarlijk. Om blunders te

voorkomen probeert de ontwerpleider zoveel mogelijk en op zo’n 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).




31

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 geïntegreerde 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.



CT1061

32




33

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 beïnvloed.

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 kunnenfixeren. 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:



CT1061

34

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 “reporter’s 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 dewaarde-as en anderzijds de kosten-as (zie figuur 5.2).




35

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



CT1061

36

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 metperceptieproblemen en de daarbij gepaard gaande onzekerheden het op zijn

minst naïef is om een vast doel als punt te definiëren. 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 capaciteitenworden onderscheiden:•

Opslagcapaciteit

•

Doorvoercapaciteit

• Transportcapaciteit

Voor de technische waarde kunnen meerdere dimensies wordenonderscheiden:• Energiegebruik

• Onderhoudsgevoeligheid

• Betrouwbaarheid

• Beschikbaarheid

Het is nu zaak om op de diverse waarde assen de oplossingsruimte te

definiëren. Een ruimte wordt begrensd door een onder- en een bovengrens. In

figuur 5.4 is schematisch een waarde-as geschetst waarop de begrenzingenzijn aangegeven.




37

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 enkelekwalificatiewedstrijd 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.



CT1061

38

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 maaktdat 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).




39

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



CT1061

40

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. Reductie MHW Rotterdam 1.60 m

2. Reductie MHW Dordrecht 0.60 m

3. Doorvaartopening 360 * 17 m

4. Ontwerplevensduur 100 jaar

Randvoorwaarden: 1. Locatie Maassluis +/- 3 km

2. Translatiegolf 10-4

3. Effect op stroomsnelheid 5%

(bij open kering)

Budget: Dfl 1.6 mld

Wensen: 1. Minimum scheepvaarthinder

tijdens de bouw

2. Onderhoudsvriendelijk

5.2.2 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 creëren.

De variabelen zijn: dimensies, oriëntatie, materialen, structuur en vorm.

5.2.3 Simulatie

De simulatiefase is uiterst belangrijk omdat het gedrag van de meest-

belovende 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.




41

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 geëigende 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).



CT1061

42

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

BeslissenDe 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




43

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, oriëntatie,

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.



CT1061

44

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 hij10.000 uren moet functioneren, bij normaal gebruik. De fabriek komt in




45

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 fabriekkomen 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 efficiëntie.

Het verband tussen de te verwachten afwijkingen en toleranties wordt bepaald

door het creëren 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




CT1061

46

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 deimprovisatiegevolgen van dien.

Met een afkeur- (tolerantie-)grens waarboven wordt afgekeurd, kan worden

bereikt dat de kans op onacceptabele productie aanzienlijk wordt verkleind.




47

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 tevinden. 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 verifiëren is het dus noodzakelijk om zowel eenverificatie 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.



CT1061

48




49

6

Systeemtheorie en complexiteit

6.1

Algemeen

Systeemtheorie is een van de basistheorieën 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 geïntegreerd geheel vormen.

Vanuit deze definitie gaan we het systeem verder exploreren en definiëren.

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 kleinstekrijgen 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



CT1061

50

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 beïnvloeden.

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.




51

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 hetmaximaliseren 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



CT1061

52

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 beïnvloeden of omgekeerd, worden beïnvloed 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.




53

6.3 Subsystemen, aspectsystemen en fasesystemen

6.3.1

AlgemeenOm 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

SubsysteemEen 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 trappenhuiseen 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.



CT1061

54

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.

Gesloten

2.

Openend

3.

Geopend

4.

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.

Parkeerstand

2.

Sluitend

3.

Kerend

4.

Spuiend

5. Openend




55

6.4 Toestand, proces en gedrag

6.4.1

AlgemeenNaast 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 inhet 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 destructuur, 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.



CT1061

56

•

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 optredenvan 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 omeen 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 beschrevenworden met de volgende formule:




57

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 beïnvloeden.

• 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 enverbinding, 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.



CT1061

58

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 geïllustreerd. Een ontwerper moet een systeemontwerpen 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 uitslechts twee elementen.




59

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 hiërarchie 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 wordtbehandeld.

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 systeembepalend zijn voor de complexiteit. Naast deze twee grootheden worden er in



CT1061

60

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” organiserenDit 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.




61

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 allenoodzakelijke 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 algemeneverhandeling 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 definiëren. Clusters bestaan uitdeelsystemen, die op hun beurt weer bestaan uit elementen met hun relaties.



CT1061

62

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

coördinatie.

• 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.




63

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.



CT1061

64

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).




65

7.4. Decompositiemethoden voor de ontwikkeling vancomplexe 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 coördineren.

•

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 methooggekwalificeerde 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.



CT1061

66

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 enoplossingen produceert voor een probleem, zelfs in een veranderende context.

Vanuit de systeemtheoretische kant van een ontwikkelingsproces wordt een

ontwerpopgave bepaald door de ontwerpvariabelen, die potentiële “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 tenaanzien 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 proberenof er wel mogelijkheden zijn om de variabelen min of meer onafhankelijk van




67

elkaar aan te passen. Het lijkt in eerste instantie vruchtbaar om de variabelen

te benaderen met behulp van de verzamelingenleer.

Veronderstel m variabelen: xi………xm

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 zo’n 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 coördineerbaar.

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.



CT1061

68

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 derelaties.

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 geïsoleerde 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 wordengestuurd en beheerst met alle aspectsystemen in samenhang. Dit

sturingsmechanisme is geschetst in figuur 7.8.




69

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



CT1061

70

•

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 naarsubsystemen)

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





71

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 dezemethode moeilijk te begrijpen is en als zodanig te ver af staat van de huidige



CT1061

72

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 risico’s.

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 nietbenijdenswaardig is. Uiteraard komt hij/zij er uiteindelijk wel uit, maar vraag




73

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 tebegrijpen.

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



CT1061

74

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.




75

8

Coördinatie 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

gecoördineerd. Beide factoren hebben zoals gezegd veel met elkaar te maken.

Het kunnen coördineren is een belangrijk uitgangspunt voor de manier waarop

we decomponeren. De gekozen decompositiemethode bepaalt de

coördinatiemogelijkheid. In hoofdstuk 7 is de verdeling van het werk reeds

behandeld. In dit hoofdstuk wordt ingegaan op hoe een en ander

gecoördineerd moet worden.Het coördinatiemodel 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 beïnvloeding van het bestuurd systeem

•

Externe besturing die gericht is op de beïnvloeding van de omgeving



CT1061

76

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 hiërarchie 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 de gewone besturing over zes

sturingsmogelijkheden:• Interne routine metasturing

• Interne adaptieve metasturing

• Intern doel metasturing

• Externe routine metasturing

• Externe adaptieve metasturing

• Extern doel metasturing

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).




77

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-meta-

besturingsconfiguratie wordt de metabestuurder weer bestuurd door een

meta-metabestuurder. Dit is weergegeven in figuur 8.4.

Figuur 8.4: Meta-metabesturing

8.3.3 Coördinatie en metabesturing

Coördinatie 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 coördinatie 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



CT1061

78

twee stappen te doen. Deze twee stappen zijn dan eenvoudig in een meta-

besturingsconfiguratie 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 Coördinatie en decompositie

Nu de verschillende meta-besturingscoördinaties gekoppeld zijn aan een

coördinatie, 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: Coördinatie en decompositie

De twee koppelingen zijn:

• Doelcoördinatie: aspectsystemen

• Structuurcoördinatie: clusters van elementen

Duidelijk is dat de coördinatie primair gericht is op het systeem en de daarin te

onderscheiden deelsystemen. Dat is van groot belang, omdat dat de

coördinatie 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.




79

8.4 Voorwaarden voor effectieve besturing

8.4.1

AlgemeenMet 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 besturingsvariëteit te beschikken

4.

Informatie te hebben over de van invloed zijnde omgevingsparameters die

in het model van het systeem zijn geïdentificeerd

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

besturingsvariëteit. De punten 4, 5 en 6 komen aan de orde in hoofdstuk 10:

Informatie.



CT1061

80




81

9

Doel, model en besturingsvariëteit

9.1

Algemeen

Doel, model en besturingsvariëteit 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 besturingsvariëteit 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



CT1061

82

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 aande orde moeten komen. We spreken dus eigenlijk van een

doelgeoriënteerde 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 entechnische 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).




83

9.2.3 Doel als het product van effectiviteit en efficiëntie

Er wordt in de meeste processen gestuurd op zowel effectiviteit als efficiëntie.

(zie figuur 9.3)

Figuur 9.3: Effectiviteit en efficiëntie

Er geldt:

Effectiviteit = P/PO

Efficientie = K O /K

Met:

P = werkelijke prestatie

PO = normprestatieK = werkelijke kosten

K O = 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 effectiviteitP/PO < 1

• De kosten worden onderschat. Het valt altijd tegen. Daarom is de

efficiëntie K O /K < 1

In de gangbare bedrijfskunde is het product van effectiviteit en efficiëntie 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 definiëren als de tolerantie ruimte rond de specificatie. (ziehoofdstuk 5.)



CT1061

84

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 categorieën

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 categorieën drie soorten entiteiten teonderscheiden:

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).




85

Tabel 9.1: De verschillende model - systeemparen

Modellen Voorbeeld

Concreet model van een concreetsysteem

Het gedrag van staal onder trek

Concreet model van een conceptueel

systeem

De piramide van Cheops as een

toepassing van de stereometrische

figuur piramide

Concreet model van een formeel

systeem

Een temperatuurschaal als een

toepassing van de formele

getallentheorie

Conceptueel model van een concreet

systeem

Een relatiediagram als een model van

alle interrelaties tussen de elementen

van een systeem

Conceptueel model van eenconceptueel systeem

De algebraïsche representatie vaneen cirkel

Conceptueel model van een formeel

systeem

Een taalsysteem van de formele

logica

Formeel model van een concreet

systeem

Een mathematisch model van een

economisch proces

Formeel model van een conceptueel

systeem

De Euclidische ruimte

Formeel model van een formeel

systeem

De vertaling van een formeel systeem

naar een ander

Op grond van de tabel kan worden vastgesteld dat voor een besturingsmodelvoor 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 driesoorten 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 theorieën. Deze modellen overbruggen het gat tussen de theorie

en de empirische wereld en worden gebruikt om het gedrag van systemente simuleren.



CT1061

86

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 deverzameling 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 gedachte-

experimenten, reconstructies en hypothesen en (2) empirische

ideaalmodellen die meestal gesimplificeerde prototypes zijn. Het

belangrijkste principe is een geïdealiseerde begrenzing. Een speciaal

ideaalmodel is de “Black Box” die tussen een open en gesloten systeeminstaat. 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 hiërarchisch schema van Black Box

modellen.

• Mathematische modellen, die een theoretische afbeelding zijn van de

werkelijkheid.

De modellen die gebruikt worden voor het sturen van eenontwikkelingsopgave 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:

• 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 geïdentificeerd.• Streef niet al te precieze modellen na in een vroege fase. Een snel overall




87

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 eengevoeligheidsonderzoek.

• 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 Besturingsvariëteit

9.4.1

AlgemeenIn 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 = K O /PO x P/K

Te zien valt dat bij constante K O 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>K O)

9.4.4 Geen afwijking van het initiële doel

In dit specifieke geval kan alleen worden besloten tot het verhogen van de

waarde van P/K.




89

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 ontwerp-

en 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 beïnvloeding.

Beïnvloeding 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



CT1061

90

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, gerekendbinnen 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 “perceptioneleonzekerheid” 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 bekendover 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 gegevendie nergens op gebaseerd zijn. Maar met deze kansverdelingen worden dan




91

wel zeer precieze berekeningen gemaakt die rechtstreeks worden gebruikt

voor beslissingen!

Als er niets bekend is kun je beter je toevlucht nemen tot de kwalitatieverisicoanalyse. 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 (coördinatie) voor haar rekeningneemt. 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 coördinatie 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.



CT1061

92

Distributie gewenst gedragZoals 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 wordtgekozen voor het contant maken van de budgeten

Ophalen actuele gedragHet 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 eengevoeligheidsonderzoek. 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.




93

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 coördinatie

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 coördinatie is groot als er sprake is van grotecomplexe systemen en er in geval veel mensen bij het project zijn betrokken.




95

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 gegeven voor effectieve

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 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 hetontwerpwerk, met delen van een geheel een kwestie is van informatie-

uitwisseling. 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.



CT1061

96

Figuur 10.3: Decompositiediagram

Werken aan het elementOp het laagste werkniveau wordt er gewerkt aan de vorm van de elementen.

Dat gebeurt simultaan. Vorm betekent: plaats, oriëntatie, 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, financiële (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 onderhoudsschema’s, 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 collega’s 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) wordtgegeven. Voorts wordt een indicatie gegeven van de marginale meerkosten




97

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 hetbesef 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 clusterZoals 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 geëiste 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 wordtgekeken, 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 watzeker is en datgene wat onzeker is.

Werken aan het systeemOp 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



CT1061

98

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 gecoördineerd wordt. Dit betekent dat modelonderzoek wel

vanuit de elementen en clusters geïnitieerd wordt, maar centraal in de

projectorganisatie op elkaar wordt afgestemd. Dit gebeurt om dubbel werk te

voorkomen.




99

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. Zijworden in eerste instantie aangesteld voor de coördinatie, 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 coördinatie 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 optimaalingezet 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).



CT1061

100

Figuur 11.2: Vijf onderdelen van een organisatie

1. De uitvoerende kern

2. De strategische top

3. Het middenkader

4. De technostructuur

5. 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



CT1061

102

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 eenfunderingsexpert 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 hiërarchie. 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 zo’n 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 moetenwerken 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 extradisciplinairwerken

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




103

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

gecoördineerd door de leider van het werk aan een element.

Het werk aan verschillende elementen vindt op korte termijn plaats binnen eencluster.

Het werk binnen het cluster is multi-disciplinair en er wordt interdisciplinair

gecoördineerd. Daarboven is er sprake van structurele coördinatie, die

gekenmerkt wordt door het in de gaten houden van de relaties tussen de

elementen onderling.

Het werk aan het systeem wordt extra-disciplinair gecoördineerd. 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

coördinatie) 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 coördinatie van de

ontwerpopgave. Met het daaruit ontstane beeld van de informatievoorziening

kan een relatieschema worden geschetst. Dit is links in figuur 11.5

weergegeven.




105

11.7 De disciplinaire inbreng

De disciplinaire inbreng kan niet direct in het organisatieschema worden

ondergebracht. Het kan overigens wel in een relatieschema wordenondergebracht. 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 georiënteerd is op de mens. Komt

vaak voor in professionele organisaties. Leden beïnvloeden elkaar en er is

weinig hiërarchie.

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 eneen rolcultuur heerst.

• Responsieve organisatie, waarin een mengvorm van een rolcultuur en een

taakcultuur heerst.

• Creërende 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.



CT1061

106

Tabel 11.1: Organisatorische issues

Aspect Reactieve

organisatie

Responsieve

organisatie

Creatieve

organisatietijd verleden heden toekomst

doel overleven output creëren

planning rechtvaardig activiteiten strategie

veranderingsmethode bestraffend aanpassend organisch

management schuldvraag coördinatie navigatie

structuur hiërarchisch matrix netwerken

oriëntatie egocentrisch team cultuur

motivatie pijn vermijden beloningen bijdrage

communicatiemethode opgedrongen feed back feed through

leiderschapstijl dwingend sturend 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 creërende organisatievorm. Dit wordt geïllustreerd in tabel

11.2:

Tabel 11.2: Responsieve en een creërende organisatievorm

Aspect Invulling Organisatievorm

tijd toekomst creërend

doel output responsief

planning activiteiten responsief

veranderingsmethode aanpassend responsief

management coördinerend responsief

structuur hiërarchisch/matrix/netwerk reactief/responsief/creërend

oriëntatie team responsief

motivatie bijdrage creërend

communicatiemethode feed back/feed through responsief/creërend

leiderschapstijl sturend/inspirerend responsief/creërend

11.9 De stap naar productontwikkeling

Op een andere manier is er ook sprake van verschillende culturen. Dat verschilheeft te maken met de aard van het te doorlopen proces. Dan spreken we

over: (1) een ontwerpcultuur met een overwegend creërende

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.



CT1061

108

Figuur 11.7: Productontwikkeling binnen een bedrijf

Duidelijk is dat de behandelde decompositie, coördinatie 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.




109

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 kortetermijn 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 geïsoleerde 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 creëren van blokken zodanig dat wordt voldaan aan

de decompositieregel. Er zijn verschillende decompositievormen.

De volledige decompositie Als de relatiematrix A kan worden verdeeld in:



CT1061

110

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 hiërarchische decompositie

Een andere - meer realistischere- decompositie is de zogenaamdehiërarchische 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 hiërarchische decompositie wordt hieronder geïllustreerd 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.




111

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 gecreëerd. Dit resulteert bijvoorbeeld in de volgende

getransformeerde matrix:



CT1061

112

Het systeem dat op deze manier is gedecomponeerd is weergegeven in figuur

A.3.

Figuur A.3: Hiërarchische 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 decompositieEen 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 ennullen dikke zwarte punten te gebruiken. Visueel is dat overzichtelijker. Voor




113

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.



CT1061

114




115

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 relatiesIn 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 variëren. 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



CT1061

116

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 vóór 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), descharnierfundatie (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.




117

Figuur A.8: Eerste clustering

Figuur A.9: Tweede clustering



119

13 Bijlage B: Ekofisk Barrier

THE TOP DOWN RISK MANAGEMENT SYSTEM OF THE OFFSHOREOPERATIONS OF THE EKOFISK PROTECTIVE BARRIER

By dr Hennes A J de RidderProfessor in Design and Construction Management, Faculty of Civil Engineering and Geosciences,

Delft University of Technology, The Netherlands.

ABSTRACT

The Ekofisk Field in the centre of the North Sea is a veryimportant 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 thetotal offshore operations, including tow-out, installation,coupling and completion. The operations were governedby conflicting requirements with respect to relevantaspects like stability, strength, stiffness, weight,geometry and were perceived to be extremely risky dueto the marginal resistance against the expected loadcases. The operations were weather dependent, thusdominated by changing stochastic boundary conditions.Most of the processes were irreversible, non-linear, anddetermined by a large number of variables. A top downrisk management system was developed for controlpurposes. The system provided a continuous insight rightfrom the very start of the project till the end of theproject in the percentage of failure in the most relevantfailure modes as a function of tow out date. The systemallowed for strategic, tactical and operationalinterventions in case critical criteria were exceeded. Thisin particular makes that the approach – even 10 yearsafter completion of the project – is still a newdevelopment in risk management and an interestingbasis of further research on control of the design,construction and installation of complex Civil Engineeringand other Systems.

INTRODUCTION

In 1987 it was necessary to elevate the decks supportedby steel jackets at the Ekofisk Field due to significantseabed subsidence, which resulted in an increased waveload [12]. A different solution however was required forthe central concrete bottom founded tank, supporting themain field processing facilities. The solution adopted wasa bottom founded concrete protective barrier surroundingthe existing tank structure. The Engineering,Procurement, Construction and Installation contract forthe project was awarded to Peconor Ekofisk AF inFebruary 1988.The Ekofisk Protective Barrier was, and still is, rather

unique. Firstly, it was the first offshore concreteconstruction, which was not installed as a monolith.Secondly, the shape of the construction is different fromall realised structures in this construction discipline.Thirdly, the wave load on the structure during both theconstructional phase as well as the utilisation phase isbeyond the load on any other existing offshore structure.The most significant characteristic of the project was theavailable total development time with respect to the sizeof the project. The Ekofisk Protective Barrier wascompleted in autumn 1989 [13].

THE CONCEPT AT THE START OF THE PROJECT

The concept of the Protective barrier was developed fromthe basic requirement that the oil and gas producingactivities may not be disturbed. Two floating caissons, tobe towed to the Ekofisk field, placed on the seabedaround the tank and subsequently connected with eachother. A horizontal cross section of the Protective Barrierand a side view is given in figure 1.



120

Figure 1 Concept of the Ekofisk Protective barrier

The most critical phase was the connection of the twobarrier halves [14]. After installation on the seabed, thetwo barrier halves had to provide enough strength andstability to withstand the design wave condition during joint connection works. The connection itself was to beprovided by key piles to be inserted in circular recesses in

interlocking keys and in-situ concrete to be cast in theremaining holes. This concept is sketched in figure 2.

Figure 2 Initial concept of the joint connection

THE PROBLEMS WITH INSTALLATION ANDOFFSHORE COMPLETION

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 loadswith 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 soilcondition, the stability of the uncoupled barrier halveswas not ensured during the temporary offshore phase atthe offshore location. Stability could be improved byincreasing the amount of ballast. A larger amount ofballast however would cause larger differentialpenetration and settlements due to non-uniform soil

conditions. This would lead to horizontal fitting problems(figure 3a). Due to the fitting problems, it was advisableto limit the amount of ballast prior to joint connectionworks. Unfortunately, the initial phasing of a reducedballast quantity would lead to larger built-in stresses dueto deformations after the connection works when thebalance of the ballast was added (figure 3b).

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.



121

a.

b.

Figure 3 Geometrical problems and strength problemsassociated with ballasting strategy

Confronted with the stability problem, the client decidedto change the summer storm-condition. Instead of a 10-year return period, a 3-year return period was decidedupon for the governing wave condition. However, even

this wave condition proved to be too heavy to ensurestability. Besides that, the tolerance problem remained.In addition, model tests on floating behaviour resulted inlarger wave induced motions than assumed during thefloating position prior to installation of the second halfunit. In order to avoid clashes, the gap between the twoinstalled halves had to be enlarged. As result the amountof concrete to be cast into the gap became larger. Inconsequence, the necessary concreting time andhardening time increased. As motions were not allowedduring the hardening time and periods without waveaction are hardly available in the North Sea, the offshoreoperations became more difficult. This, together withseveral related features as tolerances, clearances,strength, fatigue, construction problems, etc. enforced achange in the connection method from the key and keypile concept into a steel plate and prepared box concept.The enforced change took place approximately sevenmonths after the start of detailed engineering. At thattime the lowest keys were already constructed. Thechanged joint concept is sketched in figure 4.

Figure 4 Changed concept of the joint connection

DESIGN APPROACH

Tolerances, stability and temporary strength duringinstallation and offshore completion revealed

contradictory requirements with respect to ballasting. Onthe one hand the fitting problem would be less critical ifthe amount of ballast prior to the connection is as less aspossible, on the other the stability of the uncoupledhalves and the strength of the joint would be less criticalif the maximum amount of ballast is achieved as soon aspossible. Right from the start, the design team wasconfronted with critical choices at system level. Decisionshad to be made under a number of uncertainties. Thebest way to attack the design dilemma was to describethe total behaviour of the installation and subsequentoffshore completion with respect to the critical aspects in

a mathematical model of the system at the highestabstraction level. In that way the relatively small amountof knowledge at the start of the project could be used inthe most critical phase of the project (figure 5). Thismakes that the approach followed still is advanced. Mostrisk management systems are developed in later designphases focussing on components and elements.



122

Figure 5 Influence on design process, development ofknowledge and uncertainties as a function oftime and scale levels

Given the urgency and the main purpose, it was clearthat the risk management systems must be kept assimple as possible and split up where possible. Thisresulted in a tolerance model and a stability/ strength-model. Moreover it was important to develop the modelsfrom rough to fine. Rough insight in the main aspectsand associated solutions at the early project phases wasrecognised more important than fully validated models atthe end of the project.

TOLERANCE RISK MANAGEMENT SYSTEM

A detailed analysis of the fitting of the jointconstructions, which had to cope with deformations,deviations; and displacements, concluded that adeterministic approach would lead to unrealistic jointdimensions. Due to the three-dimensional problem as afunction of the height, and the stochastically independentprocesses, a Monte Carlo simulation model was adopted.The simulation runs aimed at establishing the effects ofdesign variables, environmental boundary conditions and

the processes on the probability of failure. The tolerancemodel was developed for the temporary phase afterinstallation of both barrier halves and compriseddeformations, deviations, displacements and availableclearances of the two barrier halves with respect to eachother during the offshore operations.

Failure was defined as a misfit of at least one of theconstruction parts. A result of a fitting simulation is givenin figure 6, showing the composite tolerance chart andthe 10000 simulations. The simulation model was able todetermine the relative contribution of the variousprocesses to the total failure. Hence it was simple todetect the most critical processes, which made thetolerance model a sophisticated coordination system. Theeventual result of the tolerance model given in probabilityof failure as a function of on bottom weight of the halfunits is given in figure 7.

Figure 6 Probability of failure with respect to tolerancesas a function of on bottom weight

PROBABILITY

OF FAILURE

10%

5%

1000 1200 1400 1600 1800 2000 2200 2400

CRITERION

ON BOTTEM WEIGHT

IN MN

Figure 7 Result of the tolerance risk management system

TIME

100 %

0

INFLUENCE ON

PROJECT

KNOWLEDGE

AVAILABLE

TIME

100 %

0

SYSTEM LEVELCOMPONENT LEVEL

ELEMENT LEVEL

UNCERTAINTY



123

THE STABILITY AND STRENGTH RISKMANAGEMENT SYSTEM

The dynamic model was built around the basic failurefunctions for stability and strength. The purpose of thecoordination model was to visualise the critical items and,given the failure criterion, to establish the optimalsequence and the latest possible start date and todetermine the various process parameters. The basis ofthe model was the offshore planning, which consisted oftwo basic phases. The first was the uncoupled phase oftwo barrier halves, with stability as failure mode. Thesecond was the connection phase. Wave action washardly allowed during this phase and strength was themain failure mode.

A main part of the model was the wave climate, whichwas important for the operations itself and also for the

waveloads. Wave information was available by existingscatter diagrams of wave heights, wave directions andwave periods. An autocorrelation function wasestablished using Ekofisk time series of waves over aperiod of ten years. With this information the waveclimate was generated by simulation runs and comparedwith actual time series.In order to get insight in the wave loads on the barrierhalves, a series of model tests were conducted at SSPAGoteborg. Unfortunately, only the most critical wavedirection was investigated. Therefore the wave load onthe barrier half units as function of incident wave

direction was determined using a diffraction model.The resistance of the uncoupled barrier halves againstwave loads was a function of on bottom weight and soilproperties. Due to the "horse foot" shaped bottom slab,the backward wave induced moments were thegoverning wave loads. The results of the soilinvestigation showed that the soil properties east of thetank were substantially worse than the soil propertieswest of the tank. The backward allowable overturningmoments were expressed in parameters of a Gaussiandistribution (figure 8).

Figure 8 Backward allowable moments on the barrier

halves

The allowable motions during the grouting operations ofthe joint construction were zero. Any motion would havea negative influence on the eventual quality of theconcrete. Due to this, a connection was made at the topof the two barrier halves. However, this connection couldonly take favourable summerstorm conditions. This wasthe reason that contingency plans (differential ballasting)and even emergency plans had to be developed for thecase that the operation for what reasons ever would beget into wave conditions worse than the workingconditions agreed upon (figure 9).

Figure 9 Development of strength during the connectionworks as a function of time



124

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.

June

tow outJuly Aug Sept

20

30

40

50

60

10

0

west

east

connection

strength/stability

load

1%

10%

50%

moment

Figure 10 Indication of resistance moments of the barrierhalves and wave induced moments on thebarrier halves during the temporary phasesoffshore

As can be seen the safety against failure is marginalduring 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 offshorecompletion works per run. Per simulation firstly the waveclimate was established. Then the activities withassociated weather windows were put in. After thatfailure functions could be established per time step. Foreach failure mode the number of failures was counted.From these numbers the total probability of failure couldeasily be determined. Several cases were investigated bythe model. Sensitivity analyses were carried out forballast strategies and delays. A lot of interesting data could be established. Forinstance total workability and total duration of theinstallation operation, as a function of start date andexpressed in probability of exceedance. The mainoutcome is the probability of failure of the maincomponents as a function of tow out date (figure 11).

TOW OUT DATE

10/6 20/7 10/8 1/9 20/91/7

5

4

6

7

3

2

1

P R O B A B I L I T Y O F F A I L U R E I N

%

CRITERION

WESTERN HALF

EASTERN HALF

JOINT

Figure 11 Probability of failure with respect to strength

and stability as a function of tow out date.



125

CONCLUSIONS

The Ekofisk Protective Barrier project was a uniqueproject. The complexity and difficulty of the project

were large due to a combination of non linear,irreversible, mutually dependant processes around a riskyconcept which was exposed to transient stochasticloadings.Conflicting design aspects for the offshore operationmade it necessary to develop a top down risk modelwhich could be used for control purposes and decisionmaking right from the beginning of the project.For the development of the installation and offshorecompletion of the Ekofisk Protective Barrier, two dynamicrisk 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 fullprobabilistic Monte Carlo simulation of the totalprocedure including both the environmental conditionsand taking into account a large number of influencingvariables.The Dynamic Risk Models developed for the EkofiskProtective Barrier proved to be very worthy for thecontrol of complex design work and the subsequentconstruction and installation. Although developed in1990, the integrated and dynamic approach can beconsidered as state of the art in top down RiskManagement of the design of complex systems.

REFERENCES

11. Croucher, T.M., Integrated Team Approach to theDesign, Construction, Stat Up and Operation ofthe World's Most Modern Drilling Rig. Spe Drillingand Completion, 1999. 14(3): p. 201-207.

12. Broughton, P. and K. Waargaard, The EkofiskProtective Barrier. Proceedings of the Institutionof Civil Engineers - Water, Maritime and Energy,1992. 96(2): p. 103-119.

13. de Ridder, H.A.J. Design of th Installation andOffshore Completion of the Ekofisk Barrier . inProceedings of the Sixth InternationalConference on the Behaviour of OffshoreStructures . 1992. London.



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 praktijkIn 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 geïntregreerde 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, creëert 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 volgensde tekeningen en specificaties maakt.

In de geïntegreerde 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 geïntegreerde 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

verifiëren en valideren waarbij inderdaad geen verschil tussen die totaalverschillende toetsingen wordt gemaakt [18]. Met Systems Engineering wordt



129

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 gemaaktetekeningen 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.



15 Referenties

1. Morris, P.W.G., The Management of Projects , 1994, London: ThomasTelford.

2. Flyvbjerg B., Bruzelius N., and R. W., Megaprojects and risk: An

anatomy of ambition , 2008, Cambridge: Cambridge University Press.3. Belbin, R.M., Management Teams: Why They Succeed Or Fail , 2010:

Butterworth-Heinemann.4. Bono, E.D., Lateral thinking: creativity step by step , 1973: Harper &

Row.5. Bono, E.D., Six Thinking Hats , 2008: Penguin Group.6. Hanken, A.F.G. and H.A. Reuven, Inleiding tot de systeemleer , 1976,

Leiden: Stenfert Kroese.7. Simon, H.A., The Architecture of Complexity. Proceedings of the

American Philosophical Society, 1962. 106(6).8. Mintzberg, H., The Structuring of Organizations , 1979, Englewood

Cliffs, N.J.,: Prentice Hall.9. Leeuw, A.C.J., Bedrijfskundig management;:primair proces, strategie

en organisatie , 2002, Assen: van Gorcum.10. Leeuw, A.C.J., Besturen van veranderingsprocessen , 1994, Assen: van

Gorcum.11. Mintzberg, H., Structure in fives: designing effective organizations ,

1994, Englewood Cliffs: Prentice Hall.12. Croucher, T.M., Integrated Team Approach to the Design,

Construction, Stat Up and Operation of the World's Most ModernDrilling Rig. Spe Drilling and Completion, 1999. 14(3): p. 201-207.

13. Broughton, P. and K. Waargaard, The Ekofisk Protective Barrier. Proceedings of the Institution of Civil Engineers - Water, Maritime andEnergy, 1992. 96(2): p. 103-119.

14. de Ridder, H.A.J. Design of th Installation and Offshore Completion ofthe Ekofisk Barrier in Proceedings of the Sixth International

Dictaat CT3061 Compleet - V2012

Documents

Transcript of Dictaat CT3061 Compleet - V2012