Een studie naar de integratie tussen de Critical Chain methode en Evidence Reasoning

Transcriptie

1 UNIVERSITEIT GENT FACULTEIT ECONOMIE EN BEDRIJFSKUNDE ACADEMIEJAAR Een studie naar de integratie tussen de Critical Chain methode en Evidence Reasoning Masterproef voorgedragen tot het bekomen van de graad van Master of Science in de Toegepaste Economische Wetenschappen: Handelsingenieur Lucas Tack onder leiding van Prof. Dr. Mario Vanhoucke Annelies Martens

2

3 UNIVERSITEIT GENT FACULTEIT ECONOMIE EN BEDRIJFSKUNDE ACADEMIEJAAR Een studie naar de integratie tussen de Critical Chain methode en Evidence Reasoning Masterproef voorgedragen tot het bekomen van de graad van Master of Science in de Toegepaste Economische Wetenschappen: Handelsingenieur Lucas Tack onder leiding van Prof. Dr. Mario Vanhoucke Annelies Martens

4

5 Toestemming Ondergetekende verklaart dat de inhoud van deze masterproef mag worden geraadpleegd en/of gereproduceerd, mits bronvermelding. Lucas Tack Undersigned declares that the contents of this master thesis may be consulted and/or reproduced, provided the source is acknowledged. Lucas Tack v

6 ABSTRACT Kern woorden: Multi-project planning, Evidence Reasoning, Critical Chain, Critical Chain Project Management, Theory of Constraints. Deze thesis behandelt de multi-project planning problematiek, waarin een planning moet worden opgesteld voor een portfolio aan projecten. Binnen dit domein werd een nieuwe methode ontwikkeld door Shalin Yang en Lei Fu (2013) die steunt op een combinatie van Evidence Reasoning (ER) en de Critical Chain (CC) methode. In deze thesis werd dit model gevalideerd op fictieve data. We vergelijken het ER + CC model met alternatieve multi-project planningstechnieken die in de praktijk frequent gebruikt worden. Daarbij bestuderen we de multi-project duurtijd, de throughput van de individuele projecten en de gebruiksgraad van de resources om een oordeel te vellen over de kwaliteit van deze nieuwe aanpak. Naast het valideren van het model stapten we ook af van enkele assumpties om zo de kwaliteit van ER + CC verder te testen. Uit dit onderzoek werd een betere manier vooropgesteld om de Capacity Constraint Buffer grootte te bepalen en een nieuwe manier om de beperkende factor te definiëren. Het model werd ook zo geïmplementeerd zodat het uitvoerbaar is voor netwerken met meerdere beperkende factoren. Uit het valideren blijkt dat de ER + CC methode leidt tot een significant kortere multi-project duurtijden dan de alternatieve methodes en dat dit voordeel toeneemt bij een lagere gebruiksgraad van de resources. De hoofdreden hiertoe is dat de nieuwe methode erin slaagt om de resources efficiënter aan te wenden. Het nadeel van een planning via de ER + CC methode, is dat de geplande eindtijd van het eerste project veel later is dan in vergelijking met de alternatieve planningsmethodes. Als conclusie kunnen we het gebruik van deze nieuwe aanpak aanraden omdat deze tot kortere duurtijden leidt van het multi-project en toelaat om strategische belangen in de planning te verwerken. vi

7 INHOUD Abstract... vi Afkortingen... x Lijst van figuren... xi 1 Inleiding Literatuur Probleem situering Multi-project planning Het Positioning Framework Het Hierarchical Framework Modelmatige voorstelling Beschikbare modellen Evidential reasoning Critical Chain Project Management Genetic algorithm Combinatie van evidence reasoning en CCPM Beperkingen van de huidige methode Beschrijving van de nieuwe ER + CC methode Assumpties en onderzoeksvragen Meerdeer beperkende factoren Opzet Experiment Multi-project planningsmethodes Projecten na elkaar Project prioriteiten met Feeding buffer Project prioriteiten zonder Feeding buffer Samenvatting Performance measures Implementatie in C Overzicht vii

8 5.2 Schema 1: het maken van individuele projecten Genereren en inlezen data Verrijken van de data (ES/LS/CP) Maken van een prioriteitenlijst Opstellen ALAP schema per project Toevoegen FB aan individuele schema s Schema 2: Multi-project op basis van taak prioriteiten Bepaal bottleneck taken Maken van een prioriteitenlijst op taak level Opstellen ASAP multi-project schema Bepalen van de CCB nood Opstellen ASAP multi-project schema incl. CCB Consumeer slack van niet-bottleneck taken Bepalen van de DB nood Opstellen ASAP multi-project schema incl. CCB en DB Toevoegen van feeding buffers Multi schema laten starten op tijdstip nul Schema 3: Multi-project op basis van project prioriteiten excl. FB Opstellen ALAP multi-project schema Bepalen van de CCB nood Opstellen ALAP multi-project schema incl. CCB Consumeren van gecreëerde slack door toevoegen CCB Bepalen van de DB nood Opstellen ALAP multi-project schema incl. CCB en DB /5.4.8 Toevoegen van feeding buffers en multi schema laten starten op tijdstip nul Schema 4: Multi-project op basis van taak prioriteiten incl. FB Schema 5: multi-project door individuele projecten na elkaar te plaatsen Programma valideren Het formuleren van een antwoord op de onderzoekspunten viii

9 6.1 Onderzoekspunt 3: hoe bepalen we best de bottleneck resource Onderzoekspunt 1: Wat is het voordeel van het ER + CC model in vergelijking met andere planningsmethodes? Projecten met 1 beperkende factor Uitbreiding naar twee resources Onderzoekspunt 2: Wat is de invloed van meerdere (beperkende) resources op de multi-project planning? De Invloed van de niet-bottleneck resource Projecten met meerdere beperkende factor Onderzoekspunt 4: Hoe bepalen we best de grootte van de CCB? onderzoekspunt 5: Wat is de sensitiviteit van de ER uitkomst op het multi-project? Samenvatting Aangewezen methode per project type Algemene conclusies Bibliografie Bijlage Output programma Implementatie ER algoritme in C verwerken van de output data invloed van de niet-beperkende factor: berekeningen... 8 ix

10 AFKORTINGEN ALAP = ASAP = DB = CC = CCB = C.D.F = CP = CCPM = ER = ES = FB = GA = LS = NP-Hard = NPV = PB = RCMPSP = RSEM = WIP = As Late As Possible As Soon As Possible Drum Buffer Critical Chain Capacity Constraint Buffer Cumulative Distribution Function Critical Path Critical Chain Project Management Evidence Reasoning Earliest Start Feeding Buffer Genetisch Algoritme Latest Start Nondeterministic Polynomial-time Hard Net Present Value Project Buffer Resource-Constrained Multi-Project Scheduling Problem Root Square Error Method Work in Process x

11 LIJST VAN FIGUREN Figuur 1: Positioning Framework...p5 Figuur 2: Hierarchical Framework. p5 Figuur 3: Model van het multi-project... p7 Figuur 4: Evaluatie boom.... p9 Figuur 5: CCPM methode p18 Figuur 6: De CCB en de DB.... p20 Figuur 7: CCPM voor een multi-project schema.. p21 Figuur 8 : Genetisch algoritme in multi-project planning. p23 Figuur 9: Resource conflicten in een project vs resource conflicten tussen projecten..... p26 Figuur 10: Project vs. taak prioriteiten... p27 Figuur 11: Meerdere beperkende factoren p32 Figuur 12: Eén versus meerdere beperkede factoren p33 Figuur 13: Project prioriteiten. p35 Figuur 14: Projecten na elkaar p36 Figuur 15: Slack p44 Figuur 16: ALAP schema. p45 Figuur 17: Bepalen CC. P48 Figuur 18: Parallelle feeding chains.. p50 Figuur 19: Illustratie van het CCB algoritme.. p55 Figuur 20: De gesplitste CCB. p56 Figuur 21: De gesplitste CCB (uitzondering). P57 Figuur 22: CCB bij éénzelfde starttijd.p58 Figuur 23: CCB bij éénzelfde eindtijd. p58 Figuur 24: Na een activiteit maximaal één CCB.. p59 Figuur 25: beperking bij de gesplitste buffer p60 Figuur 26: Negatieve starttijd.. p63 xi

12 Figuur 27: Slack consumeren na toevoegen CCB p67 Figuur 28: Visualisatie van de resultaten in een boxplot..p74 Figuur 29: Testen duurtijd bij variërende S p76 Figuur 30: Testen van seriële netwerken. p77 Figuur 31: Testen throughput bij variërende S p79 Figuur 32: Invloed van CCB op de throughput. P81 Figuur 33: Testen duurtijd bij variërende RC p82 Figuur 34: Testen throughput bij variërende RC p84 Figuur 35: Testen duurtijd bij variërende RF. p85 Figuur 36: Invloed van erg lage resource gebruiksgraad.. p86 Figuur 37: Testen throughput bij variërende RF. P87 Figuur 38: Throughput bij een lage RF..p88 Figuur 39: De invloed CCB op resultaten. p89 Figuur 40: invloed van DB op de resultaten.. p91 Figuur 41: Invloed van het opdrijven van de resources op de duurtijd. P94 Figuur 42: Invloed van het opdrijven van de resources op de duurtijd (excl. buffers) p95 Figuur 43: Invloed van het opdrijven van de resources op de throughput..p96 Figuur 44: Invloed van de niet-bottleneck resource... p98 Figuur 45: Invloed van een stijgende RC op de project prioriteiten methode p100 Figuur 46: Testen duurtijd bij variërende S (netwerk met meerdere beperkende resources) p102 Figuur 47: Testen duurtijd bij variërende S (netwerk met meerdere beperkende resources).. p103 Figuur 48: Testen duurtijd bij variërende RC/RF (netwerk met meerdere beperkende resources).p105 Figuur 49: Testen throughput bij variërende RC/RF(netwerk met meerdere beperkende resources)...p106 xii

13 1 INLEIDING Project management is het plannen, managen en controleren van een project om een succesvol resultaat op te leveren. Binnen project management focust deze thesis zich op het plannen van projecten. We onderzoeken namelijk het simultaan plannen van meerdere afhankelijke projecten. In de literatuur is het onderzoek naar het bekomen van een optimale multi-project planning nog beperkt. Tot op heden is Critcal Chain Project Management (CCPM) een vaak gebruikte methode om dit probleem het hoofd te bieden. Deze methode steunt op de Theory of Constraints van E.M. Goldratt en komt tot een multi-project planning door een beperkende factor aan te duiden en projecten te spreiden volgens deze factor. In de recente paper Critical chain and evidence reasoning applied to multi-project resource schedule in automobile R&D process van Shalin Yang en Lei Fu (2013) wordt een nieuwe methode voorgesteld. Deze aanpak combineert CCPM met een evaluatie techniek die bekend staat in de literatuur als Evidence Reasoning. Omdat de aanpak van Shalin Yang en Lei Fu nog weinig bekend is, beoogt deze thesis enerzijds de nieuwe aanpak te onderzoeken en te valideren op fictieve data. Anderzijds wensen we ook enkele suggesties tot verbetering voor te stellen. De focus van deze thesis gaat dus uit naar het implementeren en testen van het model. De literatuurstudie biedt ondersteuning hierbij. Deze thesis is opgebouwd uit drie delen: In de literatuurstudie geven we een probleemsituering en gaan we dieper in op methodes om tot een multi-project planning te komen. Hierbij schenken we bijzondere aandacht aan CCPM en evidence reasoning. In het volgende deel bespreken we de ER + CC methode van Shalin Yang en Lei Fu. Daarbij stellen we enkele assumpties in vraag en sommen we de onderzoekspunten op. Er wordt ook in detail uitgelegd hoe de methode werd geïmplementeerd in C++. Tot slot wordt meer uitleg gegeven over de verschillende testen die werden uitgevoerd en worden de resultaten besproken. We geven hierbij ook een overzicht van suggesties om het model te optimaliseren. 1

14 Deel I Literatuurstudie 2

15 2 LITERATUUR 2.1 PROBLEEM SITUERING In een omgeving waar veranderingen zich steeds frequenter voordoen, is het cruciaal om mee te evalueren met de omgeving. Voortdurend investeren is een absolute noodzaak om de competitieve positie niet te verliezen. Een stijgende nood om investeringsprojecten simultaan te kunnen plannen is een logisch gevolg hiervan. De beperkte beschikbaarheid aan middelen is hierin echter een belemmerende factor. Er dienen keuzes gemaakt te worden over hoe men de middelen aan de verschillende projecten zal toekennen, hierdoor wordt het succesvol kunnen inplannen van simultane projecten steeds belangrijker. Er wordt echter nog heel wat ruimte voor verbetering vastgesteld bij het plannen van meerdere investeringsprojecten. In het slechtste geval kiest de onderneming om projecten steeds zo snel mogelijk (ASAP) te starten zonder rekening te houden met andere projecten. Bijgevolg worden projecten vaak gelijktijdig uitgevoerd en indien er zich resources tekorten voordoen, probeert men dit probleem te verhelpen door de beschikbare resources te splitsen over de projecten heen. Dit vertaalt zich vaak in werknemers die aan meerdere projecten worden toegewezen. Het gevolg hiervan is multitasking die heel wat inefficiënties veroorzaakt omdat men voortdurend van het ene naar het ander project moet omschakelen. Indien er meer aandacht wordt geschonken aan de beperkende factor(en) is de onderneming er zich van bewust dat projecten moeten worden gespreid. Na een evaluatie van de projecten op belangrijkheid kent men middelen toe aan het project met de hoogste prioriteit. Projecten met een lagere prioriteit kunnen pas worden gestart indien er voldoende middelen ter beschikking zijn, wat vaak pas het geval is na het beëindigen van voorgaande projecten. Nadat een project is geselecteerd gebruikt men hulpmiddelen zoals PERT, CPM, Gantt charts en de Critical Chain methode om tot een planning te komen per project. Deze aanpak is zeer eenvoudig om te implementeren maar heeft echter cruciale negatieve gevolgen. Ten eerste maakt men geen onderscheid tussen resource conflicten in een project en deze tussen projecten. Daarnaast kent men middelen toe per project waardoor deze niet optimaal aangewend worden. Ten slotte houdt men geen rekening met de organisatie structuur van de projecten. Deze beperkingen van de huidige aanpak worden later meer gedetailleerd besproken in de sectie 3.1. De literatuur biedt een aantal planningsalgoritmen die de besproken problematiek aanpakken. Deze leiden tot een multi-project planning met besparing van tijd en/of kosten waarin men de overstap maakt van verschillende sequentiële optimalisaties naar één globale optimalisatie. Het efficiënt 3

16 overdragen van grondstoffen over de verschillende projecten heen en de optimalisatie van de gebruiksgraad van de beschikbare middelen zijn hierbij belangrijke objectieven. Een beschrijving van planningsalgoritmes worden besproken in deze sectie na een beschrijving van de multi project planning. 2.2 MULTI-PROJECT PLANNING HET POSITIONING FRAMEWORK De aangewezen methode om meerdere projecten simultaan te plannen is sterk afhankelijk van de eigenschappen van deze projecten. Projecten die sterk in competitie treden bij de toekenning van de beperkte hoeveelheid aan beschikbare middelen vereisen een meer geavanceerde planningsaanpak dan projecten die niet in competitie treden. Ook de mate van onzekerheid heeft onder andere een invloed. Bij een stijgende onzekerheid verhoogt de nood om proactief onzekerheid te incorporeren in de planning en volstaat het niet om reactief te herplannen. Hans, E.W., Herroelen, W., Leus, R., & Wullink, G. (2005) creëerden het Positioning Framework als hulpmiddel om de verschillende multi-projectomgevingen te onderscheiden (figuur 1). Het framework is gebaseerd op de dimensies variabiliteit en afhankelijkheid. Variabiliteit ontstaat door incomplete informatie en operationele onzekerheden. Afhankelijkheid geeft aan hoe sterk een project afhankelijk is van andere interne en externe gebeurtenissen. Verschillende positioneringen op de matrix suggereren een andere planningsaanpak. In de LL en LH kwadranten van het Positioning Framework is data aggregatie de aangewezen methode om meerdere projecten gelijktijdig te plannen. Door de data van de verschillende projecten samen te voegen, verkrijgt men een geaggregeerd planningsprobleem. Dit kan vervolgens opgelost worden met gelijkaardige technieken die gebruikt worden in single-project management. In de HL en HH kwadrant is data aggregatie niet voldoende. Door de hoge onzekerheid zijn complexere methodes noodzakelijk. Vandaar dat men gebruik maakt van operations research technieken om dit type projecten succesvol te kunnen plannen. Deze technieken houden rekening met de invloed van variabiliteit in het gebruik van grondstoffen of de verwachte duurtijd van een taak. 4

17 Figuur 1: Positioning Framework Uit: A hierarchical approach to multi-project planning under uncertainty van E.W. Hans, W. Herroelern, R. Leus, G. Wullink (2005) (table 1: A positioning framework for multi-project organisations ) Deze thesis focust zich op het simultaan plannen van niet onafhankelijke investeringsprojecten, onderhevig aan heel wat onzekerheid. We bevinden ons dus met andere woorden in het HH kwadrant. Afhankelijkheid Variabiliteit Laag Hoog Laag LL LH Hoog HL HH HET HIERARCHICAL FRAMEWORK Een goede multi-project planning, in gelijke welke planningsomgeving, moet tegelijk rekening houden met de set van doelen en beperkingen van de verschillende te plannen projecten. Een algemeen gebruikte techniek om met deze hoge planningscomplexiteit om te gaan is het planningsproces op te splitsen in meer beheersbare delen. Hiërarchische planning- en controlemethodes zijn dan ook een noodzakelijk hulpmiddel om projecten succesvol te managen. Het laat toe om doelen op verschillende managementniveaus te definiëren en helpt de gebruiker bij het bewaren van het overzicht. Het Hierarchical Framework van E.W. Hans et al., (2005) geeft een hiërarchie weer, toegepast op het multi-project planningsprobleem (figuur 2). Figuur 2: Hierarchical Framework Uit: A hierarchical approach to multi-project planning under uncertainty van E.W. Hans, W. Herroelern, R. Leus, G. Wullink (2005) (figure 1: Hierarchical framework ) 5

18 Het Hierarchical framework maakt onderscheid tussen 3 niveaus en 3 functionele planningsgebieden. Voor het opstellen van een planning hechten we vooral belang aan de Resouce Capacity Planning kolom. Lange termijn beslissingen worden genomen op het strategisch niveau. De capaciteit aan resources op de lange termijn wordt bepaald en het portfolio aan investeringsprojecten wordt beheerd. Op de middellange termijn worden projecten geselecteerd op het tactische niveau. Men bepaalt de nood aan middelen en kent deadlines toe. Gegeven deze keuzes dient er op het operationele niveau een planning worden opgemaakt. Deze planning beoogt het halen van de deadlines tegen een minimale kost, waarin wordt voldaan aan de opgelegde specificaties. Dit alles rekening houdend met de beperkte hoeveelheid aan beschikbare middelen. Operationele keuzes zijn typisch korte termijn beslissingen. In het vervolg van deze thesis focussen we ons vooral op het tactische en operationele niveau. De hoeveelheid aan beschikbare middelen op de lange termijn en de reeks aan mogelijke investeringsprojecten worden als gegeven beschouwd. Om de optimale planning zo goed mogelijk te benaderen is een nauwe interactie tussen de verschillende niveaus cruciaal. Zowel top-down als bottom-up informatiestromen zijn hiervoor nodig. Een goed model brengt dit in rekening en optimaliseert over verschillende niveaus heen MODELMATIGE VOORSTELLING Een basis beschrijving van het multi project probleem wordt in figuur 3 voorgesteld. Daarbij hebben we een set van K projecten, elk project l K bestaat uit m activiteiten en start en eindigt met een dummy. We beschikken over een set van R = {1,...r} hernieuwbare middelen met een maximale beschikbaarheid van T. De resource nood is steeds afhankelijk van de activiteit. Het probleem kan model matig voorgesteld worden aan de hand van een objective function en constraints. Dit model beoogt het optimaliseren van een evaluatie criterium, rekening houdend met enkele beperkingen: Minimaliseer/maximaliseer: Evaluatie criterium (bv. minimaliseer multi project duurtijd) Onderhevig aan: F i F j d j i, j (1) j t j,r,t T r,t r, t (2) F j d j 0 j (3) 6

19 F j stelt het hierbij tijdstip voor waarop activiteit j eindigt en met d j stellen we de duurtijd van activiteit j voor. t j,r geeft aan hoeveel middelen er nodig zijn van r om activiteit j uit te voeren. Constraint (1) modelleert de volgorde waarin de activiteiten uitgevoerd dienen te worden. Activiteit j kan ten vroegste starten na het beëindigen van activiteit i. Constraint (2) zorgt dat er rekening wordt gehouden met de beperkte beschikbaarheid aan middelen. De som van de resource nood van alle activiteiten mag niet groter zijn dan de beschikbaarheid. Omdat we uitgaan dat resources hernieuwbaar zijn moet deze constraint geldig zijn voor elk tijdstip t. Tot slot modelleert constraint (3) dat het tijdstip waarop een activiteit start niet negatief kan zijn. Merk op: Indien we afhankelijke projecten hebben waarbij de starttijd van een taak uit het ene project afhankelijk is van de eindtijd van een bepaalde taak uit een ander project kan dit eenvoudig worden gemodelleerd aan de hand van constraint (1). Alle taken van de K projecten kunnen dan worden geaggregeerd en tussen deze taken kunnen ook starttijd/eindtijd relaties worden vastgelegd. Zo kan activiteit i bijvoorbeeld een element zijn van project 1 en activiteit j een element zijn van project 2. Met constraint (1) geven we dan aan dat taak j pas kan starten na het beëindigen van taak i. Figuur 3: Model van het multi-project 7

20 2.3 BESCHIKBARE MODELLEN In deze sectie worden enkele modellen besproken die hulp bieden bij het tactische en operationele planningsniveau. Op het tactische niveau bespreken we evidential reasoning, een model om projecten te evalueren en vervolgens te selecteren aan de hand van een prioriteit score. Op het operationele niveau bespreken we de critical chain methode, een algoritme om taken te plannen. We sluiten deze sectie af met het bekijken van een relatief nieuwe techniek: het genetisch algoritme. Deze techniek kan ook worden toegepast op het multi-project planningsprobleem en integreert het tactische en operationele niveau. Later in deel II komt het model van Shalin Yan en Lei Fu aan bod die evidential reasoning combineert met CCPM. Merk nog op dat het oplossen van een RCMPSP een NP-hard probleem is. Het is met andere woorden helemaal niet eenvoudig om het optimum te vinden. Vandaar valt men vaak terug op heuristieken en probeert men op deze manier het optimum zo goed mogelijk te benaderen. Deze aanpak is veel eenvoudiger en een oplossing wordt sneller gevonden. Over de jaren heen is er heel wat onderzoek verricht naar betere oplossingsregels. Het gevolg hiervan is dat de heuristieken steeds beter het globaal optimum kunnen benaderen EVIDENTIAL REASONING HET MODEL Evidential reasoning beschreven door Yang, J., & Xu, D. (2002) in On the Evidential Reasoning Algorithm for Multiple Attribute Decision Analysis Under Uncertainty is een methode die hulp biedt bij het maken van beslissingen en werkt met een evaluatie boom (figuur 4). Deze boom wordt bekomen door basis attributen te definiëren van het te evalueren object. Deze worden vervolgens geëvalueerd. De evaluatie van de basis attributen wordt beheersbaar gemaakt door deze attributen op te splitsen in verschillende onderdelen op een lager level (algemene attributen). Indien de algemene attributen nog steeds moeilijk te evalueren zijn worden ook deze opgesplitst in meer beheersbare delen. Dit tot een level wordt bereikt waar de complexiteit voldoende is gereduceerd en men een score kan toekennen aan de attributen. Aan de hand van de evaluaties van de attributen op het laagste niveau en aggregatie helpt ER om tot een beslissing te komen binnen een omgeving van onzekerheid. 8

21 De methode maakt gebruik van zowel kwalitatieve als kwantitatieve input en is in staat om naast complete data ook incomplete data te verwerken. Het evaluatie framework wordt aan de hand van volgend voorbeeld besproken. 50% Evaluatie project 1 50% Aggregatie 40% Financiële opbrengsten 60% Fit met strategie 65% 35% Risico Verwachte return Match met missie Competitief voordeel Figuur 4: Evaluatie boom In dit eenvoudig voorbeeld evalueren we 2 basis attributen financiële opbrengsten (e 1) en fit met strategie (e 2). Beide bestaan uit 2 algemene attributen: e 1 = {e 1.1,e 1.2) en e 2 = {e 2.1,e 2.2}. Elk attribuut krijgt een wegingscoëfficiënt (0 w i 1), die de relatieve belangrijkheid in rekening brengt. In het voorbeeld zijn de basis attributen even belangrijk en werken we met w 1 = w 2 = 50%. We focussen in dit voorbeeld op het rechter deel van de hiërarchie en wensen een score voor het fit met strategie basis attribuut te bekomen. Het ER algoritme start met het laagste niveau van de hiërarchie en werkt bottem-up. In de eerste stap dient elk attribuut geëvalueerd te worden aan de hand van een score op verschillende evaluatiecriteria. In dit voorbeeld veronderstellen we slechts 3 criteria, namelijk H = {slecht (H 1), gemiddeld (H 2), goed (H 3)}. Veronderstel dat we voor match met missie over complete data beschikken. We zijn 50% zeker dat de match gemiddeld (H 2) zal zijn en 50% zeker dat de match goed (H 3) zal zijn. Voor competitief voordeel hebben we niet voldoende data om een volledige evaluatie te maken. We zijn voor 30% zeker dat het voordeel slecht (H 1) zal zijn en voor 60% zeker dat het voordeel gemiddeld (H 2) zal zijn. De evaluaties worden eenvoudig uitgedrukt via de factor Β n,i. Deze toont de score op evaluatiecriteria n voor attribuut i. In ons voorbeeld komen we dus tot volgende voorstelling: Β 1,e2.1 = 0 Β 2, e2.1 = 0,5 Β 3, e2.1 = 0,5. Β 1, e2.2 = 0,3 Β 2, e2.2 = 0,6 Β 3, e2.2 = 0. Er geldt dat n β n,i = 1 voor complete informatie en n β n,i < 1 voor incomplete informatie. 9

22 Als we nu de gewichten in rekening brengen kunnen we m n,i berekenen als volgt: m n,i = Β n,i x w i. Dit geeft aan hoe het algemeen attribuut i bijdraagt tot de evaluatie van het bovenliggende attribuut van evaluatiecriterium n. In ons voorbeeld draagt de Match met missie (e 2.1) voor 32,5% bij tot de evaluatie van het evaluatiecriterium goed (H 3) van het algemeen attribuut Fit met strategië. m 1, e2.1 = 0 x 0,65 = 0 m 2, e2.1 = 0,5 x 0,65 = 0,325 m 3, e2.1 = 0,5 x 0,65 = 0,325 m 1, e2.2 = 0,3 x 0,35 = 0,105 m 2, e2.2 = 0,6 x 0,35 = 0,21 m 3, e2.2 = 0 x 0,35 = 0 In het geval van incomplete informatie definiëren we m H,i als 1 - n m n,i of 1 w i n β n,i. Deze factor valt uiteen in onvolledigheid bij het evalueren (ṁ H,i ) en de mate waarin andere attributen kunnen bijdragen bij de evaluatie van bovenliggend attribuut (ḿ H,i). Er geldt dat m H,i = ṁ H,i + ḿ H,i en ṁ H,i = w i (1 w i n β n,i ) ḿ H,i = 1- w i In de volgende stap van het algoritme worden attributen geaggregeerd. Dit stelt ons in staat om een score te berekenen op de verschillende evaluatiecriteria van een bovenliggend attribuut aan de hand van zijn onderliggende attributen. m n,i(i) stelt de geaggregeerde score op evaluatiecriteria n voor, na de aggregatie van de eerste I(i) onderliggende attributen. m 1,I(2) is dan bijvoorbeeld de overtuiging dat de Fit met strategië slecht (H 1) zal scoren. Deze score bekomt men door Match met missie en Competitief voordeel te aggregeren. Indien we over incomplete informatie beschikken geeft ṁ H,I(i) weer hoe de eerste i geaggregeerde attributen bijdragen tot de onvolledigheid van het bovenliggend attribuut. ḿ H,I(i) geeft weer hoe de laatste i+1 geaggregeerde attributen een rol kunnen spelen bij de evaluatie van bovenliggend criterium. (m H,I(i) = ṁ H,I(i) + ḿ H,I(i)) De aggregatie procedure verloopt als volgt voor elk evaluatiecriterium. Stap 1: We starten met de aggregatie van 2 attributen. m n, I(2) = K I(i+1) [m n, i x m n, j + ṁ H, i x m n, j + ḿ H, i x m n, j + m n, i x ṁ H, j + m n, i x ḿ H, j] ṁ H, I(2) = K I(i+1) [ṁ H, i x ṁ H, j + ḿ H, i x ḿ n, j + ṁ H, i x ḿ H, j] ḿ H, I(2) = K I(i+1) [ḿ H, i x ḿ H, j] N N t=1 l=1,l t m l,j ] -1 met K I(i+1) = [1 - m t,i K I(i+1) is hierbij een normalisering factor die zorgt dat n m n,i(i+1) + m H,1 = 1. 10

23 Stap 2: Vervolgens aggregeren we de uitkomst van stap 1 met een volgend attribuut (i+1). m n, I(i+1) = K I(i+1) [m n, I(i) x m n, i+1 + m H, I(i) x m n, i+1 + m n, I(i) x m H, i+1] ṁ H, I(i+1) = K I(i+1) [ṁ H, I(i) x ṁ H, i+1 + ḿ H, I(i) x ṁ H, i+1 + ṁ H, I(i) x ḿ H, i+1] ḿ H, I(i+1) = K I(i+1) [ḿ H, I(i) x ḿ H, i+1] N N h=1,j t met K I(i+1) = [1 - t=1 m t,i(i) m j,i+1 ] -1 i= {1,2,, L-1} Stap 3: na aggregatie van alle L attributen bekomen we m n,i(l) en ṁ H, I(L). Deze dienen we terug te delen door hun gewicht om respectievelijk B n en B H te bekomen. B n vertelt ons meer over de score op evaluatiecriteria n voor het basis attribuut fit met strategie B H geeft de onvolledigheid aan voor dit zelfde basis attribuut. B n = m n, I(L) / (1 - ḿ H, I(L)) n =1,2,,N B H= ṁ H, I(L) / (1 - ḿ H, I(L)) Omdat we in het voorbeeld 2 basis attributen hebben dienen we ook nog Financiële opbrengsten en Fit met strategie te aggregeren om een score voor het project te bekomen. De input hiervoor werd bekomen uit vorige aggregaties van een lager level uit de evaluatie boom. Om verschillende evaluaties beter te kunnen vergelijken kan worden gewerkt met nut scores. Bij deze aanpak wordt aan elk evaluatiecriterium een nut score gekoppeld: u(h n). Voor ons voorbeeld gaan we uit van volgende nut scores: u(h 1) = 0, u(h 2) = 1, u(h 3) = 2. Indien we n evaluatiecriteria hebben H = {H 1,...H n) bekomt men de totale score via u(project i) = n=1 β n u(h n ). Projecten met een hogere totale nut score worden geprefereerd boven projecten met een lagere totale score. In geval van incomplete informatie is β H>0 en wordt er gewerkt met een nut score interval: [β n, (β n+β H)]. In het interval wordt aan de incomplete informatie de laagst mogelijke score gegeven om de ondergrens te bekomen. De bovengrens bekomt men door aan de incomplete informatie de hoogst mogelijke score te geven. Vervolgens berekent men ook nog het gemiddelde. N 1 U max(project i) = n=1 β n u(h n ) + (β N + β H )u(h n ). U min(project i ) = (β 1 + β H )u(h 1 ) + N n=2 β n u(h n ). U gem(project i ) = (u max(project i) + u min(project i))/2. Project i wordt verkozen boven project j indien u min(project j) > u max(project i). Bij gelijke scores van de interval limieten is men indifferent. Merk op dat er geen sluitende conclusies kunnen worden genomen indien er wordt gewerkt met de U gem scores. Volgende situatie zou zich namelijk kunnen N 11

24 voor doen: u gem(project i)> u gem(project j) maar u max(project j)>u min(project i). Hierbij zou men project i verkiezen boven project j op basis van de gemiddelden. Het is echter mogelijk dat project j toch de betere keuze zou geweest zijn aangezien dit project erg goed zou kunnen scoren op het criteria waarvoor we informatie te kort hebben. Er wordt in dit geval aangeraden om extra informatie te verzamelen. Merk op dat het ER algoritme ook kan worden gebruikt voor het bepalen van taak prioriteiten. In dit geval evalueren we een set van taken om tot een prioriteitenlijst te komen. In de volgorde van deze lijst kunnen de taken dan worden gepland. Voor de evaluatie van taken gebruikt men uiteraard wel andere evaluatiecriteria dan voor projecten. Deze criteria zijn meer gefocust op het operationele level. Criteria zoals element van CC, duurtijd, bottleneck taak zijn mogelijke evaluatiecriteria. Extra informatie hierover is terug te vinden in sectie AANDACHTSPUNTEN Het ER algoritme is een sterk hulpmiddel om een evaluatie te maken. Door te werken met een evaluatie boom kunnen moeilijk evalueerbare elementen worden opgesplitst in meer beheersbare onderdelen om een finale score op te maken. Daarnaast wordt er ook rekening gehouden met de mogelijke afwezigheid van informatie. Een sterk aandachtspunt is echter dat de kwaliteit van de uitkomst zeer sterk afhankelijk is van de kwaliteit van de input. De gebruiker moet in staat zijn om goede evaluatiecriteria te bepalen en deze correct te evalueren. Daarnaast spelen de wegingscoëfficiënten ook een grote rol in de uitkomst. Het is dus van belang om ook daar een correcte inschatting te kunnen maken. In de situatie waarin we verschillende projecten wensen te evalueren komen we voor een uitdaging te staan. De evaluatie van verschillende projecten is namelijk sterk afhankelijk van verschillende criteria. Zo zal voor een IT project compatibiliteit met het huidige systeem een zeer belangrijke factor zijn terwijl dit voor een R&D project helemaal niet het geval is. Indien we voor elk project een verschillende evaluatie boom gebruiken, zijn de eindevaluaties moeilijk vergelijkbaar. Indien we werken met slechts één evaluatie boom moeten we werken met meer algemeen toepasbare criteria en verliezen we nauwkeurigheid. Gegeven deze kritiek is het ER algoritme dus vooral nuttig voor het vergelijken van projecten die min of meer aan de hand van dezelfde criteria kunnen worden geëvalueerd en waarbij we dus één zelfde evaluatie boom kunnen gebruiken. Het opstellen van dergelijk evaluatie model is geen evidentie en buiten uit de scope van deze thesis. 12

25 Tot slot merken we nog op dat er vaak meerdere beslissingsnemers instaan voor het evalueren van attributen. Hierbij is het toekennen van een score subjectief. Manager A zal bijvoorbeeld sneller een score goed toekennen dan manager B. Het is daarom cruciaal dat de beslissingsnemers in communicatie treden of dat een manager eenzelfde attribuut van alle projecten evalueert. Op deze manier verminderen we de vertekening te wijten aan subjectiviteit van het evalueren CRITICAL CHAIN PROJECT MANAGEMENT In dit deel bespreken we welke stappen moeten worden ondernomen om de CCPM methode te implementeren en sommen we enkele voordelen op van deze methode. Vervolgens kijken we ook naar enkele punten van kritiek. Tot slot bestuderen we hoe CCPM kan worden gebruikt in een multiproject omgeving. Ook daar bekijken we zowel de voordelen als de beperkingen. Hiervoor werden volgende bronnen gebruikt: Vanhoucke, M. (2013). Project Management with Dynamic Scheduling, Barnes, R., Dvir, D., & Ras, T. (2003). A Critical Look at Critical Chain Project Management, Yaning, W., (2011). Study on Critical Chain Project Portfolio Management. En Dilmaghami, F. (2008). Critical Chain Project Management (CCPM) at Bosch Security Systems (CCTV) SINGLE PROJECT METHODE De critical chain methode is ontwikkeld door E.M. Goldratt (1997), de grondlegger van de Theory of Constraints. Deze theorie stelt dat elk systeem een beperkende factor heeft en het systeem kan worden verbeterd door de beperkende factor aan te pakken. CCPM is een uitbreiding op deze theorie en wordt in deze thesis gebruikt bij het maken van een planning. De methode bestaat uit 6 basis stappen. Deze stappen zijn hieronder besproken. 1. Gebruik agressieve tijdsinschattingen Taken zijn onderhevig aan onzekerheid, vandaar voegen de uitvoerders een veiligheidsmarge toe bij het inschatten van de verwachte duurtijd. Vaak komt het echter voor dat de taak kan worden uitgevoerd zonder de (volledige) consumptie van de marge. Indien we een planning maken inclusief deze marges, lopen we gevaar op het voorkomen van het Students Syndrome en de Parkinsons s Law. Het Students Sydrome stelt dat de uitvoerders pas starten wanneer iets echt dringend wordt. Parkinsons s Law stelt dat de uitvoerders het werktempo vertragen als ze weten dat de deadline zal gehaald worden om zo net alle voorziene tijd te vullen. 13

26 De veiligheidsmarge kan met andere woorden leiden tot inefficiënt werk waarbij meer tijd wordt gespendeerd om een taak uit te voeren dan nodig. Vandaar pleit Goldratt dat de project manager agressieve tijdsinschattingen moet gebruiken, waarbij de veiligheidsmarges niet worden toegevoegd aan de taken maar worden vervangen door een project buffer (zie stappen 4, 5 en 6). Indien we de kans op het halen van de deadline (y-as) en de voorziene duurtijd voor een activiteit (x-as) plotten (c.d.f.) komen we een distributie uit met een rechtse staart. Bij het aangeven van een hogere vereiste duurtijd, stijgt de kans op het halen van de deadline. Met veiligheidsmarges worden vaak zekerheiden van 95% gekozen. CCPM kiest echter voor een duurtijd zodat de deadline met 50% zekerheid kan worden gehaald. Er bestaat geen formule om deze omzettingen te doen en in de praktijk gebruikt men daarom vaak een heuristiek en vermindert men de tijdsduur, aangegeven door de uitvoerder, met een percentage van 33 tot 50 percent. 2. Creëer een ALAP schema Rekening houdend met de relatie tussen de taken en de nood aan resources per taak plannen we elke taak zo laat mogelijk. Het creëren van een ALAP schema heeft diverse voordelen. Het stelt cash-outs zo lang mogelijk uit en verhoogt daarmee de NPV. Verder minimaliseert het de WIP en de rework. Een cruciaal nadeel is echter dat elke activiteit kritiek wordt en er nood is aan het toevoegen van extra buffers. Meer uitleg over de feeding buffer kan terug gevonden worden in de stappen 4,5 en Bepaal de CC De Critical Chain wordt gedefinieerd als die set aan taken die leiden tot het langste pad na het in rekening brengen van de beperkte hoeveelheid grondstoffen. Door de resource constraints zal de CC steeds langer of gelijk zijn aan het CP. Het is mogelijk dat er meerdere critical chains kunnen gedefinieerd worden bij één en dezelfde planning. In dit geval moet een duidelijke keuze gemaakt worden. 4. Bepaal de nodige buffer posities Op het einde van het project voegen we een project buffer toe. Deze beschermt het project tegen vertragingen. Een feeding buffer beschermt de CC tegen vertragingen bij een reeks van niet-kritieke taken die worden opgevolgd door een kritieke taak. Tot slot worden ook resource buffers toegevoegd. Deze reserveren geen resources of tijd maar geven een waarschuwing dat 14

27 een kritieke taak binnenkort zal worden uitgevoerd. Op deze manier kunnen de kritieke grondstoffen al in gereedheid worden gebracht. 5. Bepaal buffer grootte Verschillende methodes kunnen worden gebruikt om de buffer grootte te bepalen. De meest gebruikte zijn de 50%-rule en de root square error method. In deze thesis gebruiken we de root square error method. Onder de assumptie dat taken statistisch onafhankelijk zijn kan men een buffer voorzien die kleiner is dan de som van de geëlimineerde veiligheidsmarges. Dit omdat aan risk pooling wordt gedaan. We kozen voor 50% zekerheid op het halen van de deadline van een taak (zie punt 1). Slechts de helft van de taken wordt verwacht een extra marge nodig te hebben. Als we dus alle veiligheidsmarges samen voegen tot een project buffer, kan een buffer die kleiner is dan de som van de geëlimineerde veiligheidsmarges voldoende bescherming bieden. Dit wordt ondersteund door volgende statistische regel: de standaard afwijking van de som van onafhankelijke variabelen is kleiner dan de som van standaardafwijkingen van onafhankelijke variabelen. Bij RSEM bekomt men de buffer grootte door bij een reeks van taken de variantie van de duurtijd op te tellen en vervolgens hiervan de vierkantswortel te nemen: buffer grootte = (σi) 2. i We veronderstellen hierbij dat de covariantie gelijk is aan nul. Voor de project buffer neemt men alle taken op de CC als input. Voor de feeding buffer is het bepalen van de grootte iets complexer. Dit omdat meerdere parallelle feeding chains veel voorkomend is. Het bepalen van een reeks taken die hier als input dient voor de RSEM methode wordt uitgelegd in sectie Indien er geen data beschikbaar zijn over de grootte van de varianties gebruikt men vaak een vuistregel om deze in te schatten. Deze regel stelt dat de standaard afwijking gelijk is aan de helft van de duurtijd en dit wordt ook in deze thesis verondersteld. Merk op dat dit eerder een ruime inschatting is. Om buffer groottes nauwkeuriger te kunnen inschatten is meer data over de standaard afwijking nodig. 6. Voeg buffers toe aan de planning Na het uitvoeren van de vorige stappen kunnen de buffers worden gepland in het ALAP schema. Een vaak gebruikte assumptie hierbij is dat de buffers geen resources reserveren en de CC niet verandert na het toevoegen van de buffers. Deze assumpties worden toegepast om de complexiteit van het plannen te reduceren. 15

28 Na deze zes stappen bekomen we een planning volgens de CCPM methode. Bij het uitvoeren van het CCPM schema wordt gewerkt met een Roadrunner Mentality. Deze stelt dat we steeds zo snel mogelijk starten met de volgende activiteit. Indien een activiteit dus vroeger vervolledigd is dan verwacht beginnen we meteen met de volgende activiteit en wordt er niet gewacht tot de geplande starttijd van de volgende activiteit wordt bereikt. Door de agressieve tijdsinschattingen is de kans erg groot dat buffers worden geconsumeerd. Een goede opvolging van deze consumptie is noodzakelijk. Indien er reeds te veel van de buffer is geconsumeerd dient men de planning bij te sturen. Het opvolgen van buffer consumptie en het bijsturen van het schema krijgt de term buffer management. Buffer management valt echter buiten de scope van deze thesis De voordelen van deze methode zijn de volgende: o o o o Een kortere totale duurtijd van het project door aan risk pooling te doen bij het bufferen en het elimineren van veiligheidsmarges op taakniveau. Het opvolgen van de buffer consumptie vereenvoudigt het opvolgen van het project en legt risico s bloot. Het optimaliseert de NPV. Minimaliseert WIP en rework kosten. Hoewel velen het werk van E.M. Goldratt, (1997) als baanbrekend beschouwen, worden er ook kritiek geuit op de methode. Dit wordt hieronder besproken. PUNTEN VAN KRITIEK Een verkorte project duurtijd kan onder andere door agressieve inschattingen worden bekomen, maar het bepalen van de agressieve tijdsinschattingen door de project manager is geen evidente taak. Het is heel moeilijk om de grootte van de veiligheidsfactor te bepalen. Onderzoek toont ook aan dat niet iedereen automatisch een veiligheidsmarge toevoegt aan hun duurtijd inschattingen. De huidige heuristiek die een 33-50% duurtijd reductie voorstelt is ook absoluut niet accuraat. Het kan zelf leiden tot het opdrijven van veiligheidsmarges door de uitvoerders indien ze weten dat hun inschatting later met deze factor wordt gereduceerd. Een nieuwe manier van duurtijd inschattingen is dus nodig waarbij er een dialoog is tussen project manager en uitvoerder. De project manager moet inzicht krijgen in de grootte van de veiligheidsmarge en de uitvoerder in het bestaan van de project buffer die vertragingen opvangt. 16

29 Na het toekennen van een duurtijd aan de taken hangt de kwaliteit van het schema sterk af van de CC. Het bepalen van de CC is echter wel een complexe oefening waarvoor geen éénduidig oplossingsalgoritme bestaat. Vandaar valt men vaak terug op heuristieken die de optimale oplossing benaderen. Aangezien CCPM geen extra informatie geeft over het gebruik van heuristieken kan men tot een range van verschillende oplossingen komen al naar gelang welke heuristiek er wordt gebruikt. Daarbovenop kan de CC veranderen tijdens de uitvoering van het project door veranderingen in de beschikbaarheid aan grondstoffen of als gevolg van buffer consumptie. Bij deze CC verandering is een herplanning van de buffers opnieuw noodzakelijk. Het is dus duidelijk dat een hoge flexibiliteit noodzakelijk is bij de CCPM methode. Daarbij kan software de nodige hulp bieden. Samengevat, indien een organisatie overstapt naar het plannen van projecten via de CCPM methode is er nood aan een cultuur verandering en dient men te investeren in de nodige software. De huidige software is echter wel beperkt in beschikbaarheid en heeft heel wat beperkingen. De software is tevens relatief duur en project managers moeten leren werken met deze nieuwe methodes. Op het vlak van cultuur dienen de duurtijden van de taken anders bepaald te worden. Veiligheidsmarges worden geëlimineerd en vervangen door buffers. Het concept deadline wordt vervangen door verwachte tijd van oplevering en van zodra een taak beëindigd is moet er gestart worden met de volgende taak. Multitasking moet ook worden vermeden MULTI PROJECT METHODE Zoals eerder besproken is er een stijgende nood om te investeren in meer dan één project ter gelijk. Bedrijven beschikken over een portfolio aan projecten die men graag simultaan wenst uit te voeren. De beschikbare hoeveelheid aan resources zijn hierbij echter een beperkende factor en de verschillende projecten treden in conflict bij de toekenning van de resources. Een goede planningstechniek moet hulp bieden bij dit probleem. Voor het simultaan plannen van meerdere projecten met een beperkte beschikbaarheid aan resources werkt CCPM volgens hetzelfde principe. De resource die het systeem beperkt wordt geïdentificeerd en krijgt de naam bottleneck resource. Deze resource kan worden bepaald door na te gaan of vertragingen van taken die nood hebben aan deze resource, negatieve gevolgen hebben voor de duurtijd van alle andere projecten. Leach (2005) bepaalt de bottleneck resource als de 17

30 resource die de langste tijd op de CC tijd controleert. Merk op dat we de regel om de bottleneck resource te bepalen later in deze thesis onderzoeken. Taken die nood hebben aan deze bottleneck resource vormen de bottleneck taken. CCPM spreidt deze taken bij het plannen van de projecten om resource conflicten van de bottleneck resource te vermijden. Figuur 5 illustreert deze manier van werken. Figuur 5a: CCPM methode Figuur 5b: CCPM methode 18

31 In deze vereenvoudigde situatie plannen we 2 projecten. We hebben 4 eenheden van resources 1 en 5 eenheden van resource 2. (De nood aan resources wordt respectievelijk voor resource 1 en 2 aangeduid tussen de haakjes). Voor project 1 vormt de CC. Voor project 2 vormt 1-2 de CC. Er wordt verondersteld dat resource 1 de kritieke resource is en we maken abstractie van buffers. De kritieke taken zijn aangeduid in het blauw. Op figuur 5b maken we geen gebruik van de CCPM methode en starten beide projecten gelijktijdig. Bij de start van activiteit 2 hebben we te weinig resources om beide taken in parallel te vervolledigen. Resources worden dus gesplitst over de projecten heen. Omdat we slechts half zoveel resources toekennen op project niveau verdubbelt de geplande duurtijd van taak 2. Daarbovenop moet nog wat extra tijd worden voorzien ten gevolge van inefficiënties te wijten aan multitasking (aangeduid in het rood). Op figuur 5a gebruiken we CCPM. We identificeren we eerst de kritieke taken. Deze worden bij het plannen steeds voorzien van voldoende resources en worden met andere woorden gespreid. Andere taken worden rond deze ketting van kritieke taken gepland. Door op deze manier te werken vermijden we multitasking en de inefficiënties die daaruit voort stromen. De duurtijd om alle projecten te vervolledigen is bijgevolg korter. Een ander voordeel is dat de project throughput verhoogt. Project 1 is sneller klaar dan in de planning zonder het gebruikt van CCPM. Merk op: in het vervolg van deze thesis plaatsen we de uitleg bij de figuren steeds schuin. Op deze manier is het voor de lezer duidelijk welke tekst bij de figuur hoort. Zoals het voorbeeld illustreert stapt een goede multi-project planning af van de praktijk om projecten zo snel mogelijk te starten omdat dit negatieve gevolgen heeft voor de project throughput en de totale duurtijd. Het is beter om bottleneck taken te spreiden. Om de ketting van bottleneck taken te beschermen tegen vertragingen worden twee extra type buffers voorzien. De Capacity Constraint Buffer (CCB) beschermt de bottleneck resources tegen vertragingen in voorgaande projecten. De buffer wordt geplaatst tussen 2 bottleneck taken van verschillende projecten en is dus vergelijkbaar met een project buffer die enkel de bottleneck taken beschouwt. Voor de grootte gebruikt men 25%-30% van de duurtijd van de ketting aan bottleneck taken van het project die de bottleneck resource doorgeeft aan het volgende project. Een duidelijke verklaring van dit percentage is niet terug te vinden in de literatuur. Vandaar zal deze 30%-regel later in deze thesis verder onderzocht worden. Indien niet-bottleneck activiteiten eerst moeten vervolledigt zijn alvorens een bottleneck activiteit kan starten moet een Drum buffer (DB) worden voorzien. Deze verhindert dat een bottleneck taak 19

32 moet wachten omdat de voorgaande niet-bottleneck taak een vertraging heeft opgelopen. Wachttijd voor de beperking van het systeem, betekent wachttijd voor het hele systeem en dit willen we vermijden. De DB is noodzakelijk omdat niet-bottleneck taken ALAP zijn gepland. De grootte wordt op dezelfde manier bepaald als de feeding buffer via RSEM. Figuur 6 illustreert het gebruik van buffers: Figuur 6: De CCB en de DB In deze eenvoudige illustratie plannen we 2 projecten. De bottleneck taken zijn aangeduid in het blauw. Tussen project 1 en project 2 hebben we een CCB gepland met een duurtijd gelijk aan 30% x [duurtijd activiteit 1 (project 1) + duurtijd activiteit 2 (project 1)]. Een DB werd voorzien in project 2 tussen taak 3 en taak 4. Merk op, doordat we deze DB hebben toegevoegd kan activiteit 3 (project 2) niet meer ALAP starten. Extra uitleg over het bepalen van de CCB/DB nood en het toevoegen van deze buffers aan het schema is terug te vinden in de secties tot en met Samengevat dienen we dus eerst de beperkende factor te bepalen. Vervolgens spreiden we de projecten volgens de beschikbaarheid aan de beperkende factor. Om te bepalen aan welk project we als eerste de bottleneck resources toekennen werken we met project prioriteiten. Na een evaluatie van de verschillende projecten verloopt het toekennen van de bottleneck resource volgens een aflopende prioriteit. Een techniek die hiervoor aangewend kan worden is Evidential Reasoning (ER). Dit wordt uitvoerig besproken in sectie Het eindresultaat van de planningsfase is dus een aaneenschakeling van critical chains waarbij het project met de hoogste prioriteit het eerst wordt gepland. Dit wordt in figuur 7 geïllustreerd. 20

33 Figuur 7: CCPM voor een multi-project schema Bij het uitvoeren van het CCPM schema wordt ook hier gewerkt met een Roadrunner Mentality en dient men aan buffer management te doen. Het toepassen van de CCPM methode voor het simultaan plannen van meerdere projecten kan leiden tot de volgende voordelen: o o o Een hogere throughput van projecten. Kortere multi-project duurtijd. Beter inzicht in hoe vertragingen van het ene project, de duurtijd van ander projecten kunnen beïnvloeden. PUNTEN VAN KRITIEK De CCPM methode in een multi-project omgeving draait volledig rond het vinden van de beperkende factor. Eenmaal gevonden, bepaalt de beperkende factor de multi-project duurtijd en voorzien we buffers om de gebruiksgraad van deze factor te maximaliseren. Het bepalen van de bottleneck resources is echter geen evidente taak: Ten eerste is er nog geen sluitende regel om deze factor te bepalen. Het gebruik van verschillende methodes om de bottleneck resource te bepalen leidt tot een variërende uitkomst en bijgevolg tot een sterk variërende CCPM multi-planning. Ten tweede kan de beperkende factor veranderen over de tijd heen of kunnen er ook meerdere beperkende factoren zijn. Daarnaast is het bepalen van de grootte van de CCB nog weinig onderbouwd. 21

34 2.3.3 GENETIC ALGORITHM De paper A genetic algorithm for the resource constrained multi-project scheduling problem van J.F Gonçalves, J.J.M. Mendes, M.G.C. Resende (2007) maakt gebruik van een genetisch algoritme om tot een multi-project planning te komen. Hierbij worden m projecten gepland die samen bestaan uit n taken. De multi-project planning kan worden bekomen met behulp van een planningsalgoritme en een set van planningsregels. Deze regels worden weergeven via een chromosoom die bestaat uit 2n+m genen. Chromosoom = {gen 1,..., gen n,gen n+1,...,gen 2n,gen 2n+1,...,gen 2n+m}. In de paper van J.F Gonçalves, J.J.M. Mendes, M.G.C. Resende worden de eerste n genen gebruikt om de prioriteit van elke activiteit te bepalen, genen n+1 tot 2n om de toegestane delay times van de overeenstemmende activiteit te bepalen. De laatste m genen geven de starttijden van de projecten aan. De grootte van de populatie wordt gecontroleerd door de toegestane delay times van elke activiteit. Hoe strenger men de maximale delay times definieert hoe kleiner de populatie. Om vervolgens het genetisch algoritme te starten moet worden vertrokken van een initiële set van chromosomen. Voor elk van deze chromosomen wordt een bijhorende multi-project planning opgesteld (door gebruik te maken van een planningstechniek zoals bijvoorbeeld CCPM). Om inzicht te krijgen in de kwaliteit van het verschillende schema s evalueren we deze op enkele performance measures en berekenen we de fitness value. Deze value is een gewogen gemiddelde van de verschillend performance measures en stelt ons in staat om de multi-project schema s te ordenen van goed naar slecht. Voorbeelden van enkele performance measures zijn work in proces, geplande delays en de totale multi-project duurtijd. Gegeven de set van chromosomen en de bijhorende fitness values wenst het algoritme aan de hand van selectie, cross-over en mutatie te evalueren naar een populatie met betere fitness values. Na het sorteren worden de beste oplossingen gekopieerd naar de volgende generatie, de slechtste oplossingen worden vervangen door willekeurige chromosomen. Deze willekeur voorkomt premature convergentie en doet dienst als de mutatie stap. De overige chromosomen bekomt men via crossovers van oplossingen willekeurig gekozen uit de groep van de beste fitness values en oplossingen willekeurig gekozen uit de volledige huidige populatie. 22

35 Na voldoende iteraties worden marginale verbetering van de fitness value steeds kleiner. Bij het bereiken van een stopcriterium bekomt men een oplossing die het optimum al zeer goed benadert. Eventueel kan een local search algoritme nog worden aangewend om neighbor solutions te bestuderen en via de hill climbing methode het optimum nog beter te benaderen. Merk op: het hierboven beschreven genetisch algoritme evalueert steeds naar een betere oplossing door de chromosomen aan te passen. Het is echter dus belangrijk dat het algoritme werkt met een goede planningstechniek om tot een kwalitatief multi-project schema te komen omdat deze ongewijzigd blijft. Figuur 8 vat het algoritme nog eens samen. Figuur 8 : Genetisch algoritme in multi-project planning uit: A genetic algorithm for the resource constrained multi-project scheduling problem van van J.F Gonçalves, J.J.M. Mendes, M.G.C. Resende (figure 2: Architecture of the new approach ) 23

36 Deel II Het ER + CC model 24

37 3 COMBINATIE VAN EVIDENCE REASONING EN CCPM In dit deel bespreken we de paper Critical chain and evidence reasoning applied to multi-project resource schedule in automobile R&D process van Shalin Yang en Lei Fu (2013). Het valideren en verbeteren van deze nieuwe aanpak vormt het hoofddoel van deze thesis. Het model werd ontwikkeld voor het R&D proces binnen de auto-industrie. Dit is een omgeving waarin projecten sterk afhankelijk zijn van elkaar en waar er heel wat onzekerheden opduiken. Hoewel het Positioning Framework (zie figuur 1) van E.W. Hans et al. (2005) suggereert om OR technieken te gebruiken in een HH omgeving, wordt door Shalin Yang en Lei Fu een planningsmethode voorgesteld die steunt op data aggregatie en het gebruik van ER en CCPM. Na het aggregeren van de verschillende te plannen projecten, werkt het model op het tactische niveau met taak prioriteiten. Deze kunnen worden bepaald aan de hand van de nut score bekomen via evidential reasoning. Op het operationele niveau worden de verschillende projecten gepland, met behulp van de critical chain methode. Opnieuw is het uiterst belangrijk om informatie uit te wisselen tussen de verschillende hiërarchische niveaus. De prioriteiten bepaald in het evidential reasoning algoritme, vormen een belangrijke input bij het opstellen van de multi-project planning. In wat volgt bespreken we eerst de kritiek van Shalin Yang en Lei Fu op CCPM. Vervolgens wordt de ER + CC methode stapsgewijs uitgelegd. Daarna bestuderen we de assumpties en komen we tot de onderzoeksvragen. Op deze onderzoeksvragen wordt een antwoord geformuleerd in deel III van deze thesis. 3.1 BEPERKINGEN VAN DE HUIDIGE METHODE CCPM, zoals beschreven in sectie wordt sterk gewaardeerd omwille van zijn robuustheid. De buffers die in de planning worden voorzien beschermen het schema tegen variabiliteit. Hierdoor is de methode uiterst geschikt in een onzekere, complexe omgeving. De methode verhoogt ook de thoughput en door te werken met een project prioriteiten worden de strategisch belangrijkste projecten het eerst vervolledigd. Voor het opstellen van een planning binnen een multi-project omgeving worden er door Shalin Yang en Lei Fu echter nog gebreken geïdentificeerd: Ten eerste maakt CCPM geen onderscheid tussen resource conflicten in een project en deze tussen projecten. CCPM focust louter op resource conflicten tussen projecten. Eenmaal deze zijn opgelost (door de bottleneck taken te spreiden) focust de methode op resource conflicten binnen het project. 25

38 Het identificeert de CC per project en maakt een ALAP schema. We werken met ander woorden in twee stappen waar we twee keer resource conflicten oplossen op een ander niveau. Figuur 9 illustreert dit. Daarnaast kent men middelen toe per project volgens project prioriteiten waardoor deze niet optimaal aangewend worden. Doordat middelen per project worden toegekend houdt de ene planning te weinig rekening met de resource nood van de andere planning. Dit leidt tot een suboptimale situatie die in figuur 10 wordt verduidelijkt. Tot slot houdt men geen rekening met de organisatie structuur van de projecten. Figuur 9: Resource conflicten in een project vs resource conflicten tussen projecten Op de bovenste figuur zien we hoe de CCPM methode 2 projecten plant door de bottleneck resource (aangeduid in het blauw) te spreiden. Doordat we resources op project level toekennen en twee keer een ALAP schema opstellen komen we tot een suboptimale situatie. Indien we namelijk rekening houden met de resource nood van andere projecten kunnen we tijdswinst boeken door sommige taken ASAP te plannen. Dit wordt aangetoond in onderste figuur. Door taak 3 van project 1 ASAP te plannen kunnen we sneller starten met project 2 omdat de bottleneck resource sneller vrij komt. Dit leidt tot een uiteindelijke tijdswinst. In deze situatie is de tijdswinst even groot als de slack van taak 3 van project 1. 26

39 Figuur 10a: Project vs. taak prioriteiten Figuur 10b: Project vs. taak prioriteiten Op de figuur 10a werd de CC methode toegepast waarbij resources worden toegekend op basis van project prioriteiten. De bottleneck resource is hierbij aangeduid in het blauw. Dit leidt tot een totale duurtijd van 20 tijdseenheden. Project 1 heeft een geplande eindtijd van 12 tijdseenheden. Het is echter wel duidelijk dat in deze situatie die bottleneck resource niet efficiënt wordt aangewend. De eerste bottleneck taak start pas nadat de bottleneck resource 4 tijdseenheden ongebruikt ligt te wachten. In figuur 10b schakelen we over op taak prioriteiten in plaats van project prioriteiten. Hierbij kreeg taak 1 van project 2 de hoogste prioriteit, daarna plannen we taak 2 van project 1 en vervolgens de andere taken. Deze situatie leidt tot een efficiënter gebruik van de bottleneck resource en bijgevolg tot een daling van de geplande eindtijd met 4 tijdseenheden. Een vereiste van deze tijdswinst is dat de taak prioriteiten op een efficiënte manier kunnen worden toegekend. 27

40 Merk op: we zien hier dat het werken met taak prioriteiten negatieve gevolgen heeft voor de throughput van de projecten. Project 1 heeft nu een eindtijd die 2 tijdseenheden later is dan de eindtijd bij het gebruiken van project prioriteiten. Rekening houdend met deze gebreken stelden Shalin Yang en Lei Fu een nieuwe methode voor die op twee axioma s steunt. Ten eerste werken we met taak prioriteiten. Ten tweede staan we geen multitasking toe. Grondstoffen worden met andere woorden niet gesplitst over meerdere taken op eenzelfde moment. 3.2 BESCHRIJVING VAN DE NIEUWE ER + CC METHODE Volgend schema geeft stapsgewijs aan hoe de methode van Shalin Yang en Lei Fu in zijn werk gaat. 1. Creëer een evaluatie model op projectlevel 2. Pas ER algoritme toe en creëer project prioriteiten 3. Pas CCPM voor het multi-project toe 4. Identificeer taken die resource conflicten hebben tussen projecten 5. Identificeer de bottleneck resource 6. Creëer een evaluatie model op taaklevel 7. Creëer taak prioriteiten aan de hand van het ER algoritme 8. Spreid projecten volgens de taak prioriteiten* 9. Voeg capacity constraint buffers toe 10. Voeg drum buffers toe 11. Beëindig de planning *Merk op indien het ER algoritme voor het creëren van taak prioriteiten tot een onmogelijke planning leidt dient het schema te herhalen vanaf stap 7. 28

41 Via deze methode aggregeren we de taken van de verschillende projecten en kennen we prioriteiten toe op taak level in plaats van op project level. Dit zorgt dat we nu wel onderscheid kunnen maken tussen resource conflicten in een project en tussen projecten. Het opstellen van de taak prioriteitenlijst gebeurt in twee verschillende stappen via het ER algoritme. Omdat evaluatiecriteria voor taken meer gefocust zijn op operationele maatstaven wordt eerst CCPM toegepast aan de hand van project prioriteiten zoals beschreven in sectie Aan de hand van dit schema kan de bottleneck resource worden bepaald als de resource die de langste tijd op de CC controleert. Ook kunnen we dit multi-project schema gebruiken om operationele evaluatiecriteria te evalueren. De criteria die in dit model worden gebruikt zijn de volgende: o o o o o Prioriteit van het project waartoe de taak behoort. Gebruik van de bottleneck resource door de taak. Is de taak een element van de CC. Duurtijd van de taak. Starttijd en eindtijd prioriteit. Eventueel kan het ER algoritme ook rekening houden met strategische belangen van bepaalde taken of de organisatie structuur van de projecten. Na het bekomen van een prioriteitenlijst van de verschillende taken wordt een planning opgesteld. Hierbij worden taken gepland in de volgorde van de lijst. De bottleneck taken worden steeds ASAP gepland en niet-bottleneck taken ALAP. Hierdoor worden de middelen optimaal aangewend zoals eerder beschreven in figuur 9. Na het toevoegen van buffers bekomen we een finale multi-project planning. Deze zou een kortere totale duurtijd moeten hebben en een even grote kans op het halen van de deadlines. Later in deel III wordt nagegaan als dit ook werkelijk het geval is. Een gedetailleerde beschrijven van de implementatie van de methode is terug te vinden in sectie 5 (schema 2). 29

42 3.3 ASSUMPTIES EN ONDERZOEKSVRAGEN Samengevat elimineert deze nieuwe methode de aangehaalde nadelen van de CCPM methode die werden besproken in sectie 3.1. Daarvoor wordt er echter wel op enkele assumpties gesteund: 1. Afhankelijke projecten: de uitkomst van het ene project heeft invloed op het andere project. In deze situatie kunnen vaak positieve cashflows pas worden gegenereerd nadat alle projecten die invloed hebben op elkaar zijn verwezenlijkt. 2. Het is mogelijk om een evaluatiemodel op te bouwen: aan de hand van evaluatiecriteria kunnen we een prioriteitenlijst opstellen met behulp van het ER algoritme. Er wordt verondersteld dat verschillende projecten toch via één evaluatiemodel kunnen worden vergeleken. 3. Agressieve tijdsinschattingen: de verwachte duurtijd van een activiteit kan worden ingeschat exclusief een veiligheidsmarge. 4. Geen onderbreking: als een taak start wordt deze volledig afgewerkt. 5. Geen multitasking: resources mogen enkel gebruikt worden voor de taak waartoe ze zijn toegekend (op een bepaald tijdstip). 6. Feeding buffers hebben geen invloed op de CC: er wordt verondersteld dat feeding buffers geen resources reserveren en deze buffer wordt enkel ingevoegd indien dit geen invloed heeft voor de CC. 7. Buffers reserveren geen resources: er wordt verondersteld dat project buffers en drum buffers geen nood aan resources hebben. Enkel de CCB reserveert de hernieuwbare resources. 8. De bottleneck resources is de resource die de langste tijd op de CC controleert. 9. De CCB grootte wordt bepaald als 30% van de duurtijd van de ketting bottleneck taken die uitmondt in een bottleneck taak van een ander project. 10. Er is slechts 1 duidelijk beperkende resource. Heel wat van deze assumpties zijn standaard assumpties die in vele planningsmethodes worden gebruikt. Zo worden assumpties 3, 4, 5, 6 en 7 ook vaak gebruikt in de CCPM methode. Omwille van de algemene aanvaarding worden deze assumpties ook aangenomen in deze thesis. Assumpties 1, 2, 8, 9 zijn specifiek voor het model van Shalin Yang en Lei Fu. In deze thesis stellen we vooral assumpties 8, 9 en 10 in vraag. 30

43 Assumptie 8: Als de critical resource overgedragen wordt van het ene naar het andere project, wordt er een buffer voorzien om vertragingen op te vangen (de capacity constraint buffer). Voor de grootte hiervan wordt een range van 25% tot 30% voorop gesteld. Deze range is echter intuïtief en steunt niet op een experimentele basis. Vandaar dient hier kritisch naar gekeken te worden. Graag wensen we te onderzoeken wat een meer gestaafde regel zou kunnen zijn om de buffer grootte te bepalen. Assumptie 9: In het algoritme wordt de bottleneck resource bepaald als deze die de langste tijd op de CC controleert. Dit is echter een betwistbare assumptie. Er kan zich namelijk een situatie voordoen waar we veel van resource 1 ter beschikking hebben maar slechts een beperkte hoeveelheid van resource 2. Indien veel taken op de CC resource 1 nodig hebben kan deze onterecht als de beperkende factor (of de bottleneck resource) worden aangeduid. Assumptie 10: zoals eerder aangehaald in sectie (punten van kritiek) wensen we te onderzoeken wat de invloed is van meerdere beperkende factoren. Verder bekijken we ook assumptie 2 met het oog op optimalisatie. We wensen de invloed van een variërende ER output te bestuderen op de multi-project planning. Samengevat wensen we volgende zaken te onderzoeken: 1. Wat is het voordeel van het ER + CC model in vergelijking met andere planningsmethodes? 2. Wat is de invloed van meerdere beperkende resources op de multi-project planning? 3. Hoe bepalen we best de bottleneck resource? 4. Hoe bepalen we best de grootte van de CCB? 5. Wat is de sensitiviteit van de ER uitkomst op het multi-project Alvorens we een antwoord zoeken op deze onderzoeksvragen spenderen we bijzondere aandacht aan de invloed van het overstappen naar een multi-project met meerdere beperkende factoren. Daarna geven we een uitgebreide beschrijving van het uitgevoerde experiment en de implementatie van het model in C++. 31

44 3.4 MEERDEER BEPERKENDE FACTOREN Bij het plannen van één project heeft de overstap naar meerdere beperkende factoren weinig invloed. Bij een multi-project planning daarentegen, hebben meerdere beperkende factoren een invloed op het bepalen van de bottleneck resource en het bufferen van de bottleneck taken. In het 'ER + CC model van Shalin Yang en Lei Fu hebben we slechts één bottleneck resource en is de gebruiksgraad typisch hoog. Door de planningsmethode (ASAP) kunnen we duidelijk de overgang van deze resource over de projecten heen definiëren. Er zijn geen resource conflicten van niet-bottleneck taken waardoor de bottleneck taak nooit hoeft te wachten en deze steeds uitmondt in een aaneensluitende volgende bottleneck taak. In de literatuur vernemen we echter dat het voorkomen van één duidelijk beperkende factor zelden voorkomt. Daarom houden we bij het bepalen van de CCB rekening dat op sommige momenten andere resources het systeem kunnen beperken en dat de bottleneck resource dus moet wachten op het vrijkomen van de niet-bottleneck resource. Figuur 11 illustreert dit. Figuur 11: Meerdere beperkende factoren In dit voorbeeld is er nood aan 2 resources. Deze worden aangegeven tussen de haakjes. Resource 1 vormt hier de bottleneck resource. Bottleneck taken worden aangegeven in het blauw. Doordat er tussen tijdstip 4 en 7 een resource conflict optreed van de niet-bottleneck resource werd taak 2 verlaat in de tijd. Dit heeft als gevolg dat we op de planning taak 4 pas kunnen starten vanaf tijdstip 10. De bottleneck kan hierdoor niet gebruikt worden in het interval [7-10]. Indien de bottleneck resource een periode ongebruikt is door het voorkomen van niet-bottleneck resource conflicten, moet dit in rekening worden gebracht bij het bepalen van de CCB grootte. We mogen namelijk geen CCB voorzien indien ongebruikte bottleneck resources worden doorgeven naar 32

45 een ander project. Om de situatie te testen waarin er niet één duidelijk beperkende factor is bij het plannen van meerdere projecten houden we bij het bepalen van de CCB rekening met het feit dat er meerdere beperkende factoren kunnen zijn. Dit verhoogt de complexiteit omdat we geen duidelijke opeenvolging van bottleneck taken kunnen definiëren. Een verduidelijk is gegeven in figuur 12 In deze figuur tonen we op de x-as de tijd aan en op de y-as de nood aan de bottleneck resource van elke activiteit. Meerder beperkende facoren Eén beperkende facor Figuur 12: Eén versus meerdere beperkede factoren Deze figuur stel 2 verschillende multi-projecten voor elk bestaande uit 3 projecten. Op de rechter figuur duiken er heel wat conflicten op bij de niet-bottleneck resources. Daardoor zijn er veel periodes waar de bottleneck resource ongebruikt ligt te wachten. Het identificeren van een duidelijke ketting van bottleneck taken en het toevoegen van de nodige Capacity Constraint Buffers is in deze situatie erg complex. Op de linker figuur is er slechts 1 duidelijk beperkende factor. Daar is het meteen duidelijk dat er na activiteit 2,3 en 9 een CCB moet worden ingevoegd. Gegeven de complexiteit van dit probleem, werken we opnieuw met een heuristiek om de CCB te bepalen en toe te voegen. Deze wordt tot in detail uitgelegd in sectie

46 4 OPZET EXPERIMENT 4.1 MULTI-PROJECT PLANNINGSMETHODES Om het ER + CC algoritme te testen vergelijken we het met 3 andere multi-project planningsmethodes. De basis van deze methodes worden hier beschreven. In sectie 5 treden we meer in detail over de implementatie van elke methode PROJECTEN NA ELKAAR In deze meest primitieve methode plannen we op basis van project prioriteiten. We kennen eerst grondstoffen toe aan het project met de hoogste prioriteit en maken een ALAP planning via de CC methode. Pas na het eindigen van de project buffer van dit project, laten we een volgend project op de prioriteitenlijst starten. Opnieuw plannen we dit ALAP via de CC methode. Dit herhalen we tot alle projecten gepland zijn. Merk op dat er bij deze methode geen CCB of DB wordt toegevoegd. Het na elkaar plannen van projecten is een zeer eenvoudige methode. De literatuur vermeldt dat deze methode nog steeds gebruikt wordt omdat ze eenvoudig te controleren valt en er geen nood is aan extra buffers zoals een CCB of een DB. Het grote nadeel is echter het inefficiënt gebruikt van de hernieuwbare grondstoffen PROJECT PRIORITEITEN MET FEEDING BUFFER Deze planningsmethode is gebaseerd op CCPM voor een multi-project. Op basis van project prioriteiten kennen we eerst grondstoffen toe aan het project met de hoogste prioriteit en stellen we een ALAP schema op inclusief feeding buffers en project buffers. Merk op dat we veronderstellen dat deze buffers geen resources reserveren. Het toevoegen van een feeding buffer kan echter wel invloed hebben op de starttijd van de activiteiten (door de feeding buffers starten bepaalde activiteiten niet langer ALAP maar is hun starttijd vervroegd met de grootte van de buffer). Van zodra er voldoende resources zijn vrij gekomen, worden de grondstoffen doorgegeven aan het volgende project op de prioriteitenlijst die tevens ALAP wordt gepland. Omdat we in de literatuur vernemen dat er zelden slechts één duidelijk beperkende factor kan geïdentificeerd worden, kijken we naar elk type resource om te identificeren wanneer er voldoende resources zijn vrij gekomen om het volgend project te starten. Deze controle gebeurt op de volgende manier: 34

47 Stap 1: Maak een individuele ALAP planning inclusief buffers voor het volgend project op de prioriteitenlijst en bekijk de resources nood van elk type. Stap 2: Ga voor elke resource de beschikbaarheid na op elk tijdstip in de multi-project planning. Stap 3: Controleer of het volgend project kan starten op tijdstip 0. Indien er zich resource tekorten voordoen (resources nood is op sommige tijdstippen hoger dan de resources beschikbaarheid) verhogen we de mogelijke starttijd van het project met één tijdseenheid. Dit herhalen we tot we een starttijd hebben gevonden waar er voldoende resources beschikbaar zijn. Vervolgens voegen we de individuele ALAP planning toe aan de multi-project planning. Stap4: Indien er nog projecten op de prioriteitenlijst staan gaan we terug naar stap 1. Het is dus mogelijk dat een volgend project reeds start voordat het voorgaande project volledig beëindigd is. Dit is een groot verschil met de projecten na elkaar methode. Figuur 13 illustreert nogmaals volledige de aanpak. Figuur 13: Project prioriteiten In dit voorbeeld werd de starttijd van project 2 opgeschoven tot tijd = 10 opdat er voldoende resources beschikbaar zijn om het volledige project uit te voeren. Na het bekomen van een multi-project planning voegen we nog CCB s toe. Daarna consumeren we extra vrijgekomen slack en voegen we drum buffers toe. Meer details over deze werkwijze is terug te vinden in de secties tot In de praktijk wordt deze methode vaak gebruikt. Het is relatief eenvoudig om resources te alloceren volgens een prioriteitenlijst waarop de projecten gesorteerd zijn volgens aflopende prioriteit. Indien we veronderstellen dat er slechts één beperkende factor is, is het ook eenvoudig om te bepalen wanneer het volgende project kan starten. De methode vormt dus een ketting van bottleneck taken waarrond niet-bottleneck taken worden gepland. 35

48 4.1.3 PROJECT PRIORITEITEN ZONDER FEEDING BUFFER Met deze methode vergelijken Shalin Yang en Lei Fu het ER+ CC model. Deze methode werkt op dezelfde manier als Project prioriteiten met feeding buffer. Het enige grote verschil is dat we bij het maken van individuele planningen geen buffers toevoegen. We voegen enkel de nodige buffers aan de multi-project planning SAMENVATTING Volgende figuur toont duidelijk de verschillen. Voor de eenvoud veronderstellen we 1 beperkende factor en werden de bottleneck taken aangeduid in het blauw. Merk op dat dit een sterk vereenvoudig voorbeeld is die louter werd opgesteld om de lezer inzicht te geven in de verschillen tussen de methodes. Figuur 14a: Projecten na elkaar 36

49 Figuur 14b: Project prioriteiten met FB Figuur 14c: Project prioriteiten zonder FB Bij het vergelijken van figuur 14b met figuur 14c zien we dat de feeding buffer wel degelijk invloed kan hebben op de multi-project duurtijd. Omdat we activiteiten ALAP plannen (CCPM methode) kunnen resources pas worden doorgegeven na de LF ( latest finish ). Bij het toevoegen van een FB wordt aan activiteit 3 echter een vroegere starttijd toegekend. Omdat de FB geen resources reserveert kunnen deze sneller worden doorgegeven aan het volgende project waardoor dit project sneller start en bijgevolg ook sneller kan eindigen. 37

50 4.2 PERFORMANCE MEASURES Om de verschillende planningsmethodes te vergelijken introduceren we drie performance measures. Deze zijn de totale multi-project duurtijd, de throughput van de projecten en de gebruiksgraad van de resources. Aan de hand van deze variabelen bekijken we welke planningsmethode tot de beste resultaten leidt. Een gunstige planning is een schema met een zo kort mogelijke duurtijd, een hoge gebruiksgraad van de resources en waarbij de individuele projecten zo snel mogelijk opgeleverd worden (= een hoge throughput). Om de voordelen beschreven door Shalin Yang en Lei Fu van de ER + CC methode te valideren, vergelijken we het met de hierboven beschreven alternatieve planningsmethodes. Hier wordt verder op ingegaan in sectie 6. Om de invloed van de CCB en de DB op de totale duurtijd van de verschillende methodes te meten vergelijken we de starttijden van de verschillende planningsmethodes voor en na het toevoegen van de CCB en de DB. 5 IMPLEMENTATIE IN C++ Om het model, hierboven beschreven, te valideren werd het geprogrammeerd in C++ met Microsoft Visual Studio Express 2013 als compiler. In deze sectie geven we eerst een overzicht en gaan we vervolgens dieper in op de werkwijze van de verschillende stappen. Om inzicht te krijgen in de verschillende planningsmethodes en de invloed van de verschillende buffers werd niet alleen de eind output weggeschreven naar een.txt bestand maar ook de verschillende tussenstappen. Na het laten lopen van het programma worden 3 output bestanden gegenereerd: o Output.txt is een overzicht van de verschillende tussenstappen o Conclusies.txt vergelijkt de verschillende planningsmethodes door het verschil te nemen van de starttijden van elke taak en de totale duurtijden. o Samenvatting.txt geeft een samenvatting van de verschillende performance measures. Een voorbeeld Samenvatting.txt werd opgenomen in bijlage 9.1. Een voorbeeld van Output.txt en Conclusies.txt werd toegevoegd in het extra boekje in bijlage. 38

51 5.1 OVERZICHT Dit overzicht bevat de verschillende stappen om tot een multi-project planning te komen. Elke stap verwijst naar een sectie die meer details bevat over de implementatie van deze stap. Schema 1: het maken van individuele projecten Genereren en inlezen data Verrijken van de data (ES/LS/CP) Maken van een prioriteitenlijst Opstellen ALAP schema per project Output 1 = ALAP schema per project excl. FB Schema 2: Multi-project op basis van taak prioriteiten (= ER + CC ) Bepaal bottleneck taken Maken van een prioriteitenlijst op taak level Opstellen ASAP multi-project schema Bepalen van de CCB nood Opstellen ASAP multi-project schema incl. CCB Consumeer slack van niet-bottleneck taken Bepalen van de DB nood 39

52 5.3.8 Opstellen ASAP multi-project schema incl. CCB en DB Toevoegen van feeding buffers Multi schema laten starten op tijdstip nul Output 2 = Multi-project schema op basis van taak prioriteiten Schema 3: Multi-project op basis van project prioriteiten excl. FB Opstellen ALAP multi-project schema op basis van individuele schema s (excl. FB) en hun prioriteiten Bepalen van de CCB nood Opstellen ALAP multi-project schema incl. CCB Consumeren van gecreëerde slack door toevoegen CCB Bepalen van de DB nood Opstellen ALAP multi-project schema incl. CCB en DB Toevoegen van feeding buffers Multi-schema laten starten op tijdstip nul Output 3 = Multi-project schema op basis van project prioriteiten 40

53 Schema 4: Multi-project op basis van taak prioriteiten incl. FB Toevoegen FB aan individuele schema s Opstellen ALAP multi-project schema op basis van individuele schema s (incl. FB) en hun prioriteiten Toepassen van stap x.3.2 tot en met x.3.8 van schema 3 Output 4 = ALAP schema per project incl. FB Output 5 = Multi-project schema op basis van project prioriteiten incl. FB Schema 5: Multi-project door individuele projecten na elkaar te plaatsen ALAP schema per project incl. FB na elkaar plaatsen aan de hand van de project prioriteiten Output 6 = Na elkaar multi-project schema incl. PB per project 41

54 5.2 SCHEMA 1: HET MAKEN VAN INDIVIDUELE PROJECTEN In schema 1 worden individuele planningsschema s gemaakt per project. We blijven schema 1 herhalen tot we voor elk project een planning hebben gecreëerd GENEREREN EN INLEZEN DATA Het programma werd getest op fictieve data bekomen door de RanGen2 data generator. Deze generator stelt de gebruiker in staat om netwerken te maken waarbij hij zelf een keuze kan maken over enkele parameters. Bij het testen hebben we de volgende parameters laten variëren: S (Serie/parallel indicator): hoe hoger deze indicator hoe sterker het netwerk in serie is. RF (Resource factor): hoe hoger deze factor hoe sterker de taken alle beschikbare types aan resources nodig hebben om uitgevoerd te kunnen worden. RC (Resource constrainedness): hoe hoger deze factor hoe dichter de resource nood van elk type aansluit bij de maximale beschikbaarheid. Number of resources: het aantal types aan resources. Number of activities: het aantal activiteiten per project. Zoals eerder aangehaald wensen we projecten te testen waarbij één of meerdere resources een sterkere beperking vormen voor het multi-project schema dan de andere. Omdat RanGen2 alle resources volgens dezelfde input variabelen behandeld is de output van elke resource even beperkend. Vandaar werden in deze thesis RanGen outputs samen gevoegd om per resource een andere RC en RF te hebben en bijgevolg een verschillende mate van beperking. Bijvoorbeeld voor een project met 3 resources werden 3 RanGen outputs gecreëerd met dezelfde S, hetzelfde aantal activiteiten en hetzelfde aantal resource types. Elke output heeft echter wel een andere RC en RF. Aan de hand van een C++ programma werden deze drie projecten samengevoegd door van de eerste output de 2 de resources kolom te vervangen door de 2 de resources kolom van de 2 de output en door de 3 de resources kolom te vervangen door de 3 de resources kolom van de 3 de output. Een eenvoudig voorbeeld van een samengevoegde RanGen output staat hieronder beschreven. Hierbij is S = 50, werken we met 3 resources en 12 activiteiten waarvan de eerste en de laaste een dummy zijn. Voor de eerste resource is RF = 55 en RC = 25 (een niet beperkende resource), voor de 2 de resource is RF = 75 en RC = 45 (een beperkende resource) en voor de derde resource is RF = 80 en RC = 50 (de meest beperkende resource). 42

55 Op de eerste rij zien we het aantal activiteiten en het aantal verschillende hernieuwbare resources. De tweede rij geeft de beschikbaarheid aan van elk type resource. Het voorbeeld netwerk bestaat hier uit 12 activiteiten en 3 verschillenden resources waarvan er steeds 10 beschikbaar zijn. Op de volgende rijen staat informatie over elke taak. In de eerste kolom valt de duurtijd van de taak af te lezen, in de volgende 3 kolommen het aantal resources van elk type die de taak nodig heeft om uitgevoerd te kunnen worden. In de volgende kolom staat het aantal opvolgers en vervolgens kunnen de nummers van de opvolgers worden terug gevonden in de daaropvolgende kolommen. Er wordt steeds gestart en geëindigd met een dummy taak. Bij de model validatie werden deze parameters op sterk variërende waarden gezet om zo na te gaan bij welk type netwerken de ER + CC methode de beste resultaten geven. Deze resultaten zijn terug te vinden in deel III van deze thesis VERRIJKEN VAN DE DATA (ES/LS/CP) Na het inlezen van de data voegen we nog enkele andere variabelen toe zodat een individueel planningsschema voor elk project kan worden opgesteld. Eerst bepalen we de voorgangers van elke activiteit aan de hand van de opvolgers. Vervolgens berekenen we de CP duurtijd via een recursieve functie die de duurtijd van alle mogelijke paden bepaalt en de langste duurtijd opslaat. Eenmaal we het kritieke pad hebben gevonden kunnen we de ES en LF van elke activiteit bepalen. Aan de hand van de LF en ES kunnen we de slack berekenen van elke activiteit. In deze thesis maken we onderscheid van 2 soorten slack. De totale slack bestaat namelijk uit de som van slack voor en 43

56 slack na en dit wordt in figuur 15 verduidelijkt. De slack voor van een activiteit kan worden gevonden door het verschil te maken tussen de starttijd van de activiteit en de maximale eindtijd van al zijn voorgangers. Slack na bekomt men door het verschil te maken tussen de eindtijd van de activiteit en de minimale starttijd van al zijn opvolgers. Figuur 15: Slack MAKEN VAN EEN PRIORITEITENLIJST Vervolgens houden we rekening met de beperkte beschikbaarheid aan resources om de CC te bepalen. Omdat dit een NP hard probleem is wordt de CC bepaald aan de hand van een heuristiek. Met behulp van een prioriteitenlijst worden de verschillende activiteiten in de volgorde van de lijst steeds ALAP gepland. Omdat deze thesis zich focust op het vergelijken van verschillende planningsmethodes en niet op het vinden van de beste planning is het werken met een heuristiek verantwoord. De prioriteitenlijst bekomen we via een functie die alle taken van een project sorteert volgens oplopende slack. Om veel verschuiving van reeds geplande activiteiten te voorkomen zorgen we dat alle voorgangers van een bepaalde activiteit reeds gepland zijn alvorens we een starttijd aan deze activiteit toekennen. Indien een activiteit meerder voorgangers heeft worden deze volgens oplopende slack toegevoegd aan de prioriteitenlijst alvorens we de activiteit in kwestie toevoegen. Merk op dat dit een ketting in werking kan zetten waarbij ook voorgangers van voorgangers en zo voort eerst worden toegevoegd aan de prioriteitenlijst. De prioriteitenlijst wordt opgesteld volgens oplopende slack omdat dit ons in staat stelt om de totale duurtijd van het project te minimaliseren. Omdat we eerst de kritieke activiteiten plannen 44

57 (activiteiten zonder slack) en daarna de niet-kritieke activiteiten ontstaan de meeste resource conflicten pas na het plannen van de activiteiten zonder slack. Tijdens het plannen van de nietkritieke activiteiten en het voorkomen van een resource conflict hebben we bijgevolg meer flexibiliteit om de conflicten op te lossen door de hogere slack van de te plannen activiteit OPSTELLEN ALAP SCHEMA PER PROJECT In de volgorde van de prioriteitenlijst maken we een ALAP schema. Met een ALAP schema wensen we activiteiten te starten aan hun LS of meteen na het beëindigen van zijn voorgangers als dit een latere starttijd oplevert dan de LS. Activiteiten plannen wordt in het programma verwezenlijkt door een starttijd toe te kennen aan deze activiteit en de beschikbare resources met de resource(s) nood van deze activiteit te verminderen. Indien er een resource conflict opduikt proberen we om dit eerst op te lossen door slack voor te consumeren. We gaan met andere woorden na of het conflict kan worden verholpen door de taak vroeger te plannen. Daarbij vormt de maximale eindtijd van de voorgangers de vroegst mogelijke starttijd. Indien dit geen oplossing biedt zijn we genoodzaakt om de taak later te plannen waardoor de totale geplande duurtijd van het project stijgt. Figuur 16a illustreert. Figuur 16a: ALAP schema 45

58 Er wordt verondersteld dat we 5 eenheden beschikbaar hebben van de hernieuwbare resource 1. De nood aan resources per activiteit wordt in de activiteit aangegeven tussen de haakjes. Activiteit 3 kan pas starten nadat activiteit 1 en 2 zijn beëindigd. Activiteit 1 en 3 hebben het minst slack. Omdat 3 pas kan starten na het beëindigen van activiteit 1 en 2 komt activiteit 2 toch voor 3 op de prioriteitenlijst. Het plannen van activiteit 2 aan zijn LS veroorzaakt echter een resource conflict dat niet kan worden opgelost door slack voor te consumeren. We verlaten bijgevolg de starttijd van activiteit 2. Vervolgens bij het plannen van activiteit 3, kennen we ook een latere starttijd toe zoals aangegeven op de onderste figuur. Door het verlaten van opvolgers is het echter mogelijk dat opnieuw slack na wordt gecreëerd voor andere activiteiten. Om een ALAP schema te bekomen dienen we dus deze slack te consumeren. Verduidelijking is terug te vinden in figuur 16b. Naast het minimaliseren van WIP en rework wil een ALAP schema de NPV optimaliseren door uitgaves zo lang mogelijk uit te stellen in de tijd. Indien we niet voldoende resources hebben om van alle activiteiten de extra vrijgekomen slack te consumeren wordt er bijgevolg gekozen om de starttijd te verlaten van de activiteiten die de meeste resources consumeren en waarbij het consumeren van slack niet tot nieuwe resource conflicten leidt. Onder de assumptie dat het gebruik van elk type resource een even grote kost veroorzaakt kunnen we de hoogste kosten uitstellen door slack na te consumeren van activiteiten die de meeste resources gebruiken. We werken hierbij volgens het volgende algoritme. Van elke taak bereken we de slack na door het verschil te nemen van de vroegste starttijd van de opvolgers en de eindtijd van de activiteit in kwestie. Voor elke activiteit met een positieve slack berekenen we de resource nood. Vervolgens sorteren we deze lijst op aflopende resource nood. In de volgorde van de lijst controleren we welke activiteit we één tijdseenheid slack na kunnen laten consumeren zonder dat er nieuwe resource conflicten ontstaan. Na het consumeren van één tijdseenheid slack start het algoritme opnieuw. Het algoritme stopt als alle mogelijke slack na is geconsumeerd en er geen resource conflicten zijn. 46

59 Figuur 16b: ALAP schema (vervolg) Er wordt verondersteld dat we 5 eenheden beschikbaar hebben van de hernieuwbare resource 1. We plannen volgens de prioriteitenlijst. Bij het plannen van de activiteit 2, ontstaat een resource conflict. Conform met de figuur 16a verlaten we de starttijd. In dit voorbeeld leidt dit echter tot de creatie van slack na voor activiteit 3. Deze slack consumeren we door de starttijd van activiteit 3 te verlaten. Het consumeren van slack kan zorgen dat het volledige schema opschuift en het project bijgevolg niet meer start op tijdstip nul. Vandaar is het noodzakelijk om het volledige project in zijn geheel te verschuiven zodat de eerste activiteit opnieuw start op tijdstip nul. Dit doen we door alle starttijden met eenzelfde tijd te vervroegen. Het bepalen van het ALAP schema wordt met ander woorden bekomen door activiteiten naar voor en achter te verschuiven om op deze manier een efficiënt schema te vinden. Deze methode is gebaseerd op de aanpak van K.Y. Li en E.J. Willis (1990) en werd beschreven in An iterative scheduling technique for resource-constrained project scheduling. De aanpak moest echter wel aangepast worden in deze thesis omdat het doel van K.Y. Li en E.J. Willis het maken van een ASAP schema is. Nu het schema is opgesteld kunnen we de CC definiëren als het langste pad dat de totale project duurtijd bepaalt. De CC is echter niet altijd uniek. Soms kunnen meerdere aaneenschakelingen van 47

60 taken worden gevonden die leiden tot eenzelfde maximale duurtijd. In deze thesis bepalen we de critical chain als de minimale aaneenschakeling van taken die leiden tot een maximale project duurtijd. Figuur 17a verduidelijkt dit. Figuur 17a: Bepalen CC In dit vereenvoudigd voorbeeld kunnen twee verschillende critical chains worden bepaald. Namelijk en In deze thesis kiezen we om het aantal taken in de CC te minimaliseren en kiezen we dus voor de taken met de langste duurtijd. Bijgevolg definiëren we de CC als Na het uitvoeren van enkele testen werd het duidelijk dat in sommige situaties de CC niet op de hierboven beschreven manier kan bepaald worden. Door resource beperkingen moeten taken soms worden opgeschoven waardoor de CC ketting wordt onderbroken. Figuur 17b verduidelijkt dit. Figuur 17b: Bepalen CC 48

61 Via de prioriteitenlijst bekomen we volgend schema (=ander project dan figuur 17a) waarbij we (voor de eenvoud) slechts één resource type hebben. Activiteit 4 en 11 hebben geen resource nood en zijn bijvoorbeeld noodzakelijke rusttijden. Activiteit 9 kan pas starten na activiteit 11 maar door de hoge resources nood werd de activiteit verlaat tot starttijd 22 in plaats van 20. Indien we nu de CC willen bepalen als het langste pad dat de totale project duurtijd bepaalt en waarbij het aantal activiteiten minimaal is vormt het eerst deel van de CC. Daarna komen we in de problemen omdat activiteit 11 en 9 niet aaneensluitend zijn. Als oplossing wordt de CC op een andere manier bepaald enkel en alleen als we in de beschreven situatie terecht komen. Als alternatief vormt de CC het langste pad dat de totale project duurtijd bepaalt en waarbij het aantal activiteiten maximaal is. Onder deze situatie voegen we met andere woorden steeds de kortste taak toe aan de CC. In het voorbeeld vormt daarom de CC TOEVOEGEN FB AAN INDIVIDUELE SCHEMA S Na het bepalen van de CC kunnen buffers worden toegevoegd aan het schema. Bij het toevoegen van de feeding en project buffer maken we conform met het model van Shalin Yang en Lei Fu de assumptie dat deze buffers geen resources reserveren. In wat volgt worden taken die onderdeel uitmaken van de CC kritieke taken genoemd en alle andere taken noemen we niet-kritieke taken. De project buffer wordt steeds toegevoegd na de laatste activiteit van een project. Voor het bepalen van de grootte gebruiken we de eerder beschreven RSEM. We maken hierbij de veronderstelling dat de standaardafwijking van een taak gelijk is aan de helft van de duurtijd. De feeding buffers lokaliseren we na een niet-kritieke taak die op zijn minst één kritieke opvolger heeft. Om de buffer grootte te berekenen, moeten we de feeding chain bepalen. Dit is een pad van opeenvolgende niet-kritieke taken die uitmondt in een kritieke taak. Na het identificeren van deze taken kunnen we opnieuw RSEM gebruiken waarbij we veronderstellen dat de standaardafwijking van een taak gelijk is aan de helft van de duurtijd. Indien we met sterk parallelle netwerken te maken hebben verhoogt de complexiteit omdat we dan meerdere feeding chains kunnen identificeren die uitmonden in dezelfde kritieke taak. Om de CC voldoende te beschermen tegen vertragingen moeten we de buffer grootte bepalen aan de hand van de langste feeding chain. Dit gebeurt via de recursieve functie die de duurtijd van alle mogelijke feeding chains bepaalt en aan de hand van de ketting met de langste duurtijd de buffer grootte bepaalt met RSEM. Figuur 18 illustreert het voorkomen van parallelle feeding chains. 49

62 Figuur 18: Parallelle feeding chains In dit netwerk werd de CC aangeduid in het blauw en werd de duurtijd vermeld bij elke taak. Van taak 11 naar 4 moeten we een feeding buffer voorzien. We kunnen echter 3 verschillende feeding chains bepalen: , en Omdat de laatst vernoemde de langste duurtijd heeft voorzien we een buffer grootte voor deze ketting. De ketting werd aangeduid in het grijs. Omdat we een ALAP schema hebben dienen we starttijden te vervoegen indien nog een buffer moet worden toegevoegd na een taak. We voegen een buffer toe na een taak als deze voldoende slack voor heeft en het vervroegen van de taak geen resource conflicten doet ontstaan. Indien er onvoldoende slack voor is consumeren we het maximum en laten we een melding verschijnen hoeveel slack er te weinig was. Ook indien het vervroegen van een taak tot resource conflicten leidt laten we een melding verschijnen en geven we aan met hoeveel we de taak maximaal hebben vervroegd opdat er geen resource conflict ontstond. Merk op: omdat starttijden steeds natuurlijke getallen zijn ronden we de buffer ook af tot een natuurlijk getal. Om een voldoende te bufferen kiezen we om de buffer naar boven af te ronden. We doen dit later ook voor de CCB en de DB. Na het doorlopen van de secties tot en met bekomen we ALAP schema s excl. FB per individueel project. Na het uitvoeren van sectie bekomen we ALAP schema s incl. FB. Als output verschijnt de starttijd van elke activiteit, de CP duurtijd, de CC en de duurtijd van dit pad en de buffer locaties alsook de grootte van elke buffer. We voegden ook de slack voor en slack na toe van elke activiteit. Deze output is tevens terug te vinden in het bijlage boekje (p 3 en 4). 50

63 5.3 SCHEMA 2: MULTI-PROJECT OP BASIS VAN TAAK PRIORITEITEN In dit deel bespreken we de implementatie van het ER + CC model die werd voorgeteld in sectie BEPAAL BOTTLENECK TAKEN Conform met de CCPM methode starten we met het bepalen van de beperkende factor. Aanvankelijk werd de bottleneck resource bepaald via de regel beschreven in de paper (de grondstof de langste tijd op de CC controleert). We vertrekken van een vereenvoudigde CCPM planning bekomen door de individuele planningen (uit schema 1) na elkaar te plaatsen. De CC van deze multi-project planning is dus een aaneenschakeling van CC s van de individuele projecten en dit vormt de input om te bepalen welke grondstof de langste tijd op de CC controleert. Concreet werd dit verwezenlijkt door alle taken op de CC te bestuderen en de verwachte uitvoeringstijd van deze taak toe te voegen aan een counter gelinkt aan grondstof x indien deze taak grondstof x nodig heeft. Vervolgens kan de bottleneck taak geselecteerd worden als de grondstof met de hoogst bijhorende counter. Alle taken die nood hebben aan de bottleneck resource vormen de kritieke taken. Na het uitvoeren van testen leerden we dat de resource met de laagste RF/RC wel degelijk de langste tijd op de CC kan controleren. Indien we de regel uit de ER + CC methode toch volgen, spreiden en bufferen we mogelijks de resource waarvan de gebruiksgraad veel lager ligt dan de beschikbaarheid terwijl dit voor andere resources niet het geval is. Dit heeft tot gevolg dat we taken indekken tegen vertragingen zodat een resource op overschot niet hoeft te wachten. Het resultaat is een suboptimale situatie waarbij de resource waarvan de gebruiksgraad dicht aanleunt bij de beschikbaarheid onvoldoende gebufferd is en in de plaats de resource op overschot ingedekt wordt tegen vertragingen (in deel III van deze thesis komen we hierop terug). Als verbetering werd een nieuwe definitie voorgesteld, namelijk: de bottleneck resource is de resource die de grootste negatieve impact heeft op de totale duurtijd. Vandaar voeren we schema 2 meerdere keren uit, telkens met een andere resource als bottleneck resource. Nadat we elke resource eens als bottleneck resource hebben aangeduid bepalen we bij welke resource de totale duurtijd van het multi-project schema incl. buffers het langst is. Deze resource wordt dan aangeduid als de bottleneck resource en het schema opgesteld met deze bottleneck resource wordt gebruikt als output. Merk op: de bottleneck resource heeft vooral invloed op de taak prioriteitenlijst van schema 2 (zie sectie 5.3.2) en dus op de uitkomst van het multi-project schema op basis van taak prioriteiten. 51

64 Daarnaast kan de bottleneck resource ook een criteria zijn in het ER algoritme om de project prioriteiten te bepalen. In deze thesis werd echter verondersteld dat het grootste gewicht in het ER algoritme naar andere zaken ging en de bottleneck resource geen invloed heeft op de prioriteitenlijst van de projecten MAKEN VAN EEN PRIORITEITENLIJST OP TAAK LEVEL Zoals eerder besproken wordt de prioriteitenlijst op taak niveau ook opgesteld aan de hand van het ER algoritme. De paper van Shalin Yang en Lei Fu geeft echter geen suggestie van een goede evaluatie boom waarin de relevante attributen en gewichten zijn terug te vinden. Vandaar moeten we deze zelf bepalen. In het programma wordt belang gehecht aan de volgende drie evaluatiecriteria: 1. De project prioriteit waartoe de taak behoort. 2. De nood aan de bottleneck resource van de taak in kwestie. 3. De starttijd verkregen uit de individuele planning. De output is bijgevolg een lijst die eerst alle bottleneck taken bevat van het project met de hoogste prioriteit. Deze taken zijn gesorteerd volgens een oplopende starttijd. Vervolgens volgen de bottleneck taken van het project met de 2 de hoogste prioriteit. Opnieuw gesorteerd volgens oplopende starttijd. Dit blijft zich herhalen tot alle bottleneck taken zijn gepland. Na deze taken volgen de niet-bottleneck taken. Deze worden ook eerst gesorteerd volgens project prioriteiten daarna volgens oplopende starttijd. Omdat de projecten geaggregeerd werden kunnen dezelfde taak nummers meerdere malen voorkomen. Om taken toch te kunnen identificeren werken we met twee lijsten. De eerste lijst bevat de taak nummers, de tweede lijst bevat het corresponderende project nummer. Dit ziet er bijvoorbeeld als volgt uit: Taak prioriteiten : [1,2,3,2] Corresponderende projecten : [1,2,2,1] Taak 1 van project 1 krijgt in dit voorbeeld de hoogste prioriteit, vervolgens de taken 2 en 3 van project 2. Taak 2 van project 1 krijgt hier de laagste prioriteit. Merk op: de werkwijzen om het ER algoritme te implementeren in C++ werd toegevoegd in bijlage

65 5.3.3 OPSTELLEN ASAP MULTI-PROJECT SCHEMA Met behulp van de prioriteitenlijst maken we een multi-project planning. Daarbij worden de taken in de volgorde van de lijst steeds ASAP gepland. De starttijd van elke activiteit is dus gelijk aan de ES of aan de hoogste eindtijd van de voorgangers indien dit later is dan de ES. We plannen de taken zo vroeg mogelijk omdat we zo sneller de bottleneck resource kunnen doorgeven aan de volgende taak. Op deze manier proberen we de gebruiksgraad van de resources te maximaliseren. Indien we door de volgorde van de prioriteitenlijst een taak moeten plannen waarvan de voorganger zijn starttijd/eindtijd nog niet bepaald is, plannen we eerst deze voorganger ASAP. Indien meerdere voorgangers nog moeten gepland worden, gebeurt het plannen van deze taken in dezelfde volgorde als hun voorkomen op de prioriteitenlijst. Merk op dat dit een ketting in werking kan zetten die pas stopt als alle nodige voorgangers gepland zijn. Indien we later een taak tegen komen op de prioriteitenlijst die reeds gepland is gaan we meteen over naar de volgende taak op de lijst. Bij het voorkomen van een resource conflict zijn we genoodzaakt de taak op een later tijdstip in de tijd te plannen. Daarbij maken we steeds sprongen van één tijdseenheid en na elke sprong controleren we of het resource conflict is opgelost BEPALEN VAN DE CCB NOOD Zoals eerder besproken beschermt de CCB de bottleneck resource tegen vertragingen in voorgaande projecten. Deze buffer wordt toegevoegd tussen twee bottleneck taken die elk behoren tot een verschillend project. In tegenstelling tot andere buffers wordt er verondersteld dat deze buffer wel resources reserveert. Zoals aangehaald in sectie 3.3 stappen we af van de assumptie dat er slechts één duidelijk beperkende resource is. We creëren een algoritme die de CCB nood correct kan bepalen voor een schema met één of meerdere beperkende factoren. Om hierin te slagen is het noodzakelijk om inzicht te krijgen in hoe de resources worden doorgegeven. Van elke taak wensen we namelijk te weten naar welke andere taak/taken de resources worden doorgegeven. Met deze informatie kunnen we vervolgens nagaan of resources worden overgedragen naar een ander project en er dus een CCB nood is. Gegeven de complexiteit van dit probleem, werken we opnieuw met een heuristiek. Gebaseerd op de planning exclusief de CCB s stellen we een CCB prioriteitenlijst op. De lijst bevat enkel bottleneck taken en deze zijn gesorteerd volgens oplopende starttijd en bij een gelijke starttijd zijn de taken gesorteerd volgens oplopende duurtijd. 53

66 In de volgorde van deze lijst met n elementen [1,2,,i,, n] doorlopen we het volgende algoritme. Merk op dat dit algoritme informatie over de CCB enkel opslaat maar nog niet echt toevoegt aan het schema. Pas bij het opnieuw plannen van het multi-project probleem voegen we de nodige Capacity Constraint Buffers toe. Stap1: Indien taak i nog geen CCB heeft voegen we een tijdelijke CCB toe na de geselecteerde activiteit. Zoals hierboven vermeld betekent dit toevoegen enkel dat we opslaan na welke activiteit de CCB moet komen, wat de duurtijd van deze CCB is (via de 30%-regel ) en hoeveel grondstoffen deze reserveert. Later controleren we of het toevoegen van deze CCB terecht is. Stap2: We bestuderen aan welke taken, taak i zijn resources kan doorgeven. Dit doen we door de taken in de volgorde van de opgestelde CCB prioriteitenlijst te beschouwen. We testen of taak i + j (j = {1,2,,n - i}) start na het eindigen van taak i en taak i + j nog niet al de nodige resources heeft ontvangen om de taak te kunnen starten. Indien beide testen positief zijn betekent dit dat na het beëindigen van taak i, de vrijgekomen resources worden doorgegeven aan taak i + j en gaan we verder naar stap 3. Indien niet, controleren we de volgende activiteit op de lijst (j = j + 1). Stap3: Bij het overdragen van resources van activiteit i naar activiteit i + j maken we onderscheid tussen drie verschillende situaties. In de eerste situatie is de eindtijd van activiteit i gelijk aan de starttijd van activiteit i + j en behoren de taken niet tot hetzelfde project. In dit geval is de tijdelijke CCB van activiteit i terecht en wordt deze niet verwijderd. Indien activiteit i al zijn resources overdraagt naar activiteit i + j, gaan we naar stap 4. Indien slechts een deel van de resources wordt overgedragen behouden we ook de tijdelijke buffer, verhogen we j (j= j + 1) en gaan we over naar stap 2. In de tweede situatie is de eindtijd van activiteit i gelijk aan de starttijd van activiteit i + j en behoren de taken wel tot hetzelfde project. In dit geval is de tijdelijke CCB van taak i onterecht en moeten we deze corrigeren. Indien alle resources van taak i worden doorgegeven aan taak i + j mag de buffer na taak i worden verwijderd. Indien slechts een deel van de resources wordt doorgegeven verminderen we de resources nood van de CCB van taak i met de hoeveelheid resources die worden doorgegeven. Voor de resterende resources verhogen we j (j = j + 1) en gaan we terug naar stap 2. Let op, in de situatie waarin resources worden doorgegeven aan een aaneensluitende activiteit van hetzelfde project vormt er zich een ketting van bottleneck taken. Dit moet in rekening worden gebracht bij het bepalen van de grootte van de CCB. Vandaar voegen we in deze stap na i + j een tijdelijke CCB toe waarvan de grootte gelijk is aan de grootte van de CCB van taak i geaccumuleerd met 30% van de duurtijd van taak i + j. Ook de hoeveelheid grondstoffen die de buffer reserveert slaan we opnieuw op. Deze is gelijk aan de grondstoffen nood van taak i + j. 54

67 In de laatste situatie zijn de taken niet aaneensluitend. De starttijd van i + j is met andere woorden later dan de eindtijd van taak i. Indien i en i + j tot verschillende project behoren, is de tijdelijke buffer van activiteit i terecht en gaan we tewerk zoals in de eerste situatie. Indien dit niet het geval is en de twee beschouwde activiteiten tot hetzelfde project behoren, maken we onderscheid tussen twee verschillende mogelijkheden. Indien taak i de volledige resource nood van taak i + j kan voorzien behouden we de tijdelijke buffer na taak i. Dit betekent dat er wordt gewerkt met een gesplitste buffer. Meer duiding van deze werkwijze wordt aan de hand van een voorbeeld geïllustreerd in figuur 20. Indien de taken niet aaneensluitend zijn en i de volledige resources nood van i + j niet kan voorzien, verminderen we de resources nood van de CCB van taak i met de hoeveelheid resources die worden doorgegeven en slaan we na i + j op dat er een buffer nood is met een grootte van buffer i + 30% van de duurtijd van taak i + j. De grondstoffen die door deze buffer gereserveerd worden, is opnieuw de grondstoffen nood van activiteit i + j. Indien taak i al zijn resources heeft doorgegeven gaan we naar stap 4. Indien dit niet het geval is verhogen we j (j = j + 1) en gaan we naar stap 2. Stap 4: taak i heeft al zijn resources doorgegeven. We verhogen i (i = i + 1) en gaan terug naar stap 1 tenzij i = n dan stoppen we het algoritme. Figuur 19 geeft een voorbeeld van de werking van het algoritme. Figuur 19: Illustratie van het CCB algoritme We maken onderscheid tussen 2 projecten. Project 1 is aangeduid in het grijs en project 2 in het blauw. Het algoritme start met de eerste activiteit op de lijst. In stap 1 plaatsen we een tijdelijke CCB na activiteit 1 door de nodige info op te slaan. Vervolgens kijken we aan welke taken activiteit 1 zijn resources overdraagt. Omdat het 2 de element op de lijst (activiteit 2) start voor het beëindigen van 55

68 activiteit 1 bestuderen we het volgende element op de lijst (activiteit 4). Bij de het doorgeven van de resources van activiteit 1 naar activiteit 4, hebben we te maken met aaneensluitende taken van hetzelfde project. De CCB na activiteit 1 is dus niet terecht. We verwijderen daarom deze CCB en we voorzien een CCB na activiteit 4 die beide activiteiten buffert. Vandaar is de grootte gelijk aan 30% van (duurtijd taak 1 + duurtijd taak 4). Omdat taak 1 al zijn resources heeft doorgegeven gaan we naar de volgende activiteit op de lijst, activiteit 2. We plaatsen na 2 een tijdelijke CCB. Deze CCB reserveert 3 resources. Eén van de resources van activiteit 2 wordt doorgegeven aan activiteit 4 (omdat deze activiteit nog niet zijn volledige resource nood heeft ontvangen). Activiteit 4 behoort tot hetzelfde project, dus worden de gereserveerde resources van de CCB na activiteit 2 verminderd tot twee eenheden. De rest van de resources wordt doorgegeven aan activiteit 5 van project 2. Omdat deze taak behoort tot een ander project is de resterende buffer na activiteit 2 terecht en moet deze niet verwijderd worden. Nu 2 al zijn resources heeft doorgegeven kunnen we terug naar een volgend element op de prioriteitenlijst. We blijven dit herhalen tot we aan het einde van de lijst komen. Later nadat de CCB nood is bepaald van elke activiteit wordt een nieuwe planning gemaakt waarbij we deze CCB s ook werkelijk toevoegen. Onderstaande figuur verduidelijkt het voordeel van het werken met de gesplitste buffer: Figuur 20: De gesplitste CCB In dit voorbeeld wordt het werken met een gesplitste buffer duidelijk. We beschouwen een nieuw multi-project die staat uit 3 verschillende projecten (aangegeven in het grijs, blauw en donkergrijs). Nadat activiteit 1 de helft van zijn resources heeft overgedragen aan activiteit 2 wordt de andere helft overgedragen aan activiteit 4. Activiteit 4 is niet aaneensluitend en heeft een resource nood kleiner of gelijk aan de resources die vrij komen. In plaats van na activiteit 4 een buffer te plaatsten die activiteit 1 en 4 buffert plaatsen we reeds na activiteit 1 een buffer. Op deze manier kunnen we na 4 56

69 een veel kleiner buffer plaatsen. Dit komt de totale duurtijd van het project ten goede. Deze werkwijze is ook intuïtief aanvaardbaar: voordat we de resources terug op non-actief plaatsen (waar ze wachten op de start van activiteit 4) plaatsen we een buffer opdat we zo met grootte zekerheid kunnen zeggen dat ze na het tijdstip van de buffer beschikbaar zullen zijn. Merk op: indien de buffer na activiteit 1 een langere duurtijd heeft dan de slack tussen activiteit 1 en 4 zorgt de gesplitste buffer wel voor een latere starttijd van activiteit 4 maar het totale voordeel op de multi-project duurtijd blijft echter positief van deze werkwijze. Figuur 21: De gesplitste CCB (uitzondering) Figuur 21 illustreert waarom we in stap 3 (in de derde situatie) enkel een gesplitste buffer toevoegen indien één taak aan de volledige resources nood van de volgende taak kan voldoen. Indien we dit niet doen en we bij het doorgeven van een deel van de resources van taak 5 naar taak 4 toch een gesplitste buffer zouden toevoegen van 3 (30% * duurtijd activiteit = 3) zou taak 4 later bij het plannen pas kunnen starten op tijdstip 13 i.p.v. 12. Omdat taak 2 ook resources doorgeeft aan de nu nog aaneensluitende taak 4, wordt er na taak 4 een buffer toegevoegd die de taken 1, 5, 2 en 4 buffert. Het gevolg bij het plannen is dat taak 4 is verlaat door de gesplitste buffer en er ook nog een volledige buffer werd toegevoegd. Dit leidt uiteraard tot een incorrect resultaat waarin teveel CCB s werden toegevoegd. Het algoritme houd ook nog rekening met 3 uitzonderingen: 1) Indien meerdere taken op de CCB prioriteitenlijst dezelfde starttijd hebben en voorkomen na taak i (met andere woorden de starttijd van i + j is dezelfde als de starttijd van i + j + k met k = {1,2, n - i - j}), worden de resources van taak i op een zo efficiënt mogelijk manier doorgegeven. We gaan dan na welke van deze taken (met éénzelfde starttijd) tot hetzelfde project behoren als taak i. In de volgorde van hun voorkomen op de CCB prioriteitenlijst dragen we dan eerst de resources van taak i over naar deze taken die behoren tot hetzelfde project als taak i. 57

70 Figuur 22: CCB bij éénzelfde starttijd In dit voorbeeld werken we met een multi-project bestaande uit 3 projecten (aangegeven in het blauw, grijs en donkergrijs). Indien we de prioriteitenlijst blind volgen, zouden we zonder de dezelfde starttijd aanpassing tussen activiteit 1 en 5 een CCB plaatsen. Dit zou leiden tot een suboptimale situatie. Omdat activiteit 2 tot hetzelfde project behoort als activiteit 1 en ook aansluitend start, geven we de resources van activiteit 1 beter door aan activiteit 2. Het rekening houden met eenzelfde starttijd leidt dus duidelijk tot een beter resultaat. 2) Indien bij het doorlopen van de CCB prioriteitenlijst een set van taken (i, i + j met j = {1,2, n - i}) eenzelfde eindtijd hebben, proberen we resources zo efficiënt mogelijk over te dragen. Dit door te kijken tot welk project i + j + 1 behoort (=de eerst volgende taak op de lijst met een ander eindtijd als i) en eerst resources door te geven van taken die tot eenzelfde project behoren. Indien meerdere taken moeten eindigen voordat er voldoende resources vrij komen om i + j + 1 te starten, worden resources van taken van hetzelfde project eerst doorgegeven volgens de volgorde van de CCB prioriteitenlijst. Indien dit nog steeds leidt tot een tekort, dan pas dragen we resources van een ander project over na het opslaan van een buffer nood tussen beide. Figuur 23: CCB bij éénzelfde eindtijd 58

71 In dit voorbeeld hebben we 3 verschillende projecten (aangegeven in het blauw, grijs en donkergrijs). De activiteiten 5, 3 en 4 hebben dezelfde eindtijd. We willen activiteit 6 van grondstoffen voorzien. Om grondstoffen zo efficiënt mogelijk over te dragen kijken we naar taken die tot hetzelfde project behoren. Dit tot activiteit 6 al de nodige grondstoffen heeft ontvangen. We zullen dus de grondstoffen van activiteit 4 en later van activiteit 3 overdragen naar activiteit 6. We dragen eerst de grondstoffen van 4 over en later deze van 3 omdat deze activiteiten in deze volgorde voorkomen op de prioriteitenlijst. Deze aanpassing leidt opnieuw tot een beter resultaat dan het blind volgen van de CCB prioriteitenlijst. 3) Indien meerdere activiteiten van eenzelfde project resources moeten overdragen opdat een activiteit (tevens van hetzelfde project) voldoende resources heeft om te starten, wordt er slechts 1 buffer toegevoegd na deze taak. Figuur 24: Na een activiteit maximaal één CCB. In dit voorbeeld dragen activiteit 3 en 7 hun resources over aan activiteit 8. Activiteit 8 geeft zijn resources door aan activiteit 9 en tussen deze activiteiten wordt er een buffer voorzien die het interval [0 tot eindtijd taak 8] buffert. Ook al liggen de resources na activiteit 3 even te wachten tot activiteit 7 eindigt, toch zorgt dit niet voor een gedeeltelijke reductie in CCB grootte zoals op de rechter figuur aangegeven. Dit omdat alle resources van activiteit 8 op slechts eenzelfde tijd kunnen vrijkomen. Indien er vertragingen zijn in activiteit 7 heeft dit gevolgen voor het vrijkomen van alle resources van activiteit 8. Merk nog op dat de CCB prioriteitenlijst bij een gelijke starttijd, als tweede criterium gesorteerd werd volgens oplopende duurtijd. Dit zorgt ervoor dat we de resources steeds zo snel mogelijk doorgeven. Door te werken met een heuristiek wordt het probleem beheersbaar maar bekomen we een oplossing die een benadering is van het optimum. Het is dus belangrijk om de zwaktes van de 59

72 heuristiek te kennen. Dit vormt een indicatie hoe ver we van het optimum verwijderd zijn. Hieronder worden de nadelen besproken: 1) Door te werken met een CCB prioriteiten lijst geven we resources door op basis van de volgorde van deze lijst. Hoewel er 3 correcties werden voorzien om resources zo efficiënt en correct mogelijk door te geven blijft dit een suboptimale manier van werken. 2) Doordat we eerst alle capacity constraint buffers opslaan en vervolgens pas toevoegen aan de planning bekomen we een suboptimale planning. Dit omdat het invoegen van een CCB bepaalde activiteiten doet verschuiven in de tijd. Hierdoor hebben eerdere CCB s mogelijks invloed op het doorgeven van resources en bijgevolg op andere CCB s. Dit probleem kan verholpen worden door iteratief te werken. Indien we na het toevoegen van één CCB een nieuwe planning maken en op basis van deze planning bekijken waar de volgende CCB moet worden toegevoegd komt deze fout niet meer voor. Aangezien een iteratieve methode veel meer rekenkracht vraagt en dit de run time van het programma sterk negatief kan beïnvloeden kiezen we om niet iteratief te werken. 3) Indien meerdere taken moeten eindigen om een niet aaneensluitende activiteit van resources te voorzien werken we niet met een gesplitste buffer. Dit omwille van de complexiteit om dan de correcte buffers toe te voegen in deze situatie. Figuur 25: beperking bij de gesplitste buffer Ook al heeft de heuristiek enkele nadelen, de belangrijkste voordelen om met deze heuristiek te werken is dat er rekening wordt gehouden met de situatie waarin meerdere bottleneck resources kunnen voorkomen. Ook werkt de heuristiek voor variërende prioriteitenlijsten (sectie 5.3.2). Bij het testen van een lijst waar niet-bottleneck taken vroeger voorkomen op de lijst dan bottleneck taken, kunnen we ook tot een planning komen waar de CCB correct werd toegevoegd. 60

73 5.3.5 OPSTELLEN ASAP MULTI-PROJECT SCHEMA INCL. CCB Na het doorlopen van het algoritme hebben we voor elke activiteit de eventuele nood aan een CCB opgeslagen. Bij het opnieuw plannen houden we rekening met deze informatie. De planning van een schema incl. CCB s gebeurt opnieuw via een prioriteitenlijst. De taken op deze lijst zijn gerangschikt volgens oplopende starttijd, waarbij de starttijden worden verkregen uit het multi-project schema exclusief buffers. Bij een gelijke starttijd worden taken gerangschikt volgens hun voorkomen op de prioriteitenlijst die als input werd gebruikt voor het maken van een schema zonder buffers. In de volgorde van deze prioriteitenlijst plannen we taken opnieuw ASAP maar nu moeten ook de CCB s in rekening worden gebracht. Dit gebeurt enerzijds door de beschikbare resources te verminderen na de activiteit waar de CCB moet komen met de grondstoffen nood van deze CCB, over de duurtijd van de CCB. Anderzijds passen we indien nodig de ES aan bij het ASAP plannen. Indien een activiteit wordt gepland na een CCB wordt de ES aangepast zodat deze activiteit pas kan starten na het beëindigen van de CCB. Bij het optreden van resource conflicten gaan we op dezelfde manier tewerk als bij het maken van een schema exclusief buffers CONSUMEER SLACK VAN NIET-BOTTLENECK TAKEN Het ER + CC algoritme wenst enerzijds de multi-project duurtijd te minimaliseren door bottleneck taken steeds ASAP te plannen. Anderzijds wenst het ook de voordelen van een ALAP gedeeltelijk te bekomen door slack te consumeren van niet-bottleneck taken. Dit doen we op dezelfde manier zoals beschreven in sectie waar we slack na consumeren voor individuele schema s. We werken dus opnieuw via een prioriteitenlijst waarop taken met een positieve slack na voorkomen en gesorteerd zijn volgens aflopende resources nood. In de volgorde van deze lijst wordt slack geconsumeerd. Het enige grote verschil in vergelijking met sectie is dat we nu enkel slack na consumeren van de niet-bottleneck taken over alle projecten heen. Merk op dat we bij het consumeren van slack na nu ook rekening moeten houden met de CCB s om te bepalen of het verlaten van de starttijd tot geen nieuwe resource conflicten leidt. Omdat een CCB steeds gelinkt is aan een bottleneck taak heeft het consumeren van slack geen invloed op de starttijd van de CCB s. 61

74 5.3.7 BEPALEN VAN DE DB NOOD De drum buffer beschermt de bottleneck taken tegen vertraging van voorgaande niet-bottleneck taken. Niet-bottleneck taken worden ALAP gepland, indien we geen buffer voorzien zouden vertragingen negatieve gevolgen hebben voor opvolgende bottleneck taken. De locatie van de drum buffer kan eenvoudig bepaald worden: tussen elke niet-bottleneck taak die opgevolgd wordt door een bottleneck taak hoort een drum buffer. Daarbij wordt de geplande starttijd van de nietbottleneck taak vervoegd met de buffer grootte en behouden we de starttijd van de bottleneck taak. We veronderstellen dat de DB geen resources reserveert. Voor het vastleggen van de buffer grootte gaan we op een gelijkaardig manier tewerk als bij het bepalen van de grootte van de feeding buffer. We bepalen namelijk de langste ketting van nietbottleneck taken die uitmondt in een bottleneck taak. Met deze ketting als input kan de grootte berekend worden via de eerder besproken RSEM methode. Opnieuw veronderstellen we dat de standaardafwijking even groot is als de helft van de duurtijd. Van al de nodige drum buffers slaan we eerst de grootte op en na welke taak deze buffer moet komen. Pas bij het opnieuw plannen van alle projecten voegen we deze buffers toe OPSTELLEN ASAP MULTI-PROJECT SCHEMA INCL. CCB EN DB Het opstellen van een planning inclusief drum buffer gebeurt opnieuw via een prioriteitenlijst. Op deze lijst zijn de activiteiten gesorteerd volgens afnemende starttijd en bij een gelijke starttijd volgens afnemende taak prioriteit. We gebruiken de planning na het toevoegen van de Capacity Constraint Buffers (sectie 5.3.6) als input om taken te ordenen volgens geplande starttijd. Bij het plannen starten we dus met het toevoegen van de activiteit met de hoogste starttijd aan de planning en eindigen we met het plannen van de activiteit die de vroegste starttijd heeft. Bij het aflopen van de prioriteitenlijst plannen we de taak steeds aan dezelfde starttijd als op het schema exclusief drum buffers tenzij er een drum buffer na deze activiteit moet komen. In dit geval vervroegen we de starttijd met de grootte van de buffer. Omdat niet-bottleneck taken steeds ALAP zijn gepland (door het consumeren van slack na ), kunnen de taken met slack voor een vroegere starttijd toegekend krijgen zonder dat dit invloed heeft op de starttijd van andere taken. Indien de slack voor kleiner is dan de buffernood moet de starttijd van voorgangers echter wel aangepast worden. Dit is in de planning geïncorporeerd door de starttijd + duurtijd van voorgangers steeds gelijk te stellen aan de vroegste starttijd van al zijn opvolgers. Zo worden deze taken ALAP gepland zonder dat er voorganger/opvolger relaties worden geschonden. We controleren ook of er geen 62

75 nieuwe resource conflicten ontstaan bij het plannen. Indien dit wel het geval is, vervroegen we de starttijd van de activiteit die we aan het inplannen zijn tot het conflict is opgelost. Via deze methode zal een taak nooit een latere starttijd hebben dan in vergelijking met het schema exclusief drum buffers. Doordat de starttijd van niet-bottleneck taken worden vervroegd, is het echter wel mogelijk (bij onvoldoende slack voor ) dat taken een negatieve starttijd toegekend krijgen (Figuur 26 illustreert dit). Het is dus noodzakelijk om na het plannen van alle activiteiten de starttijd van elke activiteit te verhogen met de meest negatieve tijd van de volledige planning. We verschuiven met andere woorden de volledige planning zodat deze op tijdstip nul begint. Merk op dat we bij het plannen ook steeds controleren of er een CCB aan de taak gekoppeld is. Bij het toevoegen van de CCB controleren we ook of de starttijd niet moet worden aangepast van de CCB en de bijhorende activiteit. Dit is soms noodzakelijk door het verschuiven van taken na het toevoegen van de DB en het veranderen van de beschikbare resources daardoor. Figuur 26: Negatieve starttijd In dit voorbeeld werden 2 projecten gepland volgens de prioriteitenlijst. Project 1 is aangegeven in het grijs en project 2 in het blauw. Activiteit 3 (project 1), activiteit 4 en activiteit 6 (project 2) zijn bottleneck taken. Om deze te beschermen tegen vertragingen identificeren we een DB nood na taak 1 (project 1) en taak 5 (project 2). Bij het plannen starten we met de eerste taak op de prioriteitenlijst, taak 6. Steeds controleren we of er geen resources tekorten zijn om de taak te plannen aan dezelfde starttijd uit het vorige opgesteld schema exclusief drum buffers en of er geen DB nood is. Voor taak 6 zijn beide testen negatief. Vervolgens plannen we taak 5. Voor deze taak moeten we de starttijd vervroegen omdat er een DB 63

76 nood is tussen taak 5 en 6. Omdat er geen slack voor is in dit schema heeft het vervoegen van de starttijd van activiteit 5 invloed op zijn voorgangers. Bij het plannen van taak 4 moeten we de starttijd ook vervroegen met de grootte van de DB omdat taak 5 pas kan starten na het vervolledigen van taak 4. Dit blijven we herhalen tot we alle taken op de prioriteitenlijst hebben gepland. In dit voorbeeld zien we dat door het toevoegen van drum buffers de eerst taak nu een negatieve starttijd heeft. We moeten dus de starttijd van alle taken aanpassen opdat het schema start op tijdstip 0. Het werken met deze prioriteitenlijst heeft enkele voordelen. Door te plannen volgens afnemende starttijd wordt de invloed van de ene drum buffer op de andere automatisch in rekening gebracht. Door het opnieuw plannen volgens de prioriteitenlijst vermijden we ook meteen de nood om taken te verschuiven door het ontstaan van resource conflicten. Dit omdat we meteen bij het plannen controleren als er voldoende resources beschikbaar zijn op een bepaald tijdstip TOEVOEGEN VAN FEEDING BUFFERS Voor het bepalen van de FB positie en de grootte gebruiken we dezelfde methode zoals beschreven in sectie Om buffers toe te voegen aan het multi-project schema voeren we enkele veranderingen door. Er geldt dat kritieke taken ASAP gepland zijn. Van deze taken controleren we de slack na voor het toevoegen van de FB. Indien deze slack kleiner is dan de nodige buffer grootte wordt er een foutmelding gegeven. Deze meldt dat er slechts een FB kon worden toegevoegd die even groot is als de grootte van de slack na. Niet-kritieke taken zijn ALAP gepland. Van deze taken controleren we dus als er voldoende slack voor is en indien er voldoende resources beschikbaar zijn om de taak te vervroegen met de buffer grootte. Opnieuw geven we een foutmelding indien de FB niet correct kon worden toegevoegd. Omdat bottleneck taken het systeem beperken werden ze gespreid en zijn deze vaak terug te vinden op de CC. De niet-bottleneck taken komen minder vaak voor op de CC. Dit kan tot gevolg hebben dat de feeding chain dezelfde is als de drum chain en er dus overlap is tussen de DB en de FB. Daar moet rekening mee gehouden worden. Indien we namelijk reeds een DB hebben toegevoegd en er is een FB nood op dezelfde locatie van dezelfde grootte, hoeven we deze niet meer toe te voegen. Indien de FB groter is dan de DB moeten we wel deze FB toevoegen. Merk op dat we nu slechts één project buffer toevoegen na de laaste activiteit van het multi-project schema. 64

77 MULTI SCHEMA LATEN STARTEN OP TIJDSTIP NUL Zoals aangegeven in sectie kunnen taken een negatieve starttijd hebben na het toevoegen van drum buffers. Het is dus noodzakelijk om het volledige multi-project te verschuiven zodat het start op tijdstip nul. De tijd waarmee we alle taken verschuiven is de kleinste, negatieve starttijd van alle taken. Indien alle taken starten op een tijdstip groter of gelijk aan nul is er geen nood om het volledige multi-project te verschuiven. 5.4 SCHEMA 3: MULTI-PROJECT OP BASIS VAN PROJECT PRIORITEITEN EXCL. FB In dit schema werken we via project prioriteiten. Een project kan starten van zodra er voldoende resources vrij komen OPSTELLEN ALAP MULTI-PROJECT SCHEMA Via deze methode plannen we op project niveau en niet langer op taak niveau. Als input gebruiken we een project prioriteitenlijst en maken we voor elk project (die tot het multi-project behoort) een individueel ALAP schema excl. FB met behulp van overzicht schema 1 (sectie tot en met 5.2.4). Merk op: hoewel het ER algoritme werd geïmplementeerd in C++, werden projecten niet geëvalueerd met het algoritme maar met een vuistregel. Dit omdat project prioriteiten worden bekomen aan de hand van strategische evaluatiecriteria. Aangezien we met fictieve data werken hebben we daar geen informatie over. Bij het testen van n projecten werd daarom steeds uitgegaan van volgende project prioriteitenlijst: project 1 > project 2 > project 3 > > project n. Binnen de multi-project planning, plannen we eerst het project met de hoogste prioriteit. Hierbij stellen we de starttijden van de taken gelijk aan de starttijden uit de individuele planning. Vervolgens kijken we wanneer het volgende project op de prioriteitenlijst kan starten. Dit doen we door de resources nood over de volledige duurtijd van het ALAP project in kwestie na te gaan. We verschuiven het ALAP project tot we een starttijd hebben gevonden waar er voldoende resources beschikbaar zijn om aan de resources nood over de volledige duurtijd van het te plannen project te voldoen. De projecten plannen we door alle starttijden bekomen uit schema 1 te verhogen met het tijdstip waarop er voldoende resources vrij gekomen zijn. Dit herhalen we tot alle projecten zijn gepland. 65

78 Merk op dat we alle resources checken en niet enkel de beperkende resources. Dit omdat we bij het valideren ook schema s testen met meerdere beperkende resources. Extra verduidelijking kan worden teruggevonden in figuur 13 (p44) waar een voorbeeld is beschreven BEPALEN VAN DE CCB NOOD Het bepalen van de CCB gebeurt via hetzelfde algoritme zoals beschreven in Merk op dat we nu wel een andere prioriteitenlijst hebben omdat deze gebaseerd is op starttijden uit het schema excl. CCB uit stap Door de andere planningsmethode zijn deze starttijden verschillend. Indien we gelijke starttijden hebben, sorteren we de taken op de CCB prioriteitenlijst volgens oplopende project prioriteit en vervolgens volgens oplopende slack OPSTELLEN ALAP MULTI-PROJECT SCHEMA INCL. CCB Voor het maken van een planning inclusief CCB s werken we terug via een gelijkaardige methode. De prioriteitenlijst wordt op eenzelfde manier opgesteld maar zal een andere uitkomst hebben door het verschil in starttijden. Het grote verschil met de ER + CC methode is dat we taken nu ALAP plannen en niet meer ASAP. Concreet wordt dit verwezenlijkt door na te gaan of een taak gepland kan worden aan dezelfde starttijd als het ALAP schema exclusief buffers. Indien door het reserveren van resources door de CCB dit niet meer mogelijk is, wordt deze taak verlaat in de tijd tot er wel genoeg resources beschikbaar zijn. Merk op dat indien er een gebrek is aan slack, het mogelijk is dat we bij het plannen van een volgende taak op de prioriteitenlijst ook deze moeten verlaten in de tijd doordat een CCB werd toegevoegd. Via deze werkwijze bekomen we een aaneensluiting van ALAP schema s inclusief een CCB bij de overgang van het ene project naar het andere CONSUMEREN VAN GECREËERDE SLACK DOOR TOEVOEGEN CCB Omdat het toevoegen van een CCB extra slack kan creëren is het noodzakelijk om slack na te consumeren. Bij de project prioriteiten planningsmethode werken we op dezelfde manier als de taak prioriteiten planningsmethode, maar nu wordt er slack geconsumeerd van elke taak en niet enkel van de niet-bottleneck taken. Volgende figuur illustreert. 66

79 Figuur 27: Slack consumeren na toevoegen CCB Na het toevoegen van de CCB tussen taak 4 en 6 wordt er slack na gecreëerd voor taak 5. Om een ALAP schema te bekomen verlaten we taak 5 zodat deze eindigt op tijdstip 20 i.p.v. tijdstip 18. Merk op dat we taak 2 ook kunnen verlaten na het consumeren van de slack van taak 5. Het huidig algoritme is echter nog niet in staat dit uit te voeren. De huidige werkwijze leunt echt wel dicht aan bij het optimum BEPALEN VAN DE DB NOOD Op een gelijkaardige manier zoals beschreven in sectie bepalen we de DB nood OPSTELLEN ALAP MULTI-PROJECT SCHEMA INCL. CCB EN DB Gebaseerd op het schema incl. CCB maken we een prioriteitenlijst volgens aflopende starttijd en volgens aflopende prioriteiten in het geval van een gelijke starttijd. Aan de hand van deze lijst maken we zoals op eenzelfde manier zoals ER + CC (eerder uitgelegd in sectie ) een schema inclusief drum buffer /5.4.8 TOEVOEGEN VAN FEEDING BUFFERS EN MULTI SCHEMA LATEN STARTEN OP TIJDSTIP NUL Om tot een finale planning te komen, voegen we opnieuw de feeding buffers toe en vervolgens laten het multi-project schema starten op tijdstip nul. De methodes die dit verwezenlijken werden eerder reeds besproken in sectie en SCHEMA 4: MULTI-PROJECT OP BASIS VAN TAAK PRIORITEITEN INCL. FB Voor deze methode gaan we op exact dezelfde manier tewerk zoals schema 3. Het enige verschil is dat we eerst feeding buffers toevoegen aan de individuele ALAP schema s. Merk op maakt nog een het verschil duidelijk tussen deze en de vorige planningsmethode. 67

80 5.6 SCHEMA 5: MULTI-PROJECT DOOR INDIVIDUELE PROJECTEN NA ELKAAR TE PLAATSEN In de meest eenvoudige planningsmethode plaatsen we de individuele schema s inclusief FB en PB na elkaar. Dit in de volgorde van de project prioriteitenlijst. Merk op: ook al consumeert de PB geen resources, toch zorgen we bij deze methode dat een volgend project pas kan starten na het beëindigen van de project buffer van het voorgaande project. 5.7 PROGRAMMA VALIDEREN Na het programmeren werd het C++ programma uitvoerig getest op verschillende netwerktypes. Hiervoor werd handmatig een multi-project schema opgesteld om dit te vergelijken met de output van het programma. Bij het voorkomen van inconsistenties werd de reden hiervoor gezocht en de code aangepast. Doordat heel wat testen werden uitgevoerd (op sterk variërende netwerken) kunnen we de kwaliteit van het programma garanderen. Het is echter wel nog steeds mogelijk dat het programma een error geeft voor een netwerk met enkele bijzonderheden. Dit omdat er assumpties werden gemaakt en het onmogelijk is om elke uitzondering ook te implementeren. Tijdens het formuleren van een antwoord op de onderzoeksvragen in sectie 6, kwam het programma in 97% van de gevallen tot een schema zonder een error. Het programma werd uiteraard ook getest op hetzelfde multi-project zoals besproken in de paper van Shalin Yangen Lei Fu. Deze output werd toegevoegd in het extra boekje in bijlage. De guideline van dit boekje geeft meer duiding hierover. De lezer zal bij het vergelijken van de resultaten uit de paper met de resultaten van de programma output echter wel kleine verschillen opmerken. De reden hiervan is dat de DB niet altijd correct werd toegevoegd in de paper. Bij het bekijken van Figure 7: Finally resources-based constrained scheduling of multi-project valt namelijk te zien dat bij project A2, na taak 1 er geen DB werd toegevoegd, ook al hebben we een overgang van een niet-bottleneck taak naar een bottleneck taak. Ook bij project A3 waar taak 3 opgevolgd wordt door taak 4, is de DB grootte te kort waardoor taak 3 te weinig verschuift naar een vroeger (negatief) tijdstip. 68

81 Deel III Resultaten 69

82 6 HET FORMULEREN VAN EEN ANTWOORD OP DE ONDERZOEKSPUNTEN In deze sectie gebruiken we het C++ programma om experimenten uit te voeren op fictieve RanGen data. Hierbij proberen we een antwoord te formuleren op volgende onderzoeksvragen: 1. Wat is het voordeel van het ER + CC model in vergelijking met andere planningsmethodes? 2. Wat is de invloed van meerdere beperkende resources op de multi-project planning? 3. Hoe bepalen we best de bottleneck resource? 4. Hoe bepalen we best de grootte van de CCB? 5. Wat is de sensitiviteit van de ER uitkomst op het multi-project? 6.1 ONDERZOEKSPUNT 3: HOE BEPALEN WE BEST DE BOTTLENECK RESOURCE In sectie beschreven we de implementatie van het bepalen van de bottleneck resource. Daar werden de zwaktes van de huidige methode beschreven en werd een nieuwe methode voorgesteld. Bij het uitvoeren van de testen wordt meteen gewerkt aan de hand van de nieuwe methode. De bottleneck resource is namelijk steeds deze resource die de grootste invloed heeft op de totale multi-project duurtijd. Om te bepalen welke methode tot de beste resultaten leidt, moeten multi-project schema s vergeleken worden die dezelfde projecten bevatten maar waar de bottleneck resource bepaald is via de verschillende regels. Een goede multi-project planning moet in staat zijn om de totale duurtijd zo kort mogelijk te houden, maar ook zekerheid kunnen verschaffen over het halen van die deadline. Een goed buffering is hierin cruciaal. Bij het bufferen moet er dus een balans worden gevonden tussen de positieve impact op de zekerheid en de negatieve impact op de duurtijd. Het testen van de zekerheid tot het halen van de deadline van een bepaald schema gebeurt via simulaties. Belangrijke input hierbij zijn de verdeling van de duurtijden, de relaties tussen de verschillende activiteiten en de positie/duurtijd van de buffers. Wegens de afwezigheid van vrij te gebruiken simulatie software voor multi-project schema s waren we niet in staat om de schema s te simuleren. Hier kunnen we enkel de invloed op de totale duurtijd van de verschillende bufferingsmethodes bespreken. Het spreekt voor zich dat de nieuwe methode tot langere multi-project schema s leidt omdat de regel zo gekozen is. Om te weten hoeveel langer deze schema s zijn bekijken we deze multi-project schema s waar de resource die de grootste invloed heeft op de multi-project duurtijd verschillend is van resource die de langste tijd op de CC controleert. Onderstaande tabel toont dat de nieuwe regel 70

83 een gemiddelde duurtijd stijging van 7% tot gevolg heeft. Merk op: de 12 geteste netwerken hadden steeds nood aan 3 verschillende resource types. Hiervan hadden er 2 min of meer dezelfde gebruiksgraad en had het 3 de resource type een erg lage gebruiksgraad. Zoals beschreven in sectie verwachten we echter dat de nieuwe methode veel doelgerichter buffers plaatst waardoor de duurtijd stijging van 7% gecompenseerd wordt door een schema met een veel grotere zekerheid tot het halen van de vooropgestelde deadline. Eventueel kan een opvolgend onderzoek via simulatie uitwijzen of deze lange duurtijd gerechtvaardigd is en tot een schema leidt met een significant grotere zekerheid. Bottleneck resource ER + CC 'multiproject' duurtijd: Langste tijd op CC Grootste invloed op duurtijd S50_RF80_RC75 1 S50_RF75_RC70 S50_R50_RC30 S50_RF70_RC % % % % S50_RF65_RC % S50_RF50_RC15 S80_RF80_RC50 S80_RF75_RC % % % % % % % S80_R55_RC % % % S30_RF80_RC % % S30_RF75_RC % S30_R55_RC % *Meer uitleg bij deze notatie volgt in sectie 6.2 GEMIDDELD 7% 71

84 6.2 ONDERZOEKSPUNT 1: WAT IS HET VOORDEEL VAN HET ER + CC MODEL IN VERGELIJKING MET ANDERE PLANNINGSMETHODES? Om het model te valideren vergelijken we de ER + CC methode met 3 andere planningstechnieken: na elkaar, project prioriteiten excl. FB en project prioriteiten incl. FB. We bestuderen zowel de duurtijden als de throughput tijden en we berekenen de procentuele verschillen. Dit werd als volgt bekomen: (duurtijd alternatief schema duurtijd ER + CC schema)/ duurtijd ER + CC schema. Een positieve waarde toont dus aan hoeveel langer de duurtijd/througput tijd van het alternatieve schema is, een negatief verschil legt bloot dat de ER + CC methode tot een langer duurtijd/througput tijd leidt. Meer informatie over de alternatieve planningsmethodes is terug te vinden in sectie 4.1. Bij deze vergelijkingen wensen we meer inzicht te krijgen bij welke projecttypes de ER + CC methode het grootste voordeel oplevert en bij welk projecttypes we beter een andere methode gebruiken. We verklaren ook steeds waarom. Vandaar onderzoeken we projecten met een variërende mate van serie (S) en een variërende mate van resource nood (RF en RC). We werken in drie verschillende levels : laag, gemiddeld en hoog. Variabelen S RF RC Laag: Gemiddeld: Hoog: Bij het testen hebben we voor eenzelfde type project (= projecten met dezelfde input waarde van de parameters), 45 verschillende projecten laten genereren door RanGen. Van deze projecten creëerden we 15 verschillende multi-projecten, elk bestaande uit drie projecten (waarbij elke project bestaat uit 10 niet-dummy activiteiten). Er werd voor 15 multi-projecten gekozen omdat het opdrijven tot bijvoorbeeld 30 multi-projecten niet meer leidt tot een grotere verandering van de resultaten. Verder is het laten opstellen van 15 multi-projecten per project type al erg tijdsintensief. De werkwijze om bijvoorbeeld de resultaten te verwerken van een project met slechts nood aan één resource type en waarvan S = 95, RF = 80, RC = 50 is, gebeurt als volgt: 72

85 1. We laten voor de 15 multi-projecten het programma lopen en vatten de gegevens samen in dergelijke tabel: Multi-Project Nummer Project vs. ER+CC S95_RF80_RC50 Project incl. fb vs. ER+CC Na elkaar vs. ER+CC 1: : : : : : : : : : : : : : : Deze tabel toont bijvoorbeeld aan dat het na elkaar plannen van multi-project 9 tot een totale duurtijd leidt die 23 tijdseenheden langer is dan indien we de ER + CC methode toepassen voor hetzelfde multi-project. Indien we project prioriteiten en project prioriteiten incl. fb vergelijken met de ER + CC planning zien we dat voor beide alternatieve methodes de totale duurtijd 15 tijdseenheden langer is. Voor de throughput maken we gelijkaardige tabellen (zie bijlage 9.3). Vervolgens zetten we deze verschillen om in percentages door ze te delen door de gemiddelde totale multi-project duurtijd van de ER + CC methode ( = 145 in dit voorbeeld). ER + CC Project Project fb Na elkaar DUURTIJD

86 2. Op basis van de gegevens uit de tabellen van stap 1 berekenen we het gemiddelde, kwartiel 1, kwartiel 3, de minimale waarde en de maximale waarde. S95_RF80_RC50 Project vs. ER+CC Project incl. FB vs. ER+CC Na elkaar vs. ER+CC Min: 6,9% 6,9% 15,2% Q1: 12,0% 12,0% 20,7% Q2: 15,9% 15,9% 26,9% Q3: 27,9% 27,9% 33,1% Max: 40,7% 40,7% 44,8% Deze tabel toont dat de project prioriteiten methode gemiddeld (over de 15 multiprojecten heen) tot een planning leidt die 16% langer is dan de ER + CC methode. Merk op dat we wel met sterk variërende waarden te maken hebben: voor Project vs ER + CC is het minimale voordeel 7% en het maximale voordeel 41%. 3. Met de tabel uit stap 2 als input kunnen we de resultaten visualiseren in een boxplot. 50% 45% 40% 35% 30% 25% 20% 15% 10% 5% S95_RF80_RC50 (n = 15) 0% Project vs. ER+CC Project incl. fb vs. ER+CC Na elkaar vs. ER+CC Figuur 28: Visualisatie van de resultaten in een boxplot Deze boxplot toont dat ER + CC tot significant kortere multi-project schema s leidt voor een netwerk met een hoge S en RF waarde en een gemiddelde RC waarde. Om de invloed van een variërende parameter te bestuderen wordt deze procedure meerdere keren doorlopen. Per test laten we één parameter variëren en behouden we de waarden van de andere parameters. Op basis van de bekomen data vergelijken en rapporteren we de procentuele gemiddelden van de duurtijden/throughput tijden die we uitkomen per test. 74

87 Om het type netwerk te beschrijven die wordt getest, werken we met deze notitie: S95_RF 180_RF 270_RC 150_RC 240. Hierbij geven we eerst aan wat de waarde is van de S parameter, vervolgens vermelden we de RF factor van resource 1 en daarna van resource 2. Tot slot geven we de RC van resource 1 en resource 2 aan. Indien we met meer of minder resources werken gaan we op dezelfde manier tewerk maar hebben we evenveel RF s en RC s als er resources zijn. In wat volgt, starten we met het testen van projecten die slechts nood hebben aan één resource type. Op deze manier hebben we slechts één beperkende factor en wordt de invloed van resource conflicten van niet-bottleneck taken nog even buiten beschouwing gehouden. Vervolgens drijven we het aantal resources op en bekijken we wat de invloed is van het toevoegen van één extra resource waarvan de gebruiksgraad ver onder de beschikbaarheid ligt. Na het testen van de methode op projecten met één duidelijk beperkende factor voeren we testen uit op projecten met meerdere beperkende factoren PROJECTEN MET 1 BEPERKENDE FACTOR TESTEN SERIE (S) Hier testen we wat de invloed is van de parameter serie (s) door deze te laten variëren. De andere parameters werden constant gehouden op RF = 80 en RC = 50. We veronderstellen dat het multiproject slechts nood heeft aan één resource type. Om onderstaande tabel te bekomen hebben we dus 3x de procedure van hierboven doorlopen voor telkens een ander project type waarbij enkel S varieert (30,50,95). Voor deze samenvattende tabel gebruiken we enkel de gemiddelden. DUURTIJD: Gemiddelden duur S Project vs. ER+CC Project incl. fb vs. ER+CC Na elkaar vs. ER+CC ER + CC 30: 5% 5% 1% : 10% 11% 9% : 20% 17% 27%

88 x_rf80_rc50 30% 27% 25% 20% 20% 17% 15% 10% 5% 5% 5% 1% 10% 11% 9% Project vs. ER+CC Project incl. fb vs. ER+CC Na elkaar vs. ER+CC 0% S Figuur 29: Testen duurtijd bij variërende S De ER + CC techniek leidt tot significant betere resultaten voor netwerken met een hoge in serie parameter. Bij het gebruik van de ER + CC methode komen we tot significant kortere multi-project schema s dan indien we de alternatieve planningsmethodes gebruiken bij sterk seriële netwerken (S = 95). Dit is te danken aan de relationele constraint tussen de activiteiten (constraint 1 uit sectie 2.2.3). Taken moeten namelijk wachten op het beëindigen van voorgangers alvorens ze kunnen starten ook al zijn er reeds voldoende resources beschikbaar. De individuele projecten bestaan uit lange kettingen met een relatief lage gebruiksgraad van de resources. Het bekomen van een multi-project schema door activiteiten na elkaar te plaatsen zorgt dus ook voor een inefficiënte gebruiksgraad van de resources. Indien we het multi-project plannen door middel van project prioriteiten komen we tot betere resultaten (=de methode leidt tot projecten met een minder lange duurtijd dan de na elkaar methode ). Omdat projecten echter pas kunnen starten indien er voldoende resources beschikbaar zijn over de volledige duurtijd van het te plannen project leidt deze methode nog steeds tot significant langere multi-project duurtijden dan de ER + CC methode. Met ER + CC daarentegen plannen we op taak level. Hierdoor kunnen er voor seriële netwerken, taken van verschillende projecten meer in parallel worden geplaatst. Dit reduceert de totale duurtijd en zorgt voor een efficiënter gebruik van de grondstoffen. Figuur 30 illustreert dit met een sterk vereenvoudigd voorbeeld. 76

89 Figuur 30a: Testen van seriële netwerken Figuur 30b: Testen van seriële netwerken Figuur 30c: Testen van seriële netwerken Figuur 30d: Testen van seriële netwerken Figuur 30a toont de 2 netwerken waaruit ons multi-poject bestaat. Indien we wensen te plannen op basis van de project prioriteiten methode toont figuur 30b en figuur 30c dat project 2 pas kan starten na taak 3 en 4 van project 1. Deze starttijd is echter wel vroeger dan de starttijd van het na elkaar plannen. Tot slot toont figuur 30d dat we door middel van taak prioriteiten de duurtijd van het multi-project schema significant kunnen reduceren. Merk op voor de eenvoud werden er geen buffers toegevoegd. 77

90 Indien S zakt zien we dat het voordeel kleiner wordt. Taken van individuele projecten kunnen nu in parallel worden gepland omdat de constraint die de relaties tussen de taken aangeeft minder beperkend is. Dit komt de gebruiksgraad van de resources voor een individueel project ten goede. Omdat deze gebruiksgraad stijgt, vormt deze een sterkere beperking om taken van verschillende projecten in parallel te plannen. De ER + CC methode is dus genoodzaakt om ook meer projecten na elkaar te plannen zoals de andere methodes. Bij parallelle netwerken is de totale duurtijd reductie dus kleiner. Projecten met slechts één resource bevatten geen drum buffers indien alle taken nood hebben aan deze resource (RF = 100). Dit type projecten bestaat dan enkel en alleen uit bottleneck taken. In deze test is de RF = 80 waardoor sommige taken geen nood hebben aan de beschikbare resource (verplichte rusttijden). Hierdoor kunnen we toch onderscheid maken tussen bottleneck taken en niet-bottleneck taken en ontstaat er een DB nood. Graag wensen we ook inzicht te krijgen in de invloed van de CCB en de DB op de verschillende planningsmethodes. Analyses tonen hier dat de invloed van het toevoegen van buffer sterk varieert van project tot project omdat verschillende mechanismen een tegenstrijdige invloed hebben. Meer uitleg hierover is terug te vinden in sectie Tot slot wensen we nog de invloed van de FB te analyseren. Hiervoor vergelijken we de project prioriteiten incl. FB methode met de project prioriteiten excl. FB methode. De bekomen resultaten hiervan staan haaks op de verwachtingen. Er werd verwacht dat de methode incl. FB tot kortere multi-project duurtijden zou leiden omdat een FB er voor zorgt dat sommige bottleneck taken een vroegere starttijd toegewezen krijgen, waardoor er sneller voldoende resources vrij komen om het volgend project te laten starten. Omdat parallelle netwerken gemiddeld langere Feeding Chains hebben en bijgevolg grotere feeding buffers werd verwacht dat het voordeel van de methode incl. FB zou groeien bij een dalende S parameter. Uit de testen blijkt echter dat de FB een zeer minieme invloed heeft op de multi-project duurtijd en dat in deze steekproef de methode excl. FB tot de beste resultaten leidt. Uit verdere analyse leerden we dat de invloed van de FB op de multi-project duurtijd zo klein is omdat bij de project prioriteiten methode de projecten pas kunnen starten als er voldoende resources beschikbaar zijn over de volledige duurtijd van het te plannen project. Het toevoegen van een FB zorgt voor een vervroegde beschikbaarheid van resources op een bepaald moment, echter kan het volgend project toch niet vroeger starten door de blijvende aanwezigheid van resource conflicten op andere 78

91 momenten. We zien dus dat er zelden verschillen zijn tussen deze 2 methodes voor het toevoegen van de CCB en de DB. Als we deze methodes vergelijken na het toevoegen van de CCB en de DB leidt de project prioriteiten incl. FB methode tot multi-project schema s met een iets langere duurtijd. De oorzaak ligt hier bij de CCB. Omdat de FB taken doet verschuiven komen we tot een andere prioriteitenlijst om de CCB nood te bepalen. Daarbovenop kunnen niet aaneensluitende taken plots aaneensluitend worden. We observeren dat het CCB algoritme tot een meer nadelige CCB nood leidt voor de duurtijd van het project bij de project prioriteiten incl. FB methode. THROUGPUT Throughput Project 1 0% % -10% -9% -9% -7% -7% Project vs. ER+CC -15% -20% -13%-12% Project incl. fb vs. ER+CC Na elkaar vs. ER+CC -25% -22% -22% S -21% Figuur 31a: Testen throughput bij variërende S Throughput Project 2 20% 15% 10% 5% 0% -5% 15% 15% 11% 7% 7% -1% -1% % 95 Project vs. ER+CC Project incl. fb vs. ER+CC Na elkaar vs. ER+CC -10% -6% S Figuur 31b: Testen throughput bij variërende S 79

92 Throughput Project 3 30% 27% 25% 20% 20% 19% 15% 10% 5% 5% 5% 1% 10% 11% 9% Project vs. ER+CC Project incl. fb vs. ER+CC Na elkaar vs. ER+CC 0% S Figuur 31c: Testen throughput bij variërende S *Merk op: de throughput project 3 ( = het laaste project) is gelijk aan de totale multi-project duurtijd. Vandaar dat de grafiek dezelfde is als deze uit de vorige sectie waarin de totale duurtijd werd bestudeerd. De ER + CC techniek leidt tot een betere throughput vanaf het 2de project voor netwerken met een hoge in serie parameter. Deze grafiek maakt duidelijk dat de ER + CC methode negatief is voor de throughput van het eerste project. Voor projecten bestaande uit slechts één resource met een RF < 1 consumeren niet alle taken de bottleneck resource. Bij het maken van een taak prioriteitenlijst ( ER+CC methode) komen daarom bottleneck taken van een project met een lagere prioriteit voor de niet-bottleneck taken van een project met een hogere prioriteit. Dit resulteert in een planning waar taken van verschillende projecten door elkaar zijn gepland, de CCB s zorgen dat taken worden verschoven naar latere starttijden waardoor we een slechtere throughput van project 1 hebben. Daarnaast spelen ook de DB mechanismen (zoals beschreven in sectie ) en hebben we bij de ER + CC methode meer verschuivingen van het volledige multi-project en hierdoor eindigt het eerste project gemiddeld op een later tijdstip. Merk op, omdat niet-bottleneck taken in deze situatie geen resource nood hebben (slechts één resource en RF = 0 voor deze taken) ontstaan geen resource conflicten bij het inplannen van deze taken en hoeven ze dus niet te verschuiven naar een later tijdstip. Een illustratie van de invloed van de CCB is opgenomen in figuur

93 Figuur 32: Invloed van CCB op de throughput Dit voorbeeld toont aan hoe de taken 2 en 3 van project 1 een latere starttijd toegewezen kregen omdat de ER + CC methode taak 4 parallel plant met de taken van project 1. Doordat er tussen taak 4 (project 2) en taak 3 (project 1) een CCB moet geplaatst worden verschuiven achterliggende taken en heeft project 1 een langere duurtijd dan in vergelijking met het na elkaar plannen van de projecten. Bij het plannen met de project prioriteiten methode, zijn er minder overgangen tussen de projecten en is de invloed van de CCB kleiner. Project 1 is hierdoor gemiddeld sneller klaar dan in vergelijking met de ER + CC methode. Indien we werken met de na elkaar methode worden er geen CCB s aan het schema toegevoegd omdat we werken met project buffers. Dit heeft een sterk positieve invloed op de duurtijd van het eerste project. Een onverwachte waarneming is dat S weinig invloed heeft op de throughput van het eerste project. Er werd verwacht dat een hoge S een significant langere duurtijd van het eerste project zou veroorzaken doordat taken van verschillend projecten sterker door elkaar worden geplaatst en de CCB nood hierbij wordt opgedreven. Na verder analyse (sectie ) zien we dat niet het aantal CCB s maar vooral de locatie, de duurtijd van de CCB en de beschikbaarheid aan resources de belangrijkste variabelen zijn. Bij het bestuderen van de throughput van het tweede project zien we dat S wel een belangrijke factor is. Een stijging van S zorgt namelijk voor een significant kortere duurtijd van project 2 binnen het multi-project schema. Dit valt te verklaren doordat bij seriële netwerken taken van verschillende projecten meer in parallel worden gepland bij de ER + CC methode. Hierdoor moeten minder taken nog worden uitgevoerd van project 2 na de afloop van project 1. Dit komt de totale duurtijd van dit project ten goede. 81

94 Indien we de project prioriteiten methode vergelijken met het na elkaar plannen, zien we dat project 2 een langere duurtijd heeft bij de project prioriteiten methode. Eén verklarend effect hiervoor is de significant kortere duurtijd van de PB in vergelijking met de CCB. Indien de resource nood te groot is van project 2 om project 2 reeds te starten voor het beëindigen van project 1, worden deze na elkaar geplaatst met daartussen een CCB die veel langer is dan de PB. Voor de throughput van het derde project kan worden verwezen naar sectie : Duurtijd. In wat volgt bespreken we enkel nog de throughput van project 1 en 2 omdat de verwachte eindtijd van het laaste project (project 3) steeds gelijk is aan verwachte eindtijd van het multi-project schema en uitvoerig wordt besproken onder de titels Duurtijd TESTEN RESOURCE CONSTRAINEDNESS (RC) Hier testen we wat de invloed is van de Resource Constrainedness (RC) door deze te laten variëren. De andere parameters werden constant gehouden op S = 50 en RF = 80. DUURTIJD: Gemiddelden duur RC Project vs. ER+CC Project incl. fb vs. ER+CC Na elkaar vs. ER+CC ER + CC 30: 20% 18% 36% 88 50: 10% 11% 9% : 6% 6% 0% 159 S50_RF80_x 40% 35% 36% 30% 25% 20% 20% 18% Project vs. ER+CC 15% 10% 5% 0% 10% 11% 9% 6% 6% % Project incl. fb vs. ER+CC Na elkaar vs. ER+CC RC Figuur 33: Testen duurtijd bij variërende RC De ER + CC techniek leidt tot significant betere resultaten voor netwerken met een niet al te hoge gebruiksgraad van de resources. 82

95 Deze test geeft duidelijk weer dat RC een belangrijke factor is. Algemeen geldt voor een lage RC dat de ER + CC techniek tot multi-project schema s leidt die een significant kortere duurtijd hebben dan de schema s bekomen met behulp van de alternatieve methodes. Dit resultaat ligt in de lijn van de verwachtingen. Hoe lager de resources gebruiksgraad van de individuele projecten hoe meer ruimte er is om in de multi-project planning taken van verschillende projecten in parallel te plannen. We zien dat RC de grootste invloed heeft op Na elkaar vs ER + CC. Bij een lage resources gebruiksgraad van de taken (RC = 30), zorgt het na elkaar plannen van de individuele schema s voor een multi-project schema met een tevens zeer lage resource efficiëntie. Bij een hoge resource gebruiksgraad van de taken (RC = 80), resulteert het na elkaar plannen al in een relatief goede resource efficiëntie. Daarnaast werkt de na elkaar methode met een PB tussen de projecten en niet met CCB s. Deze PB is in het algemeen korter omdat de grootte bepaald wordt aan de hand van een sterker onderbouwde techniek (RSEM vs. 30% regel). De kortere PB is tevens de verklaring voor het verschil tussen de project prioriteiten methode en de na elkaar methode bij een RC van 80. In wat volgt testen we ook nog de invloed van een lage RC in combinatie met een varierende S: Project vs. ER +CC Na elkaar vs. ER +CC S stijgt S50_RF80_RC30 20% 36% S60_RF80_RC30 27% 52% S95_RF80_RC30 19% 89% S95_RF80_RC20 0% 145% Het vergelijken van deze schema s maakt duidelijk dat de combinatie van een hoge S met een lage RC het voordeel van de ER + CC methode versterkt. Zeker bij het bekijken van na Na elkaar vs. ER + CC kolom zien we blijvend voordeel bij een toenemende S of/en een afnemende RC. De vergelijking tussen de project prioriteiten methode met de ER + CC methode toont het bestaan van limieten. Een beperkte stijging van S gegeven een lage RC is nog steeds in het voordeel van de ER + CC methode. Indien S echter stijgt tot bijvoorbeeld 95, neemt dit voordeel opnieuw af. De verklaring hiervoor is dat er in dergelijke projecten gemiddeld voldoende resources beschikbaar zijn om de volledige projecten meer in parallel te plannen. Hierdoor is het voordeel van ER + CC uiteraard kleiner. Via trial en error vonden we dat bij S95_RF80_RC20 projecten volledig in parallel kunnen worden gepland via de project prioriteiten methode en dat er ook nog voldoende resources 83

96 beschikbaar zijn voor de CCB s zodat deze geen verschuivingen teweeg brengen. Merk op dat het voordeel van ER + CC op de multi-project duurtijd enorm is vergeleken met het na elkaar plannen. Bij het bestuderen van de invloed van de buffers op de verschillende methodes spelen dezelfde mechanismen zoals beschreven in sectie THROUGHPUT 0% Throughput Project % -10% -8% -6% -9% -9% -5% -5% Project vs. ER+CC Project incl. fb vs. ER+CC -15% Na elkaar vs. ER+CC -16% -20% -25% -21% -22% RC Figuur 34a: Testen throughput bij variërende RC Throughput Project 2 30% 25% 20% 15% 10% 5% 0% -5% -10% 24% 13% 14% 7% 7% 1% 1% % 80-6% RC Project vs. ER+CC Project incl. fb vs. ER+CC Na elkaar vs. ER+CC Figuur 34b: Testen throughput bij variërende RC De ER + CC techniek leidt tot een betere throughput vanaf het 2 de project voor netwerken met een lage RC parameter. 84

97 De invloed van RC op de throughput van het eerst project is vergelijkbaar met de invloed van S. Hierbij leidt een lage RC tot dezelfde resultaten als een hoge S. De slechtere throughput van project 1 is namelijk opnieuw te verklaren door de CCB s. Voor het tweede project kunnen we ook dezelfde opmerkingen maken zoals beschreven in de vorige sectie. Een lage RC creëert de mogelijkheid om meer taken van verschillend projecten in parallel te plaatsen waardoor de ER + CC methode tot significant kortere duurtijden leidt van project 2 binnen het multi-project schema TESTEN RESOURCE FACTOR (RF) Hier testen we wat de invloed is van de Resouce Factor (RF) door deze te laten variëren. De andere parameters werden constant gehouden op S = 50 en RC = 50. DUURTIJD Gemiddelden RF Project vs. ER+CC Project incl. fb vs. ER+CC Na elkaar vs. ER+CC ER + CC 30: 0% 2% 90% 57 50: 12% 12% 26% 94 80: 10% 11% 9% 125 S50_x_RC50 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% 0% 2% 90% 26% 12% 12% 10% 11% 9% Project vs. ER+CC Project incl. fb vs. ER+CC Na elkaar vs. ER+CC RF Figuur 35: Testen duurtijd bij variërende RF Bij een erg lage RF kunnen volledige projecten in parallel worden gepland en heeft ER + CC geen voordeel meer. 85

98 Het testen van schema s met een nood aan slechts één resource en met een lagere RF heeft hier invloed op het aantal niet-bottleneck taken. De lage RF leidt tot meer taken zonder resource nood ( = rusttijden) en dus tot minder bottleneck taken. Bij het opstellen van een schema heeft dit invloed op de prioriteitenlijst en het bufferen. Meer niet-bottleneck taken betekent een grotere DB nood. In combinatie met weinig slack voor (sectie ) zorgt dit voor meer verschuivingen van het volledige schema. Voor de interpretatie van de resultaten van na ekaar vs ER + CC geldt dat de invloed van RF vergelijkbaar is met de invloed van RC. Bij een lage RF hebben heel wat taken geen resources nodig, hierdoor blijven er voldoende middelen beschikbaar om taken van andere projecten in parallel toe te voegen aan het schema. We zien dus multi-project schema s met een significant korter duurtijd bij het gebruik van ER + CC in vergelijking met het na elkaar plannen van de projecten. Het vergelijken van de project prioriteiten methode met ER + CC zien we een niet-lineaire invloed van RF op de totale duurtijd. De reden hiervan werd reeds besproken bij de tabel op p92. Indien de gebruiksgraad van de resources namelijk erg laag ligt, wat het geval is voor RF = 30, kunnen volledige projecten in parallel worden uitgevoerd. Hierdoor heeft ER + CC geen voordeel meer ten opzichte van de project prioriteiten methode. Figuur 36 geeft dit grafisch weer. Figuur 36a: Invloed van een erg lage resource gebruiksgraad Figuur 36b: Invloed van erg lage resource gebruiksgraad 86

99 Van de projecten weergegeven in figuur 36a wensen we een multi-project planning te maken. Door de lage RF hebben taak 2 en taak 6 geen resources nodig. Het b luik van de figuur geeft de uitkomst weer. We zien dat er voldoende resources op overschot zijn om de 2 projecten in parallel uit te voeren. Indien we dus werken met project prioriteiten of taak prioriteiten komen tot dezelfde planning. Het is niet evident om te bepalen vanaf welke RF waarde het hierboven beschreven effect zich voordoet omdat S en RC ook een bepalende factor zijn. Indien S en RC gemiddeld zijn vinden we via trail and error dat vanaf een RF van 30 het effect voldoende optreedt zodat het gemiddeld voordeel ( Project vs ER + CC ) nul is. Merk op: eenmaal RF voldoende hoog is, zodat volledige projecten niet langer parallel kunnen gepland worden, is de invloed van een stijgende RF op de multi-project duurtijd eerder klein bij Project prioriteiten vs ER + CC. THROUGHPUT Throughput Project 1 0% % -10% -3% -5% -5% -5% -9% -9% -15% Project vs. ER+CC Project incl. fb vs. ER+CC -20% -25% -20% -24% -22% Na elkaar vs. ER+CC -30% RF Figuur 37a: Testen throughput bij variërende RF 87

100 Throughput Project 2 60% 54% 50% 40% 30% Project vs. ER+CC 20% 10% 2% 3% 14% 11% 10% 7% 7% Project incl. fb vs. ER+CC Na elkaar vs. ER+CC 0% -10% RF -1% Figuur 37b: Testen throughput bij variërende RF Voor een lage RF (RF = 30) komt ER + CC tot min of meer dezelfde planning als de project prioriteiten methode, hierdoor is de throughput vergelijkbaar. Bij het bestuderen van de throughput van het eerste project, komen we voor een RF van 30 tot 50 tot min of meer dezelfde throughput voor de project prioriteiten methode en de ER + CC methode. Bij een RF van 30 worden volledige projecten parallel gepland. Bij een RF van 50 is dit niet het geval maar zijn er toch nog genoeg resources zodat de CCB geen verschuivingen teweeg brengt als deze de resources reserveert. Figuur 38 toont een vereenvoudigd voorbeeld. Bij een hoge RF in combinatie met een gemiddelde S en RC zorgt de ER + CC methode voor een slechtere throughput van het eerste project. De reden hiervoor is dat de CCB voor verschuivingen zorgt van taken van project 1. Dit mechanisme werd in de vorige secties reeds besproken. Figuur 38: Throughput bij een lage RF 88

101 Een eerder verrassend resultaat is dat projecten met een lage RF zorgen voor een kortere duurtijd van het eerste project als de projecten na elkaar worden gepland (bij hete vergelijken met de ER + CC methode). Het parallel plannen van taken van andere projecten leidt namelijk niet tot verschuivingen omdat er toch voldoende resources op overschot zijn voor de resources reservatie van de CCB. Verdere analyses tonen aan dat het toevoegen van de drum buffers de oorzaak was van de verschillende throughput tijd. Omdat de ER + CC methode bij een lage RF relatief veel DB s moet toevoegen is het beschreven effect uit sectie groter. Merk op dat bij het na elkaar plannen geen DB s worden toegevoegd aan de planning. Voor het tweede project is het verschil in throughput bij Project prioriteiten vs ER + CC voor RF = 30 uiteraard ook erg klein. Dit doordat beide methodes min of meer tot dezelfde parallelle planning komen. Een RF = 50 zorgt voor kleine verschillen. ER + CC is hierbij in het voordeel omdat deze methode bij een gemiddeld resource gebruik toch meer in parallel kan plannen dan de project prioriteiten methode INVLOED VAN BUFFERS CCB Bij het vergelijken van de ER + CC methode met de project prioriteiten methode voor en na het toevoegen van de CCB zien we sterk variërende resultaten. Het verwachte effect dat de CCB s het voordeel van de ER + CC methode deels elimineert doet zich niet altijd voor. Het werken met taak prioriteiten zorgt wel degelijk voor een hogere CCB nood en bijgevolg meer verschuivingen van de projecten zoals aangegeven op figuur 39. Figuur 39: De invloed CCB op resultaten 89

102 In dit voorbeeld wordt eenzelfde multi-project gepland volgens de project prioriteiten methode en de ER + CC methode. Onder de ER + CC methode is de CCB nood hoger omdat taken van verschillende projecten meer in parallel zijn gepland. Door de CCB nood wordt de starttijd van activiteit 6 en 8 verlaat. Dit heeft tot gevolg dat ook de opvolgers opschuiven naar een latere starttijd. Het voordeel van de ER + CC methode wordt dus gedeeltelijk geneutraliseerd door het toevoegen van de CCB s. Toch leidt het toevoegen van de CCB niet altijd tot een grotere verlenging van de multi-project duurtijd bij de ER + CC methode dan bij de project prioriteiten methode. Het verwachte effect zoals hierboven beschreven doet zich enkel voor als er te weinig resources beschikbaar zijn om een volgend project te starten voor de afloop van het vorige project en indien ER + CC wel enkele taken in parallel kan plannen. Dit is het geval bij een relatief hoge gebruiksgraad van de resources en een maximale gebruiksgraad van de resources op het einde van project 1 (een zeer zeldzame situatie dus). Het variërende effect van de CCB op de multi-project duurtijd is te wijten aan de beschikbare resources, de grootte van de CCB en de CCB locaties. Deze variabelen hebben een sterke impact: o o o Gegeven dat de CCB resources reserveert, zorgt een project met een hoge resources gebruiksgraad dat het toevoegen van de CCB resource conflicten veroorzaakt. Hierdoor moeten taken worden opgeschoven en verhoogt de duurtijd van het project in kwestie. Indien de CCB een lange ketting aan voorgangers heeft is de CCB duurtijd groter en bij gebrek aan resources zijn de verschuivingen van de taken na de CCB groter. In het algemeen geld dat switchen tussen projecten dicht bij het aflopen van één project leidt tot langere ketting van voorliggende taken waardoor de CCB duurtijd groter is. Doordat de invloed van de CCB zo sterk varieert van project tot project, kunnen we niet eenduidig zeggen dat (voor een gegeven multi-project planning excl. CCB) het toevoegen van de CCB s het meest negatief zal zijn voor de duurtijd van de ER + CC methode of voor de duurtijd van de project prioriteiten methode. Indien we voor een set projecten de bijkomende duurtijd van het toevoegen van de CCB bij de project prioriteiten methode vergelijken met de bijkomende duurtijd van het toevoegen van de CCB bij de ER + CC methode zien we gemiddeld dat dit verschil dicht bij nul ligt. 90

103 Merk op, de methode die de projecten na elkaar plant voegt geen CCB toe. Een gelijkaardige vergelijking maken met deze methode is dus niet mogelijk. DB Sectie beschreef hoe de drum buffers aan het multi-project schema worden toegevoegd. Daarin werd duidelijk dat de slack voor van de niet-bottleneck taken een sterke invloed heeft. Indien deze namelijk kleiner is dan de DB grootte, heeft de DB ook invloed op de starttijd van de voorgangers van de niet-bottleneck taak. Dit kan een ketting in werking zetten waardoor het multiproject schema niet meer start op tijdstip nul. In dit geval dienen we het volledige multi-project te verschuiven tot er geen negatieve starttijd meer in het schema is opgenomen. Samengevat, indien we het volledige multi-project moeten verschuiven heeft de DB een negatieve invloed op de starttijd van alle taken, zowel niet-bottleneck taken als bottleneck taken. De invloed van de DB op verschillende planningsmethodes vergelijken we door zowel de multiproject duurtijden voor en na het toevoegen van de DB te bestuderen. In het algemeen geldt dat de drum buffers het tijdsduurvoordeel van de ER + CC methode gedeeltelijk reduceert. Dit omdat deze methode een schema maakt met minder slack, waardoor de DB niet kan worden opgevangen door slack voor en de multi-project planning gemiddeld een sterkere negatievere starttijd heeft van de eerste activiteit. We moeten dus alle activiteiten meer verschuiven in de volgende stap zodat het schema start op tijdstip nul. Er is in het ER + CC schema minder slack aanwezig omdat deze methode bottleneck taken steeds ASAP plant. De methode op basis van project prioriteiten maakt daarentegen een multi-project planning als een aaneenschakeling van individuele ALAP schema s. Hierdoor komt dit probleem minder sterk voor. Extra verduidelijking wordt gegeven in figuur 40a. Figuur 40a: invloed van DB op de resultaten 91

104 In dit voorbeeld bestaat het multi-project uit 2 projecten en de bottleneck taken zijn aangeduid in het donker grijs. Het linker deel van figuur 40a bevat een schema gebaseerd op de ER + CC methode. Bottleneck taken worden hier ASAP gepland, hierdoor komt de bottleneck resource sneller vrij en kan taak 5 een vroegere starttijd toegewezen krijgen. Doordat taak 5 vroeger start op het schema zorgt dit voor de eliminatie van slack tussen taak 4 en 5. Het toevoegen van de DB heeft een multi-project schema met een negatieve starttijd tot gevolg en daarom moeten we het volledige schema verschuiven opdat taak 4 start op tijdstip nul (dus ook de taken van project 1). Het rechter deel van figuur werkt met CCPM en project prioriteiten. Hier is taak 3 ALAP gepland waardoor er meer slack aanwezig is. Na het toevoegen van de DB start het multi-project schema al op een tijdstip 0 en moeten we geen verschuiving meer doorvoeren. Naast dit mechanisme moeten we ook rekening houden met de mate waarin de ene DB invloed heeft op de andere drum buffers. Indien deze buffers namelijk in parallel kunnen worden gepland is het effect op de totale multi-project duurtijd minder nadelig dan drum buffers gepland in serie. Figuur 40b en 40c verduidelijken dit mechanisme. Toevoegen DB Figuur 40b: invloed DB op resultaten 92

105 Toevoegen DB Figuur 40c: invloed DB op resultaten Figuur 40b (=ander multi-project dan figuur 40a) gebruikt de ER + CC methode. Hierdoor bekomen we een planning waarin taken meer parallel worden gepaland. Na het toevoegen van de drum buffers zien we dat DB 1 geen invloed heeft op DB 2 waardoor de verschuivingen na het toevoegen van de DB s eerder beperkt zijn. In Figuur 40c wordt een planning opgesteld aan de hand van project prioriteiten. Hier is het multi-project meer in serie gepland waardoor DB 2 invloed heeft op DB 1. Het gevolg hiervan is meer verschuivingen. Activitiet 7 heeft namelijk een sterk negatieve starttijd waardoor alle taken in de volgende stap moeten worden verschoven opdat het schema kan starten op tijdstip nul. Voor sterk seriële netwerken (S = 95) zien we dat het laatst beschreven mechanisme het sterkst is. Daar zorgt de DB dat het voordeel van de ER + CC methode groter wordt. De reden hiervan is dat bij dit type netwerk taken van verschillende projecten parallel kunnen worden gepland en we dus parallelle drum buffers hebben UITBREIDING NAAR TWEE RESOURCES DUURTIJD Hier testen we de invloed van het toevoegen van een extra niet-beperkende factor met RF = 80 en RC = 30. We kijken naar de invloed door deze te vergelijken met de schema s met 1 beperkende resource. We vergelijken dus bijvoorbeeld het multi-project type S50_RF80_RC80 met het type S50_RF 180_RF 280_RC 180_RC 230. Voor de eenvoud geven we enkel het netwerk met slechts één resource op bij de notatie. De lezer weet echter dat dit netwerk dan steeds vergeleken werd met een netwerk met dezelfde parameters maar waarvan een 2 de resource werd toegevoegd met RF = 80 en RC =

106 Project vs. ER+CC Gemiddelden Duurtijd 1 Resource 2 Resources Project incl. fb vs. ER+CC Na elkaar vs. ER+CC ER + CC Project vs. ER+CC Project incl. fb vs. ER+CC Na elkaar vs. ER+CC S50_RF80_RC80 6% 6% 0% 159 4% 4% -1% 171 S50_RF80_RC50 10% 11% 9% % 10% 11% 131 S95_RF80_RC50 20% 19% 27% % 12% 27% 146 ER + CC 1 Resource vs 2 Resources 30% 25% 20% 20% 19% 27% 27% 15% 10% 5% 0% -5% 6% 10% 11% 11% 11% 12% 12% 9% 10% 6% 4% 4% 0% S50_RF80_RC80-1% S50_RF80_RC50 S95_RF80_RC50 1 Resource Project vs. ER+CC 1 Resource Project incl. fb vs. ER+CC 1 Resource Na elkaar vs. ER+CC 2 Resources Project vs. ER+CC 2 Resources Project incl. fb vs. ER+CC 2 Resources Na elkaar vs. ER+CC Figuur 41: Invloed van het opdrijven van de resources op de duurtijd Deze grafiek kan worden gelezen door de grijze tinten met de rode tinten te vergelijken. Hierbij stellen de grijze staven multi-projecten voor met slechts één type resource. De rode staven zijn multi-projecten met twee type resources waarvan slechts één resource het systeem beperkt. Deze test toont dat het toevoegen van een niet beperkende resource, het tijdsvoordeel van ER + CC ten opzichte van de andere methodes verkleint. Deze trend is zichtbaar voor de 3 verschillende netwerk types. Door ook deze vergelijking ook te maken met multi-project schema s exclusief buffers onderzoeken we als het verschil te wijten is aan het toevoegen van de CCB en DB. (zie figuur 42) 94

107 1 Resource vs 2 Resources excl. buffers* 30% 25% 27% 25% 20% 15% 10% 5% 0% -5% 17% 11% 12% 11% 12% 9% 7% 6% 1% S50_RF80_RC80-1% S50_RF80_RC50 S95_RF80_RC50 1 Resource Project vs. ER+CC 1 Resource Na elkaar vs. ER+CC 2 Resources Project vs. ER+CC 2 Resources Na elkaar vs. ER+CC Figuur 42: Invloed van het opdrijven van de resources op de duurtijd (excl. buffers) *Merk op: project incl. fb vs ER + CC werd niet opgenomen in deze grafiek Het vergelijken van de schema s excl. buffers tonen aan dat het toevoegen van een extra nietbeperkende resource het voordeel van de ER + CC methode verkleint. De verschillen zijn echter klein en vooral zichtbaar bij het S95_RF80_RC50 netwerk. Omdat het niet mogelijk is dat de schema s van de project prioriteiten methode verkorten door het toevoegen van een resource, kunnen we besluiten dat de extra resource de duurtijd van de ER + CC schema s opdrijft. Het is dus zo dat een extra resource zelden invloed heeft op de starttijd van een volgend project bij de project prioriteiten methode maar wel een kleine invloed heeft op de mogelijkheid om taken van verschillende projecten parallel te plannen ( = ER + CC methode). Resource conflicten van de nietbottleneck resource zorgen namelijk in enkele zeldzame gevallen dat er niet genoeg resources beschikbaar zijn om een taak van een ander project in parallel te plannen. Het vergelijken van de licht grijze en de roze staven van de 2 staaf diagrammen (= 1 Resource Project vs. ER+CC van figuur 41 vs. 1 Resource Project vs. ER+CC figuur van 42 en 2 Resources Project vs. ER+CC van figuur 41 vs. 2 Resources Project vs. ER+CC van figuur 42), toont wat de invloed is van het toevoegen van de buffers. We leren hieruit dat een extra resource er voor zorgt dat het toevoegen van de CCB en DB het voordeel van de ER + CC iets meer reduceert dan bij de schema s met 1 resource. Dit is vooral te wijten aan de beperkte slack voor bij ER + CC en het DB mechanisme besproken in sectie Merk wel op dat we met een steekproef werken van 15 waarnemingen. Verschillen kunnen dus ook ontstaan door uitschieters die het gemiddelde beïnvloeden. Bij het bestuderen van boxplots van de testen zien we echter wel dat er geen grote verschillen zijn tussen de spreidingen. 95

108 THROUGHPUT Throughput Project 1 5% 0% -5% -10% -15% -20% -25% 0% 1% S50_RF80_RC80 S50_RF80_RC50 S95_RF80_RC50-5% -5% -4% -3% -4% -6% -7% -7% -9% -9% -9% -16% -16% -17% -22% -21% 1 Resource Project vs. ER+CC 1 Resource Project incl. fb vs. ER+CC 1 Resource Na elkaar vs. ER+CC 2 Resources Project vs. ER+CC 2 Resources Project incl. fb vs. ER+CC 2 Resources Na elkaar vs. ER+CC Figuur 43a: Invloed van het opdrijven van de resources op de throughput Throughput Project 2 20% 15% 10% 5% 0% -5% -10% 1% 15% 15% 11% 7% 7% 5% 5% 4% 4% 3% 3% 1% 1% S50_RF80_RC80 S50_RF80_RC50-1% S95_RF80_RC50-6% -6% 8% 1 Resource Project vs. ER+CC 1 Resource Project incl. fb vs. ER+CC 1 Resource Na elkaar vs. ER+CC 2 Resources Project vs. ER+CC 2 Resources Project incl. fb vs. ER+CC 2 Resources Na elkaar vs. ER+CC Figuur 43b: Invloed van het opdrijven van de resources op de throughput Bij het vergelijken van de ER + CC methode met de andere planningsmethodes zien we dat het toevoegen van een niet-beperkende resource ervoor zorgt dat het eerste project een kortere duurtijd heeft. Dit sluit aan met wat hierboven werd beschreven. Doordat we iets minder taken in parallel kunnen plannen, is de CCB nood kleiner en moeten taken van project 1 dus minder verschuiven naar een later tijdstip. 96

109 Gemiddeld daalt het voordeel van de ER + CC methode op de duurtijd van het 2 de project binnen het multi-project in vergelijking met de andere methodes. Dit komt, zoals eerder aangehaald, omdat er minder taken in parallel kunnen worden gepland met het eerste project. Het voordeel is echter wel klein en is het duidelijkst bij projecten met een gemiddelde RC en een hoge S. Merk nog op: bij eenzelfde RF blijft het aantal taken dat geen nood heeft aan de beperkende resource hetzelfde. Met andere woorden, het aantal niet-bottleneck taken is niet veranderd. Het toevoegen van een niet-beperkende resource is dus niet bepalend voor het aantal niet-bottleneck taken. Het enige verschil is dat de niet-bottleneck taken nu nood hebben aan een niet-beperkende resource. Indien er onvoldoende resources beschikbaar zijn kunnen er wel bijkomende resource conflicten ontstaan voor deze extra niet-bottleneck resource. Bijgevolg moeten taken verschuiven en vergroot de multi-project duurtijd. Deze invloed wordt verder besproken in de volgende sectie (figuur 44) 6.3 ONDERZOEKSPUNT 2: WAT IS DE INVLOED VAN MEERDERE (BEPERKENDE) RESOURCES OP DE MULTI-PROJECT PLANNING? DE INVLOED VAN DE NIET-BOTTLENECK RESOURCE Deze sectie sluit aan met de laatste testen van sectie We wensen namelijk de invloed van een extra resource op de multi-project duurtijd bestuderen. Hier gaan we wel anders te werk. Sectie legt de focus op de vergelijking van ER + CC met andere planningsmethodes indien we overstappen van project types met één resource, naar project types met twee resources. Deze sectie, daarentegen, bestudeert de invloed van de RF/RC van de niet-beperkende resource op de multiproject duurtijd. We wensen namelijk na te gaan onder welke planningstechniek een nietbeperkende resource het kleinste effect heeft op de duurtijd. Het doel hiervan is inzicht verkrijgen in hoe efficiënt de resources worden aangewend onder de verschillende planningstechnieken. Figuur 44 illustreert met een vereenvoudigd voorbeeld de invloed van de niet-beperkende resource op de duurtijd: 97

110 Figuur 44a: Invloed van de niet-bottleneck resource Figuur 44b: Invloed van de niet-bottleneck resource Figuur 44 maakt duidelijk dat ook een niet-bottleneck resource kan leiden tot resource conflicten waardoor de totale duurtijd stijgt. We plannen hierbij één project die nood heeft aan 2 resource types. De bottleneck taken zijn weergeven in het grijs, de niet-bottleneck taken in het donkergrijs. Op figuur 44a is de gebruiksgraad van de niet-bottleneck resource erg laag. Hierdoor zien we dat de nietbottleneck resource tot geen enkel resource conflict leidt. Op figuur 44b is dit niet meer het geval. Doordat de RC van de niet-bottleneck resource is gestegen zien we dat taak 6 en 5 niet langer in parallel kunnen worden gepland door tekorten van de niet-bottleneck resource. Om dit effect bij de verschillende planningsmethodes te bestuderen, project types vergeleken: hebben we 3 variërende S50_RF 180_RF 280_RC 150_RC 2x S50_RF 180_RF 280_RC 180_RC 2x S95_RF 180_RF 280_RC 150_RC 2x 98

111 Per type maken we 15 multi-project schema s en berekenen we de gemiddelde duurtijd. Dit herhalen we voor een variërende RC van de niet-beperkende resource (= x hierboven) en een constante input van de andere parameters. Vervolgens vergelijken we wat het effect is van een variërende niet-bottleneck resource nood op de multi-project duurtijd (bijvoorbeeld door een vergelijking te maken tussen S50_RF 180_RF 280_RF 150_RF 220 met S50_RF 180_RF 280_RF 150_RF 230). Om de resultaten te rapporteren berekenen we steeds de procentuele verschillen in multi-project duurtijd. Deze vergelijking maken we voor het plannen volgens project prioriteiten, het na elkaar plannen en het plannen met behulp van ER + CC. We starten met het bekijken wat de invloed is van de overstap van een RC = 20 naar een RC = 30 van de niet-beperkende resource. Een voorbeeld van de tussenstappen om tot de resultaten te bekomen is gegeven in bijlage 9.4. Duurtijden ER+CC Project prioriteiten X = 20->30 Project prioriteiten incl. FB Na elkaar S50_RF 180_ RF 280_RC 150_RC 2x 7% 6% 5% 6% S50_RF 180_RF 280_RC 180_RC 2x 4% 4% 4% 5% S95_RF 180_RF 280_RC 150_RC 2x 6% 0% 0% 4% We zien dat het opdrijven van de RC van de niet-beperkende factor van 20 naar 30 tot een significante stijging leidt van de multi-project duurtijd. Voor een schema met een gemiddeld gebruik van beperkende factor (RC1 = 50) is de stijging het grootst (5% tot 7%). De reden hiervoor is dat bij een gemiddeld gebruik er nog weinig resource conflicten ontstaan. Een relatief kleine opdrijving van de niet-bottleneck resource veroorzaakt heel wat extra resource conflicten en bijgevolg veel meer verschuivingen zoals beschreven op figuur 44. Een schema met een hoog gebruik van de beperkende factor (RC1 = 80) zorgt voor een minder grote stijging van de multi-project duurtijd bij een kleine opdrijving van de niet-beperkende factor (4% tot 5%). Dit is eerder contra-intuïtief. Een verklaring is echter dat de hoge RC van de bottleneck resource + een lage RC van de niet-bottleneck resource al voor resource conflicten zorgt. Hierdoor moeten taken worden opgeschoven naar een later tijdstip en bekomen we een langer schema met meer vrije resources. Een kleine opdrijving van de niet-bottleneck resource leidt dus niet tot veel bijkomende resource conflicten. Tot slot bekijken we een sterk serieel (S95) schema met een gemiddeld gebruik van de beperkende factor (RC1 = 50). Hier zien we dat er een duidelijk verschil is tussen de alternatieve planningsmethodes. Terwijl ER + CC tot gelijkaardige resultaten leidt als de andere type netwerken, 99

112 zien we dat het opdrijven van de niet-beperkende factor geen invloed heeft op de project prioriteiten methode. Dit betekend dat via deze methode de gebruiksgraad van de resources lager ligt. We kunnen hieruit besluiten dat bij een sterk serieel netwerk, de beperkende factor bepaalt wanneer een volgend project kan starten. Zolang de RC van de niet beperkende factor relatief laag is, heeft deze geen invloed. Figuur 45 visualiseert dit simplistisch. marge Figuur 45: Invloed van een stijgende RC op de project prioriteiten methode Figuur 45 toont de planning van een multi-project bestaande uit twee projecten (aangegeven in het grijs en donkergrijs). De bovenste figuur toont de gebruiksgraad van de bottleneck resource en de onderste toont de gebruiksgraad van de niet-bottleneck resource. We zien dat de starttijd van project 2 bepaald wordt door resource conflicten van de bottleneck resource. Door de sterke mate van serie zijn er nog voldoende niet-bottleneck resources op overschot waardoor een stijging van de RC geen invloed heeft. Er is dus een zekere marge. Graag merken we hierbij nog op dat bij S = 95 een stijging van de RC van de niet-bottleneck resource een stijging veroorzaakt van de duurtijd van de individuele projecten. Dit is zichtbaar aan de stijging van de na elkaar methode (+4%). De project prioriteiten methode blijft echter ongewijzigd. Omdat taken van individuele projecten bij een stijging van RC2 nu meer worden gespreid, bekomen we langere project duurtijden met een lagere resource gebruiksgraad. Doordat de gebruiksgraad lager ligt kunnen we bij het plannen via de project prioriteiten methode de opvolgende projecten nog steeds laten starten op hetzelfde tijdstip als voor het opdrijven van de RC van de niet-bottleneck resource. Vervolgens bekijken we wat de invloed is van de overstap van een RC = 30 naar een RC = 50 van de niet-beperkende resource. Hierbij houden we de RF van beide resources constant op

113 ER+CC Project prioriteiten X = 30->50 Project prioriteiten incl. FB Na elkaar S50_RF 180_ RF 280_RC 150_ RC 2x 6% 4% 5% 3% S50_RF 180_RF 280_RC 180_RC 2x 2% 2% 2% 2% S95_RF 180_RF 280_RC 150_RC 2x 5% 0% 1% -1% Deze test resulteert in gelijkaardige conclusies zoals hierboven beschreven. We zien echter wel dat de stijgingen iets kleiner zijn. Dit omdat de combinatie van een beperkende factor met een nietbeperkende factor met een RC2 van 30 al reeds tot resource conflicten leidt en noodzakelijke taakverschuivingen. Deze verschuivingen zorgen ervoor dat de gebruiksgraad terug daalt. Het opdrijven van de niet-beperkende resource tot RC2 = 50 zorgt daarom niet voor veel extra resource conflicten. Een merkwaardig resultaat is de -1% van het netwerk type S95_RF 180_RF 280_RC 150_RC 2x. Dit is te wijten aan het werken met een steekproef van 15 multi-project duurtijden. Mogelijks heeft RanGen net een netwerk gegeneerd met zeer lange taak duurtijden bij het testen van de nietbeperkende factor met een RC = 50. Deze uitschieter kan het resultaat beïnvloeden. We kunnen uit deze test concluderen dat ER + CC methode bij sterk seriële netwerken veel efficiënter gebruik maakt van de resources. Dit bevestigt experimenteel de verwachting PROJECTEN MET MEERDERE BEPERKENDE FACTOR In sectie 4.1 werd de implementatie van de verschillend planningstechnieken uitgelegd. Bij de ontwikkeling van het programma werd bijzondere aandacht besteed aan de mogelijkheid om ook multi-projecten waarvan meerdere resources het systeem beperken te kunnen testen. Zeker voor het toevoegen van de CCB leverde dit complexe algoritmes op. Na het bestuderen van multi-project met nood aan slechts 1 resource type, testen we hier projecten met meerdere beperkende resources. We gaan hierbij op dezelfde manier tewerk, maar we creëren en vergelijken nu projecten die nood hebben aan 3 verschillende soorten resources en waarbij twee van deze min of meer dezelfde gebruiksgraad hebben. Het doel van deze testen is na gaan of we dezelfde conclusies kunnen maken bij het laten variëren van S en de resources gebruiksgraad zoals deze gemaakt voor multi-project met nood aan slechts 1 resource type. 101

114 TESTEN SERIE (S) In deze sectie testen we wat de invloed is van de parameter serie (s) door deze te laten variëren. We testen hierbij netwerken die nood hebben aan 3 resource types. Hiervan hebben 2 resources een gemiddelde gebruiksgraad en heeft 1 resource een lage gebruiksgraad: Sx_RF 180_RF 275_RF 355_RC 150_RC 245_RC 325. DUURTIJD S Project vs. ER+CC Gemiddelden duur Project incl. fb vs. ER+CC Na elkaar vs. ER+CC ER + CC 30: 8% 7% 12% : 14% 14% 13% : 19% 18% 24% 145 Sx_RF 1 80_RF 2 75_RF 3 55_RC 1 50_RC 2 45_RC % 25% 24% 20% 19% 18% 15% 10% 5% 8% 7% 12% 14% 14% 13% Project vs. ER+CC Project incl. fb vs. ER+CC Na elkaar vs. ER+CC 0% S Figuur 46: Testen duurtijd bij variërende S (netwerk met meerdere beperkende resources) De ER + CC techniek leidt tot significant betere resultaten voor netwerken met een hoge in serie parameter. In grote orde bekomen we dezelfde resultaten, zoals beschreven bij netwerken met één resource. Meer seriële netwerken geven een grotere mogelijkheid om taken van andere projecten in parallel te plannen en hierdoor is de multi-project duurtijd de ER + CC methode significant korter dan de alternatieve methodes. 102

115 THROUGHPUT Throughput Project 1 0% -5% -10% -15% % -9% -20% -25% -30% -35% -40% -45% -36%-35% -40% -18%-19% -29% S -24% Project vs. ER+CC Project incl. fb vs. ER+CC Na elkaar vs. ER+CC Figuur 47a: Testen duurtijd bij variërende S (netwerk met meerdere beperkende resources) Throughput Project 2 14% 12% 10% 13% 13% 10% 8% 6% 6% 6% Project vs. ER+CC Project incl. fb vs. ER+CC 4% 3% Na elkaar vs. ER+CC 2% 0% 1% 1% 0% S Figuur 47b: Testen duurtijd bij variërende S (netwerk met meerdere beperkende resources) Bij het bestuderen van de throughput van het eerste project zien dat de duurtijd van dit project bij de ER + CC methode significant langer is. Daarbovenop zien we dat dit nadeel veel sterker is dan in vergelijking met de situatie waarin we projecten hebben die nood hebben aan slechts één type resource. Dit komt omdat we werken met een prioriteitenlijst. Hierop komen pas niet-bottleneck taken voor na alle bottleneck taken. Bij het plannen van de niet-bottleneck taken van project 1, zijn de bottleneck taken van de andere projecten reeds toegevoegd aan het schema (tenzij deze niet- 103

116 bottleneck taak een voorganger is van een andere bottleneck taak). Omdat de niet-bottleneck taken nu nood hebben aan resources, moeten deze mogelijks verschuiven naar een later tijdstip omdat er op hun LS niet genoeg resources beschikbaar zijn. Deze bijkomende verschuivingen zijn nadelig voor de duurtijd van het eerste project. Voor de throughput van het tweede project zijn de conclusies vergelijkbaar met de testen waarbij we een nood aan slechts één resource veronderstelden. Voor een hoge S, is er een significant voordeel van de ER + CC methode op de duurtijd al is dit effect iets kleiner. Voor een lage in serie parameter constateren we dat ER + CC het nadeel van de netwerken met nood aan één resource type heeft omgebogen tot een licht voordeel. Doordat twee resources nu beperkend zijn wordt het moeilijker om met de project prioriteiten methode een volgend project te laten starten voor de afloop van een vorig project. Dit omdat er nu voldoende resources van meerdere types beschikbaar moeten zijn. Bij het vergelijken van de project prioriteiten methode met de ER + CC methode is hierdoor de geplande duurtijd van het tweede project onder de project prioriteiten methode langer. ER + CC werkt op taak niveau, daarom kunnen er bij deze methode toch enkele taken in parallel met het eerste project worden gepland. Hierdoor, moeten er nog minder taken uitgevoerd worden na afloop van het eerste project INVLOED VAN RESOURCE GEBRUIKSGRAAD (RC EN RF) In deze sectie testen we de invloed van een variërende gebruiksgraad aan resources op de multiproject planning onder de verschillend methodes. Opnieuw werken we met netwerken die nood hebben aan drie resource types. We laten RC/RF variëren en testen volgende netwerk types: Hoog = resource 1 en 2 hebben een hoge gebruiksgraad en resource 3 een erg lage. S50_RF 180_RF 275_RF 350_RC 175_RC 270_RC 330 Gemiddeld = resource 1 en 2 hebben een gemiddelde gebruiksgraad en resource 3 een erg lage. S50_RF 180_RF 275_RF 355_RC 150_RC 245_RC 325 Laag = resource 1 en 2 hebben een lage gebruiksgraad en resource 3 een erg lage. S50_RF 170_RF 265_RF 350_RC 130_RC 225_RC

117 DUURTIJD RC/RF Project vs. ER+CC Gemiddelden duur Project incl. fb vs. ER+CC Na elkaar vs. ER+CC ER + CC Laag 24% 23% 57% 69 Gemiddeld 14% 14% 13% 127 Hoog 5% 5% 0% % Invloed van de resource gebruiksgraad 60% 57% 50% 40% 30% 20% 10% 0% 24% 23% 14% 14% 13% 5% 5% 0% Laag Gemiddeld Hoog RC/RF Project vs. ER+CC Project incl. fb vs. ER+CC Na elkaar vs. ER+CC Figuur 48: Testen duurtijd bij variërende RC/RF (netwerk met meerdere beperkende resources) Voor een variërende resources gebruiksgraad komen we ook tot dezelfde conclusies als deze gemaakt in sectie , hoe hoger de gebruiksgraad hoe kleiner het voordeel van de ER + CC methode. 105

118 THROUGHPUT Througput Project 1 0% -5% Laag Gemiddeld Hoog -10% -15% -20% -25% -14% -15% -18%-19% Project vs. ER+CC Project incl. fb vs. ER+CC -30% -28% -29% -28% -28% Na elkaar vs. ER+CC -35% -40% -45% RC/RF -38% Figuur 49a: Testen throughput bij variërende RC/RF (netwerk met meerdere beperkende resources) Througput Project 2 30% 27% 25% 20% 15% 10% 5% 0% -5% -10% 13% 11% 6% 6% 3% 1% 1% Laag Gemiddeld Hoog -5% RC/RF Project vs. ER+CC Project incl. fb vs. ER+CC Na elkaar vs. ER+CC Figuur 49b: Testen throughput bij variërende RC/RF (netwerk met meerdere beperkende resources) Ook hier zijn er geen grote verschillen in vergelijking met resultaten van netwerken met nood aan slechts één resource type. Het enige verschil is dat de duurtijd van het eerste project onder de ER + CC methode veel langer is. De verklaring hiervoor is dezelfde als deze gegeven bij een variërende S. 106

119 6.4 ONDERZOEKSPUNT 4: HOE BEPALEN WE BEST DE GROOTTE VAN DE CCB? Bij het bespreken van de resultaten in secties 6.2 en 6.3, toonden we aan dat de 30% regel om de grootte van de CCB te bepalen een suboptimale regel is. Er werd duidelijk dat multi-projecten met een hoge gebruiksgraad tot een langere duurtijd leiden onder de project prioriteiten methode dan indien we de projecten na elkaar plannen. De reden hiertoe is dat we bij de na elkaar methode werken met een kortere project buffer. Deze project buffer doet namelijk aan risk pooling via de RSEM methode. Volgende test toont het verschil nog eens aan. We vergelijken opnieuw 15 multiproject schema s bestaande uit 3 projecten van elk 10 activiteiten met S50_RF100_RC100 als input. Van deze 15 multi-projecten bereken we het procentueel verschil in duurtijd onder de verschillend planningsmethodes. Vervolgens bepalen we het minimale verschil, kwartiel 1, het gemiddelde, kwartiel 3 en het maximale verschil. We concluderen hieruit dat de project prioriteiten en de ER + CC methode tot eenzelfde schema komen met een gemiddelde duurtijd die 7% langer is dan indien we de projecten na elkaar plannen. Project vs. ER + CC Project incl. fb vs. ER + CC Na elkaar vs ER + CC Min 0 0-9% Q % Gemiddelde 0 0-7% Q % Max 0 0-5% Zoals eerder besproken beschermt de CCB de bottleneck resource tegen vertragingen bij het overdragen van deze resource van het ene naar het ander project. De functie van de CCB is dus sterk vergelijkbaar met de PB. Het enige verschil is dat de CCB enkel de bottleneck taken in beschouwing neemt. Omwille van deze redenen lijkt het gebruiken van RSEM een betere methode om de grootte van de CCB te bepalen. Indien we overstappen naar RSEM om de CCB te bepalen heeft dit tot gevolg dat bij een maximaal resource gebruik er geen verschillen in duurtijd meer zullen zijn tussen de verschillende planningsmethodes. Merk op: de situatie waarin we een multi-project hebben waarbij de bottleneck resource meerdere malen switcht tussen twee projecten betekent een nood aan veel (korte) CCB s. Bij gebruik van de Root Square Error Methode wordt in dit geval dus minder aan risk pooling gedaan. Eventueel zou kunnen onderzocht worden wat de invloed is op de zekerheid van het schema indien we in deze situatie enkel een CCB voorzien als de bottleneck resource wordt doorgegeven naar een 3 de project en we de CCB s tussen de 2 vervlochten projecten elimineren. Om dit te onderzoeken moeten er simulaties uitgevoerd worden. Dit valt buiten de scope van deze thesis. 107

120 6.5 ONDERZOEKSPUNT 5: WAT IS DE SENSITIVITEIT VAN DE ER UITKOMST OP HET MULTI-PROJECT? Zoals eerder aangegeven in sectie 3.2 wordt een prioriteitenlijst bekomen door alle taken van de verschillend projecten te aggregeren en deze te evalueren aan de hand van operationele criteria. Hiervoor wordt het Evidence Reasoning algoritme gebruikt. Het spreekt voor zich dat een andere selectie aan evaluatiecriteria leidt tot een andere prioriteitenlijst en dus tot een ander multi-project schema. De selectie van de beste evaluatiecriteria is geen evidente zaak omdat deze variëren van project tot project. Een goede prioriteitenlijst is namelijk een lijst die resulteert in een korte multi-project duurtijd omdat de taken zodanig op de lijst voorkomen zo dat het parallel plannen ervan wordt bevorderd en resources zo optimaal mogelijk worden aangewend. Het is dus mogelijk dat voor het ene project een goede lijst wordt bekomen door bijvoorbeeld eerst de kortste taken aan de lijst toe te voegen, terwijl een ander project tot een beter multi-project schema komt door eerst de langste taken toe te voegen. Om toch één set van evaluatiecriteria te gebruiken voor het opstellen van verschillend project types, moet gezocht worden naar algemeen relevante criteria. In de literatuur worden volgende criteria aangeraden (herhaling van sectie 3.2): o o o o o Prioriteit van het project waartoe de taak behoort. Gebruik van de bottleneck resource door de taak. Is de taak een element van de CC. Duurtijd van de taak. Starttijd en eindtijd prioriteit. Bij de implementatie van het C++ programma werd de prioriteitenlijst voor de multi-project planning gevormd door aandacht te schenken aan de prioriteit van het project waartoe de taak behoort, het gebruik van de bottleneck resource door de taak en de starttijd uit het individueel schema (sectie 5.3.2). Merk op: door de starttijd van het individueel schema te aanzien als een evaluatiecriterium, beschouwen we slack als een onrechtstreeks criterium. Dit omdat individuele schema s worden opgesteld aan de hand van een prioriteitenlijst waar taken zijn gesorteerd volgens oplopende slack. Graag wensen we hier te onderzoeken of het werken met deze prioriteitenlijst nauw aansluit bij een multi-project planning die de totale duurtijd minimaliseert. Dit doen we aan de hand van een genetisch algoritme. Dit algoritme test een zeer grote set van verschillende prioriteitenlijsten, maakt 108

121 per lijst een planning en berekent de totale duurtijd van het multi-project schema. Door voortdurend nieuwe prioriteitenlijsten te creëren op basis van andere goede prioriteitenlijsten (= lijsten die een multi-project opleveren met een korte duurtijd) en verder te gaan met de beste evolueert de methode op een efficiënte manier naar een oplossing die het optimum sterk benadert. Vervolgens vergelijken we de minimale multi-project duurtijd, bekomen door het genetisch algoritme, met de duurtijd van het schema dat opgesteld werd met behulp van een prioriteitenlijst op taak level (zoals beschreven in sectie 5.3.2). Alvorens we de resultaten bespreken, geven we eerst stapsgewijs uitleg over de implementatie van het genetisch algoritme. Er wordt hierbij verondersteld dat de lezer reeds enige voorkennis heeft van de werking van een GA. Hiervoor kan verwezen worden naar Vanhoucke, M. (2015). Applied operations research. Academia Press. 1. De startpopulatie De startpopulatie bestaat uit vijf prioriteitenlijsten met de nodige variëteit. De eerste prioriteitenlijst is opgesteld aan de hand van de algemene evaluatiecriteria op taak niveau zoals hierboven werd beschreven. De tweede lijst werd bekomen door de eerste lijst om te keren. De derde lijst werkt aan de hand van project prioriteiten. De vierde lijst is het omgekeerde van de derde lijst. Op de vijfde lijst werden de taken in een willigkeurige volgorde geplaatst. 2. Fitness value Aan elk van de hierboven beschreven lijsten wordt een fitness value toegekend. Als fitness value gebruiken we de totale multi-project duurtijd (incl. alle buffers) bekomen via de ER + CC methode. Hoe kleiner deze waarde hoe beter de bijhorende prioriteitenlijst. De fitness value werd berekend door de stappen van sectie 5.3 uit te voeren maar dan wel voor een steeds variërende prioriteitenlijst voor onderdeel Selectie Aan de hand van twee prioriteitenlijsten uit de populatie, wensen we een nieuwe prioriteitenlijst te creëren. Hiervoor moet een trade-off gemaakt worden tussen een goede fitness value en voldoende variëteit (om premature convergentie naar een lokaal optimum te voorkomen). Voor de selectie gebruiken we roulette wheel selection. We sorteren de prioriteitenlijsten volgens de bijhorende fitness value en kennen aan elke prioriteitenlijst een interval toe: 109

122 Prioriteitenlijst 1 (slechtse fitness value): [0-5] Prioriteitenlijst 2: [6-15] Prioriteitenlijst 3: [16-30] Prioriteitenlijst 4: [31-55] Prioriteitenlijst 5 (beste fitness value): [56-100] Vervolgens laten we 2 random cijfers genereren. Een lijst wordt geselecteerd indien het random nummer binnen het bijhorende interval valt. Indien we bijvoorbeeld 55 als random nummer hebben wordt prioriteitenlijst 4 geselecteerd. We zorgen steeds dat er 2 verschillende lijsten worden geselecteerd. 4. Cross-over Aan de hand van de 2 geselecteerde lijsten creëren we 2 nieuwe prioriteitenlijsten. We doen dit door middel van Partially Mapped Crossover met 2 cut-off punten. Volgend voorbeeld illustreert: lijst 1: [1,2,3,7,8,9, 4,5,6] Lijst 2: [8,5,2, 7,4,1, 9,6,3] Nieuwe lijst 1: [1,2,3 7,4,1, 4,5,6] Nieuwe lijst 2: [8,5,2,7,8,9, 9,6,3] Om de lijst feasible te maken moet nog een correctie worden doorgevoerd. In de nieuwe lijst 1 komen 4 en 1 twee keer voor, daarom zetten we deze waarden eerst op 0. Vervolgens kijken we welke taken er ontbreken en deze vullen we aan op de posities waar een 0 staat. 5. Mutatie Om de variëteit te bevorderen voeren we nog vijf random swaps uit binnen een prioriteitenlijst. Het resultaat zijn twee nieuwe prioriteitenlijsten die kunnen getest worden. 6. Evolutie populatie Voor de nieuwe prioriteitenlijsten (bekomen uit de vorige 5 stappen) maken we opnieuw een schema via het ER + CC algoritme (stappen uit sectie 5.3) en berekenen we de fitness value. Indien de fitness value lager is dan de hoogste fitness value van de huidige populatie wordt de prioriteitenlijst die correspondeert met deze hoge fitness value vervangen door de nieuwe prioriteitenlijst. 7. Stop criteria Na het updaten van de populatie gaan we opnieuw naar stap 3. Zo herhalen we het algoritme 150 keer. Experimenteel werd vastgesteld dat de fintess value niet meer significant veranderd bij extra iteraties en bij 150 iteraties is de runtime nog aanvaardbaar. 110

123 Nadat alle iteraties zijn uitgevoerd hebben we een populatie van vijf prioriteitenlijsten die leiden tot een multi-project schema met een korte duurtijd. De laagste fitness value uit de populatie is dan een benadering van de laagst mogelijk te bekomen multi-project duurtijd via de ER + CC methode. De bijhorende prioriteitenlijst sluit dan zeer sterk aan bij de beste prioriteitenlijst voor het multi-project in kwestie. De kwaliteit van de huidige methode om een taak prioriteitenlijst op te stellen werd getest op verschillende netwerktypes. Per type werden steeds vijf multi-project schema s gemaakt via de ER + CC methode (met als bottleneck resource, de resource die de grootste invloed heeft op de totale duurtijd). Hierbij bestaat elk multi-project uit 3 projecten met elk 10 niet-dummy activiteiten. Volgende tabel geeft een voorbeeld waar we S50_RF80_RC50 testen (een netwerk met slechts nood aan één soort resource). S50_RF80_RC50 nummer: Taak prioriteiten Minimum GA Gemiddelde Verschil: 16% Uit deze tabel leren we dat de gemiddelde multi-project duurtijd, bekomen aan de hand van de taak prioriteitenlijst 128 tijdseenheden bedraagt. Dit indien we werken met een steekproef bestaande uit slechts vijf waarnemingen. Het GA toont echter aan dat de minimale multi-project duurtijd voor dit type netwerk gemiddeld 108 tijdseenheden bedraagt. Het gebruik van een prioriteitenlijst zorgt dus voor een multi-project schema met een significant langere duurtijd (16%) dan de minimale duurtijd. In wat volgt geven we samenvattende tabellen waar we enkel het verschil % weergeven per netwerk type. De onderstaande tabel geeft een overzicht voor verschillende netwerktypes die steeds nood hebben aan slechts één resource type. Verschil (in %) S50_RF80_RC80 5% S50_RF80_RC50 16% S50_RF80_RC30 16% S30_RF80_RC50 12% S95_RF80_RC50 15% S95_RF80_RC80 11% 111

124 Hieruit zien we dat bij een gemiddelde (RC = 50) tot lage (RC = 30) gebruiksgraad van de resource het werken met een prioriteitenlijst zorgt voor multi-project schema s met een duurtijd die 12% tot 16% langer is dan de minimale duurtijd. Gegeven een vaste beschikbaarheid aan hernieuwbare resources, betekent deze langere duurtijd dat schema s opgesteld met een prioriteitenlijst, minder efficiënt gebruik maken van de resources. Met andere woorden blijven er meer resources ongebruikt tijdens het uitvoeren van het schema. Dit is uiteraard een ongewenste situatie. Indien we projecten hebben met een hoge resources gebruiksgraad (RC = 80) zien we dat het nadeel op de totale duurtijd van het werken met een prioriteitenlijst verkleint. Bij een sterk serieel netwerk type (S = 95) leidt het werken met een prioriteitenlijst tot een multi-project duurtijd die 11% boven de minimale duurtijd ligt. Indien we te maken hebben met parallelle netwerken (en de gebruiksgraad dus verder stijgt) is het verschil slechts 5%. Vervolgens werden ook netwerken die nood hebben aan drie resource types getest. Hiervan zijn voor twee resources de gebruiksgraad (RF/RC) min of meer dezelfde en is voor de derde resource de gebruiksgraad erg laag is. We zien dat de resultaten in grote orde dezelfde zijn als voor netwerken met nood aan één resource type. Verschil (in %) S50_RF 180_RF 275_RF 350_RC 175_RC 270_RC 330 9% S50_RF 180_RF 275_RF 355_RC 150_RC 245_RC % S50_RF 170_RF 265_RF 350_RC 130_RC 225_RC % S30_RF 180_RF 275_RF 355_RC 150_RC 245_RC % S95_RF 180_RF 275_RF 355_RC 150_RC 245_RC % S95_RF 180_RF 275_RF 355_RC 180_RC 275_RC 325 7% S30_RF 180_RF 275_RF 355_RC 180_RC 275_RC 325 8% Uit deze testen kunnen we concluderen dat het werken met de hierboven beschreven prioriteitenlijst niet optimaal is voor het plannen van een set afhankelijke projecten, indien de gebruiksgraad van de resources gemiddeld tot laag is. Deze lijst leidt namelijk tot multi-project schema s (incl. buffers) met een significant langere duurtijd dan het schema (incl. buffers) die de totale duurtijd minimaliseert en dus tot een inefficiënt gebruik van de beschikbare resources. In deze situatie is het dus aan te raden om andere set aan evaluatiecriteria te selecteren om taken te prioriteren. Verder onderzoek kan uitwijzen welke evaluatiecriteria relevant zijn voor dit type schema s. Een nuttige input voor dit onderzoek zijn prioriteitenlijsten uit het GA die voor een lage totale multi-project duurtijd zorgen. Door gelijkenissen te vinden tussen een positie op de lijst en operationele eigenschappen kan bijvoorbeeld ontdekt worden dat prioriteitenlijsten die de duurtijd minimaliseren steeds eerst de taken bevatten met de minste slack. Omdat projecten met een lage gebruiksgraad van de resources minder frequent voorkomen gaan we hier niet verder op in deze thesis. 112

125 Een belangrijke opmerking hierbij is echter wel dat het schema s met een minimale duurtijd leiden tot een significant slechtere throughput. Na het analyseren van de prioriteitenlijsten uit het GA die resulteren in een schema met een korte duurtijd zien we namelijk dat taken van verschillende projecten volledig door elkaar worden gepland. Indien we dus werken met niet-afhankelijke projecten, waar het ene project positieve kasstromen kan genereren voor het beëindigen van andere projecten is het dus raadzaam om een evaluatiecriterium die rekening houdt met deze project prioriteiten te behouden. Dit kan echter wel negatieve gevolgen hebben op de multi-project duurtijd. Onder de standaard situatie waar we te maken hebben met een hoge gebruiksgraad van de resources is het gebruik van de huidige evaluatiecriteria aan te raden. Een lijst waar eerst alle bottleneck taken op voorkomen volgens aflopende corresponderende project prioriteit en vervolgens de niet-bottleneck taken volgens aflopende corresponderende project prioriteit (sectie 5.3.2) zorgt voor zeer goede resultaten. Enerzijds wordt rekening gehouden met de project prioriteiten waardoor strategische eisen erin vervat zitten. Daarnaast tonen de testen uit sectie 6.2 dat de methode zorgt voor een relatief goede throughput vanaf het 2 de project ( na elkaar vs ER + CC ). Tot slot benadert deze werkwijze de minimaal te bekomen multi-project duurtijd, wat aangeeft dat de resources erg efficiënt worden aangewend. Dit resultaat ligt ook in de lijn met de verwachtingen. Bij een hoge gebruiksgraad van de resources zal de bottleneck resource het systeem sterker beperken en doet we er goed aan om bottleneck taken een hogere prioriteit te geven. Uit deze testen kunnen we sterk aanraden om te blijven werken met een prioriteitenlijst. Voor multi-projecten met een hoge resources gebruiksgraad leiden de hierboven beschreven evaluatiecriteria alreeds tot een prioriteitenlijst die resulteert in een zeer goede planning. Indien de gebruiksgraad laag is, wordt er beter gezocht naar een andere set van evaluatiecriteria. Het gebruik van een genetisch algoritme (of gelijkaardige technieken) om een planning te maken valt sterk af te raden. Dit omdat je dan de controle verliest. De totale multi-project duurtijd wordt wel geminimaliseerd maar het GA kan catastrofale gevolgen hebben voor de throughput. Daarbovenop houdt een GA zoals hierboven beschreven geen rekening met strategische vereisten. ER is een goede techniek om een prioriteitenlijst op te stellen als is het maken van een evaluatieboom die bruikbaar is om verschillende projecten te evalueren niet evident. 113

126 7 SAMENVATTING 7.1 AANGEWEZEN METHODE PER PROJECT TYPE *Enkele bijkomende netwerk types werden getest om de matrix te vervolledigen. Deze gebeurden op dezelfde manier zoals besproken in sectie 6.2 Deze samenvattende matrix toont welke methode het voordeligst is bij een gegeven netwerk type. De matrix werd opgesteld aan de hand van de resultaten uit sectie en is bekomen door negen verschillende netwerktypes te testen. Hierbij werd steeds gewerkt met een set multi-projecten elk bestaande uit 3 projecten en met een nood aan drie verschillende resource types. De y-as geeft aan hoe serieel het netwerk is, de x-as geeft steeds de hoogste RC weer van de 3 resources. Het voordeel van de meest voordelige methode ten opzichte van de alternatieven staat ook steeds uitgedrukt aan de hand van een percentage. Voor bijvoorbeeld een sterk serieel netwerk (S = 95) waarbij de hoogste gebruiksgraad van de 3 resources gemiddeld is (RC = 50) wordt aangeraden om de ER + CC methode te gebruiken. Hiervoor wordt verwacht dat dat de totale multi-project duurtijd gemiddeld 20% korter is dan de alternatieve methodes. 114