Critical Chain Buffer Management

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

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

Permission

Ondergetekenden verklaren dat de inhoud van deze masterproef mag geraadpleegd en/of gereproduceerd worden, mits bronvermelding.

Chistophe Bostyn

Jordy De Loose

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.

I

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 II

2.3.3 2.4

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

Hoofdstuk 3: 3.1

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

Doelstellingen en setup van het model................................................................... 23

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: 4.1

Resultaten van de experimenten............................................................................ 38

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 III

4.2.4 4.3

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

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

IV

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

V

Verklarende woordenlijst Verwijzing Benaming

Uitleg

(p.)

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 Activiteit

3 appartement, evenals heel gedetailleerd, bijvoorbeeld het boren van een gat in de muur, afhankelijk van de interne doelstelling. De Basic Feasible Schedule is een schedule van een bepaald

Basic Feasible Schedule

projectnetwerk dat voldoet aan enerzijds alle

6

volgorderelaties en anderzijds alle Resource Beperkingen. De Buffered Schedule is een ge-reschedulede vorm van de Buffered Schedule

Basic Feasible Schedule, samen met de Feeding Buffers,

29

inclusief de toevoeging van de Project Buffer. Een dummy activiteit is een fictieve activiteit, die een bepaald event vaststelt. In dit werk is er een Start Dummy Dummy activiteit

3 activiteit ( = het netwerk begint) en een Finish Dummy activiteit ( = alle activiteiten zijn gescheduled/uitgevoerd). Een duurtijd wijst op het aantal tijdseenheden, die een

Duurtijd

3 bepaalde activiteit nodig, heeft om uitgevoerd te worden. Feeding Buffers zijn de buffers die de Critical Chain beschermen tegen externe vertragingen. Ze zijn dan ook

Feeding Buffer

18 gepositioneerd waar de Niet-Critical Chain zich invoegt in de Critical Chain. De Feeding Buffered Schedules is een Buffered Schedule

Feeding Buffered Schedule

waarvan de Project Buffer is weggenomen. Deze wordt hier in feite mede gebruikt ter bepaling van de Project Buffer.

VI

29

Een Feeding Chain bestaat uit een chain van transitieve nietFeeding Chain

18 Critical Chain activiteiten. Een mijlpaal verwijst naar het tijdstip waarop de voltooiing

Mijlpaal

3 van een individuele activiteit zou moeten plaatsvinden. De Project Buffer bevindt zich aan het einde van de Buffered

Project Buffer

Schedule. Ze biedt bescherming tegen vertragingen in de

17

Critical Chain. De Projected Schedule wordt gevolgd voor de uitvoering van het project. Ze is gelijk aan de Basic Feasible Schedule Projected Schedule

waarvan de activiteiten As-Soon-As-Possible worden

33

gescheduled. 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 RC of de Resource

bepaalt het percentage dat een activiteit gemiddeld

Constrainedness

gebruikt van dit aantal beschikbare resources. Wanneer dit

27 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. 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 Rescheduling

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

Resource

Resources kunnen verschillende vormen aannemen zoals financiële resources, mankracht, machines, uitrusting, VII

3

materialen, energie, ruimte enz. Dit zijn zaken die een activiteit nodig heeft om te kunnen worden uitgevoerd. De Simulated Schedule is een gesimuleerde vorm van de Simulated Schedule

33 Projected Schedule. Netwerken kunnen in het ene uiterste 100% serieel opgebouwd zijn (de tweede activiteit komt na de eerste enzovoort…), of anderzijds geheel parallel (alle activiteiten

SP of de graad van

kunnen volgens de volgorderelaties van het netwerk

Serialiteit/Parallellisme

gelijktijdig uitgevoerd worden). SP is hier een parameter

26 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). Een netwerk wordt in dit onderzoek steeds gedefinieerd door 2 parameters, namelijk SP (de graad van Serialiteit/Parallellisme) en RC (de graad van Resource Type Netwerk

27 Constrainedness). Een bepaald Type Netwerk is dan een netwerk, gedefinieerd door een bepaalde waarde voor deze 2 parameters. Een volgorderelatie wijst op de relatie tussen 2 opeenvolgende activiteiten. Van deze relatie bestaan verschillende vormen, zoals Start-Start, Start-Finish, … De

Volgorderelatie

3 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). Whitespaces zijn tijdseenheden in de (Feeding) Buffered Schedule waar er geen enkele resource wordt gebruikt. Het

Whitespaces

47 is dus een plaats waar enkel de Feeding Buffer staat gescheduled.

VIII

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 IX

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%betrouwbaarheidsinterval .......................................................................................................................... 56 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

X

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

betrouwbaarheidsinterval .......................................................................................................................... 77 Tabel 14: Trendlijn-gecorrigeerde projectduurtijden van de Simulated Schedule inclusief het 95%betrouwbaarheidsinterval .......................................................................................................................... 77 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

XI


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. 1|Pagina

Critical Chain Buffer Management 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”.

2|Pagina


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

3|Pagina


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.

4|Pagina


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.

5|Pagina


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

6|Pagina

Critical Chain Buffer Management 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.

Figuur 4: Basic Feasible Schedule - ASAP

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

Critical Chain Buffer Management 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.

Figuur 5: Basic Schedule - ALAP

Figuur 6: Basic Feasible Schedule - ALAP

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.

8|Pagina


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

9|Pagina


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.

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

11 | P a g i n a

Critical Chain Buffer Management 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

12 | P a g i n a

Critical Chain Buffer Management 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)

13 | 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 14 | P a g i n a

Critical Chain Buffer Management 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

15 | P a g i n a

Critical Chain Buffer Management 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. 16 | 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 CCactiviteiten 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

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

Figuur 14: Invoegen van de Feeding Chains

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

18 | P a g i n a Figuur 15: Toevoegen van de Feeding Buffer aan de Feeding Chain


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, 19 | P a g i n a

Critical Chain Buffer Management 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 20 | P a g i n a

Critical Chain Buffer Management 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 21 | P a g i n a

Critical Chain Buffer Management 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.

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

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

24 | P a g i n a


3.2 Netwerkgenerator

SP

RC

3.3 Basic Feasible Schedule

3.5.1 Projected Schedule

3.5.2 Variantie en verdeling van Feeding

de activiteitsduurtijden

Buffergrootte 3.5 Simulated Schedule

3.5.3 Variantie van de projectduurtijd

3.5.2 Simulated Schedule 3.4.2 Feeding Buffered

inclusief het 95%-

Schedule

betrouwbaarheidsinterval

4.3 De Project Buffer Factor Figuur 17: Overzicht van de doelstelling

25 | 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). 26 | P a g i n a

Critical Chain Buffer Management •

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 +4 5; 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 dummyactiviteiten) 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.

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

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

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

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

32 | 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 semiactive 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 33 | P a g i n a

Critical Chain Buffer Management 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

34 | P a g i n a

Critical Chain Buffer Management Deze functie wordt gekenmerkt door 3 parameter a ≤ c ≤ b en heeft als voorschrift: D 2>? − F@ , B>G − F@>G − H@ >?@ = C 2>G − ?@ , B>G − F@>G − H@ A

F≤?≤H H≤?≤G

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

² =

F+G+H 3

F² + G² + H² − FG − FH − GH 18

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 35 | P a g i n a

Critical Chain Buffer Management 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 KolgomorovSmirnov 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).

36 | 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%.

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

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

Invloed van SP op de duurtijd van de Buffered Schedule 480 y = 19.326x + 290.82 R² = 0.9958

460 D u u r t i j d

440 420 400 380 360 340 320 300 0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

SP

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.

De duurtijd van de Feeding Buffered Schedule stijgt lineair met de serialiteit van het activiteitennetwerk. 39 | 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.

Invloed van RC op de duurtijd van de Buffered Schedule 500 D u u r t i j d

450 400 350 300 250 0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

RC

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. 40 | P a g i n a

Critical Chain Buffer Management 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.

De duurtijd van de Feeding Buffered Schedule stijgt eerst progressief en daarna degressief naarmate het gemiddelde resourcegebruik van de activiteiten stijgt.

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.

41 | P a g i n a


Invloed van SP op de duurtijd van de Buffered Schedule, gegeven een bepaalde waarde van RC 550 500

RC = 0.9

450

RC = 0.8

400 350

RC = 0.7

300

RC = 0.6

250

RC = 0.5

200

RC = 0.4

150

RC = 0.3

100

RC = 0.2

50 0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

RC = 0.1

SP

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

Procentuele verlenging van de duurtijd van de Buffered Schedule, gegeven een bepaalde verhouding van RC (RC=0.X/RC=0.1) P r o c e n t u e l e

v e r l e n g i n g

450% 400% 350% 300% 250% 200% 150% 100% 50% 0%

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 0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

RC=0.2 / RC=0.1

SP

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 42 | P a g i n a

Critical Chain Buffer Management 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.

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.

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.

43 | P a g i n a


Invloed van RC op de duurtijd van de Buffered Schedule, gegeven een bepaalde waarde van SP 600 D u u r t i j d

I2 = 0.9

500

I2 = 0.8 400

I2 = 0.7 I2 = 0.6

300

I2 = 0.5

200

I2 = 0.4 100

I2 = 0.3

0

I2 = 0.2 0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

I2 = 0.1

RC

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

Procentuele verlenging van de duurtijd van de Buffered Schedule, gegeven een bepaalde verhouding van SP (SP=0.X/SP=0.1) P r o c e n t u e l e

v e r l e n g i n g

450% 400% 350% 300% 250% 200% 150% 100% 50% 0%

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 0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

I2=0.2 / I2=0.1

RC

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

44 | P a g i n a

Critical Chain Buffer Management 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.

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.

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

Projectduurtijd van de Buffered Schedule

600 D 500 u u 400 r 300 t i 200 j d 100

0.9 0.7 0.5

0 0.1

0.2

SP

0.3 0.3

0.4

0.5

0.6

0.7

0.8

0.1 0.9

RC

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 45 | P a g i n a

Critical Chain Buffer Management 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).

Projectduurtijd van de Buffered Schedule - trendlijn correctie 600 D u 500 u 400 r 300 t i 200 j 100 d 0

0.9 0.7 0.5 0.1

0.2

SP

0.3 0.3

0.4

0.5

0.6

0.7

0.1 0.8

0.9

RC

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.

46 | P a g i n a


Invloed van de Feeding Buffergrootte op de duurtijd van de Buffered Schedule 400 D u u r t i j d

395 390 385 380 375 0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

Buffergrootte

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

Bij verhoging van de Feeding Buffergrootte, zal ook de duurtijd van de Feeding Buffered Schedule gemiddeld gezien stijgen.

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

47 | P a g i n a

Critical Chain Buffer Management 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

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

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

Procentueel aantal schedules met Whitespaces

Invloed van SP op het voorkomen van Whitespaces 35% 30% 25% 20% 15% 10% 5% 0% 0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

SP

Figuur 42: Invloed van SP op het voorkomenv an Whitespaces

50 | P a g i n a

Critical Chain Buffer Management 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 CCactiviteit. 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.

51 | P a g i n a

Critical Chain Buffer Management 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 Svormige daling (figuur 43).

Procentueel aantal schedules met Whitespaces

Invloed van RC op het voorkomen van Whitespaces 45% 40% 35% 30% 25% 20% 15% 10% 5% 0% 0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

RC

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.

De kans op het voorkomen van Whitespaces daalt, eerst progressief en daarna degressief, naarmate het gemiddelde resource gebruik van de activiteiten stijgt.

52 | P a g i n a

Critical Chain Buffer Management 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.

Procentueel aantal netwerken met whitespaces

Invloed van FB Grootte op het voorkomen van Whitespaces 20% 18% 16% 14% 12% 10% 8% 6% 4% 2% 0% 0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

Feeding Buffergrootte

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.

De kans op het voorkomen van Whitespaces stijgt naarmate de Feeding Buffers groter worden.

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

53 | P a g i n a


0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

RC

Duurtijden met Whitespaces/duurtijden zonder Whitespaces SP 0.1 0.2 0.3 0.4 0.5 0.6 0.7 109% 150% 127% 160% 141% 122% 116% 104% 130% 127% 138% 116% 114% 112% 103% 121% 120% 130% 119% 122% 111% 101% 114% 121% 122% 124% 101% 107% 96% 111% 101% 108% 101% 113% 103% 116% 103% 91% 103% 93% 106% 115% 99% 100% 103% -

0.8 95% 104% 93% 102% 90% 106% -

0.9 105% 113% 105% -

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.

De projectduurtijd van schedules die Whitespaces bevatten is significant hoger in vergelijking met schedules zonder Whitespaces.

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). 54 | P a g i n a


Invloed van SP op de duurtijd van de Simulated Schedule incl. het 95%-BI 550 500 D u 450 u r 400 t i 350 j d 300

y = 20.92x + 282.89 R² = 0.9957

250 0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

SP

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.

De duurtijd van de Simulated Schedule inclusief het 95%-betrouwbaarheidsinterval stijgt lineair naarmate het activiteitennetwerk meer serieel wordt.

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

Invloed van RC op de duurtijd van de Simulated Schedule incl. het 95%-BI 550 D u u r t i j d

500 450 400 350 300 250 200 0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

RC

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.

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.

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

56 | P a g i n a


Projectduurtijd van de Simulated Schedule 600 D u 500 u 400 r 300 t i 200 j 100 d 0

0.9 0.7 0.5 0.1

0.2

SP

0.3 0.3

0.4

0.5

0.6

0.7

0.1 0.8

0.9

RC

Figuur 47: Projectduur van de Simulated Schedule

Projectduurtijd van de Simulated Schedule trendlijn correctie 600 D u 500 u 400 r 300 t i 200 j 100 d 0

0.9 0.7 0.5 0.1

0.2

SP

0.3 0.3

0.4

0.5

0.6

0.7

0.1 0.8

0.9

RC

Figuur 48: Projectduurtijd van de Simulated Schedule - trendlijn correctie

Opnieuw verwijzen we voor de exacte cijfers naar bijlage 1.2.

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

Invloed van de variantie van de activiteitsduurtijden op de projectduurtijd 440 430 D u u r t i j d

420 410 400 390 380 370 360 350 1

2

3

4

5

6

7

8

9

Variantieniveau

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

Wanneer de variantie van de activiteitsduurtijden vergroot, stijgt gemiddeld gezien ook de duurtijd van de Simulated Schedule inclusief het 95%-betrouwbaarheidsinterval.

58 | 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: NOPQRST UVWWRO XYSTPO

= Z[RWROR\T]RWYSTPO^ ∗ Z_\`aPRb `Y\ bR SPcd]\YT]R eN R\ [f^ ∗g

h k XYSTPO `Y\ bR XRRb]\i UVWWRO jOPPTTR

∗ ZXYSTPO `Y\ bR lYO]Y\T]R^ ∗ ZXYSTPO `Y\ bR mYOa]\Rnn PW oYTR\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: gemiddelde duurtijd van het Simulated Schedule incl. 95% − betrouwbaarheidsinterval van alle netwerken van alle types met alle vormen van activiteitsvarianties en Buffergroottes * !p FHpq* = gemiddelde Feeding Buffered Netwerkduurtijd van alle netwerken van alle types met alle vormen van activiteitsvarianties en Buffergroottes

59 | P a g i n a

Critical Chain Buffer Management 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: FF* F! FHpq* G FF qq* HqG!Fp F! ! & FHpq* & & = FHpq* q * F HqG!Fp F! ! & Hieronder de bijhorende cijfergegevens:

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 87.4% 92.9% 95.9% 97.6% 98.8% 99.7% 100.4% 100.9% 101.3%

0.2 0.3 0.4 87.6% 92.7% 97.4% 92.3% 94.8% 98.1% 95.4% 96.4% 98.6% 97.4% 97.6% 99.1% 99.0% 98.6% 99.5% 100.1% 99.4% 99.8% 101.0% 100.1% 100.2% 101.8% 100.7% 100.4% 102.4% 101.2% 100.7%

RC 0.5 100.3% 100.5% 100.7% 100.8% 101.0% 101.1% 101.2% 101.3% 101.4%

0.6 101.4% 101.4% 101.5% 101.5% 101.5% 101.5% 101.5% 101.5% 101.5%

0.7 101.7% 101.7% 101.7% 101.7% 101.7% 101.7% 101.7% 101.8% 101.8%

0.8 102.0% 102.0% 102.0% 101.9% 101.9% 101.9% 101.9% 101.9% 101.9%

0.9 102.0% 102.0% 102.0% 102.0% 102.0% 102.0% 102.0% 102.0% 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. 60 | P a g i n a

Critical Chain Buffer Management FF* F! *q Hp*p, F ℎF! F! ! &, ! ! G FF * *qqpp FHpq* FHpq* F! *qqpp = *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

SP

0.1 0.2 0.3 0.4 0.1 88% 95% 97% 98% 0.2 85% 90% 92% 96% 0.3 90% 88% 91% 96% 0.4 89% 89% 93% 94% 0.5 93% 93% 94% 96% 0.6 96% 97% 97% 98% 0.7 98% 97% 98% 98% 0.8 100% 99% 99% 99% 0.9 100% 100% 100% 100%

RC 0.5 99% 98% 98% 98% 98% 98% 99% 99% 100%

0.6 99% 100% 99% 99% 99% 99% 100% 100% 100%

0.7 100% 99% 100% 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%

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.

61 | P a g i n a

Critical Chain Buffer Management FB: 0.8

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 113% 116% 111% 112% 108% 104% 103% 101% 100%

0.2 106% 110% 112% 112% 107% 103% 103% 101% 100%

0.3 104% 108% 109% 107% 106% 103% 102% 101% 100%

0.4 101% 104% 105% 106% 105% 103% 102% 101% 100%

RC 0.5 101% 102% 102% 102% 102% 102% 100% 101% 100%

0.6 101% 101% 101% 101% 101% 101% 100% 100% 100%

0.7 100% 101% 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%

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: FF* F! *q Hp*p F! Fp Hℎ , F ℎF! F! ! &, ! ! G FF *FF F! F*F!p F! FHpp p*p ! FHpq* F! F*F!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).

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 110% 109% 107% 107% 106% 105% 105% 105% 105%

0.2 108% 107% 107% 107% 106% 105% 105% 105% 105%

0.3 107% 107% 106% 106% 106% 106% 105% 105% 105%

0.4 106% 106% 106% 106% 105% 105% 105% 105% 104%

RC 0.5 106% 105% 105% 105% 105% 105% 105% 105% 105%

0.6 105% 105% 105% 105% 105% 105% 105% 105% 105%

0.7 105% 105% 105% 105% 105% 105% 104% 104% 104%

0.8 105% 105% 105% 105% 105% 105% 104% 105% 104%

0.9 105% 105% 105% 105% 104% 105% 105% 105% 104%

Tabel 5: Invloed van de Variantie van de activiteitsduurtijden

62 | P a g i n a

Critical Chain Buffer Management 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. 63 | P a g i n a

Critical Chain Buffer Management 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 softwaretool, 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.

64 | 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 CCelementen 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.

0.1 0.2 0.3 0.4 SP 0.5 0.6 0.7 0.8 0.9

0.1 85.9% 89.8% 88.6% 89.2% 89.6% 90.1% 90.1% 90.8% 91.2%

0.2 85.9% 87.3% 89.3% 89.0% 89.7% 89.8% 90.1% 90.6% 91.2%

0.3 87.2% 88.0% 88.8% 89.4% 89.8% 90.1% 90.5% 90.7% 91.0%

0.4 88.2% 88.5% 89.1% 89.6% 89.9% 90.4% 90.5% 91.0% 91.1%

RC 0.5 88.9% 89.4% 89.8% 90.1% 90.5% 90.7% 90.8% 90.9% 91.2%

0.6 89.7% 90.1% 90.3% 90.4% 90.6% 90.8% 91.2% 91.2% 91.3%

0.7 90.4% 90.7% 90.9% 90.5% 90.7% 91.1% 91.2% 91.1% 91.5%

0.8 90.6% 90.9% 91.1% 91.0% 91.1% 91.2% 91.1% 91.3% 91.4%

0.9 90.7% 90.9% 91.2% 91.3% 90.9% 91.0% 91.3% 91.4% 91.5%

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

65 | P a g i n a

Critical Chain Buffer Management 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.

0.1 0.2 0.3 0.4 SP 0.5 0.6 0.7 0.8 0.9

0.1 3 5 8 11 14 17 20 23 26

0.2 7 8 9 12 15 18 21 23 26

0.3 10 11 12 14 16 19 21 24 27

0.4 14 15 16 17 18 20 22 25 27

RC 0.5 18 19 20 21 22 23 25 26 28

0.6 22 23 24 24 25 26 27 27 28

0.7 26 27 27 27 28 28 29 29 29

0.8 29 29 29 29 29 29 29 29 29

0.9 29 29 29 29 29 30 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.

66 | P a g i n a


0.1 0.2 0.3 0.4 SP 0.5 0.6 0.7 0.8 0.9

0.1 4.7% 2.0% 1.4% 1.0% 0.7% 0.6% 0.5% 0.4% 0.3%

0.2 2.0% 1.6% 1.2% 0.9% 0.7% 0.6% 0.5% 0.4% 0.3%

0.3 1.3% 1.1% 0.9% 0.8% 0.6% 0.5% 0.5% 0.4% 0.3%

0.4 0.8% 0.8% 0.7% 0.6% 0.6% 0.5% 0.4% 0.4% 0.3%

RC 0.5 0.6% 0.6% 0.5% 0.5% 0.4% 0.4% 0.4% 0.3% 0.3%

0.6 0.5% 0.4% 0.4% 0.4% 0.4% 0.4% 0.3% 0.3% 0.3%

0.7 0.4% 0.3% 0.3% 0.4% 0.3% 0.3% 0.3% 0.3% 0.3%

0.8 0.3% 0.3% 0.3% 0.3% 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.

0.1 0.2 0.3 0.4 SP 0.5 0.6 0.7 0.8 0.9

0.1 0.8% 0.4% 0.2% 0.1% 0.1% 0.0% 0.0% 0.0% 0.0%

0.2 0.2% 0.2% 0.1% 0.1% 0.0% 0.0% 0.0% 0.0% 0.0%

0.3 0.1% 0.1% 0.1% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%

0.4 0.1% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0%

RC 0.5 0.0% 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.

67 | P a g i n a


Het onder controle houden van de Critical Chain is voordeliger wanneer de Critical Chain bestaat uit minder activiteiten.

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.

68 | 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.” 69 | P a g i n a

Critical Chain Buffer Management 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: NOPQRST UVWWRO XYSTPO

= Z[RWROR\T]RWYSTPO^ ∗ Z_\`aPRb `Y\ bR SPcd]\YT]R eN R\ [f^ ∗g

h k XYSTPO `Y\ bR XRRb]\i UVWWRO jOPPTTR

∗ ZXYSTPO `Y\ bR lYO]Y\T]R^ ∗ ZXYSTPO `Y\ bR mYOa]\Rnn PW oYTR\Rnn^ Een rekenvoorbeeld om dit geheel nog tastbaarder te maken werd gegeven op pagina 77. 70 | 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.

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 87.4% 92.9% 95.9% 97.6% 98.8% 99.7% 100.4% 100.9% 101.3%

0.2 0.3 0.4 87.6% 92.7% 97.4% 92.3% 94.8% 98.1% 95.4% 96.4% 98.6% 97.4% 97.6% 99.1% 99.0% 98.6% 99.5% 100.1% 99.4% 99.8% 101.0% 100.1% 100.2% 101.8% 100.7% 100.4% 102.4% 101.2% 100.7%

RC 0.5 100.3% 100.5% 100.7% 100.8% 101.0% 101.1% 101.2% 101.3% 101.4%

0.6 101.4% 101.4% 101.5% 101.5% 101.5% 101.5% 101.5% 101.5% 101.5%

0.7 101.7% 101.7% 101.7% 101.7% 101.7% 101.7% 101.7% 101.8% 101.8%

0.8 102.0% 102.0% 102.0% 101.9% 101.9% 101.9% 101.9% 101.9% 101.9%

0.9 102.0% 102.0% 102.0% 102.0% 102.0% 102.0% 102.0% 102.0% 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. 71 | P a g i n a

Critical Chain Buffer Management 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.

72 | 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. 73 | P a g i n a

Critical Chain Buffer Management 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: .(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. 74 | P a g i n a

Critical Chain Buffer Management 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.

75 | P a g i n a


Bijlage Bijlage 1.1 De Buffered Schedule Bijlage 1.1.1 Origineel

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 92.1 143.6 183.2 231.2 274.1 312.4 360.7 401.7 457.6

0.2 136.3 169.9 206.1 244.9 285.2 317.6 368.3 390.9 449.4

0.3 199.4 223.3 246.8 268.3 297.1 337.6 370.0 410.2 454.8

0.4 257.3 272.1 295.7 311.4 343.0 357.4 384.2 418.7 455.4

RC 0.5 316.7 342.2 354.7 366.9 386.3 397.6 419.1 440.3 469.2

0.6 384.7 406.9 422.7 419.6 430.1 443.7 458.4 464.1 473.9

0.7 437.2 451.4 459.8 463.3 466.1 462.4 485.7 485.7 494.0

0.8 488.2 493.1 476.8 495.8 486.4 494.0 491.0 493.4 494.0

0.9 498.4 487.0 500.8 485.0 485.4 496.0 490.0 502.0 488.0

RC 0.5 317.2 334.9 352.6 370.4 388.1 405.9 423.6 441.3 459.1

0.6 392.2 402.6 413.0 423.4 433.8 444.2 454.6 465.0 475.4

0.7 441.9 448.3 454.6 460.9 467.3 473.6 480.0 486.3 492.7

0.8 486.9 487.8 488.6 489.5 490.3 491.2 492.0 492.9 493.7

0.9 493.3 493.3 493.3 493.3 493.3 493.3 493.3 493.3 493.3

Tabel 11: Originele projectduurtijden van de Buffered Schedule

Bijlage 1.1.2 Trendlijn correctie

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 92.8 135.3 177.9 220.4 263.0 305.5 348.0 390.6 433.1

0.2 130.3 168.0 205.6 243.3 280.9 318.6 356.2 393.8 431.5

0.3 185.4 217.1 248.7 280.3 312.0 343.6 375.2 406.8 438.5

0.4 246.9 271.2 295.4 319.7 343.9 368.2 392.4 416.7 440.9

Tabel 12: Trendlijn-gecorrigeerde projectduurtijden van de Buffered Schedule

76 | P a g i n a


Bijlage 1.2 Simulated Schedule incl. 95%-betrouwbaarheidsinterval Bijlage 1.2.1 Origineel

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 86.4 129.6 174.1 217.4 271.0 320.1 374.4 425.4 483.8

0.2 132.2 163.2 191.0 228.2 284.0 328.2 379.9 412.5 475.9

0.3 187.7 218.3 238.1 263.0 297.4 350.1 385.7 433.6 482.2

0.4 263.1 277.1 298.8 310.7 349.3 369.4 400.3 440.8 481.3

RC 0.5 334.8 357.3 369.2 382.8 403.6 414.1 442.7 464.6 497.0

0.6 408.4 429.6 443.9 439.8 452.7 467.5 484.6 490.4 501.1

0.7 463.2 475.3 485.9 489.5 494.1 489.1 513.4 513.6 522.3

0.8 518.2 522.5 505.2 523.7 515.2 523.6 520.7 522.5 523.4

0.9 522.6 516.5 537.3 519.7 514.9 525.4 519.2 532.0 516.7

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

Bijlage 1.2.2 Trendlijn correctie

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 84.3 130.7 177.2 223.7 270.1 316.6 363.1 409.5 456.0

0.2 118.6 161.2 203.8 246.4 288.9 331.5 374.1 416.7 459.2

0.3 178.6 213.9 249.2 284.5 319.8 355.1 390.4 425.7 461.0

0.4 249.9 276.3 302.8 329.2 355.6 382.1 408.5 434.9 461.3

RC 0.5 330.7 349.9 369.0 388.2 407.3 426.5 445.6 464.8 483.9

0.6 413.4 424.5 435.5 446.5 457.6 468.6 479.6 490.7 501.7

0.7 467.0 473.7 480.5 487.3 494.0 500.8 507.6 514.4 521.1

0.8 516.0 516.9 517.8 518.6 519.5 520.3 521.2 522.1 522.9

0.9 522.9 522.9 522.9 522.9 522.9 522.9 522.9 522.9 522.9

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

77 | P a g i n a


Bijlage 1.3 De Project Buffer Factor Bijlage 1.3.1 Invloed van de Feeding Buffergrootte

0.4 102% 106% 107% 108% 106% 104% 103% 101% 101%

RC 0.5 102% 103% 103% 102% 103% 102% 101% 101% 100%

0.6 101% 101% 101% 102% 101% 101% 100% 101% 100%

0.7 100% 101% 100% 101% 100% 101% 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%

0.4 101% 104% 105% 106% 105% 103% 102% 101% 100%

RC 0.5 101% 102% 102% 102% 102% 102% 100% 101% 100%

0.6 101% 101% 101% 101% 101% 101% 100% 100% 100%

0.7 100% 101% 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%

0.4 101% 103% 103% 104% 103% 102% 101% 101% 100%

RC 0.5 101% 101% 101% 102% 101% 101% 100% 100% 100%

0.6 100% 101% 101% 100% 101% 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%

FB: 0.9

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 118% 121% 116% 116% 111% 106% 104% 101% 101%

0.2 107% 115% 117% 116% 110% 105% 105% 101% 100%

0.3 105% 112% 113% 110% 109% 104% 103% 101% 100%

FB: 0.8

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 113% 116% 111% 112% 108% 104% 103% 101% 100%

0.2 106% 110% 112% 112% 107% 103% 103% 101% 100%

0.3 104% 108% 109% 107% 106% 103% 102% 101% 100%

FB: 0.7

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 109% 110% 107% 107% 104% 102% 101% 100% 100%

0.2 104% 107% 108% 107% 104% 102% 102% 101% 100%

0.3 102% 105% 105% 105% 104% 102% 101% 100% 100%

78 | P a g i n a


0.4 101% 101% 101% 102% 101% 101% 100% 100% 100%

RC 0.5 100% 100% 101% 101% 100% 101% 100% 100% 100%

0.6 100% 101% 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%

0.4 100% 100% 99% 100% 100% 100% 100% 100% 100%

RC 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%

0.4 100% 98% 98% 98% 98% 99% 99% 100% 100%

RC 0.5 99% 99% 99% 99% 99% 99% 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%

FB: 0.6

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 103% 104% 103% 103% 102% 101% 101% 100% 100%

0.2 102% 103% 103% 103% 102% 101% 101% 100% 100%

0.3 101% 102% 102% 102% 101% 101% 101% 100% 100%

FB: 0.5

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 99% 99% 99% 99% 99% 100% 100% 100% 100%

0.2 99% 99% 99% 99% 100% 100% 99% 100% 100%

0.3 99% 99% 99% 100% 100% 100% 100% 100% 100%

FB: 0.4

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 94% 94% 96% 95% 97% 98% 99% 100% 100%

0.2 98% 96% 96% 95% 97% 99% 99% 100% 100%

0.3 98% 97% 96% 97% 97% 99% 99% 100% 100%

79 | P a g i n a


0.4 99% 97% 97% 96% 97% 98% 99% 99% 100%

RC 0.5 99% 99% 99% 98% 99% 99% 99% 100% 100%

0.6 100% 100% 100% 99% 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%

0.4 98% 96% 96% 94% 96% 98% 98% 99% 100%

RC 0.5 99% 98% 98% 98% 98% 98% 99% 99% 100%

0.6 99% 100% 99% 99% 99% 99% 100% 100% 100%

0.7 100% 99% 100% 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%

0.4 98% 95% 94% 93% 95% 97% 98% 99% 100%

RC 0.5 99% 98% 98% 98% 98% 98% 99% 99% 100%

0.6 99% 99% 99% 99% 99% 99% 100% 100% 100%

0.7 100% 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%

FB: 0.3

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 90% 89% 92% 92% 95% 97% 98% 100% 100%

0.2 96% 92% 92% 92% 95% 98% 98% 99% 100%

0.3 97% 94% 94% 95% 95% 98% 98% 99% 100%

FB: 0.2

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 88% 85% 90% 89% 93% 96% 98% 100% 100%

0.2 95% 90% 88% 89% 93% 97% 97% 99% 100%

0.3 97% 92% 91% 93% 94% 97% 98% 99% 100%

FB: 0.1

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 86% 82% 87% 87% 92% 96% 97% 100% 100%

0.2 94% 88% 85% 87% 92% 96% 97% 99% 100%

0.3 96% 90% 90% 91% 93% 97% 98% 99% 100%

Tabel 15: Invloed van de Feeding Buffergrootte op de PBF

80 | P a g i n a


Bijlage 1.3.2 Invloed van de variantie van de activiteitsduurtijden

Variantieniveau 1

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 87% 89% 91% 92% 93% 93% 94% 94% 94%

0.2 90% 91% 91% 92% 93% 93% 94% 94% 94%

0.3 92% 92% 92% 93% 93% 93% 94% 94% 94%

0.4 93% 93% 93% 93% 93% 94% 94% 94% 94%

RC 0.5 93% 93% 93% 94% 94% 94% 94% 94% 94%

0.6 94% 94% 94% 94% 94% 94% 94% 94% 94%

0.7 94% 94% 94% 94% 94% 94% 94% 94% 95%

0.8 94% 94% 94% 94% 94% 94% 94% 94% 94%

0.9 94% 94% 94% 94% 94% 94% 94% 94% 95%

0.4 94% 94% 94% 95% 95% 95% 95% 95% 96%

RC 0.5 95% 95% 95% 95% 95% 95% 95% 95% 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% 96% 96% 96% 96% 96% 96% 96%

0.9 95% 96% 96% 96% 96% 96% 96% 96% 96%

0.4 96% 96% 96% 96% 96% 97% 97% 97% 97%

RC 0.5 96% 97% 97% 97% 97% 97% 97% 97% 97%

0.6 96% 97% 97% 97% 97% 97% 97% 97% 97%

0.7 97% 97% 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%

Variantieniveau 2

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 90% 91% 93% 94% 94% 95% 95% 95% 96%

0.2 92% 93% 93% 94% 94% 95% 95% 95% 95%

0.3 94% 94% 94% 94% 95% 95% 95% 95% 96%

Variantieniveau 3

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 94% 94% 95% 96% 96% 96% 97% 97% 97%

0.2 95% 95% 95% 96% 96% 96% 96% 97% 97%

0.3 96% 96% 96% 96% 96% 96% 97% 97% 97%

81 | P a g i n a

Critical Chain Buffer Management Variantieniveau 4

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 97% 97% 97% 98% 98% 98% 98% 98% 98%

0.2 97% 97% 97% 98% 98% 98% 98% 98% 98%

0.3 98% 98% 98% 98% 98% 98% 98% 98% 98%

0.4 98% 98% 98% 98% 98% 98% 98% 98% 98%

RC 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%

0.4 100% 100% 100% 100% 100% 100% 100% 100% 100%

RC 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%

0.4 102% 102% 102% 102% 102% 102% 101% 101% 101%

RC 0.5 102% 102% 102% 101% 101% 102% 101% 101% 101%

0.6 101% 102% 101% 101% 101% 101% 101% 101% 101%

0.7 101% 101% 101% 101% 101% 101% 101% 101% 101%

0.8 102% 102% 101% 101% 101% 101% 101% 101% 101%

0.9 101% 101% 101% 101% 101% 101% 101% 101% 102%

Variantieniveau 5

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

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%

Variantieniveau 6

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 103% 103% 102% 102% 102% 102% 101% 102% 101%

0.2 102% 102% 102% 102% 102% 102% 101% 101% 101%

0.3 102% 102% 102% 102% 102% 102% 102% 101% 102%

82 | P a g i n a

Critical Chain Buffer Management Variantieniveau 7

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 106% 106% 105% 104% 104% 103% 103% 103% 103%

0.2 105% 105% 105% 104% 104% 104% 103% 103% 103%

0.3 104% 104% 104% 104% 104% 103% 103% 103% 103%

0.4 104% 104% 104% 103% 103% 103% 103% 103% 103%

RC 0.5 104% 104% 103% 103% 104% 103% 103% 103% 103%

0.6 103% 103% 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%

0.4 106% 106% 106% 106% 105% 105% 105% 105% 104%

RC 0.5 106% 105% 105% 105% 105% 105% 105% 105% 105%

0.6 105% 105% 105% 105% 105% 105% 105% 105% 105%

0.7 105% 105% 105% 105% 105% 105% 104% 104% 104%

0.8 105% 105% 105% 105% 105% 105% 104% 105% 104%

0.9 105% 105% 105% 105% 104% 105% 105% 105% 104%

0.4 108% 108% 108% 108% 108% 107% 107% 106% 106%

RC 0.5 108% 107% 107% 107% 107% 107% 107% 107% 106%

0.6 107% 107% 107% 107% 107% 107% 106% 106% 106%

0.7 107% 107% 106% 107% 107% 106% 106% 106% 106%

0.8 107% 106% 106% 106% 106% 106% 106% 106% 106%

0.9 106% 106% 106% 106% 106% 106% 106% 106% 106%

Variantieniveau 8

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 110% 109% 107% 107% 106% 105% 105% 105% 105%

0.2 108% 107% 107% 107% 106% 105% 105% 105% 105%

0.3 107% 107% 106% 106% 106% 106% 105% 105% 105%

Variantieniveau 9

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 113% 112% 109% 109% 108% 108% 107% 107% 106%

0.2 110% 110% 110% 109% 108% 108% 107% 107% 106%

0.3 109% 109% 109% 108% 108% 108% 107% 107% 106%

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

83 | P a g i n a


Bijlage 1.4 Controle van de Critical Chain Variantieniveau 9 RC

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 85.9% 89.8% 88.6% 89.2% 89.6% 90.1% 90.1% 90.8% 91.2%

0.2 85.9% 87.3% 89.3% 89.0% 89.7% 89.8% 90.1% 90.6% 91.2%

0.3 87.2% 88.0% 88.8% 89.4% 89.8% 90.1% 90.5% 90.7% 91.0%

0.4 88.2% 88.5% 89.1% 89.6% 89.9% 90.4% 90.5% 91.0% 91.1%

0.5 88.9% 89.4% 89.8% 90.1% 90.5% 90.7% 90.8% 90.9% 91.2%

0.6 89.7% 90.1% 90.3% 90.4% 90.6% 90.8% 91.2% 91.2% 91.3%

0.7 90.4% 90.7% 90.9% 90.5% 90.7% 91.1% 91.2% 91.1% 91.5%

0.8 90.6% 90.9% 91.1% 91.0% 91.1% 91.2% 91.1% 91.3% 91.4%

0.9 90.7% 90.9% 91.2% 91.3% 90.9% 91.0% 91.3% 91.4% 91.5%

0.6 91.2% 91.8% 92.0% 92.1% 92.2% 92.3% 92.5% 92.5% 92.7%

0.7 91.6% 92.0% 92.0% 92.3% 92.2% 92.5% 92.9% 92.8% 92.8%

0.8 92.1% 92.3% 92.4% 92.6% 92.4% 92.6% 92.7% 92.6% 92.8%

0.9 92.1% 92.4% 92.6% 92.5% 92.7% 92.7% 92.7% 92.5% 92.9%

0.6 93.1% 93.4% 93.5% 93.7% 93.7% 93.9% 94.0% 93.9% 94.4%

0.7 93.4% 93.6% 93.8% 93.6% 93.9% 93.9% 94.2% 94.0% 94.2%

0.8 93.9% 94.0% 93.8% 94.1% 94.0% 94.2% 94.2% 94.2% 94.2%

0.9 93.6% 93.9% 94.2% 94.1% 94.1% 94.2% 94.2% 94.2% 94.2%

Variantieniveau 8 RC

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 86.6% 90.5% 89.6% 90.2% 90.9% 91.8% 91.8% 92.2% 92.6%

0.2 87.4% 88.8% 90.6% 90.5% 91.3% 91.7% 91.9% 92.1% 92.4%

0.3 88.8% 89.4% 90.3% 90.5% 91.2% 91.7% 91.8% 92.3% 92.6%

0.4 90.0% 90.3% 91.0% 91.1% 91.8% 91.9% 91.8% 92.4% 92.7%

0.5 90.7% 91.2% 91.3% 91.6% 92.1% 92.1% 92.3% 92.5% 92.6%


SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 88.5% 91.9% 91.3% 92.0% 92.3% 93.3% 93.2% 93.9% 94.2%

0.2 89.0% 90.4% 91.9% 91.9% 92.8% 92.9% 93.4% 93.8% 93.9%

0.3 91.0% 91.4% 92.2% 92.5% 92.8% 93.4% 93.4% 93.8% 93.9%

0.4 91.6% 92.0% 92.5% 92.8% 93.5% 93.3% 93.5% 93.9% 94.0%

0.5 92.4% 92.7% 93.0% 93.4% 93.2% 93.5% 93.6% 94.0% 94.2%

84 | P a g i n a

Critical Chain Buffer Management Variantieniveau 6 RC

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 90.3% 92.9% 93.0% 93.6% 94.1% 94.6% 95.0% 95.2% 95.5%

0.2 91.5% 92.5% 93.6% 93.8% 94.3% 94.7% 94.9% 95.2% 95.4%

0.3 92.8% 93.2% 93.8% 94.0% 94.4% 94.8% 94.9% 95.4% 95.3%

0.4 93.8% 94.0% 94.2% 94.5% 94.8% 94.9% 95.1% 95.4% 95.5%

0.5 94.3% 94.5% 94.6% 94.9% 95.1% 95.0% 95.2% 95.5% 95.6%

0.6 94.7% 94.9% 95.1% 95.2% 95.2% 95.4% 95.4% 95.6% 95.6%

0.7 95.2% 95.2% 95.4% 95.3% 95.5% 95.4% 95.7% 95.6% 95.7%

0.8 95.1% 95.3% 95.4% 95.5% 95.4% 95.5% 95.6% 95.6% 95.7%

0.9 95.2% 95.7% 95.5% 95.5% 95.4% 95.6% 95.7% 95.7% 95.5%

0.6 96.4% 96.7% 96.8% 96.9% 96.8% 96.8% 97.0% 96.9% 97.3%

0.7 96.6% 96.8% 97.0% 97.0% 96.9% 96.9% 97.2% 97.3% 97.2%

0.8 96.8% 97.0% 97.0% 97.1% 97.1% 97.1% 97.2% 97.2% 97.2%

0.9 96.8% 97.0% 97.1% 97.1% 97.1% 97.2% 97.1% 97.0% 97.1%

0.6 98.2% 98.2% 98.3% 98.5% 98.5% 98.5% 98.6% 98.6% 98.6%

0.7 98.4% 98.5% 98.5% 98.6% 98.6% 98.6% 98.6% 98.7% 98.6%

0.8 98.5% 98.5% 98.6% 98.6% 98.5% 98.7% 98.6% 98.8% 98.7%

0.9 98.5% 98.6% 98.6% 98.7% 98.6% 98.6% 98.6% 98.6% 98.6%


SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 92.4% 94.6% 94.9% 95.4% 95.8% 96.3% 96.3% 96.8% 96.9%

0.2 93.5% 94.4% 95.0% 95.4% 96.1% 96.3% 96.5% 96.8% 97.0%

0.3 94.9% 95.1% 95.6% 95.9% 96.2% 96.6% 96.5% 96.8% 97.0%

0.4 95.7% 95.7% 95.9% 96.1% 96.3% 96.5% 96.6% 96.9% 97.0%

0.5 96.2% 96.2% 96.5% 96.6% 96.6% 96.8% 96.9% 97.0% 97.0%


SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 94.9% 96.5% 96.8% 97.3% 97.6% 98.1% 98.1% 98.4% 98.5%

0.2 95.8% 96.4% 97.2% 97.4% 97.8% 97.9% 98.2% 98.3% 98.4%

0.3 96.9% 97.1% 97.3% 97.6% 97.8% 98.1% 98.3% 98.4% 98.6%

0.4 97.5% 97.7% 97.8% 98.0% 98.1% 98.1% 98.4% 98.4% 98.6%

0.5 97.9% 98.1% 98.2% 98.2% 98.4% 98.3% 98.5% 98.6% 98.7%

85 | P a g i n a

Critical Chain Buffer Management Variantieniveau 3 RC

SP

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

0.1 97.5% 98.2% 98.7% 99.1% 99.2% 99.4% 99.6% 99.8% 99.8%

0.2 98.4% 98.5% 98.8% 99.1% 99.3% 99.5% 99.7% 99.8% 99.8%

0.3 98.9% 99.0% 99.2% 99.4% 99.4% 99.5% 99.7% 99.6% 99.9%

0.4 99.3% 99.3% 99.4% 99.5% 99.6% 99.6% 99.6% 99.7% 99.8%

0.5 99.4% 99.4% 99.5% 99.7% 99.7% 99.7% 99.8% 99.9% 99.9%

0.6 99.6% 99.7% 99.8% 99.8% 99.8% 99.8% 99.8% 99.9% 99.9%

0.7 99.7% 99.8% 99.9% 99.9% 99.9% 99.8% 99.9% 99.9% 99.9%

0.8 0.9 99.8% 99.8% 99.9% 99.9% 99.8% 99.9% 99.9% 99.9% 99.9% 99.8% 99.9% 99.8% 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

86 | P a g i n a

Critical Chain Buffer Management

Recommend Documents