Critical Chain Buffer Management - Ghent University › fulltxt › RUG01 › 001 › 788 › 508...

UNIVERSITEIT GENT

FACULTEIT ECONOMIE EN BEDRIJFSKUNDE

ACADEMIEJAAR 2010 – 2011

Critical Chain Buffer Management

Een simulatiestudie tot het

correct bepalen van de Project Buffer

Masterproef voorgedragen tot het bekomen van de graad van

Master in de Toegepaste Economische Wetenschappen: Handelsingenieur

Christophe Bostyn

Jordy De Loose

onder leiding van

Prof. Dr. Mario Vanhoucke

UNIVERSITEIT GENT

FACULTEIT ECONOMIE EN BEDRIJFSKUNDE

ACADEMIEJAAR 2010 – 2011


Een simulatiestudie tot het

correct bepalen van de Project Buffer

Masterproef voorgedragen tot het bekomen van de graad van

Master in de Toegepaste Economische Wetenschappen: Handelsingenieur

Christophe Bostyn

Jordy De Loose

onder leiding van

Prof. Dr. Mario Vanhoucke

Permission

Ondergetekenden verklaren dat de inhoud van deze masterproef mag geraadpleegd en/of

gereproduceerd worden, mits bronvermelding.

Chistophe Bostyn

Jordy De Loose

I

Woord vooraf

Ter afsluiting van onze studies Master in de Toegepaste Economische Wetenschappen:

Handelsingenieur, afstudeerrichting Operations Management aan de Universiteit Gent, schreven we

deze masterproef. Het onderwerp ligt in het verlengde van het vak Project Management uit de eerste

Master. Geboeid door de wereld van projecten, gingen we van start.

Graag willen wij onze oprechte dank betuigen aan enkele mensen die hun medewerking hebben

verleend tot het opbouwen van dit eindwerk. Vooreerst willen we onze promotor, tevens Professor van

het vak Project Management, Prof. Dr. Mario Vanhoucke, bedanken voor zijn tijd, advies en hulp. Hij

stond steeds klaar om onze vragen te beantwoorden en nieuwe ideeën aan te brengen. Ook heeft de

vakgroep Statistiek ons veelal voortgeholpen in het oplossen van “significante” problemen.

Onze familie en vrienden willen we bedanken voor de morele steun. Zonder hun steun gedurende heel

onze opleiding was ook dit eindwerk niet mogelijk geweest. Als laatste willen we ook Lore Goessaert

danken voor de grammatica- en spellingcontrole.

II

Inhoudsopgave

Woord vooraf ................................................................................................................................ I

Inhoudsopgave ............................................................................................................................... II

Gebruikte afkortingen ....................................................................................................................... V

Verklarende woordenlijst ................................................................................................................. VI

Lijst van de figuren en tabellen ......................................................................................................... IX

Figuren ..................................................................................................................................................... IX

Tabellen ................................................................................................................................................... XI

Inleiding ............................................................................................................................... 1

Hoofdstuk 1: Projecten en Netwerk Scheduling ............................................................................. 3

1.1 Een eenvoudig netwerk ................................................................................................................ 3

1.2 Resource Constrained Project Scheduling.................................................................................... 4

1.3 Prioriteitsregels ............................................................................................................................ 6

1.4 De Basic Feasible Schedule ........................................................................................................... 6

1.5 Problemen bij Project Scheduling ................................................................................................ 9

1.5.1 Schattingen van de activiteitsduur ....................................................................................... 9

1.5.2 De wet van Parkinson ......................................................................................................... 10

1.5.3 Het Student Syndrome ....................................................................................................... 11

1.5.4 Merge Bias .......................................................................................................................... 11

1.5.5 Multi-tasking....................................................................................................................... 12

Hoofdstuk 2: Critical Chain Buffer Management (CC/BM) ............................................................ 14

2.1 Theory of Constraints toegepast op Project Management ........................................................ 14

2.2 De Critical Chain ......................................................................................................................... 15

2.3 Buffers ........................................................................................................................................ 16

2.3.1 Project Buffers .................................................................................................................... 17

2.3.2 Feeding Buffers ................................................................................................................... 18

III

2.3.3 Bepaling van de Buffergrootte ........................................................................................... 19

2.4 Doel van Critical Chain Buffer Management .............................................................................. 21

Hoofdstuk 3: Doelstellingen en setup van het model ................................................................... 23

3.1 Einddoelstellingen en modeltoelichting ..................................................................................... 23

3.1.1 Einddoelstelling .................................................................................................................. 23

3.1.2 Het model ........................................................................................................................... 26

3.2 Netwerkgenerator ...................................................................................................................... 26

3.3 Basic Feasible Schedule .............................................................................................................. 27

3.4 (Feeding) Buffered Schedule ...................................................................................................... 29

3.4.1 Buffered Schedule .............................................................................................................. 29

3.4.2 Feeding Buffered Schedule................................................................................................. 29

3.5 Simulated Schedule .................................................................................................................... 33

3.5.1 Projected Schedule ............................................................................................................. 33

3.5.2 Variantie en verdeling van de activiteitsduurtijden ........................................................... 34

3.5.3 Variantie van de projectduurtijd ........................................................................................ 36

3.5.4 Simulated Schedule inclusief het 95%-betrouwbaarheidsinterval ................................... 36

Hoofdstuk 4: Resultaten van de experimenten ............................................................................ 38

4.1 Feeding Buffered Schedule ........................................................................................................ 39

4.1.1 Invloed van SP op de projectduurtijd ................................................................................. 39

4.1.2 Invloed van RC op de projectduurtijd................................................................................. 40

4.1.3 Invloed van de combinatie van RC en SP op de totale duurtijd ......................................... 41

4.1.4 Invloed van Feeding Buffergrootte op de projectduurtijd ................................................. 46

4.1.5 Invloed van Whitespaces op de projectduurtijd ................................................................ 47

4.2 Simulated Schedule inclusief het 95%-betrouwbaarheidsinterval ............................................ 54

4.2.1 Invloed van SP op de projectduurtijd ................................................................................. 54

4.2.2 Invloed van RC op de projectduurtijd................................................................................. 56

4.2.3 Invloed van de combinatie van RC en SP op de totale duurtijd ......................................... 56

IV

4.2.4 Invloed van de variantie van de activiteitsduurtijden op de projectduurtijd .................... 58

4.3 De Project Buffer Factor ............................................................................................................. 59

4.3.1 De Referentiefactor ............................................................................................................ 59

4.3.2 Combinatie van SP & RC ..................................................................................................... 60

4.3.3 Invloed van de Feeding Buffergrootte ............................................................................... 60

4.3.4 Invloed van de Variantie van de activiteitsduurtijden ....................................................... 62

4.3.5 Invloed van Earliness/Lateness van de activiteitsduurtijden ............................................. 63

4.3.6 Een uitgewerkt voorbeeld .................................................................................................. 63

4.4 Controle van de Critical Chain elementen.................................................................................. 65

Hoofdstuk 5: Conclusie ............................................................................................................... 69

Hoofdstuk 6: Bibliografie ............................................................................................................ 73

Bijlage ............................................................................................................................. 76

Bijlage 1.1 De Buffered Schedule ..................................................................................................... 76

Bijlage 1.1.1 Origineel ..................................................................................................................... 76

Bijlage 1.1.2 Trendlijn correctie ...................................................................................................... 76

Bijlage 1.2 Simulated Schedule incl. 95%-betrouwbaarheidsinterval ............................................. 77

Bijlage 1.2.1 Origineel ..................................................................................................................... 77

Bijlage 1.2.2 Trendlijn correctie ...................................................................................................... 77

Bijlage 1.3 De Project Buffer Factor ................................................................................................. 78

Bijlage 1.3.1 Invloed van de Feeding Buffergrootte........................................................................ 78

Bijlage 1.3.2 Invloed van de variantie van de activiteitsduurtijden ................................................ 81

Bijlage 1.4 Controle van de Critical Chain ........................................................................................ 84

V

Gebruikte afkortingen

Afkorting Verklaring

ALAP As-Late-As-Possible

AoA Activity-On-Arc

AoN Activity-On-Node

ASAP As-Soon-As-Possible

BI Betrouwbaarheidsinterval

CC Critical Chain

CC/BM Critical Chain Buffer Management

CP Critical Path

FB Feeding Buffer

N-CC Niet-Critical Chain

OS Order Strength

PB Project Buffer

PS Projected Schedule

RC Resource Constrainedness

RCPSP Resource-Constrained Project Scheduling Problem

SP Graad van Serialiteit/Parallellisme

SPT Shortest Processing Time

SS-95% Simulated Schedule inclusief het 95%-Betrouwbaarheidsinterval

TOC Theory of Constraints

VI

Verklarende woordenlijst

Benaming Uitleg Verwijzing

(p.)

Activiteit

Een activiteit is een bepaalde taak die moet uitgevoerd

worden als onderdeel van een project. Dit kan heel ruim

zijn, zoals het afwerken van een gehele verdieping van een

appartement, evenals heel gedetailleerd, bijvoorbeeld het

boren van een gat in de muur, afhankelijk van de interne

doelstelling.

3

Basic Feasible Schedule

De Basic Feasible Schedule is een schedule van een bepaald

projectnetwerk dat voldoet aan enerzijds alle

volgorderelaties en anderzijds alle Resource Beperkingen.

6

Buffered Schedule

De Buffered Schedule is een ge-reschedulede vorm van de

Basic Feasible Schedule, samen met de Feeding Buffers,

inclusief de toevoeging van de Project Buffer.

29

Dummy activiteit

Een dummy activiteit is een fictieve activiteit, die een

bepaald event vaststelt. In dit werk is er een Start Dummy

activiteit ( = het netwerk begint) en een Finish Dummy

activiteit ( = alle activiteiten zijn gescheduled/uitgevoerd).

3

Duurtijd Een duurtijd wijst op het aantal tijdseenheden, die een

bepaalde activiteit nodig, heeft om uitgevoerd te worden. 3

Feeding Buffer

Feeding Buffers zijn de buffers die de Critical Chain

beschermen tegen externe vertragingen. Ze zijn dan ook

gepositioneerd waar de Niet-Critical Chain zich invoegt in de

Critical Chain.

18

Feeding Buffered Schedule

De Feeding Buffered Schedules is een Buffered Schedule

waarvan de Project Buffer is weggenomen. Deze wordt hier

in feite mede gebruikt ter bepaling van de Project Buffer.

29

VII

Feeding Chain Een Feeding Chain bestaat uit een chain van transitieve niet-

Critical Chain activiteiten. 18

Mijlpaal Een mijlpaal verwijst naar het tijdstip waarop de voltooiing

van een individuele activiteit zou moeten plaatsvinden. 3

Project Buffer

De Project Buffer bevindt zich aan het einde van de Buffered

Schedule. Ze biedt bescherming tegen vertragingen in de

Critical Chain.

17

Projected Schedule

De Projected Schedule wordt gevolgd voor de uitvoering van

het project. Ze is gelijk aan de Basic Feasible Schedule

waarvan de activiteiten As-Soon-As-Possible worden

gescheduled.

33

RC of de Resource

Constrainedness

In dit onderzoek werken we met hernieuwbare resources.

Dit wil zeggen dat we op elke tijdsperiode X aantal resources

ter beschikking hebben, onafhankelijk van het verbruik in de

vorige periodes (bv. Een team van 10 mensen). De RC

bepaalt het percentage dat een activiteit gemiddeld

gebruikt van dit aantal beschikbare resources. Wanneer dit

bijvoorbeeld 0.3 is, zullen de activiteiten gemiddeld 3

mensen van de 10 nodig hebben. In dit werk wordt er met

sprongen van 0.1 gevarieerd van de waarde 0.1 tot en met

de waarde 0.9.

27

Rescheduling

Voor het opstellen van de Basic Feasible Schedule is

gescheduled aan de hand van een bepaalde methodiek.

Wanneer we de Feeding Buffered Schedule willen opstellen,

zijn er een soort activiteiten bijgekomen, namelijk de Buffer

Activititeiten. Deze worden opgenomen in de

activiteitenlijst samen met de bijkomende volgorderelaties.

Met deze extra elementen wordt er volgens dezelfde

methodiek een nieuwe schedule opgesteld.

32

Resource Resources kunnen verschillende vormen aannemen zoals

financiële resources, mankracht, machines, uitrusting,

3

VIII

materialen, energie, ruimte enz. Dit zijn zaken die een

activiteit nodig heeft om te kunnen worden uitgevoerd.

Simulated Schedule De Simulated Schedule is een gesimuleerde vorm van de

Projected Schedule. 33

SP of de graad van

Serialiteit/Parallellisme

Netwerken kunnen in het ene uiterste 100% serieel

opgebouwd zijn (de tweede activiteit komt na de eerste

enzovoort…), of anderzijds geheel parallel (alle activiteiten

kunnen volgens de volgorderelaties van het netwerk

gelijktijdig uitgevoerd worden). SP is hier een parameter

voor. In dit onderzoek werken we in sprongen van 0.1 van

de waarde 0.1 (hoge graad van parallellisme) tot en met 0.9

(hoge graad van serialiteit).

26

Type Netwerk

Een netwerk wordt in dit onderzoek steeds gedefinieerd

door 2 parameters, namelijk SP (de graad van

Serialiteit/Parallellisme) en RC (de graad van Resource

Constrainedness). Een bepaald Type Netwerk is dan een

netwerk, gedefinieerd door een bepaalde waarde voor deze

2 parameters.

27

Volgorderelatie

Een volgorderelatie wijst op de relatie tussen 2

opeenvolgende activiteiten. Van deze relatie bestaan

verschillende vormen, zoals Start-Start, Start-Finish, … De

relatie die in dit werk gebruikt wordt is de Finish-Start

volgorderelatie. Dit wil zeggen dat activiteit B pas kan

starten (Start) van zodra activiteit A uitgevoerd is (Finish).

3

Whitespaces

Whitespaces zijn tijdseenheden in de (Feeding) Buffered

Schedule waar er geen enkele resource wordt gebruikt. Het

is dus een plaats waar enkel de Feeding Buffer staat

gescheduled.

47

IX

Lijst van de figuren en tabellen

Figuren

Figuur 1: Een eenvoudig AoN-netwerk ........................................................................................................ 4

Figuur 2: Activiteitennetwerk - parallelle activiteiten .................................................................................. 5

Figuur 3: Activiteiten schedule - resource conflicten bij parallellisme ........................................................ 5

Figuur 4: Basic Feasible Schedule - ASAP ..................................................................................................... 7

Figuur 5: Basic Schedule - ALAP .................................................................................................................... 8

Figuur 6: Basic Feasible Schedule - ALAP ..................................................................................................... 8

Figuur 7: Rechtsscheve kansverdelingsfunctie ........................................................................................... 10

Figuur 8: Merge Bias ................................................................................................................................... 11

Figuur 9: Multi-tasking ............................................................................................................................... 12

Figuur 10: Single tasking ............................................................................................................................. 13

Figuur 11: Basic Feasible Scheduling - ALAP............................................................................................... 15

Figuur 12: Individuele Buffers .................................................................................................................... 17

Figuur 13: Invoegen van de Project Buffer ................................................................................................. 17

Figuur 14: Invoegen van de Feeding Chains ............................................................................................... 18

Figuur 15: Toevoegen van de Feeding Buffer aan de Feeding Chain ......................................................... 18

Figuur 16: Buffer Management - opvolgmethode ..................................................................................... 22

Figuur 17: Overzicht van de doelstelling .................................................................................................... 25

Figuur 18: Activiteitennetwerk ................................................................................................................... 28

Figuur 19: Basic Feasible Schedule - ALAP ................................................................................................. 28

Figuur 20: Activiteitennetwerk met CC en FB’s .......................................................................................... 30

Figuur 21: Activiteitennetwerk met CC en FB's (2) .................................................................................... 31

Figuur 22: Basic Feasible Schedule ............................................................................................................. 31

Figuur 23: Feeding Buffered Schedule - verschuiving ................................................................................ 32

Figuur 24: Feeding Buffered Schedule - rescheduled ................................................................................ 32

Figuur 25: Feeding Buffered Schedule - rescheduled ................................................................................ 32

Figuur 26: Projected Schedule.................................................................................................................... 34

Figuur 27: Symmetrisch triangulaire verdeling van de activiteitsduurtijden ............................................. 34

Figuur 28: Normale verdeling van de projectduurtijd en rechtseenzijdige 95%-betrouwbaarheidsinterval

.................................................................................................................................................................... 37

Figuur 29: Invloed van SP op de duurtijd van de Buffered Schedule ......................................................... 39

Figuur 30: Invloed van RC op de duurtijd van de Buffered Schedule ......................................................... 40

X

Figuur 31: Invloed van SP op de duurtijd van de Buffered Schedule, gegeven een bepaalde waarde van

RC................................................................................................................................................................ 42

Figuur 32: Procentuele verlenging van de duurtijd van de Buffered Schedule, gegeven een bepaalde

verhouding van RC (RC=0.X/RC=0.1) .......................................................................................................... 42

Figuur 33: Invloed van RC op de duurtijd van de Buffered Schedule, gegeven een bepaalde waarde van

SP ................................................................................................................................................................ 44

Figuur 34: Procentuele verlenging van de duurtijd van de Buffered Schedule, gegeven een bepaalde

verhouding van SP (SP=0.X/SP=0.1) ........................................................................................................... 44

Figuur 35: Projectduurtijd van de Buffered Schedule ................................................................................ 45

Figuur 36: Projectduurtijd van de Buffered Schedule - trendlijn correctie ................................................ 46

Figuur 37: Invloed van de Feeding Buffergrootte op de duurtijd van de Buffered Schedule .................... 47

Figuur 38: Activiteitennetwerk ................................................................................................................... 48

Figuur 39: Basic Feasible Schedule ............................................................................................................. 49

Figuur 40: Activiteitennetwerk met CC en FB's .......................................................................................... 49

Figuur 41: Feeding Buffered Schedule met Whitespace ............................................................................ 50

Figuur 42: Invloed van SP op het voorkomenv an Whitespaces ................................................................ 50

Figuur 43: Invloed van RC op het voorkomen van Whitespaces ................................................................ 52

Figuur 44: Invloed van FB Grootte op het voorkomen van Whitespaces .................................................. 53

Figuur 45: Invloed van SP op de duurtijd van de Simulated Schedule inclusief het 95%-

betrouwbaarheidsinterval .......................................................................................................................... 55

Figuur 46: Invloed van RC op de duurtijd van de Simulated Schedule inclusief het 95%-


Figuur 47: Projectduur van de Simulated Schedule ................................................................................... 57

Figuur 48: Projectduurtijd van de Simulated Schedule - trendlijn correctie .............................................. 57

Figuur 49: Invloed van de variantie van de activiteitsduurtijden op de projectduurtijd ........................... 58

XI

Tabellen

Tabel 1: Duurtijden met Whitespaces/duurtijden zonder Whitespaces ................................................... 54

Tabel 2: Factor SP & RC .............................................................................................................................. 60

Tabel 3: Invloed van de Feeding Buffergrootte bij FB = 0.2 ....................................................................... 61

Tabel 4: Invloed van de Feeding Buffergrootte bij FB = 0.8 ....................................................................... 62

Tabel 5: Invloed van de Variantie van de activiteitsduurtijden ................................................................. 62

Tabel 6: Invloed van de controle van de Critical Chain op de projectduurtijd startend van een

variantieniveau van 9 ................................................................................................................................. 65

Tabel 7: Aantal Critical Chain elementen per type netwerk ...................................................................... 66

Tabel 8: Invloed van controle van de CC op de projectduurtijd ten opzichte van het aantal CC-elementen

startend van een variantieniveau van 9 ..................................................................................................... 67

Tabel 9: Invloed van controle van de CC op de projectduurtijd ten opzichte van het aantal CC-elementen

startend van een variantieniveau van 3 ..................................................................................................... 67

Tabel 10: Invloed van het type netwerk op de PBF .................................................................................... 71

Tabel 11: Originele projectduurtijden van de Buffered Schedule .............................................................. 76

Tabel 12: Trendlijn-gecorrigeerde projectduurtijden van de Buffered Schedule ..................................... 76

Tabel 13: Originele projectduurtijden van de Simulated Schedule inclusief het 95%-


Tabel 14: Trendlijn-gecorrigeerde projectduurtijden van de Simulated Schedule inclusief het 95%-


Tabel 15: Invloed van de Feeding Buffergrootte op de PBF ....................................................................... 80

Tabel 16: Invloed van de Variantie van de activiteitsduurtijden op de PBF .............................................. 83

Tabel 17: Invloed van de controle van het Variantieniveau van de Critical Chain ..................................... 86


1 | P a g i n a

Inleiding

Een ondergrondse parking in Gent, flatgebouwen in Tokio, de kanaaltunnel tussen Frankrijk en

Engeland, nieuwe eilanden nabij Dubai, raketten tot in de ruimte, … Eén ding hebben deze zaken

allemaal gemeen: een stevige projectplanning. Samengevat zijn projecten een grote verzameling van

activiteiten die moeten uitgevoerd worden. Het startpunt is gegeven, de middelen zijn schaars, het geld

moet opbrengen en alles natuurlijk liefst zo snel mogelijk.

Project Management kan breed omschreven worden als het toewijzen, managen en timen van

resources om een vooraf bepaald doel te bereiken op een efficiënte en effectieve manier (Badiru, 1991).

De man die hierbij het roer stevig in handen houdt, rond de ijsbergen vaart en ondertussen de horizon

in de gaten houdt, maakt het verschil tussen succes en faling. Een ervaren Project Manager blijft, hoe

men het ook draait of keert, samen met de steun van het Algemeen Management, het succespunt bij

Project Management. Ondanks dit feit, menen wij dat een stevige portie theoretische bagage in de

scheduling mede kan bijdragen aan het succes. Net op dat punt zullen wij inpikken met deze

masterproef.

Project Management is een onderzoeksdomein dat de laatste jaren gekenmerkt wordt door een zeer

sterke groei. Er is hoofdzakelijk onderzoek verricht naar het opstellen van stevige en werkbare

schedules met als uitgangspunt een statische en deterministische omgeving. Op dit thema zullen wij

verder ingaan door de belangrijke feedback van simulatie te gebruiken ter optimalisatie ( = assumpties

van statische en deterministische omgeving verwerpen).

Critical Chain Buffer Management (CC/BM) is een onderdeel van Project Management en heeft als doel

de projectduurtijd te minimaliseren, juist in te schatten en projecten op een correcte manier te

managen. Er zijn enkele harde punten van kritiek op deze theorie. Eén daarvan is het bepalen van de

grootte van de Project Buffer. Omdat de grootte van deze Project Buffer belangrijke consequenties

heeft, stellen wij als hoofddoel van deze masterproef het ontwikkelen van een methodiek om de

correcte lengte van de Project Buffer te bepalen op een voor de Project Manager makkelijke en

betrouwbare manier, door ons te baseren op een simulatiestudie.

Dit werk is opgedeeld in een logische 5 delen. We beginnen bij de “basics” van Project Scheduling met

“Hoofdstuk 1: Projecten en Netwerk Scheduling”. De basisbegrippen van scheduling worden er

uiteengezet, alsook enkele problemen die zich kunnen voordoen. Een antwoord op deze problemen

wordt geboden door CC/BM, uiteengezet in “Hoofdstuk 2: Critical Chain Buffer Management (CC/BM)”.

Dit concept wordt voorts het centrale gegeven van deze masterproef.


2 | P a g i n a

De precieze doelstelling van ons onderzoek wordt uitgelegd in “Hoofdstuk 3: Doelstellingen en setup

van het model”. Ook wordt het door ons opgebouwde model toegelicht om te komen tot “Hoofdstuk 4:

Resultaten van de experimenten”. Dit hoofdstuk is het grote en soms erg technische data-center. Om de

lezer bij te staan, proberen we in gekaderde vorm hier en daar een leidraad aan te bieden. Deze

kadertjes zorgen ervoor dat het gehele verhaal soms wat makkelijker te volgen is. De belangrijkste

resultaten worden nogmaals opgenomen in “Hoofdstuk 5: Conclusies”.


3 | P a g i n a

Hoofdstuk 1: Projecten en Netwerk Scheduling

1.1 Een eenvoudig netwerk

Een project bestaat uit een aantal mijlpalen en activiteiten die moeten uitgevoerd worden, rekening

houdend met bepaalde volgorderelaties tussen de activiteiten onderling. Elke activiteit of taak heeft een

bepaalde duurtijd en nuttigt een aantal resources (behalve dummy activiteiten die geen van beiden

consumeren). Een mijlpaal verwijst naar het tijdstip waarop de voltooiing van een individuele activiteit

zou moeten plaatsvinden. Resources kunnen verschillende vormen aannemen, zoals financiële

resources, mankracht, machines, uitrusting, materialen, energie, ruimte, enz. Een volgorderelatie wijst

op de relatie tussen 2 opeenvolgende activiteiten. Van deze relatie bestaan opnieuw verschillende

vormen, zoals Start-Start, Start-Finish etc. Een exhaustief overzicht van volgorderelaties kan gevonden

worden in “Project Scheduling, a research Handbook” (Demeulemeester & Herroelen, 2002). In ons

onderzoek, maken we gebruik van de Finish-Start volgorderelatie. Dit wil zeggen dat een bepaalde

activiteit pas kan starten (Start) van zodra alle voorgaande activiteiten uitgevoerd zijn (Finish).

Een activiteitennetwerk is een grafische voorstelling van mijlpalen, activiteiten en volgorderelaties. Er

zijn 2 manieren om een project netwerk weer te geven:

(a) een activity-on-arc (AoA) representatie dat “arcs” (verbindingspijlen) gebruikt om de

activiteiten voor te stellen en “nodes” (knooppunten) om de mijlpalen voor te stellen en

(b) een activity-on-node (AoN) representatie die de activiteiten weergeeft als “nodes” en

waarbij de “arcs” de volgorderelaties voorstellen.

In de verdere bespreking van onze tekst zullen we gebruik maken van de AoN-representatie.

In figuur 1 wordt een eenvoudig AoN-netwerk weergegeven. We zien inderdaad dat de knooppunten de

activiteiten voorstellen (bv. de cirkel met daarin het getal 1 stelt activiteit 1 voor) en dat de

verbindingspijlen de volgorderelaties voorstellen (bv. activiteit 1 komt vóór activiteit 3). Boven en onder

elke activiteit worden respectievelijk de duurtijd en het resourcegebruik weergegeven (bv. activiteit 2

heeft een duurtijd van 3 tijdseenheden en verbruikt 2 resource-eenheden per tijdseenheid).


4 | P a g i n a

Figuur 1: Een eenvoudig AoN-netwerk

1.2 Resource Constrained Project Scheduling

Naast de volgorderelaties zijn het aantal inzetbare resources een complexe beperking in het schedulen

of uitvoeren van vele projecten. Sommige projecten hebben een bepaalde starthoeveelheid aan

resources, die doorheen het project kunnen geconsumeerd worden (bv. Aantal kg grondstof X), terwijl

andere projecten gebruik maken van hernieuwbare resources (bv. Y aantal mensen of machines). Deze

laatste soort is hernieuwbaar in de zin dat het elke tijdsperiode aanwezig is in dezelfde mate (namelijk

Y), onafgezien van het verbruik in de vorige periodes.

Dit onderzoek wordt gevoerd in een omgeving van hernieuwbare resources. Dit probleem wordt ook

wel het RCPSP of “Resource Constrained Project Scheduling Problem” genoemd en wordt als volgt

gedefinieerd:

“RCPSP kent begin en eindtijden toe aan de verschillende activiteiten, die onderhevig zijn aan

volgorderelaties en resource beperkingen, met als doel de duurtijd van een project te minimaliseren.”

In een dergelijke omgeving wordt het voor de aandachtige lezer snel duidelijk dat volgorderelaties niet

de enige beperkingen vormen voor de starten eindtijden van de netwerkactiviteiten. Resource

conflicten zijn een nieuwe vorm van dreiging en complexiteit voor het opstellen van een degelijk project

plan. Een eenvoudig voorbeeld toont dit aan. Beschouwen we het netwerk in figuur 2 , dan zien we dat

activiteit 1 en 2 in principe simultaan of in parallel kunnen worden uitgevoerd.


5 | P a g i n a

Figuur 2: Activiteitennetwerk - parallelle activiteiten

Figuur 3 geeft weer hoe de projecten worden ingepland. In eerste instantie zouden we de activiteiten

parallel plaatsen. Dit resulteert in een resource gebruik van 5. Wanneer we nu veronderstellen dat er

per tijdseenheid slechts 3 eenheden van de resource beschikbaar zijn, dan zijn we verplicht de

activiteiten na elkaar uit te voeren. Het gevolg is een seriële plaatsing om het conflict op te lossen.

Figuur 3: Activiteiten schedule - resource conflicten bij parallellisme

Er rest dan natuurlijk de vraag waarom we activiteit 1 gaan voorop plaatsen en niet omgekeerd. De

keuze om dit te doen hangt af van de prioriteitsregel die de Project Manager hanteert. Deze worden in

het volgende punt, 1.3 Prioriteitsregels, besproken.


6 | P a g i n a

1.3 Prioriteitsregels

Er is reeds veelvuldig onderzoek gevoerd naar het vinden van optimale schedules binnen het RCPSP.

Veel exacte en heuristische algoritmes zijn reeds beschreven in de literatuur (voor een overzicht:

(Herroelen, Dereyck, & Demeulemeester, 1998; Kolisch & Padman, 1999; Kolisch & Hartmann, 1999;

Brucker, Drexl, Möhring, Neumann, & Pesch, 1999; Demeulemeester & Herroelen, 2002).

Omdat de exacte technieken, zoals de “branch-and-bound” techniek (Demeulemeester & Herroelen,

1992), zorgen voor een enorme toename van complexiteit en geen grote meerwaarde vormen voor

onze doelstelling, verkiezen we een heuristische methode voor het opstellen van een planning of

schedule. We starten met het zoeken naar een ranglijst die bepaalt welke activiteit als eerste, tweede

enz. mag gescheduled worden. Deze ranglijsten worden “prioriteitslijsten” (priority lists) genoemd en

zijn het resultaat van het toepassen van een bepaalde “prioriteitsregel” (priority rule). Bij het opstellen

van deze lijsten houden we enkel rekening met de volgorderelaties in het netwerk, de resource

beperkingen komen pas in een volgende stap (1.4 Basic Feasible Schedule) aan bod.

Een uitgebreid overzicht van de brede variëteit aan prioriteitsregels wordt gegeven in “Project

Scheduling: A Research handbook” (Demeulemeester & Herroelen, 2002). Voor de resultaten van ons

onderzoek hebben we gebruik gemaakt van de activity-based “Shortest Processing Time (SPT)”-

heuristiek (Davis & Patterson, 1975), omdat blijkt uit een onderzoek van Kolish dat deze een goeie

performantie weerhoudt tegenover andere priority rules inzake duurtijd van een project (Kolish, 1996).

Bij een SPT-prioriteitslijst worden de activiteiten met de kortste duurtijd als eerste ingepland, rekening

houdend met de volgorderelaties.

Terugkerend tot het eenvoudige netwerk in figuur 1, zou de SPT-prioriteitslijst er als volgt uitzien: [1, 3,

2, 4]. Activiteit 3 kan heeft wel een kleinere duurtijd dan activiteit 1, maar komt na activiteit 1 in de

prioriteitslijst terecht omdat rekening moet worden gehouden met de volgorderelaties. Deze

prioriteitslijst vormt de input voor het volgende onderdeel, namelijk het opstellen van de Basic Feasible

Schedule.

1.4 De Basic Feasible Schedule

Een netwerk kan op veel verschillende manieren worden gescheduled (bv. volgens verschillende priority

rules, As-Late-As-Possible en As-Soon-As-Possible, met vertragingen tussen de opeenvolgende

activiteiten en zonder vertragingen, …) en het schedulen kan veel verschillende doelen voor ogen

hebben (bv. maximaliseren van de net present value, minimaliseren van de resource ‘idle time’,


7 | P a g i n a

minimaliseren van de duurtijd enz.). Een uitgebreid overzicht van deze en andere doelstellingen wordt

gegeven door Demeulemeester & Herroelen (Demeulemeester & Herroelen, 2002).

Bij de traditionele scheduling methodes, zoals de critical path method, wordt As-Soon-As-Possible

(ASAP) gepland. Dit houdt in dat de activiteiten zo vlug mogelijk worden ingepland, rekening houdend

met de volgorde relaties en de resource beperkingen. Figuur 4 geeft hier een illustratie van, afgeleid uit

het AoN-netwerk van figuur 1 en de prioriteitslijst opgesteld op het einde van punt “1.3

Prioriteitsregels” ([1,3,2,4]). Er wordt een resource beperking van 5 eenheden verondersteld. Dit wil

zeggen dat per tijdseenheid slechts 5 resources (bv. manuren, machines,…) beschikbaar zijn. Bijgevolg

mag men bij het plannen deze beperking niet overschrijden. Activiteit 1 en 2 kunnen simultaan worden

uitgevoerd aangezien hun gezamenlijke resource gebruik per tijdseenheid de resource constraint niet

overtreft en de volgorde relaties dit toelaten.

In tegenstelling tot de traditionele technieken, raadt CC/BM aan om de activiteiten zo laat mogelijk of

As-Late-As-Possible (ALAP) in te plannen. Redenen hiervoor worden aangegeven in onderdeel “1.5

Problemen bij Project Scheduling”. De input van de ALAP-procedure is weer het netwerk in figuur 1 en

de ASAP-Basic Feasible Schedule. Van elke activiteit wordt de slack berekend: dit is het verschil tussen

de vroegst mogelijke eindtijd en de laatst mogelijke eindtijd. Zoals te zien in figuur 4 bepalen activiteit 2

en 4 eigenlijk de projectduurtijd. Hun slack is dan ook gelijk aan nul aangezien ze niet vroeger, noch later

kunnen starten. Echter voor activiteit 1 en 3 ligt dit anders. De slack van activiteit 3 is niet gelijk aan 0,

aangezien zijn laatst mogelijke eindtijd gelijk is aan de eindtijd van het project. Activiteit 3 kan dus later

starten (zie figuur 5). Ook de slack van activiteit 1 is niet gelijk aan 0 aangezien zijn laatst mogelijke

Figuur 4: Basic Feasible Schedule - ASAP


8 | P a g i n a

eindtijd gelijk is aan de begintijd van activiteit 3. Activiteit 1 kan dus ook later beginnen, maar zoals te

zien in de ALAP-schedule van figuur 5 moet activiteit 1 vóór activiteit 4 worden gepland, aangezien zich

anders een resource conflict voordoet. Het resultaat is de Basic Feasible Schedule in figuur 6.

Deze Basic Feasible Schedule vormt de basis voor verdere stappen: Zowel de Buffered Scheduled (punt

“3.4.1 Buffered Schedule), als de Projected Schedule (punt “3.5.1 Projected Schedule”) worden

opgesteld op basis van deze eerste.

Figuur 6: Basic Feasible Schedule - ALAP

Figuur 5: Basic Schedule - ALAP


9 | P a g i n a

1.5 Problemen bij Project Scheduling

In een productieomgeving komt het wel eens voor dat er een machine stilvalt of dat er vertragingen

worden opgelopen doorheen de productielijn. De reden hiervoor is de willekeurigheid van een real life

proces. In dergelijke omgeving kan men via het herhaaldelijk opvolgen van duurtijden, de parameters

van de statistische benaderingen redelijk eenvoudig gaan bepalen. Bijgevolg zijn de

betrouwbaarheidsintervallen of kansen van breakdown te voorspellen.

Bij projecten ligt dit anders: elk project is uniek en schattingen op basis van vorige ervaringen, indien er

al gegevens bestaan, zijn vaak onbetrouwbaar (Vanhoucke & Leus, 2009). Bovendien worden projecten

gepland door mensen en niet door machines of computers zoals in de productieomgeving. Daarom is

het ook nodig inzicht te verwerven in de psychologie van mensen. In dit onderdeel bespreken we enkele

menselijke zaken die voor problemen kunnen zorgen bij het plannen van een project. Goldratt

ontwikkelde een methode om met onzekerheid in projecten om te gaan: Wanneer onzekerheid

opdaagt, wordt aan planners aangeraden om zich te baseren op Critical Chain/Buffer Management

(CC/BM) (Goldratt E. , 1997). CC/BM is een heuristische benadering die probeert om een goeie

bescherming in te bouwen tegen vertragingen binnen een project zodat de vooropgestelde duurtijd van

dit project bij uitvoering benaderd wordt (i.e. quality robust schedules (Van de Vonder,

Demeulemeester, Herroelen, & Leus, 2004)).

In dit deel worden 5 bronnen van mogelijkse problemen besproken die tot gevolg kunnen hebben dat

een project langer duurt dan initieel gepland. In Hoofdstuk 2 bespreken we Goldratt’s methode die deze

problemen in rekening brengt bij het opstellen van de project planning via Critical Chain/Buffer

Managament.

1.5.1 Schattingen van de activiteitsduur

Elke activiteit in een project heeft een bepaalde duurtijd. Echter, door onzekerheid kan deze niet precies

geschat worden. De duurtijd is dus een stochastische variabele, die volgens de literatuur (zie oa.

(Vanhoucke & Leus, 2009) meestal een rechtsscheve verdelingsfunctie heeft (figuur 7).


10 | P a g i n a

Figuur 7: Rechtsscheve kansverdelingsfunctie

Als we vragen aan iemand in hoeveel tijd men een bepaalde taak kan uitvoeren, dan zal men meestal

niet de correcte verwachtingswaarde (E(x)) of de mediaan (50%-kwantiel) aangeven, omdat men dan te

onzeker is om de voorgestelde duurtijd wel haalt. De persoon zal eerder een duurtijd voorstellen in de

buurt van het 90%-kwantiel, zodoende te zorgen voor meer zekerheid. De echte kansverdelingsfuncties

van de verschillende activiteiten in een project zijn natuurlijk nooit op voorhand gekend waardoor deze

persoon, om zichzelf nog meer te beschermen, geneigd is een nog ruimere schatting te maken

(Vanhoucke & Leus, 2009). Als conclusie kunnen we dus stellen dat in vele projecten de individuele

geschatte duurtijd van een activiteit al een behoorlijke graad van veiligheid incorporeert (Goldratt,

1997).

1.5.2 De wet van Parkinson

Wat zal er gebeuren als een activiteit bijvoorbeeld maar 70% van de geschatte duurtijd inneemt? Bij de

planning van een project worden doorgaans de deadlines van de individuele activiteiten vastgelegd.

Terwijl doorgaans een vroegtijdige voltooiing van een activiteit niet wordt beloond, gelden er bij

vertragingen wel afstraffingen. Het gevolg is dat wanneer iemand vroegtijdig zijn/haar taak heeft

afgewerkt, deze persoon zich gaat bezighouden om vele (onnodige) toeters en bellen aan zijn/haar taak

toe te voegen in plaats van een volgende taak te beginnen. Dit fenomeen wordt in de literatuur “De wet

van Parkinson” genoemd (Gutierrez & Kouvelis, 1991; Parkinson, 1957).

We denken bijvoorbeeld aan de programmeur die eindeloos kan blijven werken om een nog beter

resultaat af te leveren (Vanhoucke & Leus, Critical Chain Project Management, 2009). Melden dat de

opdracht reeds eerder klaar is, resulteert in een nieuwe en waarschijnlijk strenger getimede opdracht.

Dit alles resulteert in activiteiten die maar zelden vroegtijdig zullen klaar zijn.


11 | P a g i n a

1.5.3 Het Student Syndrome

Veel mensen hebben de neiging om een taak uit te stellen tot het moment dat de deadline in zicht

komt. Het beste voorbeeld hierbij is de student. Deze zal gemiddeld gezien zijn opdracht niet beginnen

aan de start, maar een bepaalde tijd voor de deadline (Vanhoucke & Leus, 2009). Bijgevolg wordt er

meer kans op vertraging ingebouwd. Gelijkaardig gedrag kan worden vastgesteld in Project

Management. Dit fenomeen wordt in de literatuur het “Student Syndrome” genoemd (Goldratt E. M.,

1997). Wanneer er sprake is van het Student Syndrome vergroot dus de kans op het laattijdig klaar zijn

van een bepaalde activiteit of taak.

Zowel het Student Syndrome als de Wet van Parkinson hebben tot gevolg dat wanneer een activiteit

hypothetisch gezien vroeger voltooid kon zijn dan gepland, dit niet zal resulteren in tijdswinst.

Integendeel, door het Student Syndrome zullen vertragingen nog meer voorkomen. Bovendien wordt

deze vertraging soms gezien als een onderschatting van de duurtijd en zullen nog hogere schattingen

gebruikt worden in de toekomst.

1.5.4 Merge Bias

Wanneer een netwerk zo is opgebouwd dat verschillende taken moeten worden afgewerkt voor een

finale taak kan worden uitgevoerd, doet er zich een nieuw probleem voor. Beschouwen we figuur 8 dan

zien we dat activiteit 4 pas kan beginnen wanneer de 3 andere activiteiten zijn afgewerkt (Finish-Start

relatie). Meestal doen dergelijke situaties zich voor naar het einde van een project omdat het werk dan

meestal bestaat uit assembleren, integreren of testen. Als we terug naar de figuur kijken en

veronderstellen dat elke activiteit in 50% van de gevallen op tijd wordt afgewerkt, dan is de kans dat 1

van de 3 activiteiten vertraging oploopt bijna 88%. Zelfs wanneer er individueel 85% zekerheid is, is er

nog steeds 40% kans dat minstens 1 activiteit te laat volbracht wordt. In de literatuur wordt dit de

“Merge Bias” genoemd (Hulett, 1996): waar verschillende activiteiten convergeren ligt de kans op

vertraging in het project hoger.

Figuur 8: Merge Bias


12 | P a g i n a

Met dit laatste probleem versterken we het kritiekpunt van de 50%-regel van Goldratt die in Hoofdstuk

2 zal uitgelegd worden. Zoals Vanhoucke & Leus reeds opmerkten wordt door deze observatie de nood

aan meer gesofisticeerde simulaties, waarbij de activiteitsduurtijden kunnen gemodelleerd worden als

onafhankelijke random variabelen, gerechtvaardigd:

“One mathematically correct way to handle the complication of parallel chains, would be to use either

simulation or statistical calculation to adapt the size of the Project Buffer accordingly” (Vanhoucke &

Leus, 2009, p.258)

Dit is één van de redenen waarom we een simulatieoefening uitvoeren. Het begrip Project Buffer wordt

tevens ook in Hoofdstuk 2 verduidelijkt.

1.5.5 Multi-tasking

Een laatste verschijnsel dat zich soms voordoet in Project Management is “Multi-tasking”. Multi-tasking

houdt in dat er ‘op hetzelfde moment’ meerdere activiteiten worden uitgevoerd. Met ‘op hetzelfde

moment’ wordt bedoeld dat er bijvoorbeeld gedurende een bepaalde periode ’s morgens aan de ene

activiteit gewerkt wordt en in de namiddag aan een tweede activiteit. Deze werkmethode kan echter

een nefast gevolg hebben op het tijdstip van afwerking van een activiteit. Dit wordt geïllustreerd in

figuur 9. Veronderstel dat we 2 activiteiten hebben die moeten uitgevoerd worden door eenzelfde

resource en die allebei 6 tijdseenheden in beslag nemen. Figuur 9 geeft de situatie weer waarin aan

Multi-tasking wordt gedaan: Er wordt dus afwisselend gewerkt aan activiteit 1 en activiteit 2. We zien

dat activiteit 1 wordt afgewerkt op tijdstip 11. De tweede activiteit wordt afgewerkt op tijdstip 12.

Figuur 9: Multi-tasking


13 | P a g i n a

In figuur 10 zien we de situatie waarin multi-tasking geëlimineerd wordt. Dit wil zeggen dat we niet aan

activiteit 2 werken zolang activiteit 1 niet is afgerond. We kunnen nu zien dat activiteit 2 nog steeds op

tijdstip 12 wordt afgewerkt. Echter, activiteit 1 kan reeds op tijdstip 1 worden afgewerkt. Het is duidelijk

dat het tijdstip van afwerken van een bepaalde activiteit afhangt van de graad van multi-tasking in een

project.

Figuur 10: Single tasking

In bovenstaande figuren wordt de afwezigheid van set-up times verondersteld. Wanneer iemand aan

een taak moet (her)beginnen, neemt dit tijd in beslag. Bijgevolg zal de duurtijd van een project waarin

aan multi-tasking wordt gedaan meestal langer duren dan wanneer men multi-tasking elimineert.

Omwille van deze reden en eenvoudigheidsredenen (oa. set-up times zijn moeilijk te schatten), wordt in

het vervolg van deze tekst de afwezigheid van multi-tasking verondersteld.

In het begin van punt 1.5 haalden we reeds kort aan dat CC/BM een methode is die probeert om buffers

in te bouwen tegen vertragingen binnen een project zodat de vooropgestelde duurtijd van dit project

benaderd wordt bij het uitvoeren van het project. CC/BM wordt uitvoerig besproken in Hoofdstuk 2. Om

duidelijk het verband te zien tussen dit en volgend hoofdstuk haalden we nog graag volgend citaat van

Herroelen & Leus aan:

“CC/BM is to be deployed as a Project Management strategy to avoid project delays caused by

Parkingson’s Law (work expands to fill the time allowed (Gutierrez & Kouvelis, 1991; Parkinson, 1957))

while protecting Murphy’s Law (uncertainty involved in the work). CC/BM tries to minimize the impact of

Parkinson’s Law by building the schedule with target duration estimates based on a 50% confidence

level, by eliminating task due dates and milestones and by eliminating multitasting.”

(Herroelen & Leus, 2001, p.560)


14 | P a g i n a

Hoofdstuk 2: Critical Chain Buffer Management (CC/BM)

CC/BM is een methodologie met als doel het optimaliseren van projectnetwerken met schaarse

hernieuwbare resources. Het is een toepassing van de ‘Theory Of Constraints’, ontwikkeld door Dr.

Eliyahu M. Goldratt.

CC/BM ontwikkelde zich vanuit het probleem dat projecten van alle maten en vormen te kampen

hebben met een hoge waarschijnlijkheid van budget overruns en projectvertragingen. Projecten sneller

voltooien en tegen een einddatum die veel betrouwbaarder is, is wat echt telt (Demeulemeester &

Herroelen, 2002). Zoals beschreven (“1.5 Problemen bij Project Scheduling”) doen er zich verschillende

problemen voor bij het uitvoeren van een project. CC/BM wijst deze problemen aan als de grootste

oorzaken van vertragingen in Project Management. Vertragingen, onder andere veroorzaakt door de

Wet van Parkinson, moeten vermeden worden, terwijl men zich moet beschermen tegen de Wet van

Murphy (als er iets kan misgaan, zal dit ook gebeuren ). CC/BM probeert dit te bereiken door een Critical

Chain te identificeren, agressieve duurtijdschatting te gebruiken, Feeding Buffers te plaatsen en het

hanteren van een Project Buffer.

In dit hoofdstuk bespreken we deze en andere basisbegrippen van CC/BM. De oorsprong van CC/BM kan

teruggevonden worden in de “Theory of Constraints”(TOC). De link tussen beiden wordt besproken in

“2.1 Theory of Constraints toegepast op Project Management”. Daarna overlopen we de belangrijkste

aspecten van CC/BM. De Critical Chain wordt behandeld in “2.2 De Critical Chain”. Buffer Management

is het tweede grote onderdeel van CC/BM en bespreken we in “2.3 Buffers”, waar zowel de

verschillende soorten buffers (Project Buffers en Feeding Buffers) worden besproken, als een overzicht

wordt gegeven van de belangrijkste technieken om de buffergroottes te bepalen. De Critical Chain en de

verschillende soorten buffers hebben een gezamenlijk doel waarop wordt ingegaan in “2.4 Doel van

Critical Chain Buffer Management”.

2.1 Theory of Constraints toegepast op Project Management

De “Theory of Constraints” (TOC) , ontwikkeld door Dr. Eliyahu M. Goldratt, biedt een gestructureerde

aanpak voor het oplossen van problemen die zich hoofdzakelijk voordoen in een productieomgeving

(Goldratt, 1997). De theorie stelt dat er in een productieproces steeds één of enkele activiteiten zijn die

de snelheid van het gehele proces bepalen. Wanneer er in een dergelijke activiteit (bottleneck)

vertraging optreedt, betekent dit een vertraging voor het gehele proces.

Volgens de TOC moet men deze bottlenecks identificeren, de capaciteit ervan maximaliseren en al de

overige activiteiten in dienst stellen om mogelijke stilstand van deze bottlenecks te minimaliseren. Een


15 | P a g i n a

veelgebruikte techniek is het plaatsen van buffers vóór het kritieke punt (bv. een inventarisbuffer vóór

de bottleneck, die voorkomt dat de bottleneck zonder input komt te zitten). Als een punt van maximale

doeltreffendheid is bereikt, kan men de bottlenecks nog efficiënter maken door er extra capaciteit aan

toe te wijzen. Na deze laatste stap kan weer op zoek gegaan worden naar nieuwe bottlenecks en wordt

het hele proces herhaald.

CC/BM is een toepassing van de ‘Theory Of Constraints’ in Project Management: de TOC heeft als doel

de doorstroomtijd van een productielijn te minimaliseren, terwijl CC/BM de duurtijd van een project wil

minimaliseren. De bottlenecks in de TOC komen overeen met wat in CC/BM de Critical Chain (CC) wordt

genoemd. In projecten zonder resource beperkingen wordt het kritieke pad of Critical Path (CP) gezien

als de grootste beperking. Het CP wordt bepaald door de opeenvolging van activiteiten die de minimale

tijd bepalen om een project te voltooien. Wanneer we met projecten te maken hebben waar zich nog

een beperking van het aantal resources voordoet, moeten we ook hiermee rekening houden bij het

inplannen van de netwerkactiviteiten. Om te duiden op de “bottleneck” van dit soort projecten, wordt

een nieuw begrip geïntroduceerd: de Critical Chain. Deze wordt gedefinieerd als de groep van

activiteiten die de totale duurtijd van een project bepaalt, rekening houdend met zowel de resource

beperkingen als de volgorde beperkingen. De CC wordt uitvoerig besproken in de volgende paragraaf.

2.2 De Critical Chain

Zoals hiervoor vermeld wordt de CC gedefinieerd als de groep van activiteiten die de totale duur van

een project bepalen, rekening houdend met zowel de resource beperkingen als de volgorderelaties.

Laten we dit illustreren met het netwerk uit figuur 1. Als we dit netwerk correct schedulen bekomen we

uiteraard de Basic Feasible Schedule uit “1.4 De Basic Feasible Schedule”. De schedule wordt hier

nogmaals weergegeven (figuur 11).

Figuur 11: Basic Feasible Scheduling - ALAP


16 | P a g i n a

Als we de definitie van de CC erbij halen, kunnen we zien dat in dit netwerk activiteiten 2 en 4 de CC

vormen. Activiteiten 1 en 2 noemt men Feeding Activiteiten aangezien deze als het ware de CC voeden

(zie ook “2.3.1 Feeding Buffers”).

Er kunnen zich in dit netwerk 2 gevaren voordoen die er kunnen voor zorgen dat de duurtijd van het

project verlengd wordt:

- Ten eerste kunnen 1 of meerdere activiteiten van de Critical Chain vertraging oplopen. Als bv.

activiteit 2 vertraging oploopt, zal dit een rechtstreeks nadelig effect hebben op de begintijd van

activiteit 4, die volgens het activiteitennetwerk na activiteit 2 moet plaatsvinden, waardoor het

gehele project vertraagd wordt. Dit risico kan in rekening worden gebracht door het invoeren

van ‘Project Buffers’ (zie “2.3.2 Project Buffers”).

- Natuurlijk is er nog steeds het gevaar dat een niet-Critical Chain activiteit, bijvoorbeeld activiteit

1, kan uitlopen. Dit heeft een nefast effect op de starttijd van activiteit 4 en dus op de Critical

Chain. Om deze externe vertraging op te vangen stelt CC/BM het gebruik van ‘Feeding Buffers’

voor (zie “2.3.1 Feeding Buffers”).

Voorgaand voorbeeld is echter erg simplistisch. Het is dan ook belangrijk te weten dat er bij complexere

netwerken meerdere Critical Chains kunnen voorkomen in de Basic Feasible Schedule en dat de

gegenereerde CC’s afhangen van de manier waarop de Basic Feasible Schedule is opgesteld (onder

andere de gebruikte prioriteitsregel). Goldratt argumenteert dat het er niet toe doet welke CC wordt

gekozen en veronderstelt dat ze gemakkelijk kunnen geïdentificeerd worden. Anderen (Leach, 2000;

R.C., 1998) verklaren dat de keuze voor een deterministische CC geen puur algoritmische procedure is,

maar een belangrijke strategische beslissing inhoudt. Ze rapporteren dat het opstellen van een goede

Basic Feasible Schedule zeker niet gemakkelijk is en wel degelijk van belang.

2.3 Buffers

Buffer Management is het onderdeel van CC/BM dat zorgt voor bescherming tegen vertragingen in een

project. Het is duidelijk dat de verschillende soorten buffers een zeer belangrijke rol spelen in de CC/BM

methodologie. De lengte van de Project Buffer moet zowel het beschermingsniveau tegen vertragingen,

als de voorziene variabiliteit van de totale duurtijd van de CC weergeven (Caron & Mancini, 2006a). De

Feeding Buffers houden rekening met het beschermingsniveau en de variabiliteit van de andere chains.

In de literatuur zijn reeds veel voorstellen gedaan tot het bepalen van een gepaste Project Buffer. In dit

punt bespreken we eerst de begrippen “Project Buffer” en “Feeding Buffers” waarna een overzicht

wordt gegeven van de belangrijkste bestaande methodes om de buffergroottes te bepalen.


17 | P a g i n a

2.3.1 Project Buffers

Het geheel correct inschatten van de duurtijd van een project is door verschillende factoren heel erg

moeilijk of zelfs onmogelijk (supra, 1.5 Problemen bij Project Scheduling). De activiteiten die tot de

Critical Chain behoren zijn cruciaal, aangezien de minste vertraging in deze activiteiten een vertraging

van het hele project tot gevolg heeft. Echter, het doel van CC/BM is niet het beschermen van de

individuele activiteiten, maar het project in zijn geheel. CC/BM stelt voor om de beschermingsbuffers

van de individuele activiteiten weg te nemen en terug samen te voegen op het einde van project onder

de vorm van een Project Buffer (PB). Dit houdt in dat we de duurtijden van de verschillende CC-

activiteiten gaan herbekijken of herschatten, zodat de bescherming tegen variabiliteit wordt uitgesloten.

De bescherming tegen variabiliteit wegnemen houdt in dat we vertrekken van een Basic Feasible

Schedule, opgesteld met agressieve schattingen van de activiteitsduurtijden, die (individueel althans)

geen bescherming tegen vertragingen bevatten (Vanhoucke & Leus, 2009).

Initieel werd voorgesteld om de agressieve duurtijd van de activiteit gelijk te stellen aan de duurtijd voor

dewelke 50% kans bestaat dat de activiteit op tijd wordt afgewerkt. Echter, de activiteit duurt ook in

50% van de gevallen langer dan gepland. Een ruwe schatting van de Project Buffer bestaat erin de

verwijderde veiligheid (door agressieve duurtijdschattingen te gebruiken) van elke activiteit te nemen

en deze op het einde van het project te plakken als buffer. Bijgevolg moet de samengevoegde

projectbuffer op het einde van het project (figuur 12) zo groot zijn als de som van de veiligheidsbuffers

van de individuele activiteiten (figuur 13) (Goldratt, 1997).

Figuur 12: Individuele Buffers

Figuur 13: Invoegen van de Project Buffer


18 | P a g i n a

2.3.2 Feeding Buffers

Ook Feeding Buffers zorgen ervoor dat de geplande einddatum van een project beschermd wordt. Deze

buffers worden geplaatst waar Non-Critical Chain (N-CC) activiteiten inpikken op de CC. Zodoende

wordt de CC beschermd tegen de externe invloed van de N-CC, door deze laatste vroeger te laten

starten.

Laat ons dit illustreren met een voorbeeld uit Vanhoucke & Leus (Vanhoucke & Leus, 2009). In figuur 14

zien we dat er een kort pad (bestaande uit activiteiten f1, f2 en f3) toekomt in de CC (het langste pad

bestaande uit activiteit c1, c2, c3, c4, c5 en c6), net voor activiteit c5 moet beginnen. Dit wil zeggen dat

eerst activiteiten f1, f2 en f3 zullen moeten afgewerkt worden vóór activiteit c5 van start kan gaan. Het

gevaar bestaat nu dat er vertraging optreedt in één van de activiteiten van het zijdelingse pad, waardoor

heel het project vertraagd wordt. De PB gaat wel vertragingen in het CC pad opvangen, maar houdt

geen rekening met vertragingen die kunnen optreden in niet-CC activiteiten.

CC/BM stelt dus voor om een Feeding Buffer in te voeren: activiteit f1, f2 en f3 worden naar voor

geschoven en een FB wordt toegevoegd om eventuele vertragingen in deze taken in rekening te

brengen (figuur 15).

Figuur 14: Invoegen van de Feeding Chains

Figuur 15: Toevoegen van de Feeding Buffer aan de Feeding Chain


19 | P a g i n a

2.3.3 Bepaling van de Buffergrootte

2.3.3.1 De 50% methode

De grootte van de Project en Feeding Buffers wordt bepaald 50% van de totale duurtijd van de chain die

ze beschermen, aangezien de agressieve activiteitsduurtijden 50% betrouwbaar zijn. Dit is de methode

die Goldratt (Goldratt, 1997) initieel voorstelde. Het voordeel van deze methode is de intrinsieke

simpliciteit. De grootte van de buffer stijgt ook lineair met de lengte van de chain (bv. een project dat 12

maanden duurt krijgt een buffer van 6 maanden, terwijl een 2-jarig durend project een buffer van 1 jaar

krijgt). De aandachtige lezer merkt al snel op dat deze methode het nadeel heeft dikwijls de duurtijd van

een project te overschatten, wat de competitiviteit in de markt niet echt ten goede komt. Deze methode

kan wel gebruikt worden bij volledig nieuwe projecten, waar weinig data over de duurtijden van de

activiteiten beschikbaar zijn.

2.3.3.2 De root square error methode

Deze methode definieert de grootte van de buffers door te kijken naar het risico verbonden aan de

chain (Hoel & Taylor, 1999). Uitgaande van de hypothese dat de duur van de activiteiten een lognormale

verdeling heeft, zijn 2 schattingen vereist om de duur van een activiteit te bepalen. Een eerste schatting

(S) is een veilige schatting en moet een marge incorporeren om vertragingen op te vangen. Een tweede

schatting (A) incorporeert deze marge niet. De auteurs stellen voor om de twee te schatten door

respectievelijk het 90% betrouwbaarheidsinterval en de mediaan va,n de verdeling voor de eerste en

tweede schatter te gebruiken. Het verschil tussen beide waarden (D=S-A) is proportioneel met de

variabiliteit in duurtijd van de activiteit. De benodigde buffergrootte wordt dan geschat als de

vierkantswortel van de som van variabiliteit D van de individuele activiteitsduurtijden in het kwadraat. In

een paper van Herroelen & Leus wordt aangetoond dat een belangrijke basisveronderstelling van deze

theorie reeds foutief is (Herroelen & Leus, 2001).

2.3.3.3 De methode der klassen van onzekerheid

Deze methode is gebaseerd op het idee dat de duurtijd van sommige activiteiten nauwkeurig kan

voorspeld worden, terwijl dit voor andere activiteiten moeilijker is. Activiteiten worden dan verdeeld

naar level van onzekerheid (Shou & Yeo, 2000). Onzekerheid wordt gemeten door de relatieve spreiding

(‘relative dispersion’(RD)), verkregen door het quotiënt van de standaarddeviatie σ en de gemiddelde

duurtijd µ van elke activiteit:

�� = �� Elke activiteit wordt onderverdeeld in 1 van de 4 klassen van onzekerheid (zeer laag, laag, hoog of zeer

hoog). Voor elke klasse zijn er 3 percentages die het gewenste veiligheidsniveau weergeven (laag,


20 | P a g i n a

medium, hoog). Men vermenigvuldigt deze percentages met de duurtijd van elke activiteit, wat

resulteert in de marge van protectie (MP). De som van deze marges van de activiteiten in een bepaalde

chain geeft de grootte van de buffer aan die deze chain moet beschermen. Indien het mogelijk is de

afwijking van de individuele activiteiten te bepalen (indien er dus een grote hoeveelheid aan verleden

data beschikbaar is), kan dit een zeer waardevolle methode zijn.

2.3.3.4 De forecast error methode

Dit model neemt expliciete data van de geschatte en feitelijke duurtijden van de activiteiten in rekening

en stelt een buffer voor op basis van de performantie van de voorspelde duurtijden (Caron & Mancini,

2006b). Voor elke activiteit wordt de gemiddelde absolute procentuele fout tegenover de voorspelling

berekend (‘mean absolute percentage error’ (MAPE)) in functie van k historische waarnemingen van de

procentuele fout tegenover de voorspelling (Pej):

�� = ∑ � ��

De grootte van de Project en Feeding Buffers (B) wordt berekend door de MAPE-waarden van de n

activiteiten in een bepaalde chain te sommeren en te vermenigvuldigen met de totale duurtijd van de

chain:

� =�� ∗ ��

Deze methode is zeer intuïtief en eenvoudig, maar heeft net zoals de 2 vorige methodes opnieuw een

grote hoeveelheid data nodig.

2.3.3.5 De simulatie methode

Dit is een methode gebaseerd op de Monte Carlo simulatie techniek en vereist de kennis van de

verdelingsfunctie, samen met de mediaan en de variantie van de verdeling van de activiteiten (Schuyler,

2000). De uitvoering van het project wordt gesimuleerd en zo verkrijgt men de verdeling van de

projectduurtijd. De grootte van de Project Buffer hangt af van de vereiste waarschijnlijkheid van de

voltooiing van het project binnen een afgesproken datum. Deze project buffer wordt bepaald door :

� = �∝ − ��%waar �∝ het ∝-percentiel van de totale duurtijd voorstelt en ��% de mediaan van de verdeling is (het

voorstel van Goldratt voor een agressieve schatting te maken). Voor de Feeding Buffer stelde deze

methode een grootte voor, gelijk aan de gemiddelde vertraging van de Feeding Chains. Als de Feeding


21 | P a g i n a

Buffer onvoldoende blijkt te zijn, waardoor de Critical Chain ook vertragingen kan oplopen, zullen de

vertragingen geabsorbeerd worden door de project buffer (Shou & Yeo, 2000).

Persoonlijk ondersteunen wij de simulatietechniek het meest. Bij complexe netwerken wordt het

moeilijk tot onmogelijk om op een correcte manier de veelheid aan informatie over alle verschillende

activiteiten in een mathematisch model te gieten, zoals de vorige technieken probeerden. Onze mening

is dan ook dat de simulatiemethode moet gebruikt worden om algemene tendensen te definiëren en

bepalen. Het resultaat zorgt er dan voor dat de Project Manager op basis van verschillende eenvoudige

en logische parameters voor uitgebreide netwerken gedetailleerde bepalingen kan doen.

2.4 Doel van Critical Chain Buffer Management

Het doel van CC/BM is vooreerst een realistische schatting te maken van de totale projectduurtijd. Door

buffers in te bouwen wordt bescherming tegen vertragingen geïncorporeerd en kan met een bepaalde

zekerheid de duurtijd van een project worden geschat. Hierop keren wij gedeeltelijk terug, zoals zal

blijken in onze resultaten van Hoofdstuk 4, omdat voor bepaalde types van netwerken de methode van

Goldratt een over- of onderschatting aanleveren.

Een tweede en tevens zeer belangrijk doel van CC/BM is een gefundeerd opvolgingsmechanisme

creëren via “Buffer management”. Gedurende het project wordt gekeken naar de Buffered Schedule om

te zien of reeds een deel van de Feeding of Project Buffers wordt geconsumeerd. De buffers hebben dus

de taak een soort van waarschuwingsmechanisme te zijn. Ze geven een indicatie over het verloop van

een project. Met andere woorden, wanneer er vertragingen opduiken in sommige taken zullen de

buffers gebruikt worden om deze vertragingen op te vangen en zo aanduiding geven van de mate

waarin het project in gevaar is om langer te duren dan gepland, rekening houdend met de proportie van

het project dat nog moet uitgevoerd worden. Dit laatste houdt natuurlijk in dat een buffer die bijna

helemaal opgebruikt is aan het begin van een project, meer gevaar inhoudt dan wanneer deze situatie

zich voordoen op het einde van een project. Wanneer één van de buffers bijna is opgebruikt, kunnen

maatregelen getroffen worden om te vermijden dat de buffer helemaal wordt opgebruikt (bijvoorbeeld

door bepaalde activiteiten meer te gaan begeleiden of controleren). Zolang een vooropgesteld deel van

een buffer nog niet werd geconsumeerd, kan geconcludeerd worden dat alles nog in orde is (groene

zone in figuur 16). Als één of meerdere activiteiten een bepaald deel van de buffer opgebruiken, kan er

een waarschuwing gelanceerd worden en kunnen maatregelen bedacht worden om het gevaar op

vertraging binnen de perken te houden (gele zone in figuur 16). Deze maatregelen (bv. werken tegen

hoger tempo door bijvoorbeeld meer resources toe te wijzen, overuren creëren, subcontracten


22 | P a g i n a

sluiten…) kunnen dan uitgevoerd worden wanneer het verbruik van de buffer een kritiek punt overstijgt

(rode zone in figuur 16).

Figuur 16: Buffer Management - opvolgmethode

Deze controlefunctie vinden wij een enorme toegevoegde waarde. In Hoofdstuk 3 zullen onze

einddoelstellingen blijken, maar we willen reeds meegeven dat de appreciatie van dit

controlemechanisme één van de redenen is waarom we verder gebruik maken van deze Buffered

Schedule in ons onderzoek naar de correcte bepaling van de lengte van de projectduurtijd.


23 | P a g i n a

Hoofdstuk 3: Doelstellingen en setup van het model

In dit hoofdstuk wordt vooreerst dieper ingegaan op de concrete doelstelling van deze masterproef,

alsook op het gevolgde pad. De samenvattende figuur in het onderdeel “3.1.1 Einddoelstelling” op p. 25

vormt tevens de leidraad voor het vervolg van dit hoofdstuk.

3.1 Einddoelstellingen en modeltoelichting

3.1.1 Einddoelstelling

Goldratt’s beschrijvingen van de Project Buffer zijn naar onze mening aan de povere kant. Zoals in het

vorige hoofdstuk werd uitgelegd, wordt doorgaans voor elk netwerk 50% van de lengte van de Critical

Chain of Feeding Chains genomen om respectievelijk de lengte van de Project Buffer en Feeding Buffers

te bepalen. Ondanks het reeds verrichte nader onderzoek (cf. supra, p.19), is dit gebied nog steeds

ontoereikend.

Een goede manier van onderzoek voor dit gegeven is, in onze ogen, de simulatiestudie zoals deze reeds

in onderdeel “2.3.3.5 De simulatie methode” werd beschreven. Het grote nadeel van deze en andere

simulatiestudies is dat ze geen rekening houden met onder andere de fundamentele vorm van de

netwerken.

Door de uitvoering van een project te simuleren, verkrijgt men een verdeling van de projectduurtijd. De

grootte van de Project Buffer hangt dan af van enerzijds de reeds opgestelde Feeding Buffered Schedule

( =Buffered Schedule zonder de Project Buffer; infra, p. 29 ) en anderzijds de vereiste waarschijnlijkheid

dat een project klaar is binnen een zeker termijn.

In ons onderzoek willen wij dan ook aantonen dat verschillende factoren resulteren in een

gedifferentieerde bepaling van de lengte van de Project Buffer (PB), zodoende zijn doel te volbrengen,

namelijk een correcte veiligheidsmarge voorzien tegen vertragingen doorheen het project. Ons

hoofddoel is het bepalen van een factor om, gegeven een bepaald netwerk en zijn eigenschappen, op

een redelijk eenvoudige manier de lengte van de PB te bepalen. Deze factor zullen we in het vervolg de

“Project Buffer Factor” (PBF) noemen.


24 | P a g i n a

De PBF wordt hier als volgt gedefinieerd:

“De Project Buffer Factor is de factor waarmee we de Feeding Buffered Schedule vermenigvuldigen om

het project in 95% van de gevallen tot een tijdig einde te brengen, gegeven:

1. de gemiddelde variantie van de activiteitsduurtijden,

2. de graad van Serialiteit/Parallellisme van het netwerk (uitgedrukt als SP),

3. de Resource Constrainedness van het netwerk (uitgedrukt als RC),

4. de Feeding Buffergrootte,

5. en de graad van Earliness of Lateness.”

Zoals gedefinieerd en te zien op de figuur op de volgende pagina (figuur 17, rood omkaderd), zijn er dus

5 zaken die een significante invloed uitoefenen op het correct bepalen van de PB. In dit hoofdstuk

beschrijven we uitgebreid de opstelling van ons experiment die we gebruiken ter uitvoering van ons

verdere onderzoek. Ook hier geeft figuur 17 de leidraad mee. In punt 3.2 bespreken we hoe we onze

werk- of dataset van netwerken hebben gegenereerd. Deze set bestaat uit een grote variëteit aan

netwerken inzake parallellisme (SP) en Resource Constrainedness (RC). Vertrekkende vanuit deze

netwerken kunnen we de Basic Feasible Schedule (infra, p. 27) opstellen, waarvan de basis reeds

gegeven werd in “1.4 De Basic Feasible Schedule”. Vanuit deze Basic Feasible Schedule worden

verschillende schedules gecreëerd, met elk hun eigen doel en functie. Zo worden de (Feeding) Buffered

Schedule en de Simulated Schedule respectievelijk toegelicht in 3.4 en 3.5.

Naast deze primaire einddoelstelling hebben we nog een bijhorend onderzoek verricht naar de

mogelijkheden en het nut van het onder controle houden van de Critical Chain in Project Execution.

Hiervoor verwijzen we direct naar het hoofdstuk van de resultaten, onderdeel 4.4 (infra, p.65)


25 | P a g i n a

3.5.2 Variantie en verdeling van

de activiteitsduurtijden

SP

RC

Feeding

Buffergrootte

3.3 Basic Feasible Schedule

3.5 Simulated Schedule

3.4.2 Feeding Buffered

Schedule

3.5.1 Projected Schedule

3.5.2 Simulated Schedule

inclusief het 95%-

betrouwbaarheidsinterval

3.5.3 Variantie van de projectduurtijd

4.3 De Project

Buffer Factor

3.2 Netwerkgenerator

Figuur 17: Overzicht van de doelstelling


26 | P a g i n a

3.1.2 Het model

Er bestaan veel verschillende commerciële programma’s en tools die gespecialiseerd zijn in Project

Scheduling (bijvoorbeeld Microsoft Project). Sommigen daarvan zijn zelfs toegespitst op Critical Chain

Scheduling (bijvoorbeeld Prochain Solutions).

Ondanks het kant-en-klare karakter van deze programma’s, misten we toch de flexibiliteit om alles

geheel naar eigen hand te zetten. We denken hierbij aan uitvoerige simulaties, het testen van

verschillende parameters, inzichten in de Critical Chain-vorming, etc. Bijgevolg ontwikkelden we zelf een

programma dat deze Critical Chain Scheduling uitvoert. Hiertoe gebruikten we de programmeertaal

“Java” binnen “IDE NetBeans”, een gratis programmeeromgeving die kan worden gedownload op

http://netbeans.org/. De broncode is tevens meegeleverd op de bijgevoegde CD-ROM achteraan dit

document.

3.2 Netwerkgenerator

Voor het genereren van de netwerken gebruikten we “Rangen2” ontwikkeld door Vanhoucke et al.

(Vanhoucke, Coelho, Debels, Maenhout, & Tavares, 2007). Elk netwerk wordt gekenmerkt door

verschillende parameters. Voor ons experiment zijn er slechts enkele van belang:

• De letter “n” geeft het aantal activiteiten in een projectnetwerk aan;

• De letter “m” geeft het aantal activiteiten op het langste pad in een projectnetwerk aan;

• De waarde van “SP” bepaalt de graad van serialiteit/parallellisme van het netwerk. Deze parameter

is een alternatief van Order Strength (OS, gebruikt in Rangen1, de voorganger van Rangen2) en een

synoniem van I2. Deze parameter werd reeds in simulatiestudies gebruikt en in de literatuur

worden enkele voordelen besproken van deze parameter ten opzichte van OS (Vanhoucke et al.,

2007). Onder andere het intuïve karakter laat toe om gemakkelijk te begrijpen waar deze

parameter voor staat. SP wordt bepaald door de lengte van het langste pad (enkel gelet op

volgorderelaties) doorheen het netwerk en het theoretisch aantal mogelijke volgorderelaties in

serie (het totaal aantal activiteiten - 1). Dit wordt op volgende manier berekend (Tavares, 1999):

� = �1� ! = 1"#��#� � ! > 1%

Een netwerk waarin alle activiteiten in parallel staan heeft een SP = 0 (m=1). Wanneer SP = 1, staan

alle activiteiten in serie tegenover elkaar (m=n).


27 | P a g i n a

• Om overbodige complexiteit te vermijden veronderstellen we dat al onze activiteiten slechts één

soort resource gebruiken. Dit aantal vermeerderen heeft geen toegevoegde waarde voor het hier

gevoerde onderzoek.

• De waarde van de Resource Constrainedness (RC), die werd geïntroduceerd door Patterson

(Patterson, 1976) bepaalt het gemiddelde resourcegebruik ten opzichte van de beschikbare

hoeveelheid resources:

�& = '̅)

met a de totale beschikbaarheid van een bepaalde (hernieuwbare) resource en *̅ het gemiddelde

resourcegebruik dat als volgt wordt berekent :

*̅ = ∑ +,-,./∑ 0�,23+45�;�789:';�<:=-,./

De parameter ri duidt de hoeveelheid resources aan die activiteit i nodig heeft per tijdseenheid. Als RC =

0.5 wil dit dus zeggen dat het resourcegebruik van de activiteiten, gemiddeld gezien, de helft bedraagt

van de beschikbare hoeveelheid.

Om onze experimenten uit te voeren, hebben we netwerken met 30 activiteiten (+ 2 dummy-

activiteiten) gegenereerd waarbij we RC laten variëren van 0.1 tot 0.9 in stappen van 0.1, idem voor SP.

Zo bekomen we 81 (= 9*9) verschillende types van netwerken. Voor elke combinatie werken we met

een steekproef van 50 netwerken om statistisch gefundeerde waarheden te kunnen bekomen.

Samengenomen resulteert dit dus in een dataset van 4050 gecontroleerde netwerken.

3.3 Basic Feasible Schedule

Nogmaals kort geresumeerd is de Basic Feasible Schedule de uitkomst van prioriteitslijsten, agressieve

duurtijdschattingen en de As-Late-As-Possible Scheduling methodologie.

Om de opbouw van ons model te illustreren gaan we in dit hoofdstuk telkens uit van het AoN-netwerk in

figuur 18. Dit netwerk bevat 13 activiteiten (waarvan 2 dummy-activiteiten) met RC=0.48 en SP=0.54. De

duurtijden van de activiteiten zijn reeds aggresief geschat.


28 | P a g i n a

Figuur 18: Activiteitennetwerk

In figuur 19 wordt de Basic Feasible schedule van dit netwerk geïllustreerd. De gebruikte priority rule is

een variant op de “Shortest Processing Time”. De prioriteitslijst wordt opgesteld door de SPT-priority

rule van achter naar voor in het netwerk toe te passen en vervolgens de lijst om te draaien:

[start,7,1,2,3,6,4,8,5,11,9,10,einde]. Vervolgens worden de verschillende activiteiten ALAP gescheduled,

rekening houdend met de volgorde van de prioriteitslijst, de volgorderelaties én een resource beperking

van 10 eenheden resource per tijdseenheid.

Figuur 19: Basic Feasible Schedule - ALAP

Deze Basic Feasible Schedule vormt de basis voor het maken van de “Buffered Schedule” en de

“Projected Schedule”. Uit deze Basic Feasible Schedule kunnen we ook reeds de Critical Chain bepalen.

In dit netwerk is er slechts 1, namelijk: [start,7,3,6,8,5,11,9,10,einde] (figuur 19, oranje inkleuring).


29 | P a g i n a

3.4 (Feeding) Buffered Schedule

3.4.1 Buffered Schedule

De Buffered Schedule bestaat uit de combinatie van de Basic Feasible Schedule (zie punt 3.3), de

Feeding Buffers en de Project Buffer. Het opstellen van deze schedule vindt plaats vóór de start van het

project en wordt gebruikt als controle tool. De uitvoering van het project verloopt echter aan de hand

van een “Projected Schedule” (infra, p.33), maar men zal het verloop steeds toetsen aan de Buffered

Schedule. Dit laatste wordt “Buffer Management” genoemd (supra, p.21). De Project Manager kan ten

allen tijde opvolgen hoeveel van de Buffers reeds geconsumeerd zijn, doordat bepaalde activiteiten

vertragingen oplopen. Zodoende kan men beter het gevaar van vertragingen inschatten en de controle

op bepaalde activiteiten opvoeren of extra resources gaan toewijzen. In Figuur 16 op p. 22 werd reeds

aangetoond hoe Buffer Management kan bijdragen tot het beschermen van de vooropgestelde duurtijd

van een project.

Gezien de hoofddoelstelling van het correct bepalen van de Project Buffer lengte, kunnen we dus nog

geen volledige Buffered Schedule opstellen. Zodoende zijn we aangewezen op het creëren van een

nieuw gegeven: de “Feeding Buffered Schedule”.

3.4.2 Feeding Buffered Schedule

De Feeding Buffered Schedule is identiek aan de Buffered Schedule, maar dan zonder het toevoegen van

een Project Buffer. Herroelen & Leus haalden reeds aan dat het logischer zou zijn zich te baseren op een

dergelijke schedule dan op de Critical Chain voor het bepalen van de Project Buffer. Wij zullen ook

uitgaan van deze redenering. Echter in tegenstelling tot Herroelen & Leus voeren wij een

simulatieoefening uit, terwijl zij een methode introduceerden die, als commentaar op de root square

methode, gebruik maakt van een logaritmische verdeling van de duurtijden (voor meer details zie

(Herroelen & Leus, 2001)).


30 | P a g i n a

Figuur 20: Activiteitennetwerk met CC en FB’s

In onze simulatie komen we terug op de 50%-regel van Goldratt. In de plaats zal er een variëteit aan

percentages worden gebruikt en de impact worden geanalyseerd. We beschouwen de Feeding Buffers

als nieuwe activiteiten met een bepaalde duurtijd en een resource-gebruik gelijk aan nul. Door het

toevoegen van de FB’s, verplaatsen de niet-CC activiteiten zich. Mogelijks kunnen bij het louter naar

voor schuiven, resource-conflicten ontstaan waardoor andere activiteiten weer verschoven moeten

worden. Een eerste aanzet tot het aankaarten van dit probleem werd reeds gegeven door Herroelen &

Leus (Herroelen & Leus, 2001). Ook Rizzo liet reeds opmerken dat de invoering van Feeding Buffers kan

resulteren in het feit dat de Critical Chain niet meer het langste pad is in het netwerk (zie het voorbeeld

gegeven in (Rizzo, 1999)). Herroelen & Leus bouwen op deze opmerking verder en zeggen dat de

procedure van Goldratt en Newbold om de buffers te integreren duidelijkheid mist. Activiteiten terug

duwen in de tijd om de Feeding Buffers te plaatsen zal resource conflicten veroorzaken. Hoe deze

conflicten moeten worden opgelost wordt echter niet beschreven. Een mogelijke oplossing is het naar

voor plaatsen van de Feeding Chains, totdat een Resource Feasible Schedule bekomen wordt. Wij halen

hier graag het voorbeeld aan gegeven door Herroelen & Leus. In Figuur 21 wordt het netwerk van dit

voorbeeld weergegeven.


31 | P a g i n a

Figuur 21: Activiteitennetwerk met CC en FB's (2)

Wanneer we een resource hoeveelheid van 3 eenheden per tijdseenheid beschouwen, dan geeft figuur

22 de Basic Feasible Schedule van dit netwerk weer. Wanneer we nu Feeding Buffers inbouwen door de

Feeding Chains naar voor te schuiven volgens het voorstel van Goldratt, treden resource conflicten op.

Deze worden opgelost door de FC naar voor te schuiven tot zich geen conflict meer voordoet. Het

resultaat zien we in figuur 23. Wat meteen opvalt is de sterke verlenging van de duurtijd (bijna 50%).

Figuur 22: Basic Feasible Schedule


32 | P a g i n a

Figuur 23: Feeding Buffered Schedule - verschuiving

Herroelen & Leus stellen dan ook voor om een volledige rescheduling uit te voeren. De uitkomst van de

volledig reschudeling wordt weergegeven in figuur 24. De resulterende Feeding Buffered Schedule heeft

(in dit geval) dezelfde lengte als de Basic Feasible Schedule.

Figuur 24: Feeding Buffered Schedule - rescheduled

Terugkerend naar ons voorbeeld gebeurt de effectieve rescheduling eigenlijk op dezelfde manier als de

Basic Feasible Schedule: een nieuwe prioriteitslijst (inclusief de FB-activiteiten) wordt opgesteld en

vervolgens worden de activiteiten ingepland volgens deze lijst. In figuur 25 zien we hoe de Feeding

Chains gebufferd worden.

Figuur 25: Feeding Buffered Schedule - rescheduled


33 | P a g i n a

3.5 Simulated Schedule

Om de correcte duurtijd van een project te schatten met een bepaalde zekerheid maken we gebruik van

een simulatie. In dit deel wordt beschreven hoe deze simulatie is opgebouwd. Zoals reeds werd

vermeld, wordt er bij de uitvoering van een project gebruik gemaakt van de Projected Schedule (PS) en

niet van de Buffered Schedule ( Goldratt E. M., 1997; Newbold, 1998). We gaan de uitvoering van een

project dan ook simuleren aan de hand van deze PS.

Voorts is de mate waarin activiteitsduurtijden variëren vanzelfsprekend een belangrijke parameter in dit

gebeuren. Zoals aangegeven in de begeleidende figuur bij de einddoelstelling (supra, p38), is dit één van

de factoren die we nader gaan bestuderen. Onder de noemer van variantie en verdeling, beschrijven

we ook de invloeden van “Earliness” en “Lateness”.

3.5.1 Projected Schedule

De Projected Schedule gehoorzaamt aan alle volgorde relaties en is resource feasible. Ook moet deze

schedule worden uitgevoerd volgens de “roadrunner mentaliteit”. Dit houdt in dat er geen individuele

mijlpalen of einddatums worden gezet per activiteit, maar elke activiteit start van zodra de voorgaande

activiteiten zijn afgewerkt. Dit wordt in het domein van scheduling theorieën “Semi-active timetabling”

genoemd:

“Timetabling is semi-active if in the resulting schedule there does not exist an operation which could be

started earlier without altering the processing sequence or violation the technological constraints and

ready dates.” (Herroelen & Leus, On the merits and pitfalls of critical chain scheduling, 2001)

Om de projectduurtijd te minimaliseren bij de uitvoering van een project, is het aangeraden om semi-

active timetabling te hanteren (French, 1960). Dit heeft als voordeel dat de tijd die gewonnen wordt

doordat sommige activiteiten vroegen klaar zijn dan gepland, niet verloren gaat omdat de volgende

activiteit meteen opgestart wordt. Deze mentaliteit houdt ook in dat we, in tegenstelling tot de Buffered

Schedule, alle activiteiten “As-Soon-As-Possible” uitvoeren en we geen rekening houden met Feeding

Buffers, noch met Project Buffers. Dit heeft natuurlijk tot gevolg dat het kan voorkomen dat het

resultaat van deze procedure in redelijke mate afwijkt van de Buffered Schedule. De Projected Schedule

van het netwerk in figuur 18 wordt weergegeven in figuur 26. We merken dat enkel activiteiten 1 en 2

vroeger kunnen starten in vergelijking met de Feeding Buffered Schedule. In de meeste gevallen is het

zo dat de Critical Chain activiteiten op dezelfde tijdstippen worden gescheduled in de Projected

Schedule en de Feeding Buffered Schedule, omdat hun slack gelijk is aan 0. Echter, soms kan het

voorkomen dat er hiaten ontstaan tussen de verschillende CC-activiteiten door het invoeren van FB. Dan


34 | P a g i n a

is dit uiteraard niet het geval (zie ook “4.1.5 Invloed van Feeding Buffers op de projectduurtijd”).

Figuur 26: Projected Schedule

3.5.2 Variantie en verdeling van de activiteitsduurtijden

Het probleem bij activiteitsduurtijden is dat ze veelal moeilijk te voorspellen zijn. Als Project Manager is

het nog moeilijker te zeggen dat de duurtijd zal variëren volgens een bepaalde verdeling (bv. normaal of

rechts scheef) met bepaalde parameters (bv. het gemiddelde en de standaardafwijking). Daarom kiezen

wij ook resoluut voor de triangulaire verdeling. Deze is eenvoudig, intuïtief en een goede benadering

van de normale of rechts scheve verdeling.

In eerste instantie wordt een symmetrische triangulaire verdeling gebruikt om het specifieke effect van

spreiding te analyseren. Daarnaast wordt ook de rechtsscheve verdeling benaderd, om op het gekende

effect van Lateness in te spelen. Figuur 27 geeft de algemene weergave van de gebruikte symmetrische

triangulaire verdeling.

Figuur 27: Symmetrisch triangulaire verdeling van de activiteitsduurtijden


35 | P a g i n a

Deze functie wordt gekenmerkt door 3 parameter a ≤ c ≤ b en heeft als voorschrift:

>?@ =ABCBD 2>? − F@>G − F@>G − H@ , F ≤ ? ≤ H

2>G − ?@>G − F@>G − H@ , H ≤ ? ≤ G

Het gemiddelde en de variantie worden respectievelijk weergegeven door de volgende formules:

� = F + G + H3

�² = F² + G² + H² − FG − FH − GH18

Praktisch geresumeerd is voor de Project Manager punt a de Best Case, punt b de Worst Case en punt c

de verwachtte duurtijd. Indien het verschil tussen a en c gelijk is aan het verschil tussen b en c, betreft

het een symmetrische verdeling. Wanneer de afstand tussen b en c groter wordt, neigen we naar

rechtsscheef en omgekeerd naar linksscheef.

Bij het bespreken van de resultaten in Hoofdstuk 4, zullen we het hebben over 9 symmetrische

variantieniveaus, reikend van geen afwijking tot grote afwijking:

- Niveau 1: duurtijd steeds gelijk aan de verwachte duurtijd (a=b=c)

- Niveau 2: duurtijd tussen 90% en 110% van de verwachte duurtijd








De effecten van Earliness en Lateness (respectievelijk links- en rechtsscheve verdeling), worden er apart

besproken.

In verband met de variantie van de activiteitsduurtijden merken we nog op dat er 2 soorten stabiliteit

bestaan. Stabiliteit kan wijzen op de ongevoeligheid van de geplande starttijden van de activiteiten voor

afwijkingen van de Projected Schedule. Dit wordt door Van de Volder solution robustness genoemd. In


36 | P a g i n a

ons onderzoek zullen we echter enkel rekening houden met quality robustness, of het belang van de

totale projectduur. In de literatuur werd reeds de trade-off tussen beide soorten robustness beschreven

(Van de Vonder, Demeulemeester, Herroelen, & Leus, 2004).

3.5.3 Variantie van de projectduurtijd

Met de besproken opzet van de Projected Schedule, de gemiddelde activiteitsduurtijden en de variantie

van de activiteitsduurtijden, voeren we een simulatie uit. De werkset van 4050 netwerken wordt elk 100

maal doorlopen voor elk van de verschillende variantiesniveaus.

De centrale limietstelling leert ons dat indien de stochastische variabelen een eindige variantie hebben,

ongeacht de onderliggende verdeling van deze variabelen, de kansverdeling convergeert naar een

normale verdeling bij grote steekproeven. Aangezien we werken met simulaties van 100 herhalingen,

gekoppeld aan 50 netwerken per type en de resultaten telkens per type bespreken, kunnen we hier

zeker op terugvallen.

Concreet wil dit zeggen dat de projectduurtijd normaal verdeeld is. Dit blijkt ook uit de Kolgomorov-

Smirnov test waarbij de nul-hypothese van normale verdeling niet verworpen wordt op het 5%-

significantieniveau. We zullen ook nagaan in welke mate variantie van de activiteiten doorsijpelt naar de

variantie van de projectduurtijd.

3.5.4 Simulated Schedule inclusief het 95%-betrouwbaarheidsinterval

In de simulatie worden activiteitsduurtijden niet deterministisch bepaalt maar we voeren de simulatie

uit met een diversiteit aan varianties van activiteitsduurtijden. Wanneer er variantie is in de

activiteitsduurtijden, verwachten we dat ook de projectduurtijden zullen variëren. Deze afwijkingen zijn

niet steeds gelijk en worden per type beschreven. Voor de projectduurtijd stellen we telkens een

betrouwbaarheidsinterval op met als bovengrens de duurtijd waarvoor 95% kans bestaat dat het project

binnen deze tijd wordt afgewerkt. Dit laatste cijfer is een gangbare assumptie. We rekenen dus met een

rechtseenzijdig interval, aangezien we veronderstellen dat het te snel afwerken van een project niet

bestraft wordt. De grafiek in figuur 28 geeft de grafische weergave van dit betrouwbaarheidinterval: De

ondergrens is uiteraard gelijk aan 0. De genoemde bovengrens is gelijk aan de gemiddelde

projectduurtijd E(x) gesommeerd met het product van de standaardafwijking en de z-waarde voor een

rechtseenzijdige betrouwbaarheidsinterval (Z5%=1,645).


37 | P a g i n a

Figuur 28: Normale verdeling van de projectduurtijd en rechtseenzijdige 95%-betrouwbaarheidsinterval

Deze laatste waarde wordt in ons onderzoek beschouwd als de referentie of ideale projectduurtijd en

wordt verkort genoteerd als SS-95%.


38 | P a g i n a

Hoofdstuk 4: Resultaten van de experimenten

In hoofdstuk 3 werd de doelstelling en gehele setup van het experiment besproken. In komend

hoofdstuk gaan we hierop verder bouwen door de resultaten van de experimenten weer te geven en te

beschrijven.

In eerste instantie bouwen we verder op het bepalen van de Project Buffer Factor. Zoals reeds vermeld,

vormen de Feeding Buffered Schedule en de Simulated Schedule de hoekstenen van de PBF. Daarom zijn

deze twee schedules dan ook opgesplitst in aparte onderdelen (respectievelijk 4.1 en 4.2). In een derde

deel finaliseren we dan het concept Project Buffer Factor (4.3). Het vierde punt staat los van dit vorige,

en toont het belang van het laag houden van de variantie binnen de Critical Chain elementen (4.4).

We merken op dat onderstaande resultaten en gevolgtrekkingen steeds statistisch getest werden in

SPSS, een softwareprogramma voor statistische analyse. Wanneer we stellen, dat een bepaald

resultaat X verschilt van een ander resultaat Y wil dit tevens ook zeggen dat dit verschil significant is

op het 5% significantieniveau. De meeste testen werden uitgevoerd door gebruik te maken van t-testen

of One-way ANOVA (= beide zijn testen om na te gaan of er een verschil is tussen de gemiddelden (bv.

gemiddelde duurtijden) van 2 of meerdere groepen uit de dataset). Wanneer een andere test werd

gebruikt, wordt dit ook expliciet vermeld bij de resultaten.

Vooraleer tot de resultaten over te gaan, resumeren we nog even de gebruikte parameterwaarden:

- We werken met een set van 81 verschillende type netwerken

o 9 waarden van SP (van 0.1 tot 0.9 met sprongen van 0.1)

o 9 waarden van RC (van 0.1 tot 0.9 met sprongen van 0.1)

- Elk type netwerk heeft opnieuw een dataset van 50 netwerken

- Elk netwerk omvat 30 activiteiten & 2 dummy-activiteiten

- De gemiddelde activiteitsduur bedraagt 16.26 tijdseenheden

- Er zijn 9 variantieniveaus (supra, p. 35) van geen variantie (niveau 1) tot grote variantie (niveau

9)

- Er zijn 9 Feeding Buffergroottes van 0.1 tot 0.9 met sprongen van 0.1

- We werken met hernieuwbare resources waarvan er steeds 10 beschikbaar zijn


39 | P a g i n a

4.1 Feeding Buffered Schedule

4.1.1 Invloed van SP op de projectduurtijd

Onderstaande grafiek (figuur 29) toont de relatie tussen de projectduurtijd van de Feeding Buffered

Schedule en de graad van Serialiteit/Parallellisme, uitgedrukt als SP. Er is duidelijk een positieve relatie

op te merken tussen beide: wanneer SP groter wordt (= het netwerk seriëler wordt), stijgt de duurtijd.

Wanneer we een lineaire regressie uitvoeren bekomen we een R² gelijk aan 0.9985 (de vergelijking van

de lineaire trendlijn en de R²-waarde worden weergegeven in de grafiek). 99.85% van de variabiliteit

wordt dus verklaard door de regressie.

Figuur 29: Invloed van SP op de duurtijd van de Buffered Schedule

Verklaring: Dit positieve verband is intuïtief aan te voelen. Hoe meer activiteiten parallel kunnen

verlopen volgens de volgorderelaties, hoe meer activiteiten samen kunnen uitgevoerd worden en dus

hoe sneller het project in zijn geheel zal uitgevoerd zijn. Omgekeerd, hoe meer activiteiten in serie

moeten verlopen volgens het netwerk, met andere woorden niet simultaan kunnen worden uitgevoerd,

hoe meer tijd het project in beslag zal nemen. We merken op dat de duurtijd van een sterk serieel

netwerk (SP=0.9) gemiddeld gezien ruim 50% groter is dan een netwerk dat sterk parallel (SP=0.1) is.

y = 19.326x + 290.82

R² = 0.9958

300

320

340

360

380

400

420

440

460

480

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

D

u

u

r

t

i

j

d

SP

Invloed van SP op de duurtijd van de

Buffered Schedule

De duurtijd van de Feeding Buffered Schedule stijgt lineair met de serialiteit van het

activiteitennetwerk.


40 | P a g i n a

4.1.2 Invloed van RC op de projectduurtijd

Onderstaande grafiek (figuur 30) toont de relatie tussen de projectduurtijd van de Feeding Buffered

Schedule en de graad van Resource Constrainedness, uitgedrukt als RC. Er is opnieuw duidelijk een

positieve relatie te bemerken tussen beiden. In tegenstelling tot de invloed van SP op de duurtijd is deze

relatie echter niet lineair, maar eerder van de S-vorm. Wanneer we RC laten variëren van netwerken

met activiteiten die weinig resources consumeren (RC=0.1) naar hoog consumerende netwerken

(RC=0.9), merken we op dat de duurtijd van de Feeding Buffered Schedule eerst progressief stijgt tot

RC=0.5 waarna zich een degressieve stijging in gang zet.

Figuur 30: Invloed van RC op de duurtijd van de Buffered Schedule

Verklaring: Ook dit verband valt opnieuw relatief duidelijk te beargumenteren. De kans dat er 2 of

meerdere activiteiten parallel komen te staan, is gelijk aan de kans dat er 2 activiteiten samen maximum

10 resources gebruiken én tevens op hetzelfde tijdstip gescheduled worden. Indien we een RC van 0.9

hebben, dan is het snel duidelijk dat deze kans over het hele netwerk gezien, miniem is, aangezien het

resource gebruik van vele activiteiten al dicht tegen de resource constraint aanliggen. Bijgevolg krijg je,

onafgezien het parallellisme in de volgorderelaties, een quasi volledig serieel netwerk.

Voor een RC van 0.8, zitten we in een vergelijkbare situatie. De kans dat 2 of meer activiteiten simultaan

worden gescheduled is ook hier zeer miniem, maar zal zich net iets sneller voordoen. Bijgevolg is er niet

veel verschil in duurtijd tussen netwerken met RC=0.8 en netwerken met RC=0.9. Wanneer we de RC

verder laten dalen, is het nu wel intuïtief aan te voelen dat het parallellisme in de volgorderelaties

exponentieel meer vrij spel krijgt.

250

300

350

400

450

500

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

D

u

u

r

t

i

j

d

RC

Invloed van RC op de duurtijd van de Buffered

Schedule


41 | P a g i n a

Anderzijds, wanneer er volgens de volgorderelaties in een bepaald netwerk 3 activiteiten parallel

kunnen worden uitgevoerd, dan maakt het niet veel uit of de RC 0.1 of 0.2 is. Zo zie je opnieuw dat ook

de kleinste waarden van RC een kleine verandering teweeg brengen.

Uit beide verhalen volgt logischerwijs dat het meeste dynamisme zich afspeelt bij een gemiddelde graad

van RC.

4.1.3 Invloed van de combinatie van RC en SP op de totale duurtijd

De aandachtige lezer zal zich waarschijnlijk enkele vragen stellen omtrent de resultaatsgrafieken van RC

en SP afzonderlijk. Al zijn de twee factoren onafhankelijk van elkaar, toch spelen ze in grote mate op

elkaar in. Wanneer een netwerk bijvoorbeeld sterk parallel is (bv. SP=0.1), volgt er het vermoeden dat

het netwerk snel kan uitgevoerd worden, aangezien de activiteiten simultaan worden uitgevoerd.

Evenwel, wanneer dit netwerk gemiddeld gezien een groot resource gebruik heeft (bv. RC=0.9), dan

zullen we moeten concluderen dat het project toch relatief lang zal duren aangezien bijna elke activiteit,

ondanks de lage SP, serieel gescheduled en uitgevoerd zal worden.

In onderstaand gedeelte bespreken we dan ook het samenspel van SP en RC.

4.1.3.1 Effect van SP voor verschillende graden van RC

Beide onderstaande grafieken (figuur 32 en figuur 33) tonen dat het effect van de SP veel sterker

uitkomt bij lage graden van Resource Constrainedness. In figuur 32 zien we dat voor netwerken met een

zeer laag resource gebruik (RC=0.1), een sterke stijging van de duurtijden aanwezig is naarmate dat de

netwerken meer serieel worden (i.e. naderen naar SP=0.9). Echter, wanneer de activiteiten in een

netwerk meer resources gebruiken, wordt deze helling getemperd of zelfs geneutraliseerd. Bij RC=0.8 en

0.9 zien we 2 horizontalen die niet significant verschillend zijn. Dit wil zeggen dat de parallellisme van

het netwerk geen enkel effect meer heeft op de duurtijd van de Buffered Schedule wanneer er een hoog

gemiddeld resource gebruik optreedt.

De duurtijd van de Feeding Buffered Schedule stijgt eerst progressief en daarna degressief

naarmate het gemiddelde resourcegebruik van de activiteiten stijgt.


42 | P a g i n a

Figuur 31: Invloed van SP op de duurtijd van de Buffered Schedule, gegeven een bepaalde waarde van RC

Figuur 32: Procentuele verlenging van de duurtijd van de Buffered Schedule, gegeven een bepaalde verhouding van RC

(RC=0.X/RC=0.1)

Verklaring: De redenering is duidelijk en intuïtief. Wanneer er een grote graad is van RC, dan resulteert

dit, onafgezien van SP reeds in een project waarvan de activiteiten serieel worden gescheduled. Deze

serialiteit ontstaat doordat de kans dat twee of meer activiteiten parallel kunnen worden uitgevoerd

50

100

150

200

250

300

350

400

450

500

550

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

Invloed van SP op de duurtijd van de Buffered

Schedule, gegeven een bepaalde waarde van RC

RC = 0.9

RC = 0.8

RC = 0.7

RC = 0.6

RC = 0.5

RC = 0.4

RC = 0.3

RC = 0.2

RC = 0.1

0%

50%

100%

150%

200%

250%

300%

350%

400%

450%

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

P

r

o

c

e

n

t

u

e

l

e

v

e

r

l

e

n

g

i

n

gSP

Procentuele verlenging van de duurtijd van de

Buffered Schedule, gegeven een bepaalde

verhouding van RC (RC=0.X/RC=0.1)

RC=0.9 / RC=0.1

RC=0.8 / RC=0.1

RC=0.7 / RC=0.1

RC=0.6 / RC=0.1

RC=0.5 / RC=0.1

RC=0.4 / RC=0.1

RC=0.3 / RC=0.1

RC=0.2 / RC=0.1


43 | P a g i n a

zeer klein is, aangezien het resource gebruik van één activiteit reeds de Resource beperking benadert.

Het gevolg is dat er voor een netwerk met RC groter dan 0.7 geen significante verschillen meer te vinden

zijn over SP heen, gegeven onze dataset. Hoe kleiner de RC, hoe significanter het verschil van de

projectduurtijden van netwerken met verschillende SP.

De tweede grafiek (figuur 32) geeft dezelfde gegevens weer, maar nu verhoudingsgewijs

(RC=0.X/RC=0.1) uitgedrukt. Een netwerk met hoge RC zal voor kleine graden van SP een heel stuk

langer zijn dan netwerken met een lage RC. Wanneer we naar de grotere graden van SP gaan, wordt dit

effect steeds kleiner. We kunnen dus zeggen dat de procentuele verlenging kleiner wordt, naarmate de

SP groter wordt. Ook kan hier nogmaals opgemerkt worden dat de resultaten voor RC=0.8 en RC=0.9

niet significant verschillen.

4.1.3.2 Effect van RC voor verschillende graden van SP

Beide onderstaande grafieken (figuur 33 en figuur 34) tonen dat het effect van RC veel sterker uitkomt

bij grotere vormen van parallellisme. In de eerste grafiek zien we de invloed van RC op de duurtijd van

de Feeding Buffered Schedule voor verschillende waarden van SP. We merken op dat de grafiek van de

netwerken met hoge graad van parallellisme (SP=0.1) een veel sterkere stijging kent over RC heen,

terwijl de grafiek van SP=0.9 niet zoveel wijzigt. Echter, naarmate RC nadert naar een waarde 0.9,

vertonen de verschillende graden van SP geen significante verschillen meer.

De mate van parallellisme in een activiteitennetwerk heeft een sterkere invloed op de duurtijd

van de Feeding Buffered Schedule bij projecten met een laag gemiddeld resourcegebruik.


44 | P a g i n a

Figuur 33: Invloed van RC op de duurtijd van de Buffered Schedule, gegeven een bepaalde waarde van SP

Figuur 34: Procentuele verlenging van de duurtijd van de Buffered Schedule, gegeven een bepaalde verhouding van SP

(SP=0.X/SP=0.1)

Verklaring: Wanneer er een grote graad is van SP, dan resulteert dit, onafgezien van RC reeds in een

project waarvan de schedule grotendeels serieel moet worden uitgevoerd. Deze serialiteit ontstaat dan

0

100

200

300

400

500

600

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

D

u

u

r

t

i

j

d

RC

Invloed van RC op de duurtijd van de Buffered

Schedule, gegeven een bepaalde waarde van SP

I2 = 0.9

I2 = 0.8

I2 = 0.7

I2 = 0.6

I2 = 0.5

I2 = 0.4

I2 = 0.3

I2 = 0.2

I2 = 0.1

0%

50%

100%

150%

200%

250%

300%

350%

400%

450%

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

P

r

o

c

e

n

t

u

e

l

e

v

e

r

l

e

n

g

i

n

gRC

Procentuele verlenging van de duurtijd van de

Buffered Schedule, gegeven een bepaalde

verhouding van SP (SP=0.X/SP=0.1)

I2=0.9 / I2=0.1

I2=0.8 / I2=0.1

I2=0.7 / I2=0.1

I2=0.6 / I2=0.1

I2=0.5 / I2=0.1

I2=0.4 / I2=0.1

I2=0.3 / I2=0.1

I2=0.2 / I2=0.1


45 | P a g i n a

puur uit de volgorderelaties, onafgezien van RC. Hoe kleiner de waarden van SP, hoe groter de invloed

van RC. Zoals bij het algemeen effect te zien was, komt ook hier de s-vormige grafiek steeds terug.

De tweede grafiek geeft wederom dezelfde gegevens verhoudingsgewijs (SP=0.X/SP=0.1) weer. Een

netwerk met hoge SP zal voor kleine waarden van RC een heel stuk langer zijn dan netwerken met een

lage SP. Wanneer we naar de grotere waarden van RC gaan, wordt dit effect steeds kleiner. We kunnen

dus zeggen dat de procentuele verlenging kleiner wordt, naarmate de RC groter wordt.

4.1.3.3 SP en RC samengebracht

Wanneer we nu de invloed van beide variabelen in een 3D-grafiek zetten, krijgen we een duidelijk

overzicht van waar zich de grootste verschillen in duurtijden voordoen (figuur 35).

Figuur 35: Projectduurtijd van de Buffered Schedule

De vorm van deze grafiek met de beschreven invloeden van SP en RC zijn duidelijk te zien. Omwille van

het statistisch gegeven zijn er natuurlijk steeds kleine afwijkingen terug te vinden. Wanneer we verder

0.1

0.3

0.5

0.7

0.9

0

100

200

300

400

500

600

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

D

u

u

r

t

i

j

d

RC

Projectduurtijd van de Buffered Schedule

Het gemiddelde resource gebruik van de activiteiten in een project heeft een sterkere invloed op

de duurtijd van de Feeding Buffered Schedule bij projecten waarvan het activiteitennetwerk

sterk parallel is.


46 | P a g i n a

zouden werken met deze afwijkingen, alsook met de afwijkingen te wijten aan Whitespaces (infra,

4.1.5), vergroten die in een volgende fase exponentieel. Daarom opteren we ervoor om trendlijnen op

de data toe te passen en deze geoptimaliseerde cijfers als verdere rekendata te gebruiken (figuur 36).

Figuur 36: Projectduurtijd van de Buffered Schedule - trendlijn correctie

In de Bijlage vindt men de exacte cijfergegevens terug van deze omvorming.

4.1.4 Invloed van Feeding Buffergrootte op de projectduurtijd

We verwachten dat vergrote Feeding Buffers zullen resulteren in een verlenging van de projectduurtijd.

Dit wordt ook bevestigd in figuur 37.

0.1

0.3

0.5

0.7

0.9

0

100

200

300

400

500

600

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

D

u

u

r

t

i

j

d

RC

Projectduurtijd van de Buffered Schedule

- trendlijn correctie


47 | P a g i n a

Figuur 37: Invloed van de Feeding Buffergrootte op de duurtijd van de Buffered Schedule

Verklaring: Indien de FBs groter worden, zullen de Feeding Chains meer naar voor worden

opgeschoven, de kans op resource conflicten wordt groter, waardoor de Feeding Buffered Schedule

uiteraard meer kans maakt om langer te duren aangezien de schedule wordt uitgerokken wanneer deze

conflicten worden opgelost.

Daarentegen, dit effect is niet algemeen waarneembaar. De Feeding Buffergrootte heeft praktisch geen

invloed op netwerken met hoge SP en/of hoge RC. Daarom is verder opsplitsen wel van belang. De

effecten van buffer vergroting zijn bij lage SP en lage RC zeer krachtig, terwijl deze bij hoge SP en/of RC

nauwelijks merkbaar zijn. Dit wordt verder beschreven in “4.3.3 Invloed van de Buffergrootte”.

4.1.5 Invloed van Whitespaces op de projectduurtijd

4.1.5.1 Inleiding

Bij het invoegen van de Feeding Buffers in de Feeding Buffered Schedule, zagen we reeds dat de

volledige rescheduling methode tot betere resultaten leidde dan het simpelweg vooruitschuiven van de

Feeding Chain (supra, p. 31). Echter, ook met deze rescheduling procedure zijn niet alle problemen van

375

380

385

390

395

400

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

D

u

u

r

t

i

j

d

Buffergrootte

Invloed van de Feeding Buffergrootte op de

duurtijd van de Buffered Schedule

Bij verhoging van de Feeding Buffergrootte, zal ook de duurtijd van de Feeding Buffered

Schedule gemiddeld gezien stijgen.


48 | P a g i n a

de baan. We zullen aantonen in dit onderdeel dat er bepaalde gaten of periodes zonder enig resource

gebruik kunnen voorkomen. Dit fenomeen wordt in de verdere tekst “Whitespaces” genoemd.

In het eerste punt van dit onderdeel bespreken we hoe deze Whitespaces tot stand kunnen komen

(4.1.5.2). Daarna onderzoeken we of het voorkomen van Whitespaces verband houdt met het Type

Netwerk waarin ze voorkomen (4.1.5.3 en 4.1.5.4), alsook hoe drastisch het effect is van de Feeding

Buffergrootte (4.1.5.5). Als laatste proberen we een conclusie te vormen over de invloed van dit

verschijnsel op het bepalen van de grootte van de Project Buffer, het einddoel van deze masterproef

(4.1.5.6).

4.1.5.2 Ontstaan van Whitespaces

Whitespaces komen tot stand door het invoeren van Feeding Buffers. Bij de rescheduling kan het

voorkomen dat de Critical Chain opgesplitst wordt in twee of meerdere delen (als gevolg van de

invoeging van de Feeding Buffers). Wanneer dit voorkomt, kan het voorts gebeuren dat er plaatsen

ontstaan zonder enig resource gebruik (enkel Feeding Buffers komen voor op die tijdseenheden).

Onderstaande figuren geven hier een visuele weergave van. Figuur 38 geeft een projectnetwerk weer

waarvan de Basic Feasible Schedule gegeven staat in figuur 39.

Figuur 38: Activiteitennetwerk


49 | P a g i n a

Figuur 39: Basic Feasible Schedule

In de volgende figuur (figuur 40) worden de plaatsen bepaald waar de Feeding Buffers zich moeten

vestigen, gegeven de Critical Chain in oranje. Vervolgens wordt een Feeding Buffered Schedule

opgesteld en een rescheduling procedure uitgevoerd. Het resultaat wordt weergegeven in figuur 41. We

merken op dat er vanaf periode 34 tot 39 geen resourcegebruik is van geen enkele activiteit. De Feeding

Buffer, die de Feeding Chain [1,5,7,10] beschermt tegen vertragingen en bijgevolg de Critical Chain ook

beschermt, zorgt ervoor dat deze ruimte ontstaat.

Figuur 40: Activiteitennetwerk met CC en FB's


50 | P a g i n a

Figuur 41: Feeding Buffered Schedule met Whitespace

Deze FB schuift de Feeding Chain [1,5,7,10] naar voor. Aangezien activiteit 6 vóór activiteit 10 moet

uitgevoerd worden (volgorderelaties), moet ook activiteit 6 naar voor schuiven, waardoor een hele

kettingreactie op gang komt. Het resultaat is dus een whitespace op tijdstippen 34 tot en met 39.

4.1.5.3 Invloed van SP op het voorkomen van Whitespaces

In dit puntje gaan we na of er een relatie bestaat tussen SP en het voorkomen van Whitespaces. De

output van dit onderzoek wordt weergegeven in figuur 42. De verticale as geeft het procentuele aantal

netwerken die Whitespaces bevatten weer. Voor elke waarde van SP gaan we dus na hoeveel van de

450 (9*50) netwerken Whitespaces bevatten.

We kunnen observeren dat het relatief aantal netwerken met Whitespaces eerst degressief stijgt tot een

waarde voor SP gelijk aan 0.3, waarna het aantal (bijna lineair) daalt. Op de top bij SP=0.3 bevatten 32%

van de geobserveerd netwerken Whitespaces.

Figuur 42: Invloed van SP op het voorkomenv an Whitespaces

0%

5%

10%

15%

20%

25%

30%

35%

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9Pro

cen

tue

el

aa

nta

l sc

he

du

les

me

t W

hit

esp

ace

s

SP

Invloed van SP op het voorkomen van Whitespaces


51 | P a g i n a

Verklaring: Veronderstellen we het extreme geval waar alle activiteiten in parallel kunnen worden

gescheduled. De CC wordt dan in principe bepaald door de langste activiteit. Om Whitespaces te

ontwikkelen moeten de parallelle activiteiten Feeding Buffers bevatten die groter zijn dan de CC-

activiteit. Bij volledig parallellisme moet de Buffergrootte dan per definitie groter zijn dan 100% van de

Feeding Chain. Daar dit niet voorkomt (maximale grootte gelijk aan 0.9), is er dan ook geen sprake van

Whitespaces in dit geval. Hierop verder bouwend, verklaren we dat bij sterk parallelle netwerken

Whitespaces weinig voorkomen. Naarmate projecten minder parallel worden, vermindert enerzijds het

aantal Feeding Buffers, maar verhoogt anderzijds wel de lengte ervan. Deze twee antagonistische

factoren blijken het sterkst Whitespaces te ontwikkelen bij SP=0.3.

Na SP gelijk aan 0.3 is er een gestage daling in het procentueel aantal schedules met Whitespaces. Dit

kunnen we beter begrijpen door het andere extreme geval van een volledige serieel netwerk te nemen.

Dit laatste heeft tot gevolg dat de Feeding Buffered Schedule ook volledig serieel zal zijn, waardoor er

geen Feeding Chains zijn en dus ook geen kans op Whitespaces. In een bijna volledig serieel netwerk is

er een minimaal aantal FB’s, waardoor de kans op resource conflicten met de CC-activiteiten bijgevolg

ook kleiner is.

De kans op het voorkomen van Whitespaces is het grootst wanneer het activiteitennetwerk van

een project noch sterk serieel, noch sterk parallel is.

De kans op het voorkomen van Whitespaces hangt af van 2 antagonistische factoren: Het aantal

Feeding Buffers en de lengte van de Feeding Buffers.


52 | P a g i n a

4.1.5.4 Invloed van RC op het voorkomen van Whitespaces

Voor de Invloed van de Resource Constrainedness op het voorkomen van Whitespaces zien we een S-

vormige daling (figuur 43).

Figuur 43: Invloed van RC op het voorkomen van Whitespaces

Verklaring: Wanneer er een hoog gemiddeld gebruik is van resources, dan is de kans op een seriële

schedule ook hoger. Zoals in vorig punt verklaard, is het voorkomen van Whitespaces in seriële

schedules erg klein. Met een dalend resource gebruik, stijgt de kans op parallellisme en dus ook op

Whitespaces. Daarentegen blijft het aantal Feeding Buffers en hun grootte gemiddeld gezien gelijk.

Bijgevolg verklaren we de S-vorm van deze grafiek aan de hand van de invloed van RC op de

projectduurtijd bij Buffered Schedules.

0%

5%

10%

15%

20%

25%

30%

35%

40%

45%

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

Pro

cen

tue

el

aa

nta

l sc

he

du

les

me

t W

hit

esp

ace

s

RC

Invloed van RC op het voorkomen van Whitespaces

De kans op het voorkomen van Whitespaces daalt, eerst progressief en daarna degressief,

naarmate het gemiddelde resource gebruik van de activiteiten stijgt.


53 | P a g i n a

4.1.5.5 Invloed van de grootte van de Feeding Buffers op het voorkomen van Whitespaces

Figuur 44 geeft het verband tussen het voorkomen van Whitespaces en de grootte van de Feeding

Buffers.

Figuur 44: Invloed van FB Grootte op het voorkomen van Whitespaces

Verklaring: Logischerwijs is er meer kans op een periode zonder resource gebruik naarmate de FBs

groter worden, aangezien deze buffers bepalen hoeveel de Feeding Chains naar voor worden

verschoven. Hoe groter de buffers, hoe groter de verschuiving van de Feeding Chains en des te meer

kans dat een volgorde relatie ervoor kan zorgen dat ook de critical chain wordt gesplitst.

4.1.5.6 Invloed op de projectduurtijd

In dit deel onderzoeken we of netwerken met Whitespaces een duurtijd hebben die significant hoger ligt

dan netwerken zonder Whitespaces. Om dit de onderzoeken hebben we natuurlijk een voldoende grote

steekproef nodig en dus voldoende samples van netwerken met Whitespaces. Daarom hebben we

ervoor gekozen om enkel naar de verschillen te kijken in netwerken met FB-grootte van 0.9, een RC

kleiner dan 0.6 en SP tussen 0.1 en 0.8. De rest van onze resultaten zijn onbetrouwbaar wegens de te

kleine steekproef in schedules met Whitespaces (grijs in tabel 1).

0%

2%

4%

6%

8%

10%

12%

14%

16%

18%

20%

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9Pro

cen

tue

el

aa

nta

l n

etw

erk

en

me

t

wh

ite

spa

ces

Feeding Buffergrootte

Invloed van FB Grootte op het

voorkomen van Whitespaces

De kans op het voorkomen van Whitespaces stijgt naarmate de Feeding Buffers groter worden.


54 | P a g i n a

Duurtijden met Whitespaces/duurtijden zonder Whitespaces

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

RC

0.1 109% 150% 127% 160% 141% 122% 116% 95% 105%

0.2 104% 130% 127% 138% 116% 114% 112% 104% -

0.3 103% 121% 120% 130% 119% 122% 111% 93% 113%

0.4 101% 114% 121% 122% 124% 101% 107% 102% 105%

0.5 96% 111% 101% 108% 101% 113% 103% 90% -

0.6 116% 103% 91% 103% 93% 106% 115% 106% -

0.7 - 99% 100% 103% - - - - -

0.8 - - - - - - - - -

0.9 - - - - - - - - - Tabel 1: Duurtijden met Whitespaces/duurtijden zonder Whitespaces

De tabel bekijkt beide duurtijden relatief en geeft het quotiënt van de duurtijd van scheduled met

Whitespaces op de duurtijd van schedules zonder Whitespaces weer voor de verschillende types

netwerken. Wat meteen opvalt is dat het quotiënt steeds meer dan 100% bedraagt, wat wil zeggen dat

netwerken met Whitespaces langer lijken te duren. Na statistisch testen (t-test), wordt dit vermoeden

van significantie ook bevestigd.

4.2 Simulated Schedule inclusief het 95%-betrouwbaarheidsinterval

In dit deel wordt ingegaan op de gevolgen van verschillende factoren op de Simulated Schedule met

95%-betrouwbaarheidsinterval (SS-95%). Zoals reeds werd vermeld (supra, p. 33), verkrijgen we de

Simulated Schedule door een simulatieoefening uit te voeren op de Projected Schedule. De

cijfergegevens uit dit deel resulteren uit een oefening van 3,650,000 simulaties (= 9*9*9*50*100 =

[SP]*[RC]*[variantie van de activiteitsduurtijden]*[aantal netwerken per type]*[aantal simulaties per

type]).

4.2.1 Invloed van SP op de projectduurtijd

Onderstaande grafiek toont de relatie tussen de projectduurtijd van de Simulated Schedule en de graad

van parallellisme, uitgedrukt als SP. Er is, net zoals bij de Buffered Schedule, duidelijk een positieve

relatie op te merken tussen beide: wanneer SP groter wordt, stijgt de duurtijd. Wanneer we een lineaire

regressie uitvoeren bekomen we een R² gelijk aan 0.9957 (de vergelijking van de lineaire trendlijn en de

R²-waarde worden weergegeven in figuur 45).

De projectduurtijd van schedules die Whitespaces bevatten is significant hoger in vergelijking

met schedules zonder Whitespaces.


55 | P a g i n a

Figuur 45: Invloed van SP op de duurtijd van de Simulated Schedule inclusief het 95%-betrouwbaarheidsinterval

Verklaring: Het is opnieuw logisch dat wanneer men de activiteiten van een project in serie moet

uitvoeren, dit langer zal duren dan wanneer men dezelfde activiteiten in parallel kan uitvoeren.

y = 20.92x + 282.89

R² = 0.9957

250

300

350

400

450

500

550

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

D

u

u

r

t

i

j

d

SP

Invloed van SP op de duurtijd van de

Simulated Schedule incl. het 95%-BI

De duurtijd van de Simulated Schedule inclusief het 95%-betrouwbaarheidsinterval stijgt lineair

naarmate het activiteitennetwerk meer serieel wordt.


56 | P a g i n a

4.2.2 Invloed van RC op de projectduurtijd

Ook hier komt de S-curve terug (figuur 46). Enkel start deze hier een stukje lager dan de

overeenkomende RC-invloed van de Buffered Schedule.

Figuur 46: Invloed van RC op de duurtijd van de Simulated Schedule inclusief het 95%-betrouwbaarheidsinterval

Verklaring: Voor de verklaring van de vorm verwijzen we naar het gedeelte van de Buffered Schedule.

Opnieuw is het dynamisme het grootst bij een gemiddelde graad van RC.

4.2.3 Invloed van de combinatie van RC en SP op de totale duurtijd

Ook hier volgen we weer dezelfde redenering als in “4.1.3 Invloed van de combinatie RC en SP op de

totale duurtijd”. We bekomen uiteindelijk een gelijkaardige 3D-grafiek (figuur 47), die we wederom gaan

corrigeren (figuur 48).

200

250

300

350

400

450

500

550

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

D

u

u

r

t

i

j

d

RC

Invloed van RC op de duurtijd van de Simulated

Schedule incl. het 95%-BI

De duurtijd van de Simulated Schedule inclusief het 95%-betrouwbaarheidsinterval stijgt eerst

progressief en daarna degressief naarmate het gemiddelde resourcegebruik van de activiteiten

groter wordt.


57 | P a g i n a

Figuur 47: Projectduur van de Simulated Schedule

Figuur 48: Projectduurtijd van de Simulated Schedule - trendlijn correctie

Opnieuw verwijzen we voor de exacte cijfers naar bijlage 1.2.

0.1

0.3

0.5

0.7

0.9

0

100

200

300

400

500

600

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

D

u

u

r

t

i

j

d

RC

Projectduurtijd van de Simulated Schedule

0.1

0.3

0.5

0.7

0.9

0

100

200

300

400

500

600

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

D

u

u

r

t

i

j

d

RC

Projectduurtijd van de Simulated Schedule -

trendlijn correctie


58 | P a g i n a

4.2.4 Invloed van de variantie van de activiteitsduurtijden op de projectduurtijd

In onderstaande grafiek (figuur 49) wordt het verband verduidelijkt tussen de variantie van de

activiteitsduurtijden en de projectduurtijd van de SS-95%. We merken een positief verband op: wanneer

de variantie in de duurtijden stijgt, dan zal ook gemiddeld gezien de duurtijd van de SS-95% toenemen.

Figuur 49: Invloed van de variantie van de activiteitsduurtijden op de projectduurtijd

Net zoals bij de invloed van de Feeding Buffers, is er een groot verschil te merken tussen de

verschillende type netwerken. Dit wordt ook verder besproken in “4.3.2 Invloed van de variantie van de

activiteitsduurtijden”.

350

360

370

380

390

400

410

420

430

440

1 2 3 4 5 6 7 8 9

D

u

u

r

t

i

j

d

Variantieniveau

Invloed van de variantie van de

activiteitsduurtijden op de

projectduurtijd

Wanneer de variantie van de activiteitsduurtijden vergroot, stijgt gemiddeld gezien ook de

duurtijd van de Simulated Schedule inclusief het 95%-betrouwbaarheidsinterval.


59 | P a g i n a

4.3 De Project Buffer Factor

In de twee vorige paragrafen bespraken we de invloeden van enkele factoren op de Feeding Buffered

Schedule en Simulated Schedule. In dit onderdeel evalueren we hoe de besproken effecten rechtstreeks

inspelen op de bepaling van de finale Project Buffer Factor (PBF). Zoals gedefinieerd in “3.1.1

Einddoelstelling” is de Project Buffer Factor de factor waarmee we de Feeding Buffered Schedule

vermenigvuldigen om het project in 95% van de gevallen tot een tijdig einde te brengen. We zullen in dit

deel tot een geïntegreerde methodiek komen voor de correctere bepaling van deze PBF via enkele

tussenstappen. De onderdelen of tussenstappen zijn:

- de referentie factor,

- de invloed van de combinatie SP en RC,

- de invloed van de Buffergrootte,

- de invloed van de Variantie van de activiteitsduurtijden

- en de invloed van Earliness/Lateness van de activiteitsduurtijden

De PBF wordt bepaald door de samenstelling van de verschillende factoren:

NOPQRSTUVWWROXYSTPO

= Z[RWROR\T]RWYSTPO^ ∗ Z_\`aPRb`Y\bRSPcd]\YT]ReNR\[f^∗ g hXYSTPO`Y\bRXRRb]\iUVWWROjOPPTTRk∗ ZXYSTPO`Y\bRlYO]Y\T]R^ ∗ ZXYSTPO`Y\bRmYOa]\RnnPWoYTR\Rnn^ 4.3.1 De Referentiefactor

De Referentiefactor streeft naar het bepalen van een startpunt om de PBF een beginnende vorm te

geven. Dit is een zeer algemene factor die gelijk is voor elke vorm van variantie, Buffergrootte, Resource

Constrainedness en parallellisme. Samengevat wordt dit gemiddelde als volgt berekend:

�� *�!p�� FHpq* =

gemiddeldeduurtijdvanhetSimulatedScheduleincl. 95% − betrouwbaarheidsintervalvanallenetwerkenvanalletypesmetallevormenvanactiviteitsvariantiesenBuffergroottesgemiddeldeFeedingBufferedNetwerkduurtijdvanallenetwerkenvanalletypesmetallevormenvanactiviteitsvariantiesenBuffergroottes


60 | P a g i n a

Deze referentiefactor geeft ons een waarde terug van 104,5%. Dit wil dus zeggen dat gemiddeld gezien,

over alle type netwerken en alle vormen van activiteitsvarianties en Buffergroottes, de duurtijd van de

Simulated Schedule inclusief het 95%-betrouwbaarheidsinterval 4,5% langer is dan de duurtijd van de

Feeding Buffered Schedule. Belangrijk is dat bij de berekening van deze factor nog geen rekening werd

gehouden met linksscheve of rechtsscheve verdeling van activiteitsduurtijden. Om de invloed van deze

laatste op te meten is een afzonderlijke simulatie uitgevoerd.

4.3.2 Combinatie van SP & RC

SP en RC zijn, zoals reeds eerder opgemerkt, niet afzonderlijk te observeren voor het becijferen van hun

invloed. Daarom nemen we deze twee factoren samen in één factor die als volgt gedefinieerd wordt:

�FHpq*�&�& =�FF*��F!�� FHpq*G��FF��qq*��Hq�G�!Fp��F!��!�&�� FHpq*q��*F��Hq�G�!Fp��F!��!�&

Hieronder de bijhorende cijfergegevens:

RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 87.4% 87.6% 92.7% 97.4% 100.3% 101.4% 101.7% 102.0% 102.0%

0.2 92.9% 92.3% 94.8% 98.1% 100.5% 101.4% 101.7% 102.0% 102.0%

0.3 95.9% 95.4% 96.4% 98.6% 100.7% 101.5% 101.7% 102.0% 102.0%

0.4 97.6% 97.4% 97.6% 99.1% 100.8% 101.5% 101.7% 101.9% 102.0%

0.5 98.8% 99.0% 98.6% 99.5% 101.0% 101.5% 101.7% 101.9% 102.0%

0.6 99.7% 100.1% 99.4% 99.8% 101.1% 101.5% 101.7% 101.9% 102.0%

0.7 100.4% 101.0% 100.1% 100.2% 101.2% 101.5% 101.7% 101.9% 102.0%

0.8 100.9% 101.8% 100.7% 100.4% 101.3% 101.5% 101.8% 101.9% 102.0%

0.9 101.3% 102.4% 101.2% 100.7% 101.4% 101.5% 101.8% 101.9% 102.0% Tabel 2: Factor SP & RC

Er blijkt dat de Project Buffer Factor voor netwerken met een lage Resource Constrainedness en hoge

graad van parallellisme (de linkerbovenhoek van tabel 2) gemiddeld een stuk kleiner is. Dit wijst erop

dat volgens onze simulatiestudie de Feeding Buffered Schedules van deze netwerken een stuk te lang

zijn. Door het parallellisme van deze netwerken worden reeds vele Feeding Buffers ingebouwd, die soms

te veel zekerheid lijken in te bouwen.

4.3.3 Invloed van de Feeding Buffergrootte

De Feeding Buffergrootte speelt in op de noemer van de Project Buffer Factor. Bijgevolg berekenen we

hier een factor, waar de referentiefactor uiteindelijk zal door gedeeld worden.


61 | P a g i n a

�FHpq*�F!��*qqpp� =��FF*��F!��*q��Hp��*p��,��F ℎF!��F!��!�&,��!��!G��FF�� *�*qqpp� FHpq*��*q��Hp��*p��F!��!�� *�Hℎ��

In “4.1.4 Invloed van Feeding Buffergrootte op de projectduurtijd” gaven we reeds mee dat het

algemene verband tussen Feeding Buffergrootte en projectduurtijd positief was. Een extra opmerking

werd wel nog toegevoegd, namelijk dat deze invloed ook type-afhankelijk is (met andere woorden,

afhankelijk van de combinatie van SP en RC). De invloed bij bepaalde combinaties is veel groter dan bij

andere.

Zodoende, moet men afhankelijk van de Feeding Buffer een bepaald getal uit de tabel nemen. We geven

hieronder het voorbeeld van Feeding Buffer met grootte 0.21.

FB:

0.2

RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 88% 95% 97% 98% 99% 99% 100% 100% 100%

0.2 85% 90% 92% 96% 98% 100% 99% 100% 100%

0.3 90% 88% 91% 96% 98% 99% 100% 100% 100%

0.4 89% 89% 93% 94% 98% 99% 99% 100% 100%

0.5 93% 93% 94% 96% 98% 99% 100% 100% 100%

0.6 96% 97% 97% 98% 98% 99% 100% 100% 100%

0.7 98% 97% 98% 98% 99% 100% 100% 100% 100%

0.8 100% 99% 99% 99% 99% 100% 100% 100% 100%

0.9 100% 100% 100% 100% 100% 100% 100% 100% 100% Tabel 3: Invloed van de Feeding Buffergrootte bij FB = 0.2

Een gegeven dat bij alle tabellen terugkeert, is dat bij grote mate van SP en/of RC, de invloed van de

Feeding Buffergrootte verwaarloosbaar is. Ook zijn de invloeden het sterkst in de linkerbovenhoek: bij

sterk parallelle schedules hebben de FB’s een directe invloed op de bepaling van de benodigde Project

Buffer. Hiermee brengen we het probleem van de Merge Bias in rekening bij de berekening van PBF (zie

“1.5.4 de Merge Bias). Logischerwijs zijn in tabellen met FB groter dan 0.5, alle getallen groter of gelijk

aan 100%, zoals onderstaande tabel voor FB=0.8 aantoont. Met andere woorden: Hoe groter de

ingebouwde Feeding Buffers, hoe kleiner de Project Buffer Factor.

1 Voor de overige tabellen, zie Bijlage 1.3.1.


62 | P a g i n a

FB:

0.8

RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 113% 106% 104% 101% 101% 101% 100% 100% 100%

0.2 116% 110% 108% 104% 102% 101% 101% 100% 100%

0.3 111% 112% 109% 105% 102% 101% 100% 100% 100%

0.4 112% 112% 107% 106% 102% 101% 100% 100% 100%

0.5 108% 107% 106% 105% 102% 101% 100% 100% 100%

0.6 104% 103% 103% 103% 102% 101% 100% 100% 100%

0.7 103% 103% 102% 102% 100% 100% 100% 100% 100%

0.8 101% 101% 101% 101% 101% 100% 100% 100% 100%

0.9 100% 100% 100% 100% 100% 100% 100% 100% 100% Tabel 4: Invloed van de Feeding Buffergrootte bij FB = 0.8

4.3.4 Invloed van de Variantie van de activiteitsduurtijden

Het is duidelijk dat de variantie van de activiteitsduurtijden verder inspeelt op de teller van de PBF: Hoe

groter de variantie, hoe groter de benodigde veiligheidsmarge. In het onderdeel over de Simulated

Schedule werd de invloed van Variantie reeds beschreven.

Hier wordt deze invloed lichtjes anders gedefinieerd:

�FHpq*�F!�� F*�F!p�� =

��FF*��F!��*q��Hp��*p��F!��Fp��Hℎ��,��F ℎF!��F!��!�&,��!��!G��FF��*FF��F!��F*�F!p��F!��FHp��p��p��*p��!��*q��Hp��*p��F!��Fp��Hℎ�� Net zoals bij de invloed van de Feeding Buffergrootte in bovenstaand punt, merken we dat ook de

variantie op een andere manier inspeelt op de verschillende type netwerken. Onderstaande tabel geeft

de factor weer voor variantieniveau 8 (tabel 5).

RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 110% 108% 107% 106% 106% 105% 105% 105% 105%

0.2 109% 107% 107% 106% 105% 105% 105% 105% 105%

0.3 107% 107% 106% 106% 105% 105% 105% 105% 105%

0.4 107% 107% 106% 106% 105% 105% 105% 105% 105%

0.5 106% 106% 106% 105% 105% 105% 105% 105% 104%

0.6 105% 105% 106% 105% 105% 105% 105% 105% 105%

0.7 105% 105% 105% 105% 105% 105% 104% 104% 105%

0.8 105% 105% 105% 105% 105% 105% 104% 105% 105%

0.9 105% 105% 105% 104% 105% 105% 104% 104% 104% Tabel 5: Invloed van de Variantie van de activiteitsduurtijden


63 | P a g i n a

In tegenstelling tot de Feeding Buffergrootte, is deze factor van belang voor alle types van netwerken.

Dit komt doordat de variantie van de activiteitsduurtijden per definitie doorsijpelt in de variantie van de

projectduurtijd. Zodoende is er overal een duidelijk effect waarneembaar. Wel geldt er voor al de

variantietabellen dat de factor in de linkerbovenhoek wederom veel meer uitgesproken is. Dit is te

verklaren door het feit dat in sterk parallel geplande netwerken een vertraging in één van de activiteiten

al meteen een invloed kan hebben op de projectduurtijd (Merge Bias; supra, p. 11). De tabellen van de

overige varianties kunnen in bijlage 1.3.2 gevonden worden.

4.3.5 Invloed van Earliness/Lateness van de activiteitsduurtijden

In de uitleg over de variantie van de activiteitsduurtijden, werd de rechtsscheve triangulaire verdeling

kort vermeld. Het gebruik van rechts scheve verdelingen in plaats van de symmetrische verdeling heeft

slechts 1 invloed, geldend voor alle types van netwerken. Indien een rechtsscheve verdeling dezelfde

variantie heeft als een symmetrische verdeling, dan moet de PBF van de symmetrische verdeling enkel

met de relatieve verwachtingswaarde vermenigvuldigd worden. Met andere woorden, indien de

verwachtingswaarde van de rechtsscheve verdeling 5 procent groter is, dan is de factor voor Lateness

1.05. Hetzelfde geldt ook voor het omgekeerde geval, namelijk Earliness.

4.3.6 Een uitgewerkt voorbeeld

Stel een bouwproject met 30 activiteiten. Er zijn in totaal 15 werknemers aanwezig waarvan er

gemiddeld 3 nodig zijn per activiteit. Het projectnetwerk bevat, gezien de definitie van

Serialiteit/Parallellisme een SP van 0.3. De Project Manager stelt dat de gemiddelde duurtijd van de

activiteiten 15 dagen telt. Hij denkt dat in een best case 10% gewonnen wordt, maar dat een worst case

kan leiden tot een vertraging van 75% per activiteit. Voor de Critical Chain te beschermen, stelt hij voor

om Feeding Buffers van 40% te nemen.

De Project Buffer Factor is dan:

1. Referentiewaarde

De referentiewaarde is een vast getal gezet op 104.5%

2. Invloed van SP/RC

a. SP = 0.3

b. RC = 3 personen / 15 personen = 0.2

c. Voor de invloed van deze combinatie verwijzen we naar de tabel op pagina 73 die deze

invloed bepaalt. We vinden daar de waarde van 95.4% terug.

3. Invloed van de Feeding Buffergrootte.


64 | P a g i n a

a. FB = 0.4

b. In de bijlage 1.3.1 vinden we hiervoor tabellen terug. We vinden een waarde van 96%

c. De invloed is de inverse van dit getal � 1/0.96 = 1.04%

4. Invloed van de Variantie

Hiervoor vergelijken we de variantie van deze case met de opgestelde variantieniveaus.

Volgens de formule van variantie van de triangulaire verdeling bekomen we dat deze ligt

tussen variantieniveau 5 en 6. Met de tabellen van variantie uit de bijlage 1.3.2 erbij,

interpoleren we 100% en 102% en bekomen we 101.3%.

5. Invloed van Earliness/Lateness

a. Uit de schatting van worst case en best case kan ook een verwachtingswaarde van de

triangulaire verdeling berekend worden.

b. (0.9*15 dagen + 15 dagen + 1.75*15dagen) / 3 = 18.25 dagen

c. 18.25 dagen / 15 dagen = 121,7%

Alles samengenomen komen we tot de volgende Project Buffer Factor. PBF = 104.5% * 95.4% * 104% *

101.3% * 121.7% = 127.8%

Met behulp van commerciële software-tools komt men snel tot de projectduurtijd van de Feeding

Buffered Schedule, namelijk 158 dagen. De Project Buffer bedraagt 27.8% van 158 dagen = 44 dagen.

Dit resulteert dan in een Buffered Schedule van 202 dagen.

De 50%-regel van Goldratt wijst op 0.5 maal de lengte van de Critical Chain. Gegeven, via de software-

tool, dat de Critical Path 147 dagen is, zou de Project Buffer 73.5 dagen zijn in plaats van 44 wat

resulteert in een Buffered Schedule van 220.5.

Ter controle gaan we dit netwerk ook eens simuleren. De simulatie geeft ons een verwachtingswaarde

van 167 dagen en een standaardafwijking van 15. De referentiewaarde is dus: 166 + 1.645*15 = 190.

Besluitend voor dit netwerk kunnen we zeggen dat ons framework in dit voorbeeld een overschatting

heeft gemaakt van 5%. De verklaring van dit gegeven is tweeërlei. Enerzijds is dit slechts één netwerk

van het type netwerk gegeven door de huidige combinatie van SP en RC. Vanzelfsprekend zijn er lichte

varianties binnen het type netwerk. Anderzijds verwijzen we hier terug naar de Whitespaces. Zoals we

zagen kunnen die zorgen voor een te hoog ingeschatte Feeding Buffered Schedule.


65 | P a g i n a

4.4 Controle van de Critical Chain elementen

Wanneer we terugblikken op het gehele concept van CC/BM, is het duidelijk dat de Critical Chain het

centrale en vitale orgaan is. Feeding Buffers zorgen steeds opnieuw dat de elementen van deze Chain

zeker op tijd kunnen beginnen. Op die manier wordt er dus een bescherming geleverd aan de Critical

Chain tegen externe factoren.

Een probleem dat zich natuurlijk kan stellen, is de variantie binnen de Critical Chain. Wanneer de

activiteiten van de CC variëren, is het gehele schedule in gevaar. In onderstaand onderzoek gaan wij dan

ook na wat het effect is van het controleren van de variantie van de Critical Chain-elementen, terwijl de

overige elementen hun eigen variantie blijven behouden. (In een realistische case kan dit gerealiseerd

worden door een Project Manager die een strakker toezicht houdt op de Critical Chain elementen.)

Als startpunt van de analyse nemen we steeds een netwerk waarin zowel de Critical Chain, als de

overige elementen een gelijke standaardafwijking hebben. Vervolgens wordt de variantie van de CC-

elementen onder controle gehouden. De referentie van controle wordt hier gegeven door een

triangulaire verdeling waarbij de duurtijd maximaal 10% kan afwijken in positieve of negatieve zin

(variantieniveau 2).

In onderstaande tabel vind je de resultaten, startend van een netwerk met variantieniveau 9 (tabel 6;

grote variantie). Hieruit blijkt dat bij de Simulated Schedule inclusief 95%-betrouwbaarheidsinterval

bijna 15% (= 1 – 0.859) van de projectduurtijd afgaat door de CC onder controle te houden.

RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 85.9% 85.9% 87.2% 88.2% 88.9% 89.7% 90.4% 90.6% 90.7%

0.2 89.8% 87.3% 88.0% 88.5% 89.4% 90.1% 90.7% 90.9% 90.9%

0.3 88.6% 89.3% 88.8% 89.1% 89.8% 90.3% 90.9% 91.1% 91.2%

0.4 89.2% 89.0% 89.4% 89.6% 90.1% 90.4% 90.5% 91.0% 91.3%

0.5 89.6% 89.7% 89.8% 89.9% 90.5% 90.6% 90.7% 91.1% 90.9%

0.6 90.1% 89.8% 90.1% 90.4% 90.7% 90.8% 91.1% 91.2% 91.0%

0.7 90.1% 90.1% 90.5% 90.5% 90.8% 91.2% 91.2% 91.1% 91.3%

0.8 90.8% 90.6% 90.7% 91.0% 90.9% 91.2% 91.1% 91.3% 91.4%

0.9 91.2% 91.2% 91.0% 91.1% 91.2% 91.3% 91.5% 91.4% 91.5% Tabel 6: Invloed van de controle van de Critical Chain op de projectduurtijd startend van een variantieniveau van 9


66 | P a g i n a

Bij deze cijfers zijn een aantal zaken op te merken:

- Het effect is het sterkst voor netwerken in de linkerbovenhoek van de tabel (kleine RC en kleine

SP). Dit is een logisch gevolg van het feit dat het effect van variantie bij deze netwerken veel

meer uitgesproken is, zoals beschreven in “4.3.4 Invloed van de Variantie van de

activiteitsduurtijden”.

- Deze cijfers dienen met kritische blik bestudeerd te worden. Wanneer we bijvoorbeeld

onderaan rechts in de tabel kijken, vinden we nog steeds een winst van 8.5 procent. Daar staat

echter wel tegenover dat dit netwerk 100% serieel is. Met andere woorden, alle elementen

behoren tot de Critical Chain en dus dienen alle activiteiten kordaat opgevolgd te worden.

Onderstaande tabel (tabel 7), die het gemiddeld aantal Critical Chain-elementen per type

netwerk weergeeft, geeft een juister beeld. De tabel vertelt ons hoeveel van de 30 niet-dummy

activiteiten (elk netwerk in onze database bestaat uit 30 niet-dummy activiteiten) onder

controle moeten worden gehouden om het resultaat in tabel 8 te verkrijgen.

RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 3 7 10 14 18 22 26 29 29

0.2 5 8 11 15 19 23 27 29 29

0.3 8 9 12 16 20 24 27 29 29

0.4 11 12 14 17 21 24 27 29 29

0.5 14 15 16 18 22 25 28 29 29

0.6 17 18 19 20 23 26 28 29 30

0.7 20 21 21 22 25 27 29 29 29

0.8 23 23 24 25 26 27 29 29 29

0.9 26 26 27 27 28 28 29 29 30 Tabel 7: Aantal Critical Chain elementen per type netwerk

Uit de 2 tabellen samen blijkt duidelijk dat de linkerbovenhoek des te interessanter is, aangezien minder

activiteiten onder controle moeten worden gehouden. Uit de 2 vorige tabellen, komen we tot

onderstaande tabel, die de gemiddelde uitgespaarde projectduurtijd weergeeft per CC-activiteit die

onder controle gehouden wordt.


67 | P a g i n a

RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 4.7% 2.0% 1.3% 0.8% 0.6% 0.5% 0.4% 0.3% 0.3%

0.2 2.0% 1.6% 1.1% 0.8% 0.6% 0.4% 0.3% 0.3% 0.3%

0.3 1.4% 1.2% 0.9% 0.7% 0.5% 0.4% 0.3% 0.3% 0.3%

0.4 1.0% 0.9% 0.8% 0.6% 0.5% 0.4% 0.4% 0.3% 0.3%

0.5 0.7% 0.7% 0.6% 0.6% 0.4% 0.4% 0.3% 0.3% 0.3%

0.6 0.6% 0.6% 0.5% 0.5% 0.4% 0.4% 0.3% 0.3% 0.3%

0.7 0.5% 0.5% 0.5% 0.4% 0.4% 0.3% 0.3% 0.3% 0.3%

0.8 0.4% 0.4% 0.4% 0.4% 0.3% 0.3% 0.3% 0.3% 0.3%

0.9 0.3% 0.3% 0.3% 0.3% 0.3% 0.3% 0.3% 0.3% 0.3% Tabel 8: Invloed van controle van de CC op de projectduurtijd ten opzichte van het aantal CC-elementen startend van een

variantieniveau van 9

De bovenstaande cijfers (tabel 8) gelden dus voor een startpunt van variantieniveau 1. Wanneer we

echter reeds starten van bijvoorbeeld variantieniveau 7, zien we in onderstaande tabel (tabel 9), dat

deze cijfers heel laag zijn.

RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 0.8% 0.2% 0.1% 0.1% 0.0% 0.0% 0.0% 0.0% 0.0%

0.2 0.4% 0.2% 0.1% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%

0.3 0.2% 0.1% 0.1% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%

0.4 0.1% 0.1% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%

0.5 0.1% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%

0.6 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%

0.7 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%

0.8 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%

0.9 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% Tabel 9: Invloed van controle van de CC op de projectduurtijd ten opzichte van het aantal CC-elementen startend van een

variantieniveau van 3

Over de lijn van variantieniveaus merken we dat de relatie tussen projectduurtijd en controle van de

Critical Chain-activiteiten ongeveer lineair aflopend is. Anders gezegd, hoe hoger de variantie van het

startnetwerk gemiddeld is, hoe groter de tijdswinst. Voor de concrete cijfers per variantieniveau,

verwijzen we naar de Bijlage 1.4.

Het onder controle houden van de Critical Chain heeft meer effect op de duurtijd van projecten

waarvan de activiteiten sterk parallel kunnen worden gescheduled.


68 | P a g i n a

We merken op dat bij sterk parallelle schedules, de Critical Chain bestaat uit minder activiteiten in

vergelijking met meer seriële schedules. De Critical Chain bij deze eerstgenoemde is bijgevolg ook

gemakkelijker te managen.

Het onder controle houden van de Critical Chain is voordeliger wanneer de Critical Chain bestaat

uit minder activiteiten.


69 | P a g i n a

Hoofdstuk 5: Conclusie

In navolging van de inleiding, blijven we duiden op het belang van menselijke factoren (uitvoerend

personeel, Hoger Management, Project Manager, …) die een cruciale rol spelen bij Project Management.

Critical Chain Buffer Management (CC/BM) dient dan als de betrouwbare partner voor de theoretische

of technische ondersteuning en opvolging. Bijgevolg vindt de methode steeds meer zijn weg tot bij de

Project Manager. Echter, door onvolmaaktheden in de theorie verloopt deze eerste ontmoeting veelal

wat stroef. Er werd reeds veel literatuur geschreven om enkele euvels aan te kaarten. Commentaar

wordt onder andere gegeven op de manier waarop de Project Buffer (PB) bepaald wordt door Goldratt

(= de 50%-regel). Het zal voornamelijk op dit punt zijn dat onze masterproef bijdrage heeft geleverd.

Vanzelfsprekend zijn er al meerdere pogingen ondernomen tot het ontwikkelen van methoden die

leiden tot het correcter bepalen of schatten van deze PB. Een overzicht werd gegeven in Hoofdstuk 2

van deze masterproef. Wij opteerden voor een simulatietechniek die de uitvoering van verschillende

soorten project met verschillende maten van onzekerheid nabootst. Vanuit een statistisch oogpunt is dit

tevens de beste techniek voor het bekomen van betrouwbare resultaten.

Onze methode of redenering omvat het volgende: we starten van de CC/BM-scheduling of dus van de

Buffered Schedule. Dit is een schedule die idealiter een weerspiegeling geeft van de duurtijd van het

project, inclusief een bepaalde veiligheidsmarge. Het is opgebouwd uit de activiteiten, de Feeding

Buffers en de Project Buffer (= Feeding Buffered Schedule en de Project Buffer). Het verloop van de

uitvoer van het project wordt nagebootst door het project te simuleren (= Simulated Schedule inclusief

het 95%-betrouwbaarheidsinterval = SS-95%). Deze laatste wordt gezien als de ideale duurtijd of

referentiewaarde. Verder bouwend op deze redenering, zou de Buffered Schedule even lang moeten

zijn als de SS-95%. Ervan uitgaande dat de Feeding Buffergroottes vooraf bepaald worden, berekenen

we de ideale grootte van de Project Buffer door het vergelijken van de Feeding Buffered Schedule met

de SS-95%. Zo komen we tot de definitie van de Project Buffer Factor:

“De Project Buffer Factor is de factor waarmee we de Feeding Buffered Schedule vermenigvuldigen om

het project in 95% van de gevallen tot een tijdig einde te brengen, gegeven:

1. de gemiddelde variantie van de activiteitsduurtijden,

2. de graad van Serialiteit/Parallellisme van het netwerk (uitgedrukt als SP),

3. de Resource Constrainedness van het netwerk (uitgedrukt als RC),

4. de Feeding Buffergrootte,

5. en de graad van Earliness of Lateness.”


70 | P a g i n a

Zoals werd verwacht, is de factor zeker niet terug te brengen tot één bepaalde X%-regel, maar hangt

deze veeleer af van bovenstaande 5 factoren. Met ons onderzoek gaan we de factoren opsplitsen om de

verschillende invloeden te analyseren en bespreken.

Met de bekomen resultaten willen wij de Project Manager een eenduidig framework aanbieden tot het

correcter bepalen van de Project Buffer. De zaken die vooraf moeten bepaald worden zijn:

- De mate van parallellisme en het gemiddelde resource gebruik: deze invloeden kunnen

opgemeten worden door gebruik te maken van de eenvoudig te berekenen parameters SP

(Serialiteit/Parallellisme), respectievelijk RC (Resource Constrainedness).

- Variantie van de activiteitsduurtijden: Omdat de Project Manager doorgaans een afkeer heeft

van varianties en standaardafwijkingen (= een weinig tastbaar gegeven), kiezen we resoluut

voor de triangulaire verdelingen. Terwijl de triangulaire verdeling van activiteiten op

projectniveau een goede benadering vormt van de normale verdeling (via de centrale

limietstelling), blijft het op activiteitsniveau veel makkelijker te bepalen. De Project Manager

kan zich beperken tot het schatten van een verwachtingswaarde, een best case en een worst

case scenario voor elke activiteit. Uit deze schattingen volgt ook meteen een mate van Earliness

of Lateness, tevens één van de 5 invloeden.

- Feeding Buffergrootte: De Project Manager bepaalt naar eigen aanvoelen de lengte van de

Feeding Buffers. Onze schatting van de Project Buffer houdt namelijk rekening met deze vorm

van reeds ingebouwde zekerheid.

Met deze gegevens in de hand, lezen we de invloeden van de verschillende parameters af uit de

opgestelde tabellen en komen zo tot de geschikte Project Buffer. Deze wordt dan, zoals vermeld,

toegevoegd aan de Feeding Buffered Schedule. Zo bepalen we een totale projectduurtijd die bij de

uitvoering in 95% van de gevallen niet overschreden wordt. De exacte becijfering van de PBF wordt als

volgt weergegeven:

NOPQRSTUVWWROXYSTPO

= Z[RWROR\T]RWYSTPO^ ∗ Z_\`aPRb`Y\bRSPcd]\YT]ReNR\[f^∗ g hXYSTPO`Y\bRXRRb]\iUVWWROjOPPTTRk∗ ZXYSTPO`Y\bRlYO]Y\T]R^ ∗ ZXYSTPO`Y\bRmYOa]\RnnPWoYTR\Rnn^ Een rekenvoorbeeld om dit geheel nog tastbaarder te maken werd gegeven op pagina 77.


71 | P a g i n a

Eerst en vooral is het belangrijk om te zeggen dat er substantiële afwijkingen zijn met de 50%-regel van

Goldratt. Terwijl Goldratt één algemene factor geeft, voorzien wij een gedifferentieerde factor per type

netwerk. Alhoewel er bij onze methode iets meer rekenwerk bij te pas komt, blijft de logica duidelijk in

beeld. Dit resulteert in een niet-complexe, maar toch veel effectievere methodiek.

De Feeding Buffered Schedule werd opgesteld met standaard buffers. Een opmerkelijk gegeven is dat

deze schedule de netwerken met kleine SP/RC sterker beschermt dan de overige netwerken. Dit is een

eerste zeer duidelijk voorbeeld van de effectiviteit van onze methodiek. Hieronder plaatsen we

nogmaals de “invloed van de combinatie van SP en RC” in tabelvorm. Zoals men kan aflezen, reageren

we op voorgaand feit door de factor voor deze netwerken kleiner te maken.

RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 87.4% 87.6% 92.7% 97.4% 100.3% 101.4% 101.7% 102.0% 102.0%

0.2 92.9% 92.3% 94.8% 98.1% 100.5% 101.4% 101.7% 102.0% 102.0%

0.3 95.9% 95.4% 96.4% 98.6% 100.7% 101.5% 101.7% 102.0% 102.0%

0.4 97.6% 97.4% 97.6% 99.1% 100.8% 101.5% 101.7% 101.9% 102.0%

0.5 98.8% 99.0% 98.6% 99.5% 101.0% 101.5% 101.7% 101.9% 102.0%

0.6 99.7% 100.1% 99.4% 99.8% 101.1% 101.5% 101.7% 101.9% 102.0%

0.7 100.4% 101.0% 100.1% 100.2% 101.2% 101.5% 101.7% 101.9% 102.0%

0.8 100.9% 101.8% 100.7% 100.4% 101.3% 101.5% 101.8% 101.9% 102.0%

0.9 101.3% 102.4% 101.2% 100.7% 101.4% 101.5% 101.8% 101.9% 102.0% Tabel 10: Invloed van het type netwerk op de PBF

Daarnaast is het volgens ons een vanzelfsprekendheid om de variantie te betrekken in de rekenwijze.

Grotere variantie gaat per definitie gepaard met grotere onzekerheid. Bijgevolg is het niet meer dan

logisch hier ook in te voorzien.

Als laatste willen we ook nogmaals vermelden dat onze factor voorziet in flexibiliteit van readiness.

Terwijl Goldratt per definitie uitgaat van een bepaalde vorm van Lateness, zien wij dit als een van belang

zijnde inputvariabele.

Een nevenonderzoek dat we voerden was de effectiviteit van het onder controle houden van de Critical

Chain. Uit deze analyse bleek dat de CC-controle tot 15% van de projectduurtijd kan besparen. Hierbij is

het effect van Lateness onder controle houden nog buiten beschouwing gelaten. Wel was er de

belangrijke opmerking dat de cijfers kritisch moeten bekeken worden. De Critical Chain onder controle

houden is voor de Project Manager telkens een trade-off tussen extra kosten (controle) en tijdswinst.


72 | P a g i n a

Voorts beschreven we het fenomeen van Whitespaces. Dit zijn plaatsen in de Feeding Buffered Schedule

waar er gedurende een bepaald aantal tijdseenheden geen enkel resource gebruik is. Deze netwerken

worden gekenmerkt door een langere Feeding Buffered Schedule in vergelijking met gelijkaardige

netwerken zonder Whitespaces. Toch is er in de uitvoering van beide gevallen, geen significant verschil

te merken. Omwille van het eerder beperkte voorkomen en invloed, hebben we in de bespreking van

onze resultaten deze Whitespaces genegeerd door middel van trendlijnanalyse. Desalniettemin zou een

verdere uitwerking tot een aanvulling kunnen leiden van onze huidige methodiek. Wij ondersteunen

bijgevolg verder onderzoek naar het voorkomen van Whitespaces en hun invloed op de projectduurtijd.


73 | P a g i n a

Hoofdstuk 6: Bibliografie

Badiru, A. , 1991, Project Management Tools for Engineering and Management Professionals. Norcross:

Industrial Engineering and Management Press.

Brucker P., Drexl A., Möhring R., Neumann K. & Pesch E. , 1999, Resource-constrained project

scheduling: notation, classification, models and methods. European Journal of Operational Research

volume 112, 3-41.

Caron F. & Mancini M. , 2006a, Project Buffer Sizing throuh Bayesian Approach. Milan, Italy: Politecnico

di Milano, Department of Management Economics and Industrial Engineering.

Caron F. & Mancini M. , 2006b, Project buffer sizing through historical errors. Proceedings of 1st ICEC en

IPMA Global Congress on Project Management, Slovenia: Global Congress on Project Management.

Davis A., & Patterson J. , 1975, A comparison of heuristic and optimum solutions in resource-

constrained prject scheduling, Management Science volume 21 no.8, April 1975 , 944-955.

Demeulemeester E. L., & Herroelen W. S. , 2002, Project Scheduling, A Research Handbook, Kluwen

Academic Publishers, Dordrecht.

Demeulemeester E. L. & Herroelen W. S. , 1992, A Branch-and-Bound procedure for the multiple

Resource-Constrained Project Scheduling Problem, The Institude of Management Science, USA.

French S. , 1960, Scheduling and Sequencing. An Introduction to the Mathematics of the Job-Shop, Ellis

HorWood, New York.

Goldratt, E. ,1997, Critical Chain, The North River Press , U.S.A, Great Barrington.

Gutierrez G. J. & Kouvelis P. , 1991, Parkingson's law and Its Implimentations for Project Management.:

Management Science, USA, Texas.

Herroelen W. & Leus R. , 2001, On the merits and pitfalls of critical chain scheduling. Journal of

Operations management volume 19 , 559-577.

Herroelen W. & Leus R. , 2004, Robust and reactive project scheduling: a review and and classification of

procedures, International Journal of Production Research 42(8), Taylor & Francis Ltd, 1599-1620 .

Herroelen W., Dereyck B., & Demeulemeester E. , 1998, Resource-constrained scheduling: a survey of

recent developments, Computers and Operations Research , 279-302.


74 | P a g i n a

Hoel K., & Taylor S. G. , 1999, Quantifying buffers for project schedules, Production and Inventory

Management Journal , 43-47.

Hulett D. T. , 1996, Schedule Risk Analysis Simplified. PM network , 23-30.

Inc. P. S. , 1999, ProChain Plus Project Sceduling, URL: <http://www.prochain.com>.(03/03/2011)

Kolisch R. & Hartmann S., 1999, Heuristic algorithms for solving the resouce-constrained project

scheduling problem: classification and computational analysis, in: J. Weglarz, Project scheduling: recent

models, algorithms and applications, Kluwen Academic Publishers, chapter 7

Kolisch R. & Padman R. ,1999, An integrated survey of deterministic project scheduling, Omega.

Kolish R. , 1996, Efficient priority rules for the resource-constrained project scheduling problem. Journal

of Operations Management volume 14, 179-192.

Leach L. P. , 2000, Critical Chain Project Management, Artech House Professional Development Library.

Newbold, R. C. ,1998, Project Management in the Fast Lane - Applying the Theory of Constraints, The St.

Lucie Press, Boca Raton.

Parkinson C. N. ,1957, Parkinson's Law, The Riverside Press, Cambridge.

Patterson J. H. , 1976, Project Scheduling: The effects of problem structure on heuristic scheduling, Naval

Research Logistics Quarterly.

Rizzo T. , 1999, Operational measurements for product development organizations, PM Magazin 13 ,

31-35.

Schuyler J. R. ,2000, Exploiting the best of critical chain and Monte Carlo simulation, PM network. Vol14,

no.1 , 56-60.

Shou Y. & Yeo K. T. , 2000, Estimation of project buffers in critical chain project management.

Proceedings of the International Conference on Management of Innovation and Technology, ICMIT2000,

162-167.

Stork F. , 2000, Branch-and-bound algorithms for stochastic Resource-Constrained Project Scheduling,

Techische Universität Berlin, Germany.

Tavares L. V. , 1999, Advanced Models for Project management, Kluwer Academic Publishers, Dordrecht.


75 | P a g i n a

Van de Volder S., Demeulemeester E., Herroelen W. & Leus R. , 2004, The use of buffers in project

management: The trade-off between stability and makespan, Elsevier , 227-240.

Van de Vonder S., Demeulemeester E., Herroelen W. & Leus R. , 2004, The trade-off between stability

and makespan in resource-constrained project scheduling, Department of Applied Economics, Leuven,

Belgium.

Van den Broeck H. & Debussche F. , 2007, Grootmeester in Teamwerk, Lanno, Tielt.

Vanhoucke M. & Leus R. , 2009, Critical Chain Project Management, in: M. Vanhoucke, Project

Management, Gent: Academia Press, Gent, 349-365.

Vanhoucke M., Coelho J., Debels D., Maenhout B. & Tavares L. V. ,2007, An evaluation of the adequancy

of project network generators with systematically sampled networks, European Journal of Operational

Research , 511-524.


76 | P a g i n a

Bijlage

Bijlage 1.1 De Buffered Schedule

Bijlage 1.1.1 Origineel

RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 92.1 136.3 199.4 257.3 316.7 384.7 437.2 488.2 498.4

0.2 143.6 169.9 223.3 272.1 342.2 406.9 451.4 493.1 487.0

0.3 183.2 206.1 246.8 295.7 354.7 422.7 459.8 476.8 500.8

0.4 231.2 244.9 268.3 311.4 366.9 419.6 463.3 495.8 485.0

0.5 274.1 285.2 297.1 343.0 386.3 430.1 466.1 486.4 485.4

0.6 312.4 317.6 337.6 357.4 397.6 443.7 462.4 494.0 496.0

0.7 360.7 368.3 370.0 384.2 419.1 458.4 485.7 491.0 490.0

0.8 401.7 390.9 410.2 418.7 440.3 464.1 485.7 493.4 502.0

0.9 457.6 449.4 454.8 455.4 469.2 473.9 494.0 494.0 488.0 Tabel 11: Originele projectduurtijden van de Buffered Schedule

Bijlage 1.1.2 Trendlijn correctie

RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 92.8 130.3 185.4 246.9 317.2 392.2 441.9 486.9 493.3

0.2 135.3 168.0 217.1 271.2 334.9 402.6 448.3 487.8 493.3

0.3 177.9 205.6 248.7 295.4 352.6 413.0 454.6 488.6 493.3

0.4 220.4 243.3 280.3 319.7 370.4 423.4 460.9 489.5 493.3

0.5 263.0 280.9 312.0 343.9 388.1 433.8 467.3 490.3 493.3

0.6 305.5 318.6 343.6 368.2 405.9 444.2 473.6 491.2 493.3

0.7 348.0 356.2 375.2 392.4 423.6 454.6 480.0 492.0 493.3

0.8 390.6 393.8 406.8 416.7 441.3 465.0 486.3 492.9 493.3

0.9 433.1 431.5 438.5 440.9 459.1 475.4 492.7 493.7 493.3 Tabel 12: Trendlijn-gecorrigeerde projectduurtijden van de Buffered Schedule


77 | P a g i n a

Bijlage 1.2 Simulated Schedule incl. 95%-betrouwbaarheidsinterval

Bijlage 1.2.1 Origineel

RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 86.4 132.2 187.7 263.1 334.8 408.4 463.2 518.2 522.6

0.2 129.6 163.2 218.3 277.1 357.3 429.6 475.3 522.5 516.5

0.3 174.1 191.0 238.1 298.8 369.2 443.9 485.9 505.2 537.3

0.4 217.4 228.2 263.0 310.7 382.8 439.8 489.5 523.7 519.7

0.5 271.0 284.0 297.4 349.3 403.6 452.7 494.1 515.2 514.9

0.6 320.1 328.2 350.1 369.4 414.1 467.5 489.1 523.6 525.4

0.7 374.4 379.9 385.7 400.3 442.7 484.6 513.4 520.7 519.2

0.8 425.4 412.5 433.6 440.8 464.6 490.4 513.6 522.5 532.0

0.9 483.8 475.9 482.2 481.3 497.0 501.1 522.3 523.4 516.7 Tabel 13: Originele projectduurtijden van de Simulated Schedule inclusief het 95%-betrouwbaarheidsinterval

Bijlage 1.2.2 Trendlijn correctie

RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 84.3 118.6 178.6 249.9 330.7 413.4 467.0 516.0 522.9

0.2 130.7 161.2 213.9 276.3 349.9 424.5 473.7 516.9 522.9

0.3 177.2 203.8 249.2 302.8 369.0 435.5 480.5 517.8 522.9

0.4 223.7 246.4 284.5 329.2 388.2 446.5 487.3 518.6 522.9

0.5 270.1 288.9 319.8 355.6 407.3 457.6 494.0 519.5 522.9

0.6 316.6 331.5 355.1 382.1 426.5 468.6 500.8 520.3 522.9

0.7 363.1 374.1 390.4 408.5 445.6 479.6 507.6 521.2 522.9

0.8 409.5 416.7 425.7 434.9 464.8 490.7 514.4 522.1 522.9

0.9 456.0 459.2 461.0 461.3 483.9 501.7 521.1 522.9 522.9 Tabel 14: Trendlijn-gecorrigeerde projectduurtijden van de Simulated Schedule inclusief het 95%-betrouwbaarheidsinterval


78 | P a g i n a

Bijlage 1.3 De Project Buffer Factor

Bijlage 1.3.1 Invloed van de Feeding Buffergrootte

FB: 0.9 RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 118% 107% 105% 102% 102% 101% 100% 100% 100%

0.2 121% 115% 112% 106% 103% 101% 101% 100% 100%

0.3 116% 117% 113% 107% 103% 101% 100% 100% 100%

0.4 116% 116% 110% 108% 102% 102% 101% 100% 100%

0.5 111% 110% 109% 106% 103% 101% 100% 100% 100%

0.6 106% 105% 104% 104% 102% 101% 101% 100% 100%

0.7 104% 105% 103% 103% 101% 100% 100% 100% 100%

0.8 101% 101% 101% 101% 101% 101% 100% 100% 100%

0.9 101% 100% 100% 101% 100% 100% 100% 100% 100%

FB: 0.8 RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 113% 106% 104% 101% 101% 101% 100% 100% 100%

0.2 116% 110% 108% 104% 102% 101% 101% 100% 100%

0.3 111% 112% 109% 105% 102% 101% 100% 100% 100%

0.4 112% 112% 107% 106% 102% 101% 100% 100% 100%

0.5 108% 107% 106% 105% 102% 101% 100% 100% 100%

0.6 104% 103% 103% 103% 102% 101% 100% 100% 100%

0.7 103% 103% 102% 102% 100% 100% 100% 100% 100%

0.8 101% 101% 101% 101% 101% 100% 100% 100% 100%

0.9 100% 100% 100% 100% 100% 100% 100% 100% 100%

FB: 0.7 RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 109% 104% 102% 101% 101% 100% 100% 100% 100%

0.2 110% 107% 105% 103% 101% 101% 100% 100% 100%

0.3 107% 108% 105% 103% 101% 101% 100% 100% 100%

0.4 107% 107% 105% 104% 102% 100% 100% 100% 100%

0.5 104% 104% 104% 103% 101% 101% 100% 100% 100%

0.6 102% 102% 102% 102% 101% 100% 100% 100% 100%

0.7 101% 102% 101% 101% 100% 100% 100% 100% 100%

0.8 100% 101% 100% 101% 100% 100% 100% 100% 100%

0.9 100% 100% 100% 100% 100% 100% 100% 100% 100%


79 | P a g i n a

FB: 0.6 RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 103% 102% 101% 101% 100% 100% 100% 100% 100%

0.2 104% 103% 102% 101% 100% 101% 100% 100% 100%

0.3 103% 103% 102% 101% 101% 100% 100% 100% 100%

0.4 103% 103% 102% 102% 101% 100% 100% 100% 100%

0.5 102% 102% 101% 101% 100% 100% 100% 100% 100%

0.6 101% 101% 101% 101% 101% 100% 100% 100% 100%

0.7 101% 101% 101% 100% 100% 100% 100% 100% 100%

0.8 100% 100% 100% 100% 100% 100% 100% 100% 100%

0.9 100% 100% 100% 100% 100% 100% 100% 100% 100%

FB: 0.5 RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 99% 99% 99% 100% 100% 100% 100% 100% 100%

0.2 99% 99% 99% 100% 100% 100% 100% 100% 100%

0.3 99% 99% 99% 99% 100% 100% 100% 100% 100%

0.4 99% 99% 100% 100% 100% 100% 100% 100% 100%

0.5 99% 100% 100% 100% 100% 100% 100% 100% 100%

0.6 100% 100% 100% 100% 100% 100% 100% 100% 100%

0.7 100% 99% 100% 100% 100% 100% 100% 100% 100%

0.8 100% 100% 100% 100% 100% 100% 100% 100% 100%

0.9 100% 100% 100% 100% 100% 100% 100% 100% 100%

FB: 0.4 RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 94% 98% 98% 100% 99% 100% 100% 100% 100%

0.2 94% 96% 97% 98% 99% 100% 100% 100% 100%

0.3 96% 96% 96% 98% 99% 100% 100% 100% 100%

0.4 95% 95% 97% 98% 99% 100% 100% 100% 100%

0.5 97% 97% 97% 98% 99% 100% 100% 100% 100%

0.6 98% 99% 99% 99% 99% 100% 100% 100% 100%

0.7 99% 99% 99% 99% 100% 100% 100% 100% 100%

0.8 100% 100% 100% 100% 100% 100% 100% 100% 100%

0.9 100% 100% 100% 100% 100% 100% 100% 100% 100%


80 | P a g i n a

FB: 0.3 RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 90% 96% 97% 99% 99% 100% 100% 100% 100%

0.2 89% 92% 94% 97% 99% 100% 100% 100% 100%

0.3 92% 92% 94% 97% 99% 100% 100% 100% 100%

0.4 92% 92% 95% 96% 98% 99% 100% 100% 100%

0.5 95% 95% 95% 97% 99% 100% 100% 100% 100%

0.6 97% 98% 98% 98% 99% 100% 100% 100% 100%

0.7 98% 98% 98% 99% 99% 100% 100% 100% 100%

0.8 100% 99% 99% 99% 100% 100% 100% 100% 100%

0.9 100% 100% 100% 100% 100% 100% 100% 100% 100%

FB: 0.2 RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 88% 95% 97% 98% 99% 99% 100% 100% 100%

0.2 85% 90% 92% 96% 98% 100% 99% 100% 100%

0.3 90% 88% 91% 96% 98% 99% 100% 100% 100%

0.4 89% 89% 93% 94% 98% 99% 99% 100% 100%

0.5 93% 93% 94% 96% 98% 99% 100% 100% 100%

0.6 96% 97% 97% 98% 98% 99% 100% 100% 100%

0.7 98% 97% 98% 98% 99% 100% 100% 100% 100%

0.8 100% 99% 99% 99% 99% 100% 100% 100% 100%

0.9 100% 100% 100% 100% 100% 100% 100% 100% 100%

FB: 0.1 RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 86% 94% 96% 98% 99% 99% 100% 100% 100%

0.2 82% 88% 90% 95% 98% 99% 99% 100% 100%

0.3 87% 85% 90% 94% 98% 99% 99% 100% 100%

0.4 87% 87% 91% 93% 98% 99% 99% 100% 100%

0.5 92% 92% 93% 95% 98% 99% 100% 100% 100%

0.6 96% 96% 97% 97% 98% 99% 100% 100% 100%

0.7 97% 97% 98% 98% 99% 100% 100% 100% 100%

0.8 100% 99% 99% 99% 99% 100% 100% 100% 100%

0.9 100% 100% 100% 100% 100% 100% 100% 100% 100% Tabel 15: Invloed van de Feeding Buffergrootte op de PBF


81 | P a g i n a

Bijlage 1.3.2 Invloed van de variantie van de activiteitsduurtijden

Variantieniveau 1

RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 87% 90% 92% 93% 93% 94% 94% 94% 94%

0.2 89% 91% 92% 93% 93% 94% 94% 94% 94%

0.3 91% 91% 92% 93% 93% 94% 94% 94% 94%

0.4 92% 92% 93% 93% 94% 94% 94% 94% 94%

0.5 93% 93% 93% 93% 94% 94% 94% 94% 94%

0.6 93% 93% 93% 94% 94% 94% 94% 94% 94%

0.7 94% 94% 94% 94% 94% 94% 94% 94% 94%

0.8 94% 94% 94% 94% 94% 94% 94% 94% 94%

0.9 94% 94% 94% 94% 94% 94% 95% 94% 95%

Variantieniveau 2

RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 90% 92% 94% 94% 95% 95% 95% 95% 95%

0.2 91% 93% 94% 94% 95% 95% 95% 95% 96%

0.3 93% 93% 94% 94% 95% 95% 95% 96% 96%

0.4 94% 94% 94% 95% 95% 95% 95% 96% 96%

0.5 94% 94% 95% 95% 95% 95% 95% 96% 96%

0.6 95% 95% 95% 95% 95% 95% 96% 96% 96%

0.7 95% 95% 95% 95% 95% 96% 96% 96% 96%

0.8 95% 95% 95% 95% 95% 96% 96% 96% 96%

0.9 96% 95% 96% 96% 96% 96% 96% 96% 96%

Variantieniveau 3

RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 94% 95% 96% 96% 96% 96% 97% 97% 97%

0.2 94% 95% 96% 96% 97% 97% 97% 97% 97%

0.3 95% 95% 96% 96% 97% 97% 97% 97% 97%

0.4 96% 96% 96% 96% 97% 97% 97% 97% 97%

0.5 96% 96% 96% 96% 97% 97% 97% 97% 97%

0.6 96% 96% 96% 97% 97% 97% 97% 97% 97%

0.7 97% 96% 97% 97% 97% 97% 97% 97% 97%

0.8 97% 97% 97% 97% 97% 97% 97% 97% 97%

0.9 97% 97% 97% 97% 97% 97% 97% 97% 97%


82 | P a g i n a

Variantieniveau 4

RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 97% 97% 98% 98% 98% 98% 98% 98% 98%

0.2 97% 97% 98% 98% 98% 98% 98% 98% 98%

0.3 97% 97% 98% 98% 98% 98% 98% 98% 98%

0.4 98% 98% 98% 98% 98% 98% 98% 98% 98%

0.5 98% 98% 98% 98% 98% 98% 98% 98% 98%

0.6 98% 98% 98% 98% 98% 98% 98% 98% 98%

0.7 98% 98% 98% 98% 98% 98% 98% 98% 98%

0.8 98% 98% 98% 98% 98% 98% 98% 98% 98%

0.9 98% 98% 98% 98% 98% 98% 98% 98% 98%

Variantieniveau 5

RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 100% 100% 100% 100% 100% 100% 100% 100% 100%

0.2 100% 100% 100% 100% 100% 100% 100% 100% 100%

0.3 100% 100% 100% 100% 100% 100% 100% 100% 100%

0.4 100% 100% 100% 100% 100% 100% 100% 100% 100%

0.5 100% 100% 100% 100% 100% 100% 100% 100% 100%

0.6 100% 100% 100% 100% 100% 100% 100% 100% 100%

0.7 100% 100% 100% 100% 100% 100% 100% 100% 100%

0.8 100% 100% 100% 100% 100% 100% 100% 100% 100%

0.9 100% 100% 100% 100% 100% 100% 100% 100% 100%

Variantieniveau 6

RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 103% 102% 102% 102% 102% 101% 101% 102% 101%

0.2 103% 102% 102% 102% 102% 102% 101% 102% 101%

0.3 102% 102% 102% 102% 102% 101% 101% 101% 101%

0.4 102% 102% 102% 102% 101% 101% 101% 101% 101%

0.5 102% 102% 102% 102% 101% 101% 101% 101% 101%

0.6 102% 102% 102% 102% 102% 101% 101% 101% 101%

0.7 101% 101% 102% 101% 101% 101% 101% 101% 101%

0.8 102% 101% 101% 101% 101% 101% 101% 101% 101%

0.9 101% 101% 102% 101% 101% 101% 101% 101% 102%


83 | P a g i n a

Variantieniveau 7

RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 106% 105% 104% 104% 104% 103% 103% 103% 103%

0.2 106% 105% 104% 104% 104% 103% 103% 103% 103%

0.3 105% 105% 104% 104% 103% 103% 103% 103% 103%

0.4 104% 104% 104% 103% 103% 103% 103% 103% 103%

0.5 104% 104% 104% 103% 104% 103% 103% 103% 103%

0.6 103% 104% 103% 103% 103% 103% 103% 103% 103%

0.7 103% 103% 103% 103% 103% 103% 103% 103% 103%

0.8 103% 103% 103% 103% 103% 103% 103% 103% 103%

0.9 103% 103% 103% 103% 103% 103% 103% 103% 103%

Variantieniveau 8

RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 110% 108% 107% 106% 106% 105% 105% 105% 105%

0.2 109% 107% 107% 106% 105% 105% 105% 105% 105%

0.3 107% 107% 106% 106% 105% 105% 105% 105% 105%

0.4 107% 107% 106% 106% 105% 105% 105% 105% 105%

0.5 106% 106% 106% 105% 105% 105% 105% 105% 104%

0.6 105% 105% 106% 105% 105% 105% 105% 105% 105%

0.7 105% 105% 105% 105% 105% 105% 104% 104% 105%

0.8 105% 105% 105% 105% 105% 105% 104% 105% 105%

0.9 105% 105% 105% 104% 105% 105% 104% 104% 104%

Variantieniveau 9

RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 113% 110% 109% 108% 108% 107% 107% 107% 106%

0.2 112% 110% 109% 108% 107% 107% 107% 106% 106%

0.3 109% 110% 109% 108% 107% 107% 106% 106% 106%

0.4 109% 109% 108% 108% 107% 107% 107% 106% 106%

0.5 108% 108% 108% 108% 107% 107% 107% 106% 106%

0.6 108% 108% 108% 107% 107% 107% 106% 106% 106%

0.7 107% 107% 107% 107% 107% 106% 106% 106% 106%

0.8 107% 107% 107% 106% 107% 106% 106% 106% 106%

0.9 106% 106% 106% 106% 106% 106% 106% 106% 106%

Tabel 16: Invloed van de Variantie van de activiteitsduurtijden op de PBF


84 | P a g i n a

Bijlage 1.4 Controle van de Critical Chain

Variantieniveau 9

RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 85.9% 85.9% 87.2% 88.2% 88.9% 89.7% 90.4% 90.6% 90.7%

0.2 89.8% 87.3% 88.0% 88.5% 89.4% 90.1% 90.7% 90.9% 90.9%

0.3 88.6% 89.3% 88.8% 89.1% 89.8% 90.3% 90.9% 91.1% 91.2%

0.4 89.2% 89.0% 89.4% 89.6% 90.1% 90.4% 90.5% 91.0% 91.3%

0.5 89.6% 89.7% 89.8% 89.9% 90.5% 90.6% 90.7% 91.1% 90.9%

0.6 90.1% 89.8% 90.1% 90.4% 90.7% 90.8% 91.1% 91.2% 91.0%

0.7 90.1% 90.1% 90.5% 90.5% 90.8% 91.2% 91.2% 91.1% 91.3%

0.8 90.8% 90.6% 90.7% 91.0% 90.9% 91.2% 91.1% 91.3% 91.4%

0.9 91.2% 91.2% 91.0% 91.1% 91.2% 91.3% 91.5% 91.4% 91.5%

Variantieniveau 8

RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 86.6% 87.4% 88.8% 90.0% 90.7% 91.2% 91.6% 92.1% 92.1%

0.2 90.5% 88.8% 89.4% 90.3% 91.2% 91.8% 92.0% 92.3% 92.4%

0.3 89.6% 90.6% 90.3% 91.0% 91.3% 92.0% 92.0% 92.4% 92.6%

0.4 90.2% 90.5% 90.5% 91.1% 91.6% 92.1% 92.3% 92.6% 92.5%

0.5 90.9% 91.3% 91.2% 91.8% 92.1% 92.2% 92.2% 92.4% 92.7%

0.6 91.8% 91.7% 91.7% 91.9% 92.1% 92.3% 92.5% 92.6% 92.7%

0.7 91.8% 91.9% 91.8% 91.8% 92.3% 92.5% 92.9% 92.7% 92.7%

0.8 92.2% 92.1% 92.3% 92.4% 92.5% 92.5% 92.8% 92.6% 92.5%

0.9 92.6% 92.4% 92.6% 92.7% 92.6% 92.7% 92.8% 92.8% 92.9%

Variantieniveau 7

RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 88.5% 89.0% 91.0% 91.6% 92.4% 93.1% 93.4% 93.9% 93.6%

0.2 91.9% 90.4% 91.4% 92.0% 92.7% 93.4% 93.6% 94.0% 93.9%

0.3 91.3% 91.9% 92.2% 92.5% 93.0% 93.5% 93.8% 93.8% 94.2%

0.4 92.0% 91.9% 92.5% 92.8% 93.4% 93.7% 93.6% 94.1% 94.1%

0.5 92.3% 92.8% 92.8% 93.5% 93.2% 93.7% 93.9% 94.0% 94.1%

0.6 93.3% 92.9% 93.4% 93.3% 93.5% 93.9% 93.9% 94.2% 94.2%

0.7 93.2% 93.4% 93.4% 93.5% 93.6% 94.0% 94.2% 94.2% 94.2%

0.8 93.9% 93.8% 93.8% 93.9% 94.0% 93.9% 94.0% 94.2% 94.2%

0.9 94.2% 93.9% 93.9% 94.0% 94.2% 94.4% 94.2% 94.2% 94.2%


85 | P a g i n a

Variantieniveau 6

RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 90.3% 91.5% 92.8% 93.8% 94.3% 94.7% 95.2% 95.1% 95.2%

0.2 92.9% 92.5% 93.2% 94.0% 94.5% 94.9% 95.2% 95.3% 95.7%

0.3 93.0% 93.6% 93.8% 94.2% 94.6% 95.1% 95.4% 95.4% 95.5%

0.4 93.6% 93.8% 94.0% 94.5% 94.9% 95.2% 95.3% 95.5% 95.5%

0.5 94.1% 94.3% 94.4% 94.8% 95.1% 95.2% 95.5% 95.4% 95.4%

0.6 94.6% 94.7% 94.8% 94.9% 95.0% 95.4% 95.4% 95.5% 95.6%

0.7 95.0% 94.9% 94.9% 95.1% 95.2% 95.4% 95.7% 95.6% 95.7%

0.8 95.2% 95.2% 95.4% 95.4% 95.5% 95.6% 95.6% 95.6% 95.7%

0.9 95.5% 95.4% 95.3% 95.5% 95.6% 95.6% 95.7% 95.7% 95.5%

Variantieniveau 5

RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 92.4% 93.5% 94.9% 95.7% 96.2% 96.4% 96.6% 96.8% 96.8%

0.2 94.6% 94.4% 95.1% 95.7% 96.2% 96.7% 96.8% 97.0% 97.0%

0.3 94.9% 95.0% 95.6% 95.9% 96.5% 96.8% 97.0% 97.0% 97.1%

0.4 95.4% 95.4% 95.9% 96.1% 96.6% 96.9% 97.0% 97.1% 97.1%

0.5 95.8% 96.1% 96.2% 96.3% 96.6% 96.8% 96.9% 97.1% 97.1%

0.6 96.3% 96.3% 96.6% 96.5% 96.8% 96.8% 96.9% 97.1% 97.2%

0.7 96.3% 96.5% 96.5% 96.6% 96.9% 97.0% 97.2% 97.2% 97.1%

0.8 96.8% 96.8% 96.8% 96.9% 97.0% 96.9% 97.3% 97.2% 97.0%

0.9 96.9% 97.0% 97.0% 97.0% 97.0% 97.3% 97.2% 97.2% 97.1%

Variantieniveau 4

RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 94.9% 95.8% 96.9% 97.5% 97.9% 98.2% 98.4% 98.5% 98.5%

0.2 96.5% 96.4% 97.1% 97.7% 98.1% 98.2% 98.5% 98.5% 98.6%

0.3 96.8% 97.2% 97.3% 97.8% 98.2% 98.3% 98.5% 98.6% 98.6%

0.4 97.3% 97.4% 97.6% 98.0% 98.2% 98.5% 98.6% 98.6% 98.7%

0.5 97.6% 97.8% 97.8% 98.1% 98.4% 98.5% 98.6% 98.5% 98.6%

0.6 98.1% 97.9% 98.1% 98.1% 98.3% 98.5% 98.6% 98.7% 98.6%

0.7 98.1% 98.2% 98.3% 98.4% 98.5% 98.6% 98.6% 98.6% 98.6%

0.8 98.4% 98.3% 98.4% 98.4% 98.6% 98.6% 98.7% 98.8% 98.6%

0.9 98.5% 98.4% 98.6% 98.6% 98.7% 98.6% 98.6% 98.7% 98.6%


86 | P a g i n a

Variantieniveau 3

RC

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

SP

0.1 97.5% 98.4% 98.9% 99.3% 99.4% 99.6% 99.7% 99.8% 99.8%

0.2 98.2% 98.5% 99.0% 99.3% 99.4% 99.7% 99.8% 99.9% 99.9%

0.3 98.7% 98.8% 99.2% 99.4% 99.5% 99.8% 99.9% 99.8% 99.9%

0.4 99.1% 99.1% 99.4% 99.5% 99.7% 99.8% 99.9% 99.9% 99.9%

0.5 99.2% 99.3% 99.4% 99.6% 99.7% 99.8% 99.9% 99.9% 99.8%

0.6 99.4% 99.5% 99.5% 99.6% 99.7% 99.8% 99.8% 99.9% 99.8%

0.7 99.6% 99.7% 99.7% 99.6% 99.8% 99.8% 99.9% 99.8% 99.9%

0.8 99.8% 99.8% 99.6% 99.7% 99.9% 99.9% 99.9% 99.9% 99.9%

0.9 99.8% 99.8% 99.9% 99.8% 99.9% 99.9% 99.9% 99.9% 100.0% Tabel 17: Invloed van de controle van het Variantieniveau van de Critical Chain

Date post:	29-Jun-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

Critical Chain Buffer Management - Ghent University › fulltxt › RUG01 › 001 › 788 › 508...

Documents