Critical Chain Buffer Management

Transcriptie

1 UNIVERSITEIT GENT FACULTEIT ECONOMIE EN BEDRIJFSKUNDE ACADEMIEJAAR 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

2

3 UNIVERSITEIT GENT FACULTEIT ECONOMIE EN BEDRIJFSKUNDE ACADEMIEJAAR 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

4 Permission Ondergetekenden verklaren dat de inhoud van deze masterproef mag geraadpleegd en/of gereproduceerd worden, mits bronvermelding. Chistophe Bostyn Jordy De Loose

5 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

6 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 Een eenvoudig netwerk Resource Constrained Project Scheduling Prioriteitsregels De Basic Feasible Schedule Problemen bij Project Scheduling Schattingen van de activiteitsduur De wet van Parkinson Het Student Syndrome Merge Bias Multi-tasking Hoofdstuk 2: Critical Chain Buffer Management (CC/BM) Theory of Constraints toegepast op Project Management De Critical Chain Buffers Project Buffers Feeding Buffers II

7 2.3.3 Bepaling van de Buffergrootte Doel van Critical Chain Buffer Management Hoofdstuk 3: Doelstellingen en setup van het model Einddoelstellingen en modeltoelichting Einddoelstelling Het model Netwerkgenerator Basic Feasible Schedule (Feeding) Buffered Schedule Buffered Schedule Feeding Buffered Schedule Simulated Schedule Projected Schedule Variantie en verdeling van de activiteitsduurtijden Variantie van de projectduurtijd Simulated Schedule inclusief het 95%-betrouwbaarheidsinterval Hoofdstuk 4: Resultaten van de experimenten Feeding Buffered Schedule Invloed van SP op de projectduurtijd Invloed van RC op de projectduurtijd Invloed van de combinatie van RC en SP op de totale duurtijd Invloed van Feeding Buffergrootte op de projectduurtijd Invloed van Whitespaces op de projectduurtijd Simulated Schedule inclusief het 95%-betrouwbaarheidsinterval Invloed van SP op de projectduurtijd Invloed van RC op de projectduurtijd Invloed van de combinatie van RC en SP op de totale duurtijd III

8 4.2.4 Invloed van de variantie van de activiteitsduurtijden op de projectduurtijd De Project Buffer Factor De Referentiefactor Combinatie van SP & RC Invloed van de Feeding Buffergrootte Invloed van de Variantie van de activiteitsduurtijden Invloed van Earliness/Lateness van de activiteitsduurtijden Een uitgewerkt voorbeeld Controle van de Critical Chain elementen Hoofdstuk 5: Conclusie Hoofdstuk 6: Bibliografie Bijlage Bijlage 1.1 De Buffered Schedule Bijlage Origineel Bijlage Trendlijn correctie Bijlage 1.2 Simulated Schedule incl. 95%-betrouwbaarheidsinterval Bijlage Origineel Bijlage Trendlijn correctie Bijlage 1.3 De Project Buffer Factor Bijlage Invloed van de Feeding Buffergrootte Bijlage Invloed van de variantie van de activiteitsduurtijden Bijlage 1.4 Controle van de Critical Chain IV

9 Gebruikte afkortingen Afkorting Verklaring ALAP AoA AoN ASAP BI CC CC/BM CP FB N-CC OS PB PS RC RCPSP SP SPT SS-95% TOC As-Late-As-Possible Activity-On-Arc Activity-On-Node As-Soon-As-Possible Betrouwbaarheidsinterval Critical Chain Critical Chain Buffer Management Critical Path Feeding Buffer Niet-Critical Chain Order Strength Project Buffer Projected Schedule Resource Constrainedness Resource-Constrained Project Scheduling Problem Graad van Serialiteit/Parallellisme Shortest Processing Time Simulated Schedule inclusief het 95%-Betrouwbaarheidsinterval Theory of Constraints V

10 Verklarende woordenlijst Benaming Uitleg Verwijzing (p.) Activiteit Een activiteit is een bepaalde taak die moet uitgevoerd worden als onderdeel van een project. Dit kan heel ruim zijn, zoals het afwerken van een gehele verdieping van een appartement, evenals heel gedetailleerd, bijvoorbeeld het boren van een gat in de muur, afhankelijk van de interne doelstelling. 3 Basic Feasible Schedule De Basic Feasible Schedule is een schedule van een bepaald projectnetwerk dat voldoet aan enerzijds alle volgorderelaties en anderzijds alle Resource Beperkingen. 6 Buffered Schedule De Buffered Schedule is een ge-reschedulede vorm van de Basic Feasible Schedule, samen met de Feeding Buffers, inclusief de toevoeging van de Project Buffer. 29 Dummy activiteit Een dummy activiteit is een fictieve activiteit, die een bepaald event vaststelt. In dit werk is er een Start Dummy activiteit ( = het netwerk begint) en een Finish Dummy activiteit ( = alle activiteiten zijn gescheduled/uitgevoerd). 3 Duurtijd Een duurtijd wijst op het aantal tijdseenheden, die een bepaalde activiteit nodig, heeft om uitgevoerd te worden. 3 Feeding Buffer Feeding Buffers zijn de buffers die de Critical Chain beschermen tegen externe vertragingen. Ze zijn dan ook gepositioneerd waar de Niet-Critical Chain zich invoegt in de Critical Chain. 18 Feeding Buffered Schedule De Feeding Buffered Schedules is een Buffered Schedule waarvan de Project Buffer is weggenomen. Deze wordt hier in feite mede gebruikt ter bepaling van de Project Buffer. 29 VI

11 Feeding Chain Een Feeding Chain bestaat uit een chain van transitieve niet- Critical Chain activiteiten. 18 Mijlpaal Een mijlpaal verwijst naar het tijdstip waarop de voltooiing van een individuele activiteit zou moeten plaatsvinden. 3 Project Buffer De Project Buffer bevindt zich aan het einde van de Buffered Schedule. Ze biedt bescherming tegen vertragingen in de Critical Chain. 17 Projected Schedule De Projected Schedule wordt gevolgd voor de uitvoering van het project. Ze is gelijk aan de Basic Feasible Schedule waarvan de activiteiten As-Soon-As-Possible worden gescheduled. 33 RC of de Resource Constrainedness In dit onderzoek werken we met hernieuwbare resources. Dit wil zeggen dat we op elke tijdsperiode X aantal resources ter beschikking hebben, onafhankelijk van het verbruik in de vorige periodes (bv. Een team van 10 mensen). De RC bepaalt het percentage dat een activiteit gemiddeld gebruikt van dit aantal beschikbare resources. Wanneer dit bijvoorbeeld 0.3 is, zullen de activiteiten gemiddeld 3 mensen van de 10 nodig hebben. In dit werk wordt er met sprongen van 0.1 gevarieerd van de waarde 0.1 tot en met de waarde Rescheduling Voor het opstellen van de Basic Feasible Schedule is gescheduled aan de hand van een bepaalde methodiek. Wanneer we de Feeding Buffered Schedule willen opstellen, zijn er een soort activiteiten bijgekomen, namelijk de Buffer Activititeiten. Deze worden opgenomen in de activiteitenlijst samen met de bijkomende volgorderelaties. Met deze extra elementen wordt er volgens dezelfde methodiek een nieuwe schedule opgesteld. 32 Resource Resources kunnen verschillende vormen aannemen zoals financiële resources, mankracht, machines, uitrusting, VII 3

12 materialen, energie, ruimte enz. Dit zijn zaken die een activiteit nodig heeft om te kunnen worden uitgevoerd. Simulated Schedule De Simulated Schedule is een gesimuleerde vorm van de Projected Schedule. 33 SP of de graad van Serialiteit/Parallellisme Netwerken kunnen in het ene uiterste 100% serieel opgebouwd zijn (de tweede activiteit komt na de eerste enzovoort ), of anderzijds geheel parallel (alle activiteiten kunnen volgens de volgorderelaties van het netwerk gelijktijdig uitgevoerd worden). SP is hier een parameter voor. In dit onderzoek werken we in sprongen van 0.1 van de waarde 0.1 (hoge graad van parallellisme) tot en met 0.9 (hoge graad van serialiteit). 26 Type Netwerk Een netwerk wordt in dit onderzoek steeds gedefinieerd door 2 parameters, namelijk SP (de graad van Serialiteit/Parallellisme) en RC (de graad van Resource Constrainedness). Een bepaald Type Netwerk is dan een netwerk, gedefinieerd door een bepaalde waarde voor deze 2 parameters. 27 Volgorderelatie Een volgorderelatie wijst op de relatie tussen 2 opeenvolgende activiteiten. Van deze relatie bestaan verschillende vormen, zoals Start-Start, Start-Finish, De relatie die in dit werk gebruikt wordt is de Finish-Start volgorderelatie. Dit wil zeggen dat activiteit B pas kan starten (Start) van zodra activiteit A uitgevoerd is (Finish). 3 Whitespaces Whitespaces zijn tijdseenheden in de (Feeding) Buffered Schedule waar er geen enkele resource wordt gebruikt. Het is dus een plaats waar enkel de Feeding Buffer staat gescheduled. 47 VIII

13 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 Figuur 8: Merge Bias Figuur 9: Multi-tasking Figuur 10: Single tasking Figuur 11: Basic Feasible Scheduling - ALAP Figuur 12: Individuele Buffers Figuur 13: Invoegen van de Project Buffer Figuur 14: Invoegen van de Feeding Chains Figuur 15: Toevoegen van de Feeding Buffer aan de Feeding Chain Figuur 16: Buffer Management - opvolgmethode Figuur 17: Overzicht van de doelstelling Figuur 18: Activiteitennetwerk Figuur 19: Basic Feasible Schedule - ALAP Figuur 20: Activiteitennetwerk met CC en FB s Figuur 21: Activiteitennetwerk met CC en FB's (2) Figuur 22: Basic Feasible Schedule Figuur 23: Feeding Buffered Schedule - verschuiving Figuur 24: Feeding Buffered Schedule - rescheduled Figuur 25: Feeding Buffered Schedule - rescheduled Figuur 26: Projected Schedule Figuur 27: Symmetrisch triangulaire verdeling van de activiteitsduurtijden Figuur 28: Normale verdeling van de projectduurtijd en rechtseenzijdige 95%-betrouwbaarheidsinterval Figuur 29: Invloed van SP op de duurtijd van de Buffered Schedule Figuur 30: Invloed van RC op de duurtijd van de Buffered Schedule IX

14 Figuur 31: Invloed van SP op de duurtijd van de Buffered Schedule, gegeven een bepaalde waarde van RC Figuur 32: Procentuele verlenging van de duurtijd van de Buffered Schedule, gegeven een bepaalde verhouding van RC (RC=0.X/RC=0.1) Figuur 33: Invloed van RC op de duurtijd van de Buffered Schedule, gegeven een bepaalde waarde van SP Figuur 34: Procentuele verlenging van de duurtijd van de Buffered Schedule, gegeven een bepaalde verhouding van SP (SP=0.X/SP=0.1) Figuur 35: Projectduurtijd van de Buffered Schedule Figuur 36: Projectduurtijd van de Buffered Schedule - trendlijn correctie Figuur 37: Invloed van de Feeding Buffergrootte op de duurtijd van de Buffered Schedule Figuur 38: Activiteitennetwerk Figuur 39: Basic Feasible Schedule Figuur 40: Activiteitennetwerk met CC en FB's Figuur 41: Feeding Buffered Schedule met Whitespace Figuur 42: Invloed van SP op het voorkomenv an Whitespaces Figuur 43: Invloed van RC op het voorkomen van Whitespaces Figuur 44: Invloed van FB Grootte op het voorkomen van Whitespaces Figuur 45: Invloed van SP op de duurtijd van de Simulated Schedule inclusief het 95%- betrouwbaarheidsinterval Figuur 46: Invloed van RC op de duurtijd van de Simulated Schedule inclusief het 95%- betrouwbaarheidsinterval Figuur 47: Projectduur van de Simulated Schedule Figuur 48: Projectduurtijd van de Simulated Schedule - trendlijn correctie Figuur 49: Invloed van de variantie van de activiteitsduurtijden op de projectduurtijd X

15 Tabellen Tabel 1: Duurtijden met Whitespaces/duurtijden zonder Whitespaces Tabel 2: Factor SP & RC Tabel 3: Invloed van de Feeding Buffergrootte bij FB = Tabel 4: Invloed van de Feeding Buffergrootte bij FB = Tabel 5: Invloed van de Variantie van de activiteitsduurtijden Tabel 6: Invloed van de controle van de Critical Chain op de projectduurtijd startend van een variantieniveau van Tabel 7: Aantal Critical Chain elementen per type netwerk Tabel 8: Invloed van controle van de CC op de projectduurtijd ten opzichte van het aantal CC-elementen startend van een variantieniveau van Tabel 9: Invloed van controle van de CC op de projectduurtijd ten opzichte van het aantal CC-elementen startend van een variantieniveau van Tabel 10: Invloed van het type netwerk op de PBF Tabel 11: Originele projectduurtijden van de Buffered Schedule Tabel 12: Trendlijn-gecorrigeerde projectduurtijden van de Buffered Schedule Tabel 13: Originele projectduurtijden van de Simulated Schedule inclusief het 95%- betrouwbaarheidsinterval Tabel 14: Trendlijn-gecorrigeerde projectduurtijden van de Simulated Schedule inclusief het 95%- betrouwbaarheidsinterval Tabel 15: Invloed van de Feeding Buffergrootte op de PBF Tabel 16: Invloed van de Variantie van de activiteitsduurtijden op de PBF Tabel 17: Invloed van de controle van het Variantieniveau van de Critical Chain XI

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

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

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

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

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

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

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

23 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 Buffered Schedule), als de Projected Schedule (punt Projected Schedule ) worden opgesteld op basis van deze eerste. 8 P a g i n a

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

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

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

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

28 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

29 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

30 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

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

32 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

33 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). Figuur 15: Toevoegen van de Feeding Buffer aan de Feeding Chain 18 P a g i n a

34 2.3.3 Bepaling van de Buffergrootte 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 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) 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

35 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 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 (Pe j ): = 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 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

36 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

37 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