Universiteit van Amsterdam
Faculteit Economie en Bedrijfskunde
Studierichting
Master of Science in Operations Research
Uitgevoerd bij
KLM Engineering & Maintenance
Logistiek
Doorlooptijdverkorting bij het Logistiek Centrum van de KLM
Pre Alerts voor de totale Inbound/Outbound stroom
Door:
Bram de Vries
6034101
Datum
10-02-2014
Begeleiders
Pim Stam (KLM)
Ed Rijnbeek (KLM)
Dr. H.J. van der Sluis (UvA)
Voorwoord
Dank gaat uit naar alle medewerkers van de Expeditie voor het beschrijven van de
binnenkomende stromen van onderdelen; Farid Kassim, Willy Eckstein, Zahier Sultan, J.P. Westerveld en alle anderen. Ook gaat er dank uit naar alle medewerkers van de Inbound en de Outbound (inclusief CLA) voor het verstrekte inzicht in de werkzaamheden en de
mogelijkheid om metingen naar de verwerkingstijd uit te voeren bij deze afdelingen, onder anderen: Brigitte Doleyschi, Andre Ruis, Niesko Harmsen, Rene Schenkius, Martin van Duivenbooden, Soenil Soekhram, Nico Zuidhoek, Ruud Vervaart, Danny Bauer, Eric Burger, Frank Westerman, Gerard van den Ploeg, Wim Bennink, Joop Prins, Phill Ansell en Anita van Dijk.
Verder gaat er uiteraard dank uit naar Pim Stam en Ed Rijnbeek voor de begeleiding bij de KLM, naar Leo Vennik en Martijn Wennekes voor de verstrekking van gegevens en andere hulp en naar dr. Erik van der Sluis voor de begeleiding vanuit de UvA.
Managementsamenvatting
De unit Logistiek van KLM Engineering & Maintenance (E&M) is verantwoordelijk voor de logistieke afhandeling van de vliegtuigonderdelen waarvan E&M de reparatie verzorgt. Naast de eigen onderdelen verzorgt de KLM ook reparaties voor andere maatschappijen. Binnen het Logistiek Centrum (LC) van de KLM wordt met behulp van verschillende softwarepakketten bepaald waar de onderdelen gerepareerd moeten worden en wanneer dit is gebeurd, wordt er door het LC nagegaan of de onderdelen administratief kunnen worden geregistreerd als zijnde gerepareerd. Beide processen bestaan naast de beschreven administratieve handelingenook uit een fysieke controle van de onderdelen.
Bij Logistiek wordt momenteel gekeken naar mogelijkheden om de doorlooptijden van onderdelen tijdens de verschillende stappen binnen het reparatieproces te verkorten. Voor de specifieke processen binnen het LC is geopperd om onderdelen die op weg zijn naar het Logistiek Centrum al tijdens dit transport in de administratieve software in te voeren, zodat ze bij binnenkomst alleen nog maar gecontroleerd dienen te worden. Dit moet gebeuren op basis van Pre Alerts; dit zijn kopieën van het bij elk onderdeel horende papierwerk die de gegevens bevatten die nodig zijn om de onderdelen administratief te verwerken. Deze Pre Alerts dienen te worden aangeleverd door de partijen die de onderdelen naar het LC opsturen. Deze nieuwe werkwijze wordt momenteel bij een klein deel van de onderdelen al uitgevoerd en leidt tot goede resultaten.
Het onderzoek dat bij dit rapport hoort, is uitgevoerd met als doel om uit te vinden wat de verkorting in doorlooptijd van de onderdelen binnen het LC is wanneer Pre Alerts
ingevoerd worden voor alle behandelde onderdelen. Dit is gedaan op basis van de aanname dat deze Pre Alerts de correcte gegevens over de bijbehorende onderdelen bevatten. Er zijn met behulp van de simulatiesoftware Enterprise Dynamics modellen opgesteld om de verschillende processen binnen het LC weer te geven. Deze modellen zijn ingericht naar de geobserveerde werkelijkheid binnen het LC en kunnen in een korte tijd het gedrag op lange termijn van de bekeken processen simuleren en analyseren. De ontwikkelde modellen zijn valide gebleken, in de zin dat ze doorlooptijden hebben opgeleverd die vergelijkbaar zijn met de tijden die binnen het LC gemeten worden. Vervolgens zijn deze modellen aangepast om het effect van de invoer van Pre Alerts op deze doorlooptijden te analyseren. Met Pre Alerts verkort men de doorlooptijd bij elke afdeling met minstens 50 procent en het gebruik ervan valt dus ten zeerste aan te raden.
Inhoud
1 Inleiding
2 Achtergrond en motivatie onderzoek - 2.1 Achtergrond
- 2.2 Het bekeken proces: kringloop ruilartikelen - 2.3 Processen Inbound/Outbound
- 2.4 Motivatie: Pre Alerts
3 Onderzoeksvoorbereiding
- 3.1 Gekozen onderzoeksmethode - 3.2 De gebruikte gegevens
- 3.2.1 Beschikbaarheid benodigde gegevens - 3.2.2 Aankomstgegevens
- 3.2.3 Verwerkingstijden
- 3.2.4 Aantal aanwezige medewerkers - 3.3 Werkelijk gemeten doorlooptijden - 3.4 Verblijftijden in probleemstellingen - 3.5 Conceptueel model
- 3.5.1 De situatie zonder Pre Alerts - 3.5.2 De situatie met Pre Alerts
4 Simulaties: de situatie zonder Pre Alerts - 4.1 De CLA stroom
- 4.2 De resterende Outbound stroom - 4.3 De Inbound stroom
5 Simulaties: de invoering van Pre Alerts - 5.1 De CLA stroom
- 5.2 De resterende Outbound stroom - 5.3 De Inbound stroom 7 8 15 37 46
6 Exacte resultaten
- 6.1 Het M/M/s model voor de Inbound stroom - 6.2 Gegevens en resultaten
- 6.3 Simulaties 7 Overzicht Resultaten
- 7.1 Doorlooptijdverkorting
- 7.2 Percentages Pre Alerts te laat behandeld
8 Conclusies
Bijlage A: Literatuuronderzoek
Bijlage B: Code voor het meten met Lazarus
Bijlage C: Tabel voor de Chi-kwadraat verdeling
58 62 63 64 68 69
1 Inleiding
Dit rapport doet verslag van een onderzoek dat is uitgevoerd voor de unit Logistiek van KLM Engineering & Maintenance (E&M). Het onderzoek heeft voornamelijk plaatsgevonden bij het Logistiek Centrum (LC) van de KLM en is uitgevoerd in het kader van een afstudeerstage horende bij de Master Operations Research (OR), een studie die aangeboden wordt door de Universiteit van Amsterdam. Het onderzoek is uitgevoerd in de periode van maart tot en met juli 2013.
Voor dit onderzoek zijn OR technieken gebruikt om een voorgenomen verandering in de procesketen bij het LC te analyseren. Kort gezegd worden er in de procesketen
vliegtuigonderdelen verwerkt. Deze onderdelen komen naar het LC vanaf verschillende buitenlandse locaties en de voorgestelde aanpassing is zodanig dat men reeds tijdens de transporttijd de onderdelen alvast in de administratieve systemen op wil gaan nemen. Op deze manier kan de verblijftijd binnen het LC van deze onderdelen verkort worden. De mate waarin dit doel wordt gerealiseerd is onderwerp van dit onderzoek.
Voordat er aan de beschrijving van deze analyse begonnen zal worden, volgteen kort overzicht van de indeling van dit rapport. Sectie 2 zal dieper ingaan op de beschreven
motivatie voor het uitgevoerde onderzoek. In Sectie 3 zullen dan de voorbereidingen van het onderzoek besproken worden. Bovendien worden er in deze sectie conceptuele modellen voor het onderzoek opgesteld, waarna Sectie 4 en 5 ingaan op de implementatie van deze modellen en de verkregen resultaten. In Sectie 6 wordt bekeken of sommige resultaten ook met exacte modellen behaald hadden kunnen worden. Vervolgens zal Sectie 7 een overzicht bieden van de resultaten en hierop aansluitend volgen er conclusies in Sectie 8.
2 Achtergrond en motivatie onderzoek
Deze sectie zal onder andere ingaan op de omgeving waarbinnen het bij dit rapport horende onderzoek is uitgevoerd. De bekeken processen zullen besproken worden, evenals de voorgestelde veranderingen op deze processen.
2.1 Achtergrond
De in 1919 opgerichte Koninklijke Luchtvaart Maatschappij (KLM) is de grootste luchtvaartmaatschappij van Nederland. Een vloot die bestaat uit 211 vliegtuigen vervoert dagelijks passagiers en vracht voor de KLM. Hiermee zijn gelijk twee van de drie
kernactiviteiten van het bedrijf genoemd. De derde kerndienst die KLM levert is het
onderhoud van vliegtuigen, uitgevoerd door KLM E&M. De divisie E&M zal centraal staan in dit rapport.
De activiteiten die bij E&M worden uitgevoerd bestaan naast het onderhoud van vliegtuigen uit het repareren van losse vliegtuigonderdelen. De divisie heeft verschillende subafdelingen. Naast verschillende ondersteunende afdelingen als Human Resources en Milieuzaken zijn er drie afdelingen op het gebied van reparatie en onderhoud, te weten:
- Engine Services (gespecialiseerd in vliegtuigmotoren) - Vliegtuigonderhoud
- Component Services
Het onderzoek dat bij deze scriptie hoort is uitgevoerd bij een unit van Component Services. Component Services is verantwoordelijk voor het beheer en de reparatie van
vliegtuigonderdelen uit de voorraad van de KLM (exclusief motoren). Deze afdeling heeft vier units:
- Component Management: beheer van de vliegtuigonderdelen in de KLM voorraad. - Base Maintenance Support Shops: onderhoud van bepaalde vliegtuigonderdelen. - Avionics & Accessories: onderhoud van bepaalde vliegtuigonderdelen.
Dit rapport richt zich op de unit Logistiek, een afdeling die onder andere opereert vanuit het Logistiek Centrum van de KLM. Andere medewerkers van Logistiek zijn te vinden in de verschillende werkplaatsen en hangars van E&M. Samen met het LC zijn deze werkplaatsen en hangars te vinden op het bedrijventerrein Schiphol Oost. Dit bedrijventerrein is gevestigd op Schiphol en de KLM heeft hier naast het LC, de hangars en de werkplaatsen veel kantoren staan. Centraal in dit rapport staan enkele subafdelingen in het LC, te weten de Inbound en de Outbound. Het LC acteert als de voordeur van E&M. De afdelingen in dit gebouw houden zich bezig met de logistieke verwerking van vliegtuigonderdelen die door E&M behandeld worden. Hierin wordt onderscheid gemaakt tussen onderdelen die gerepareerd moeten worden (vuil genoemd) en onderdelen die
gerepareerd of nieuw en dus bruikbaar zijn (schoon). Binnen de schone onderdelen wordt er ook onderscheid gemaakt tussen onderdelen die na een defect weer
gerepareerd kunnen worden voor hergebruik en onderdelen die eigenlijk maar één keer gebruikt worden en nooit gerepareerd (kunnen) worden. Deze onderdelen worden
respectievelijk ruilartikelen en verbruiksartikelen genoemd. De verbruiksartikelen zullen in dit onderzoek buiten beschouwing gelaten worden.
De Outbound is de afdeling die bepaalt welke externe partij door de KLM wordt ingeschakeld om een vliegtuigonderdeel te repareren, wanneer dit onderdeel niet door E&M zelf gerepareerd kan worden in de interne werkplaatsen op Schiphol Oost wegens
capaciteitsredenen. Dit betreft dus vuile onderdelen en deze onderdelen zijn niet per definitie alleen van de KLM zelf. Andere luchtvaartmaatschappijen kunnen hun onderdelen namelijk ook door E&M laten repareren. Ook hier kan E&M externe partijen voor inschakelen. E&M sluit verschillende contracten af met deze luchtvaartmaatschappijen. Sommige
maatschappijen krijgen een schoon onderdeel uit de voorraad van KLM als ze hun vuile onderdeel opsturen, andere maatschappijen willen hun eigen onderdeel terug.
Wanneer onderdelen schoon terugkomen bij E&M, dan is de Inbound
verantwoordelijk voor de (grotendeels) administratieve ontvangstbehandeling die hiermee gepaard gaat. Deze taken worden ook uitgevoerd voor nieuw aangekochte ruil- en
verbruiksartikelen. Als er vanaf nu over de Inbound wordt gesproken, zal het echter alleen over de ruilartikelen gaan. Het merendeel van de onderdelen die de Inbound behandelt gaat in
de voorraad van de KLM (omdat veel klanten al een schoon onderdeel hebben gekregen bij het opsturen van hun vuile onderdeel). Sommige onderdelen worden echter direct gebruikt voor het onderhoud van de door E&M behandelde vliegtuigen of gaan terug naar de klant. Wat volgt is een globale beschrijving van de processen die horen bij de reparatie van vliegtuigonderdelen.
2.2 Het bekeken proces: kringloop ruilartikelen
De eerste stap van het onderzoek horend bij dit rapport is geweest om een goed beeld te krijgen van de globale processen die gepaard gaan met het repareren van vliegtuigonderdelen, met als doel om de activiteiten van de Inbound en de Outbound in perspectief te plaatsen. Deze onderdelen bevinden zich als het ware in een kringloop. Elk onderdeel krijgt op een gegeven moment te maken met een defect. Organisaties als KLM E&M zorgen ervoor dat ze gerepareerd worden wanneer dat defect optreedt en vanaf dat moment is het wachten op een volgend defect. Dit proces herhaalt zich totdat de kosten van de reparatie van een onderdeel niet meer opwegen tegen de verwachte opbrengsten die het onderdeel na reparatie met zich meebrengt. De unit Logistiek is binnen dit proces onder andere verantwoordelijk voor het opvangen van onderdelen die gerepareerd dienen te worden. Deze taak begint wanneer deze onderdelen bij het LC aankomen. Vervolgens dient Logistiek onderdelen die door E&M zelf gerepareerd worden bij de juiste werkplaats op Schiphol Oost af te leveren en onderdelen die door externe partijen gerepareerd worden aan te bieden voor transport vanaf het LC naar deze partijen. Ook is Logistiek er dus verantwoordelijk voor dat het juiste terugkerende schone onderdeel naar de juiste KLM afdeling/externe partij
terugkeert.
De taken van Logistiek hebben niet alleen in het LC plaats. Zoals aangegeven zijn er ook
medewerkers van deze afdeling bij de verschillende hangars en werkplaatsen op Schiphol Oost om de onderdelen daar op te vangen. Er is echter besloten om de onderzoeksfocus alleen op de afdelingen binnen
het LC te plaatsen. Dit houdt in dat er voornamelijk naar de afdelingen Inbound en Outbound gekeken is. Wat volgt is dan ook een beschrijving van de processen rondom deze afdelingen.
2.3 Processen Inbound/Outbound
Van buitenaf gezien lijken de dagelijkse werkzaamheden bij de Inbound en de Outbound veel op elkaar. Voordat deze werkzaamheden verder besproken worden, is het nodig om een beschrijving te geven van de afhandeling van de onderdelen binnen het LC voordat ze bij de genoemde afdelingen komen. Vliegtuigonderdelen worden binnen het LC vervoerd in hun verpakking. Deze verpakking bevat ook de documenten die door de Inbound en de Outbound worden gebruikt om een onderdeel te identificeren en af te handelen. In het vervolg zal er dan ook niet alleen gesproken worden over onderdelen, maar ook over pakketten die door de verschillende afdelingen behandeld worden. De afdeling die verantwoordelijk is voor het transport van pakketten binnen het LC is de Expeditie, de afdeling die tevens
verantwoordelijk is voor de ontvangst van de onderdelen bij het LC. Het transport van de onderdelen gebeurt met behulp van karren waarop de pakketten geplaatst kunnen worden. De Expeditie levert deze karren aan bij de Inbound en de Outbound, waarna de pakketten op het eerst mogelijke moment worden behandeld door medewerkers van deze afdelingen. Als aankomende pakketten niet gelijk kunnen worden behandeld, dan ontstaan er uiteraard wachtrijen.
Wanneer een pakket eenmaal in behandeling is genomen, dan wordt er bij beide afdelingen gekeken of de documenten in de verpakking wel overeenkomen met het daadwerkelijke onderdeel (een inspectie). Als dit het geval is, dan wordt het pakket
administratief behandeld met behulp van verschillende software. De Inbound en de Outbound gebruiken voornamelijk de computersystemen Crocos, Sap en Tracking. Met Crocos en Sap kunnen de onderdelen administratief bij de afdelingen binnengemeld worden. Ook zijn hierin bijvoorbeeld gegevens te vinden over de uit te voeren, of juist uitgevoerde modificaties aan de onderdelen en kunnen er financiële transacties mee uitgevoerd worden. Uiteraard verschillen de werkzaamheden van de Inbound en Outbound het meest in de handelingen die in deze systemen uitgevoerd moeten worden. Tracking is een systeem waarmee medewerkers van E&M uit kunnen vinden waar een onderdeel dat in het beheer van E&M is zich bevindt. Dit gebeurt op basis van een systeem met barcodes en scanners. Elk pakket dat in het beheer van E&M is, bevat namelijk een sticker met een unieke barcode. Wanneer een onderdeel bij een E&M locatie aankomt of vertrekt, dan scant een medewerker van Logistiek deze barcode. Deze scan wordt geregistreerd in Tracking, waardoor E&M medewerkers in deze software kunnen zien waar een onderdeel zich bevindt. Een verdere beschrijving van de binnen het LC gebruikte software zou voorbij gaan aan het doel van dit rapport.
Wanneer een onderdeel niet afgehandeld kan worden door bijvoorbeeld een fout in de meegeleverde gegevens, dan kunnen andere afdelingen van E&M worden ingeschakeld om dit probleem te verhelpen. Deze onderdelen worden voor dit proces in een probleemstelling of Troubleshoot (TSO) stelling geplaatst. Als het probleem verholpen is, dan kan de
administratieve behandeling van dit onderdeel afgemaakt worden. Onderdelen die succesvol zijn behandeld worden voor verder transport aan de Expeditie aangeboden. Onderdelen die van de Outbound komen gaan uiteraard naar een interne of externe werkplaats. Onderdelen die van de Inbound komen worden zoals bekend in de meeste gevallen opgeslagen door E&M. Soms worden deze onderdelen echter direct gebruikt voor het vliegtuigonderhoud of gaan ze terug naar de klant. Wat volgt is een door Logistiek voorgestelde verandering op de beschreven processen. Deze verandering is de motivatie is geweest voor het onderzoek horend bij dit rapport.
2.4 Motivatie: Pre Alerts
De huidige situatie binnen het LC is zo dat medewerkers van de Inbound en de Outbound pas beginnen met de afhandeling van een pakket wanneer het fysiek bij hun afdeling aanwezig is. Voor een groot deel van de administratieve behandeling van de onderdelen zijn echter alleen de gegevens nodig die te vinden zijn op de bij een onderdeel horende documenten. Als de medewerkers van de Inbound en de Outbound eerder beschikking zouden hebben over deze gegevens, dan zouden zij de onderdelen administratief kunnen behandelen
voordat ze daadwerkelijk aanwezig zijn.
In dit kader denkt de unit Logistiek aan een werkmethode bij de Inbound en de Outbound waarbij alle aankomende onderdelen op basis van zogeheten Pre Alerts
administratief worden verwerkt met de gebruikte software. Deze Pre Alerts bevatten de voor E&M benodigde gegevens per onderdeel en dienen op het moment dat de bijbehorende onderdelen op transport gaan aangeleverd te worden door de externe partijen die ruilartikelen naar E&M opsturen (zowel schoon als vuil). Wanneer de onderdelen van tevoren correct in de computersystemen staan, dan hoeft er bij aankomst van de fysieke pakketten alleen nog maar gecontroleerd te worden of het correcte onderdeel is opgestuurd. Deze inspectie is een fysieke handeling die veel minder tijd kost dan de administratieve handelingen. Deze kortere
verwerkingstijd per fysiek pakket leidt in theorie tot een kortere doorlooptijd voor deze pakketten bij de afdelingen Inbound en Outbound; dit is een doorlooptijd die uiteraard voor het grootste deel bestaat uit de periode die een onderdeel wacht op behandeling. Wanneer deze wachttijd verkort wordt, heeft de beheerder van de vliegtuigonderdelen in theorie minder onderdelen in de voorraad nodig om aanvragen voor deze onderdelen op te vangen. Dit zou schelen in de voorraadkosten. Ook maakt een kortere doorlooptijd het overzichtelijker voor de afdeling Logistiek om hun activiteiten te plannen. Een significante verkorting in de
doorlooptijd kan echter alleen gerealiseerd worden onder een aantal voorwaarden:
- De opsturende partijen gaan akkoord met het verzoek om Pre Alerts aan te gaan leveren.
- De Pre Alerts die worden opgestuurd bevatten correcte gegevens over de bijbehorende onderdelen.
- Er is bij de afdelingen Inbound en Outbound genoeg capaciteit aanwezig om (een groot deel van) de Pre Alerts te behandelen voordat de bijbehorende pakketten aankomen.
Deze laatste voorwaarde is ook afhankelijk van wanneer Pre Alerts worden aangeleverd door opsturende partijen en hoe lang het hierna duurt voordat de daadwerkelijke pakketten bij het LC zijn. Het onderzoek dat bij dit rapport hoort is uitgevoerd om een kwantitatief inzicht te geven in de mogelijk te behalen verkorting in de doorlooptijd bij de afdelingen Inbound en Outbound als er gewerkt gaat worden op basis van Pre Alerts. Hierbij is aangenomen dat aan de eerste twee voorwaarden is voldaan. Ook is er onderzocht in hoeverre aan de derde voorwaarde voldaan kan worden met de huidige capaciteit bij de Inbound en de Outbound.
Voordat aan de beschrijving van het onderzoek begonnen kan worden, moet er echter nog een onderscheid gemaakt worden met betrekking tot een bepaalde subafdeling die binnen de Inbound en de Outbound verantwoordelijk is voor de verwerking van Closed Loop
Amsterdam (CLA) onderdelen. Dit zijn onderdelen van maatschappijen die een contract met de KLM hebben waarbij ze hetzelfde onderdeel dat ze voor reparatie opsturen ook weer terugkrijgen. Medewerkers die deze onderdelen behandelen houden zich niet bezig met de overige Inbound en Outbound onderdelen en vice versa. Uiteraard worden er zowel vuile als schone CLA onderdelen in het LC behandeld. De afdeling Logistiek heeft al een onderzoek gedaan naar het effect van het gebruik van Pre Alerts op de doorlooptijden van de vuile CLA onderdelen. Bij het onderzoek horend bij dit rapport zijn ter vergelijking ook deze onderdelen
behandeld. De schone CLA onderdelen zullen in het vervolg compleet buiten beschouwing worden gelaten. In het vervolg zal de CLA divisie als losse afdeling worden gezien en zal er wanneer er gesproken wordt over afdelingen de volgende verdeling bedoeld worden:
- De subafdeling die zich bezig houdt met vuile CLA onderdelen.
- De subafdeling die zich bezig houdt met de resterende vuile onderdelen. - De subafdeling die zich bezig houdt met schone ruilartikelen (niet CLA).
Deze afdelingen doen zoals bekend een administratieve en een fysieke handeling, waarna de onderdelen weer aan de Expeditie aangeboden worden voor vervolgtransport. Na het in kaart brengen van dit proces is er besloten om onderzoek uit te voeren naar het effect van het beschreven gebruik van Pre Alerts op de doorlooptijden van onderdelen binnen het LC. Wat volgt is een beschrijving van de keuze voor de voor dit onderzoek gebruikte methode.
3 Onderzoeksvoorbereiding
Deze sectie gaat in op de voorbereidingen die zijn getroffen met betrekking tot het vergaren van de benodigde invoer voor het uitgevoerde onderzoek. Aandacht zal uitgaan naar de gekozen onderzoeksmethode. Ook wordt er in deze sectie een conceptueel model opgesteld voor de gebruikte onderzoeksmethode.
3.1 Gekozen onderzoeksmethode
Het vakgebied van de Operationele Research biedt veel mogelijkheden om het wachtaspect van een werkomgeving te analyseren en sluit dus goed aan op het beschreven onderzoek naar eventuele doorlooptijdverkorting op basis van een vermindering in wachttijd. Er zijn
analytische wachtrijmodellen beschikbaar, maar wanneer deze niet hanteerbaar blijken kan er ook gebruik gemaakt worden van simulatiesoftware. Als men wachtrijmodellen gebruikt om de wacht- en doorlooptijden op een werkplaats te bepalen, dan komen hier exacte verwachte waarden voor deze grootheden uit voort. Deze modellen gaan uit van één of meerdere afdelingen die in serie of parallel aankomende
klanten behandelen. Deze klanten kunnen mensen zijn die bij een balie aankomen, maar ook bijvoorbeeld binnenkomende
telefoongesprekken of pakketten met vliegtuigonderdelen. Wachtrijmodellen zijn gebaseerd op een aantal per werkplaats unieke gegevens, onder andere:
- Het gemiddelde aantal aankomende klanten per tijdseenheid.
- De gemiddelde verwerkingstijd per klant per afdeling van de werkplaats. - Het aantal werknemers dat aanwezig is per afdeling.
- De grootte van de eventueel aanwezige wachtruimte van de werkplaats.
Het probleem met wachtrijmodellen is echter dat ze in de praktijk nauwelijks bruikbaar zijn. Werkplaatsen kunnen bepaalde aspecten hebben waardoor ze niet met behulp van
wachtrijmodellen geanalyseerd kunnen worden. Wachtrijmodellen gaan bijvoorbeeld uit van
een kansverdeling voor de verwerkingstijd per klant. Sommige wachtsystemen laten maar voor één bepaalde kansverdeling analytische resultaten toe. Als de verwerkingstijden dan niet blijken te voldoen aan deze kansverdeling, dan kan er geen gebruik worden gemaakt van wachtrijmodellen. Sommige systemen zijn ongevoelig voor de kansverdeling van de verwerkingstijden, maar aspecten die dit in de weg kunnen zitten zijn:
- Een wachtruimte.
- Een First Come First Serve discipline, waarbij de klant die het langst staat te wachten als eerste geholpen wordt.
Er zijn dus veel factoren die het verkrijgen van analytische waarden voor wacht- en
doorlooptijden onmogelijk kunnen maken. De consequenties van het gebruik van Pre Alerts bij de Inbound en de Outbound kunnen echter al niet met behulp van wachtrijmodellen geanalyseerd worden, omdat deze modellen een belangrijk aspect van de Pre Alerts niet kunnen meenemen. Een pakket kan namelijk pas behandeld worden als de bijbehorende Pre Alert al gedaan is. Wachtrijmodellen bieden geen mogelijkheden om deze koppeling tussen pakket en Pre Alert mee te nemen in de analyse van de doorlooptijden.
Het is om deze reden dat er gekozen is om voor dit onderzoek gebruik te maken van simulatie. Bij een simulatie wordt er getracht om met specifieke software een model te maken dat de werkelijke situatie op de werkplaats zo goed mogelijk nabootst. Hiermee is ook gelijk een nadeel van simulatie genoemd. Een model is net zo goed als de observaties die gebruikt worden om het op te stellen. Simulatie lijkt echter de beste optie te zijn om de complexiteit die de analyse van het invoeren van Pre Alerts met zich meebrengt op te vangen. Er zijn met de simulatiesoftware Enterprise Dynamics (ED) simulatiemodellen opgesteld voor de situatie waarbij er op de verschillende werkplaatsen nog geen Pre Alerts worden gebruikt. Dit om te kijken of de huidige situatie binnen het LC goed gemodelleerd kon worden. Vervolgens zijn deze modellen aangepast om de invoering van Pre Alerts te analyseren. Wachtrijmodellen zijn wel gebruikt om te testen of ze vergelijkbare resultaten kunnen opleveren met de simulaties voor de situaties waar er nog geen Pre Alerts worden gebruikt. Dit zou als verificatie voor de met simulatie behaalde resultaten gebruikt kunnen worden. De resultaten van dit proces volgen in een later stadium. Wat nu volgt is een beschrijving van de vergaring van de gegevens die nodig zijn geweest voor de gebruikte simulatiemodellen.
3.2 De gebruikte gegevens
Na het bepalen van het te analyseren proces en het maken van een keuze met betrekking tot de gebruikte onderzoeksmethode, is een volgende stap geweest om de voor deze methode
benodigde gegevens te verkrijgen. De volgende subsecties gaan in op dit proces.
3.2.1 Beschikbaarheid benodigde gegevens
De te analyseren afdelingen zijn allemaal afdelingen waar pakketten aankomen vanaf de Expeditie en vervolgens worden behandeld door een wisselend aantal medewerkers dat aanwezig is. Medewerkers werken in principe niet samen aan pakketten. De invoer die een simulatiemodel nodig heeft om dit proces te analyseren bestaat uit:
- Een kansverdeling voor de aankomstintensiteit van het proces. Dit is hoeveel pakketten er per tijdseenheid het proces binnenkomen.
- Een kansverdeling voor de verwerkingstijd per afdeling per pakket. - Het aantal medewerkers dat gemiddeld per afdeling aanwezig is. - Een eventuele capaciteit voor de wachtgelegenheid.
Allereerst is er gezocht naar gegevens over de aankomsten van pakketten in het proces. Zoals aangegeven wordt er in de software Tracking geregistreerd wanneer een onderdeel bij een E&M locatie aankomt of vertrekt. Dit houdt in dat elke aankomst van een onderdeel bij elke subafdeling in het LC te vinden is. De benodigde aankomstgegevens zijn dus in Tracking te vinden. Naast de mogelijkheid om de benodigde gegevens handmatig uit Tracking te halen, is er ook de optie om gegevens te gebruiken die worden verzameld naar aanleiding van een afstudeerproject dat in het verleden bij het LC is uitgevoerd door Jan-Hoite van Hees [1] (deze referentie is te vinden in bijlage A). Sinds dit onderzoek heeft plaatsgevonden, wordt er bijgehouden hoeveel onderdelen er wekelijks bij de Expeditie binnenkomen. Ook wordt er bijgehouden waar deze onderdelen vandaan komen. Onderdelen die vanuit het buitenland naar het LC komen moeten eerst langs de importafdeling van het LC om ingeklaard te worden. Deze afdeling gebruikt het programma Scarlos, waar deze aankomsten ook in geregistreerd worden.
Een afweging die echter eerst gemaakt moest worden, is of de Expeditie wel als afdeling in het simulatiemodel opgenomen moest worden. De Expeditie is namelijk de
afdeling die binnen het LC onderdelen doorstuurt naar de Inbound en de Outbound. Het meenemen van de Expeditie in het simulatiemodel zou misschien kunnen leiden tot een realistischere weergave van de werkelijkheid. Het probleem is alleen dat alle onderdelen die bij het LC aankomen door de Expeditie ontvangen worden. Hier zitten ook veel onderdelen tussen die niet naar de Inbound of de Outbound gaan. Tracking bevat dus ook gegevens over hoeveel van deze aankomsten uiteindelijk naar de Inbound en de Outbound gaan. Men zou deze gegevens kunnen verwerken in een simulatiemodel. Er zijn echter enkele problemen met de data:
- De Expeditie stuurt onderdelen die van Schiphol Oost komen gelijk door naar hun bestemming binnen het LC. Deze onderdelen hebben namelijk al een Tracking sticker, aangezien ze van E&M locaties komen waar medewerkers van Logistiek hun
bestemming al hebben bepaald. Dit aspect moet meegenomen worden in een simulatie, aangezien deze onderdelen een significant andere behandeling hebben dan onderdelen van externe partijen. De gegevens die naar aanleiding van het project van Jan-Hoite van Hees verzameld worden met betrekking tot het aantal onderdelen dat vanaf externe partijen bij het LC aankomt, komen echter niet overeen de gegevens uit het programma Scarlos.
- Onderdelen die van externe partijen komen worden administratief door de Expeditie behandeld. Voor de vuile onderdelen wordt er in Crocos bepaald wat hun bestemming is. Hierna krijgen ze een Tracking sticker. Schone onderdelen hoeven alleen een Tracking Sticker te krijgen. Deze verschillende bewerkingen zouden meegenomen moeten worden in een simulatiemodel, maar uit de gegevens uit Tracking en Scarlos is niet op te maken of een aangekomen onderdeel schoon of vuil is.
Een simulatiemodel zou dus als invoer nodig hebben hoeveel procent van de totale aankomsten bij de Expeditie van externe partijen komt en hoeveel van deze onderdelen schoon, dan wel vuil zijn. Het eerstgenoemde probleem kan worden opgelost door alleen uit te gaan van de gegevens van het onderzoek van Jan-Hoite van Hees, maar het tweede
probleem blijkt onoplosbaar. Er is dan ook gekozen om de Expeditie niet als afdeling mee te nemen in de simulatie. In plaats hiervan is de Expeditie beschouwd als een mechanisme dat aankomsten genereert voor de subafdelingen van de Inbound en de Outbound. Dit kon gedaan worden aangezien er in Tracking dus ook gegevens beschikbaar zijn over deze
Men kan de beschikbaarheid van gegevens voor de overige benodigde invoer korter beschrijven. Verwerkingstijden per pakket per afdeling zijn nooit gemeten. Roosters per afdeling worden bewaard en hieruit kan men afleiden hoeveel medewerkers er gemiddeld aanwezig zijn. Aankomende pakketten worden nooit afgewezen wegens capaciteitsgebrek en in theorie kan men dus spreken van een oneindig grote wachtruimte. Het vervolg van deze sectie gaat in op de verschillende manieren waarop de benodigde gegevens vergaard zijn en de methoden die zijn gebruikt om deze gegevens te vertalen naar bruikbare invoer voor een simulatiemodel.
3.2.2 Aankomstgegevens
Allereerst is er per afdeling een meetperiode gekozen. Dit zijn steeds drie maanden in het recente verleden geweest waarvoor de benodigde gegevens verzameld zijn. Deze periodes verschillen per afdeling omdat er het afgelopen jaar enkele veranderingen zijn geweest in de werkzaamheden die bij de Inbound en de Outbound plaatsvinden. Deze veranderingen zijn op verschillende momenten ingevoerd en het was zaak om een meetperiode te nemen die niet deze momenten bevat. Voor de Inbound is de meetperiode februari 2013 tot en met april 2013 geweest. Voor de Outbound (en ook de vuile CLA onderdelen) is de meetperiode december 2012 tot en met februari 2013 geweest.
Vervolgens is er besloten om niet te zoeken naar een kansverdeling voor de
aankomstintensiteit van losse pakketten bij de afdelingen. Pakketten komen namelijk altijd in groepen bij de subafdelingen van het LC aan, aangezien de Expeditie de onderdelen op karren vervoert. Soms komen er wel meerdere karren met daarop groepen onderdelen tegelijk aan bij een afdeling. Een groep onderdelen die tegelijk aankomt bij een afdeling zal in het vervolg een batch genoemd worden. Met behulp van Tracking zijn Excel bestanden verkregen waarin per afdeling en per meetperiode een lijst te vinden is van de onderdelen die in die periode zijn aangekomen bij de respectievelijke afdelingen. Bij deze onderdelen staat ook het tijdstip van aankomst vermeldt en op basis hiervan is het mogelijk geweest om te bepalen welke
onderdelen samen een batch hebben gevormd. Deze onderdelen hebben namelijk een aankomsttijd die bijna identiek is (er blijven seconden tussen zitten omdat
Expeditiemedewerkers deze onderdelen nog steeds los moeten scannen). Op basis van deze gegevens is per meetperiode een lijst gemaakt van hoeveel batches elke dag aankwamen bij de verschillende afdelingen. Een klein voorbeeld voor de schone ruilartikelen is te vinden in
tabel 3.1. Ook is bijgehouden hoeveel onderdelen deze batches hebben bevat. Dit wordt later in deze sectie uitgebreider besproken.
Wat overbleef was dus per afdeling een lijst met aantallen batches die per dag van de meetperiode aankwamen en per afdeling een lijst met de groottes van alle batches die in de meetperiode aankwamen. Per afdeling is vervolgens met behulp van een statistische Chi-kwadraat test op basis van deze lijsten onderzocht of het aankomstproces van de batches
Maand 2 2013: Aantal batches per dag
Vrijdag 1 februari 12 Zaterdag 2 februari 7 Zondag 3 februari 7 Maandag 4 februari 5 Dinsdag 5 februari 21 Woensdag 6 februari 12 Donderdag 7 februari 15 Vrijdag 8 februari 10 Zaterdag 9 februari 11 Zondag 10 februari 6 Maandag 11 februari 7 Dinsdag 12 februari 13 Woensdag 13 februari 15 Donderdag 14 februari 11 Vrijdag 15 februari 17 Zaterdag 16 februari 9 Zondag 17 februari 5 Maandag 18 februari 9 Dinsdag 19 februari 9 Woensdag 20 februari 14 Donderdag 21 februari 12 Vrijdag 22 februari 10 Zaterdag 23 februari 8 Zondag 24 februari 3 Maandag 25 februari 9 Dinsdag 26 februari 16 Woensdag 27 februari 15 Donderdag 28 februari 9
voldoet aan de Poisson verdeling die over het algemeen voor dit soort processen wordt gebruikt. Hierbij dient opgemerkt te worden dat er op het oog minder batches in het weekend dan doordeweeks bij de Inbound aankomen. Ook komen er voor de CLA afdeling geen batches aan in het weekend. Deze opmerkingen zijn meegenomen in de toetsen.
De besproken Chi-kwadraat toetsen zijn in Excel uitgevoerd op basis van de vergaarde gegevens. Eerst is er bekeken hoe vaak de verschillende aantallen batches zijn voorgekomen in de meetperiode en vervolgens is dit vergeleken met hoe vaak deze aantallen zouden moeten voorkomen als ze een Poisson verdeling zouden volgen. Deze verwachte aantallen zijn
berekend door eerst de kansfunctie van de Poisson verdeling te gebruiken om de kansen op deze aantallen te berekenen en deze kans voor elk aantal vervolgens te vermenigvuldigen met het aantal waarnemingen. De verwachte waarnemingen voor de aantallen aankomende
batches zijn dan ook berekend met de volgende formule:
( ) ! x P aantal batches x e n x
Hierbij staat de variabele x voor de verschillende aantallen batches die per dag aankomen. De constanten λ en n staan respectievelijk voor de per afdeling gemeten gemiddelde aantallen aankomende batches per dag en het aantal waarnemingen van de bijbehorende meetperiode. Wat volgt is een beschrijving van deze toets voor de CLA onderdelen. Op basis van de vergaarde gegevens is er bepaald dat er elke doordeweekse dag gemiddeld 2,073 batches bij de CLA afdeling aankomen. Met deze waarde voor λ en met een aantal van n = 65
waarnemingen komt men op verwachte frequenties waarmee bepaalde aantallen aankomende batches voorkomen bij 65 waarnemingen. Deze frequenties zijn voor de aantallen nul tot en met tien te vinden in tabel 3.2, samen met de werkelijk geobserveerde frequenties van deze aantallen.
Omdat een Chi-kwadraat toets onbetrouwbare resultaten kan opleveren voor geobserveerde frequenties die lager zijn dan vijf, zijn enkele aantallen batches samen
gecategoriseerd. Dit heeft ervoor gezorgd dat elke geobserveerde frequentie hoger is dan vier. Het resultaat van dit proces is te vinden in tabel 3.3. De Chi-kwadraat toets gaat vervolgens uit van een nulhypothese, een alternatieve hypothese en een toetsingsgrootheid. De
nulhypothese is de hypothese die getoetst dient te worden en de alternatieve hypothese is hier het complement van. De hypotheses zijn op de volgende pagina opgesteld.
Aantal Verwachte frequentie Realisatie 0 13,84 22 1 28,69 23 2 29,74 30 3 20,54 17 4 10,65 9 5 4,41 4 6 1,52 2 7 0,45 1 8 0,12 0 9 0,03 1 10 0,01 1
Tabel 3.2: verwachte en geobserveerde aantallen batches
Aantal Verwachte frequentie Realisatie
0 13,84 22 1 28,69 23 2 29,74 30 3 20,54 17 4 10,65 9 5 4,41 4 6 en hoger 2,13 5
Tabel 3.3: nieuwe categorieën voor de Chi-kwadraat toets
0:
H de per dag aankomende batches volgen een Poisson verdeling met gemiddelde 2,073.
1:
H de per dag aankomende batches volgen geen Poisson verdeling met gemiddelde 2,073.
De toetsingsgrootheid wordt berekend op basis van de verwachte en geobserveerde
frequenties en als deze grootheid binnen een kritiek gebied ligt, dan dient de nulhypothese verworpen te worden. De toetsingsgrootheid die bij de gebruikte toets hoort is:
2 2 ( i i) i i f e e
Hierbij is i een index over de verschillende gebruikte categorieën met betrekking tot de aantallen aankomende batches en zijn f en i ei respectievelijk de geobserveerde en verwachte frequenties die horen bij de categorie i. Als men deze toetsingsgrootheid uitrekent op basis van de gegevens uit tabel 3.3, dan volgt dat 2 10,73.
De vraag is nu dus of deze grootheid in het kritieke gebied van deze specifieke toets ligt. Dit kritieke gebied bevat alle waarden boven een bepaalde ondergrens. Deze ondergrens wordt bepaald door de karakteristieken van de uitgevoerde toets. Tabellen die horen bij de
Chi-kwadraat toets bevatten ondergrenzen voor kritieke gebieden die gebaseerd zijn op de gekozen betrouwbaarheid en het aantal vrijheidsgraden van de toets. In dit geval is er besloten om een betrouwbaarheid van 95 procent te hanteren. Een tabel voor verschillende
betrouwbaarheidsniveaus is te vinden in Bijlage C. Het aantal vrijheidsgraden van de
uitgevoerde toets wordt bepaald door de formule (k – 1) – p. Hierbij staat de variabele k voor het aantal categorieën met betrekking tot de verwachte en geobserveerde frequenties en p voor het aantal parameters van de onderzochte verdeling. Omdat er zeven categorieën zijn
gehanteerd en omdat de Poisson verdeling bepaald wordt door één parameter, is het aantal vrijheidsgraden van de uitgevoerde toets vijf. Op basis van deze gegevens kan uit de tabellen van de Chi-kwadraat verdeling gehaald worden dat de ondergrens van het te gebruiken kritieke gebied 11,07 is. Op basis hiervan kan er geconcludeerd worden dat de berekende toetsingsgrootheid zich niet in dit kritieke gebied bevindt. Zoals al eerder aangegeven komen de batches bij de CLA afdeling dus volgens een Poisson proces aan. Dit is verwerkt in de gebruikte simulatiemodellen, met de specificatie dat er dus geen onderdelen in het weekend aankomen. Vergelijkbare toetsen hebben uitgewezen dat de aankomstprocessen bij de andere afdelingen ook de Poisson verdeling volgen. Wel zijn er twee verschillende toetsen nodig geweest voor de aankomsten doordeweeks en in het weekend bij de Inbound.
Vervolgens is er ook een kansverdeling gevonden voor de groottes van de batches die bij elke afdeling aankomen. Een voorbeeld van een lijst batchgroottes voor de Inbound is te vinden in tabel 3.4. Vervolgens is met Enterprise Dynamics voor de verschillende afdelingen een kansverdeling voor de batchgroottes gevonden. Dit is gedaan met de Autofit Tool. Een functie van ED die te vinden is onder Tools Autofit. Deze functie vindt kansverdelingen op basis van ingevoerde tabellen met gegevens. Eerst is er geprobeerd om voor elke afdeling de batchgroottes die gemeten zijn tijdens de totale meetperiode in te voeren. Het is echter zo vaak voorgekomen dat een batch maar uit één onderdeel bestond, dat ED met te weinig betrouwbaarheid een kansverdeling kon vinden. Er is dan ook besloten om per afdeling 50 batchgroottes te gebruiken om een verdeling te vinden. Dit is voor elke afdeling een Beta verdeling geworden.
Nu lijkt dit apart, aangezien het hier om een continue verdeling gaat en de batches uiteraard alleen maar uit discrete aantallen bestaan. ED kan echter alleen maar continue verdelingen bepalen voor databestanden. Als het nodig is rondt het programma trekkingen uit deze verdelingen af naar hele getallen en dit is tijdens dit onderzoek ook gebeurd. Er is gecontroleerd of ED met de gevonden verdelingen het correcte aantal onderdelen genereert
in een bepaald tijdsbestek (gebaseerd op werkelijke aantallen uit een vergelijkbare periode) en het is gebleken dat dit zo is. Figuur 3.2 toont een histogram van de gevonden batchgroottes voor de CLA onderdelen. Met de juiste parameters en opschaling kan deze grafiek vergeleken worden met de kansdichtheid van een Beta verdeling.
Vervolgens is er over de hele meetperiode een gemiddelde van de batchgroottes genomen en zijn deze gemiddelden in combinatie met de voor 50 groottes gevonden
kansverdelingen gebruikt als invoer voor ED. Het invoeren van deze kansverdelingen in het gebruikte simulatiemodel moet namelijk leiden tot een correcte weergave van het
aankomstproces bij de bekeken afdelingen. De gevonden kansverdelingen zijn te vinden in tabel 3.6 aan het eind van deze sectie over gegevens.
Maand 2 2013 Batchnummer Batchgrootte
Vrijdag 1 februari 1 1 2 2 3 9 4 3 5 1 6 4 7 1 8 1 9 3 10 13 11 7 12 5 Zaterdag 2 februari 1 1 2 11 3 6 4 9 5 2 6 0 7 6
Figuur 3.2: histogram voor de CLA batchgroottes
3.2.3 Verwerkingstijden
Bij het LC wordt er zoals eerder aangegeven niet bijgehouden hoe lang medewerkers
daadwerkelijk met een pakket bezig zijn. Een kansverdeling voor deze variabele is echter een noodzakelijke invoer voor een simulatie. Er moesten dus metingen uitgevoerd worden. Dit is gedaan met behulp van de software Lazarus, waarmee een computerprogramma is geschreven dat de tijd tussen twee aangegeven momenten meet en deze tijd gelijk wegschrijft naar een bestand op de computer waarmee gewerkt wordt. Dit maakte het mogelijk om tijdens het meten door te gaan met overige onderdelen van het onderzoek. Aan Lazarus moest alleen aangegeven worden wanneer met een pakket begonnen werd en wanneer dit pakket werd afgerond door de desbetreffende medewerker. De code van dit programma is te vinden in Bijlage B.
Er is gekozen om per afdeling geen onderscheid te maken tussen eventuele
verschillende soorten onderdelen die er aankomen. Het kan bijvoorbeeld het geval zijn dat onderdelen van bepaalde luchtvaartmaatschappijen meer of juist minder werk opleveren dan KLM onderdelen. Uit Tracking is echter niet te halen door welke maatschappij de
aankomende onderdelen opgestuurd zijn. Ook was er niet genoeg tijd geweest om per afdeling voor meerdere soorten onderdelen metingen te doen, aangezien er minstens 50 metingen nodig zijn om een betrouwbare kansverdeling voor één type onderdeel te verkrijgen. Dit is de reden dat er is besloten om alle onderdelen die per afdeling binnenkomen onder dezelfde
0 2 4 6 8 10 12 14 16 18 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31
kansverdeling te scharen. Voor de verschillende afdelingen zijn er uiteraard wel verschillende kansverdelingen verkregen. Dit is weer gedaan met de Autofit Tool van ED.
Verder zijn tegelijkertijd metingen uitgevoerd naar de inspectietijden per onderdeel. Deze tijden zijn nodig voor het onderzoek naar Pre Alerts; als een Pre Alert is gedaan hoeft een aangekomen fysiek onderdeel alleen nog maar geïnspecteerd te worden. Als men dan het verschil tussen de inspectietijd en de verwerkingstijd van voor de invoering van de Pre Alerts neemt, is dit een gemiddelde tijd die genomen kan worden voor de administratieve
verwerking (de Pre Alert). Voor de verschillende beschreven verwerkingstijden zijn er kansverdelingen verkregen. Ook de kansverdelingen voor de totale verwerkingstijden en de inspectietijden zijn te vinden in tabel 3.6.
3.2.4 Aantal aanwezige medewerkers
Aangezien er voor de verschillende afdelingen binnen het LC roosters bewaard worden, is het mogelijk geweest om voor elke bekeken afdeling te bepalen hoeveel mensen er gemiddeld aanwezig zijn geweest in de respectievelijke meetperioden. Binnen het LC wordt gewerkt met dag- en avonddiensten en voor elke afdeling is er per dag van de meetperiode in Excel het aantal mensen geteld dat toen een dienst had. Op basis hiervan is er bepaald hoeveel
medewerkers er gemiddeld per dienst op een bepaalde afdeling gewerkt hebben. Omdat er in het weekend significant minder mensen aanwezig zijn, is er per afdeling wel een onderscheid gemaakt tussen het gemiddelde aantal medewerkers per weekdienst en per weekenddienst. Hiernaast is er een inschatting gemaakt van de tijd die werknemers besteden aan pauze en andere zaken waardoor men niet bezig is met het verwerken van vliegtuigonderdelen. Er is gewerkt met de aanname dat er op een werkdag die bestaat uit twee diensten van 8,5 uur steeds 12,5 uur daadwerkelijk besteed wordt aan het verwerken van vliegtuigonderdelen. Dit komt neer op een productiviteit van ruim 75 procent, hierover volgt later meer.
Voor de CLA onderdelen is er op een iets andere manier gewerkt. Ook hiervoor is gekeken naar hoeveel mensen er gemiddeld op de afdeling aanwezig zijn geweest. Dit is echter een moeilijk vraagstuk gebleken. In de meetperiode zijn er enkele mensen gestopt met werken bij deze afdeling, of juist hiermee begonnen. Ook springen mensen van andere afdelingen soms in om onderdelen van deze afdeling te behandelen. Hierdoor is op basis van de roosters niet definitief vast te stellen hoeveel mensen er tijdens een bepaalde dienst in de meetperiode aanwezig zijn geweest.
Aantal medewerkers Dag Avond
0 17% 50%
1 23% 13%
2 60% 37%
Tabel 3.5: percentages aanwezigheid CLA
Op basis van observaties en gesprekken met medewerkers is er gebleken dat er elke dienst nul, één of twee mensen aanwezig zijn om CLA onderdelen te behandelen. In plaats van een gemiddelde te zoeken voor het aantal medewerkers dat per weekdienst en weekenddienst aanwezig is geweest, is er een verdeling gevonden met betrekking tot hoe vaak er nul, één of twee mensen aanwezig waren. Om dit te bereiken is er in Excel in de verkregen roosters geteld hoeveel mensen er per dienst met de CLA onderdelen bezig zijn geweest. Als dit aantal een keer boven de twee uitkwam, dan is ervan uitgegaan dat er deze dienst toch twee mensen aanwezig zijn geweest. Hieruit is een verdeling gekomen met betrekking tot hoeveel procent van de diensten in de meetperiode er nul, één of twee medewerkers dienst hadden. Deze percentages zijn terug te vinden in tabel 3.5.
Deze percentages en de gemiddelde aantallen aanwezigen per week- en weekenddienst voor de overige afdelingen dienen als invoer voor de gebruikte simulaties. De gegevens voor de Outbound en de Inbound zijn weer te vinden in tabel 3.6. Ook zijn er per afdeling voor de verschillende soorten diensten bezettingsgraden berekend. Dit is alleen niet gedaan voor de CLA onderdelen, omdat het aantal medewerkers hier alternatief is berekend. Wat volgt is een voorbeeld voor de berekening die hoort bij de weekdienst voor de Outbound afdeling. Uit het aantal aankomende batches en de gemiddelde batchgrootte is af te leiden dat er λ = 36,58 onderdelen per weekdag aankomen. Als men kijkt naar de besproken werkdag van 12,5 uur, dan kan één medewerker in deze tijd μ = 12,5*60/25,9 = 28,96 onderdelen verwerken. Met het feit dat er in de bekeken dienst gemiddeld s = 2,22 werknemers aanwezig zijn en de wetenschap dat de formule voor de bezettingsgraad gegeven wordt door ρ = λ/sμ, komt de bezettingsgraad in dit geval uit op ρ = 0,57. De overige bezettingsgraden zijn ook te vinden in tabel 3.6. Hieruit valt op te maken dat er doordeweeks mogelijk sprake is van overbezetting, terwijl er in het weekend juist onderbezetting plaatsvindt. Voor de overzichtelijkheid is er tevens een gemiddelde bezettingsgraad voor deze afdelingen te zien. In de volgende sectie zullen de binnen het LC gemeten doorlooptijden bij de bekeken afdelingen besproken worden die op basis van deze gegevens gehaald worden binnen het LC.
Afdeling CLA Outbound Inbound
Batches per weekdag Gemiddelde 2,073 10,45 12,7
Bijbehorende kansverdeling Poisson Poisson Poisson
Batches per weekenddag Gemiddelde 2,073 10,45 8
Bijbehorende kansverdeling Poisson Poisson Poisson
Batchgrootte (onderdelen)
Gemiddelde 9,2 3,5 4,14
Bijbehorende kansverdeling Beta Beta Beta
Verwerkingstijd (minuten)
Gemiddelde 25,9 25,9 23,2
Bijbehorende kansverdeling Lognormaal Lognormaal Lognormaal
Inspectietijd (minuten)
Inspectietijd (minuten) 4,4 4,4 3,6
Bijbehorende kansverdeling Erlang Erlang Lognormaal
Aantal medewerkers per dienst Weekdienst N.v.t. 2,22 2,36 Weekenddienst N.v.t. 0,71 0,62 Bezettingsgraad per dienst Weekdienst N.v.t. 0,58 0,69 Weekenddienst N.v.t. 1,78 1,65 Gemiddelde N.v.t. 0,92 0,96
Tabel 3.6: verkregen gegevens voor de bekeken afdelingen in het LC
3.3 Werkelijk gemeten doorlooptijden
Om te kunnen bepalen of de doorlooptijden die uit de uitgevoerde simulaties naar voren komen realistisch zijn, moet er bepaald worden of deze doorlooptijden overeenkomen met de tijden die daadwerkelijk behaald worden door de afdelingen van het LC. Gelukkig bestaat deze mogelijkheid, aangezien er door Logistiek met behulp van Tracking gemiddelde doorlooptijden worden bijgehouden voor de verschillende afdelingen. Deze gemiddelden worden berekend over een week en zijn voor een bepaalde periode te vinden op de gedeelde schijf op computers binnen het KLM netwerk. Het gaat hier om de tijd tussen het moment dat de Expeditie in Tracking registreert dat een pakket bij een bepaalde afdeling ligt en het moment dat een medewerker van deze afdeling registreert in Tracking dat dit pakket voor vervolgtransport is aangeboden aan de Expeditie.
Bij deze doorlooptijden wordt ook rekening gehouden met het feit dat sommige onderdelen tijdelijk aan andere afdelingen worden overgedragen omdat er problemen mee zijn. Deze onderdelen zijn niet meegenomen in de metingen. De enige afdeling waarvoor hier geen rekening mee wordt gehouden is de afdeling die de CLA onderdelen behandeld. Voor de andere afdelingen zijn de doorlooptijden opgezocht voor de gebruikte meetperioden. Deze doorlooptijden zijn te vinden in tabel 3.7.
De gemiddelden van deze doorlooptijden kunnen uiteindelijk vergeleken worden met de resultaten van de uitgevoerde simulaties. Alleen voor de CLA onderdelen was dit proces dus problematisch, aangezien er niet bekend is hoeveel onderdelen er daar naar de
Outbound Inbound
Week meetperiode Doorlooptijden Week meetperiode Doorlooptijden
Week 1 52,44 Week 1 36,86 Week 2 29,54 Week 2 74,61 Week 3 54,33 Week 3 48,61 Week 4 54,06 Week 4 56,92 Week 5 52,18 Week 5 63,39 Week 6 63,20 Week 6 37,77 Week 7 82,08 Week 7 45,92 Week 8 65,73 Week 8 74,55 Week 9 37,12 Week 9 55,17 Week 10 41,02 Week 10 45,26 Week 11 33,39 Week 11 57,04 Week 12 31,50 Week 12 32,26 Week 13 34,12 Week 13 39,36 Week 14 42,14 Week 14 18,70
Tabel 3.7: uit Tracking verkregen doorlooptijden voor de Outbound/Inbound
onderdeel dat in een bepaalde maand deze afdeling heeft bezocht. Besloten is om aan te nemen dat alle onderdelen die een doorlooptijd hebben gehad van langer dan 100 uur te classificeren als probleemstellingonderdelen. Dit betreft dertien procent van de onderdelen.
Deze onderdelen zijn weggelaten uit de berekeningen, en hiermee is een gemiddelde doorlooptijd van 42,83 uur verkregen over alle CLA pakketten die in deze maand niet naar de probleemstelling zijn gegaan. Dit is niet de exact behaalde doorlooptijd, maar er is besloten om hiervan uit te gaan. Een reden hiervoor is ook geweest dat er al een experiment is
uitgevoerd binnen het LC om het effect van het gebruik van Pre Alerts op de doorlooptijd van de CLA onderdelen te bepalen. Omdat dit al is gebeurd was het dus niet noodzakelijk om simulaties uit te voeren voor de CLA onderdelen. Deze zijn echter toch uitgevoerd, om te kijken of dezelfde resultaten worden bereikt als tijdens het experiment. De gemiddelde doorlooptijden voor alle andere afdelingen zijn ook berekend en de doorlooptijden zijn per afdeling samengevat in tabel 3.8. Uiteindelijk zijn er dus simulaties uitgevoerd waarvan de resultaten vergeleken moeten worden met deze doorlooptijden.
CLA Inbound Outbound
42,83 49,03 48,06
3.4 Verblijftijden in probleemstellingen
Zoals aangegeven worden sommige onderdelen bij de verschillende afdelingen in stellingen geplaatst omdat er een probleem mee is. Als men dit mee wil nemen in een simulatiemodel, dan moet er onderzocht worden hoe lang de verblijftijd van onderdelen in deze stellingen is. Allereerst dient er opgemerkt te worden dat er bij de Inbound afdeling in de hele meetperiode maar 61 onderdelen naar de probleemstelling gegaan. Dit aantal is zo laag dat er is besloten om de probleemstelling te negeren voor de Inbound onderdelen. Verder is besloten om de verblijftijd van CLA en Outbound onderdelen in de stellingen gelijk te stellen, omdat het om vergelijkbare onderdelen gaat. Bij de Outbound afdeling wordt er een groot aantal onderdelen tijdelijk opzij gezet. Bij deze afdeling gaan namelijk veel onderdelen naar een stelling, omdat er naast een probleemstelling ook zogenaamde sidestep stellingen zijn. Dit zijn stellingen waar bepaalde types onderdelen standaard naar toe moeten. Om de verblijftijd van deze onderdelen in de verschillende stellingen te kunnen bepalen, is er gekeken naar de bij de KLM beschikbare gegevens over de doorlooptijden van onderdelen bij de Outbound.
Naast de eerder beschreven doorlooptijden voor onderdelen die niet naar een stelling gaan en gelijk doorgestuurd worden, worden er door Logistiek namelijk ook doorlooptijden bijgehouden voor alle onderdelen die door de Outbound verwerkt worden. Een lijst met deze doorlooptijden voor de weken in de meetperiode is te vinden in tabel 3.9. De doorlooptijden staan hier vermeld in uren. De gemiddelde doorlooptijd van onderdelen die niet in een stelling
Week meetperiode Doorlooptijd alle onderdelen
Week 1 69,10 Week 2 68,26 Week 3 70,10 Week 4 104,39 Week 5 109,58 Week 6 128,96 Week 7 77,05 Week 8 51,06 Week 9 52,69 Week 10 46,07 Week 11 46,04 Week 12 48,26
terechtkomen is zoals bekend 48,06 uur. De gemiddelde doorlooptijd van alle onderdelen die langs de Outbound gaan komt uit op 72,63 uur. Aangezien vijftig procent van de onderdelen bij de Outbound naar een stelling gaan, kan er gesteld worden dat vijftig procent van alle onderdelen een doorlooptijd van 48,06 uur bijdragen aan de totale doorlooptijd van 72,63 uur en vijftig procent een nog onbekende doorlooptijd (die van de stellingonderdelen dus). Oftewel:
Hierbij is de variabele x de gemiddelde doorlooptijd van de onderdelen die bij de Outbound naar een stelling gaan, met betrekking tot de meetperiode. Als men deze vergelijking oplost, dan komt men op een doorlooptijd van 97,2 uur voor deze onderdelen. Aangezien bekend is dat onderdelen zonder stellingbezoek gemiddeld 48,06 uur bij de Outbound verblijven, is het verschil tussen de doorlooptijd van de stellingonderdelen en de doorlooptijd van de overige onderdelen een benadering van de gemiddelde verblijftijd van onderdelen in de verschillende stellingen. Dit komt dus neer op 49,14 uur.
3.5 Conceptueel model
Met alle gegevens beschikbaar zal er nu een conceptueel model beschreven worden, waarin deze gegevens gebruikt worden om een basis te creëren voor mogelijke simulatiemodellen. Er zal een conceptueel model beschreven worden voor de situatie waarbij er geen Pre Alerts gebruikt worden en een conceptueel model voor de situatie waarbij dit wel gebeurt. De verwerking van deze conceptuele modellen in Enterprise Dynamics zal in de volgende secties besproken worden.
3.5.1 De situatie zonder Pre Alerts
In een simulatiemodel voor de situatie zonder Pre Alerts wordt er gekeken naar de huidige situatie binnen het LC. De modellen voor de verschillende beschreven soorten onderdelen zullen er veelal hetzelfde uitzien. Onderdelen komen in batches via de Poisson verdelingen uit tabel 3.6 het model binnen. In deze tabel is ook te vinden hoeveel onderdelen deze batches gemiddeld bevatten. De onderdelen dienen vervolgens gerepareerd te worden door het correcte aantal aanwezige medewerkers (dit hangt dus af van wat voor soort dienst er op dat moment gaande is). Deze reparatie dient per type onderdeel met de eerder beschreven
verwerkingstijden uitgevoerd te worden. Verder dient de genoemde productiviteit van 75 procent voor de medewerkers in een simulatiemodel verwerkt te worden. Mochten er niet genoeg medewerkers aanwezig zijn om een onderdeel direct op te pakken, dan dient er in het model een wachtmogelijkheid aanwezig te zijn. Onderdelen die succesvol gerepareerd zijn door de medewerkers verlaten vervolgens het model, maar zoals beschreven moeten sommige onderdelen tijdelijk opzij gezet worden omdat er een probleem mee is. In een model voor deze situatie dient dus ook een gelegenheid te zijn waar deze probleemonderdelen de eerder genoemde tijd wachten. Deze onderdelen dienen met prioriteit opgepakt te worden wanneer hun specifieke probleem is verholpen.
Figuur 3.3 laat een flowchart zien waarin een conceptueel model voor de situatie getoond wordt voor de verschillende typen onderdelen. De probleemstelling in dit model is optioneel, aangezien deze niet voor alle afdelingen nodig is. Zoals eerder beschreven gaat er gemiddeld dertien procent van de CLA onderdelen naar een probleemstelling. Er is al aangegeven dat dit percentage hoger zal zijn voor de Outbound onderdelen. Met behulp van Tracking is dit percentage ook bepaald.
Aankomst onderdelen Wachtrij Medewerkers Probleemstelling (optioneel) Vertrek onderdelen
Week meetperiode Totaal TSO Percentage Week 1 69 25 36% Week 2 237 101 43% Week 3 282 149 53% Week 4 229 106 46% Week 5 151 102 68% Week 6 196 85 43% Week 7 227 174 77% Week 8 247 149 60% Week 9 295 137 46% Week 10 270 134 50% Week 11 318 131 41% Week 12 329 139 42% Week 13 318 113 36% Week 14 203 80 39%
Tabel 3.10: percentage pakketten naar TSO bij de Outbound
Uit de gegevens is gebleken dat ongeveer 50 procent van de onderdelen bij deze afdeling naar een stelling gaat. Per week van de meetperiode is er gekeken hoeveel onderdelen er bij de Outbound aan zijn gekomen en hoeveel van deze onderdelen in Tracking bij een stelling geregistreerd zijn. Hieruit zijn wekelijkse percentages op te maken met betrekking tot het aantal onderdelen dat naar een stelling moet. Deze aantallen en percentages zijn te vinden in tabel 3.10. De aantallen in de eerste en laatste week zijn lager omdat de meetperiode niet alle dagen van deze weken bevat. Ook zijn er lage aantallen in sommige weken omdat die weken feestdagen bevatten. Nadat deze onderdelen opnieuw uit de stellingen opgepakt zijn door een medewerker verlaten zij het model.
3.5.2 De situatie met Pre Alerts
Om de invoer van Pre Alerts bij het LC te kunnen analyseren, dient het model voor de situatie zonder Pre Alerts uiteraard aangepast te worden. De manier waarop onderdelen het systeem binnenkomen verandert niet. Wat wel nieuw is, is het feit dat de meeste onderdelen vooraf zijn gegaan door een Pre Alert. Pre Alerts dienen over het algemeen een paar dagen voor het bijbehorende onderdeel het model te betreden. De koppeling tussen een onderdeel en zijn Pre Alert moet gemaakt worden, aangezien er ook onderzocht moet worden hoeveel Pre Alerts er op tijd behandeld kunnen worden. Als een Pre Alert niet op tijd uitgevoerd kan worden, dan moet een onderdeel dat opgepakt wordt alsnog op dat moment administratief verwerkt worden. De medewerkers moeten in een model dus onderscheid kunnen maken tussen onderdelen waarvan Pre Alerts al wel of nog niet behandeld zijn. Ook zal voor de CLA
onderdelen in deze situatie de probleemstelling ontbreken, aangezien er aangenomen wordt dat Pre Alerts de juiste gegevens bevatten over een onderdeel. De stelling zal er nog wel zijn in het model voor de Outbound onderdelen, aangezien veel onderdelen bij deze afdeling standaard naar een stelling gaan. In het vervolg zal gespecificeerd worden welke soorten onderdelen op basis van Pre Alerts verwerkt worden. In figuur 3.4 is alvast een flowchart gemaakt waarin een conceptueel model voor de situatie met Pre Alerts wordt weergegeven. De medewerkers pakken dus zowel Pre Alerts op als fysieke onderdelen. Er kan gevarieerd worden met betrekking tot de prioriteit van deze twee taken. De fysieke onderdelen worden verwerkt volgens de gevonden verdelingen voor inspectietijden per afdeling uit tabel 3.6. De verwerkingstijd van de Pre Alerts is te berekenen als het verschil tussen de totale
verwerkingstijd van de desbetreffende onderdelen en de bijbehorende inspectietijd. Aankomst onderdelen Aankomst Pre Alerts Wachtrij onderdelen Wachtrij
Pre Alerts Medewerkers
Probleemstelling (optioneel)
Vertrek onderdelen
Aangenomen is dat deze tijden dezelfde kansverdelingen volgen als de totale verwerkingstijden.
Er dienen enkele opmerkingen gemaakt te worden met betrekking tot het model voor de invoer van Pre Alerts. Zo gaan pakketten die bij interne KLM werkplaatsen worden gerepareerd sinds de invoering van de Pre Alerts niet meer langs de CLA afdeling voor inspectie, maar worden deze door de Expeditie gelijk naar de werkplaats doorgestuurd. Dit gebeurt onder voorwaarde dat de administratie (de Pre Alert) wel al door de CLA afdeling is gedaan. Volgens de gegevens uit Tracking ging in de meetperiode 50 procent van de CLA onderdelen naar interne werkplaatsen. Om dit percentage te bepalen, is er per hele week van de meetperiode met behulp van Tracking bepaald hoeveel van de die week door de CLA afdeling verwerkte onderdelen uiteindelijk gescand zijn op Expeditiepunten van interne werkplaatsen. Dit zijn dertien weken en dus één minder dan de eerder genoemde veertien weken. De gegevens voor deze berekening zijn te vinden in tabel 3.11. Dit feit dient uiteraard meegenomen te worden in een model voor de CLA Pre Alerts.
Verder zullen Pre Alerts niet voor alle onderdelen aangevraagd worden. Alle CLA en Inbound onderdelen zullen idealiter in de toekomst van Pre Alerts voorzien worden. Voor onderdelen die vanaf Schiphol Oost bij de Outbound aankomen, zal er echter niet met Pre Alerts gewerkt gaan worden; dit omdat de korte transporttijd van deze onderdelen naar het LC waarschijnlijk niet genoeg mogelijkheid biedt tot het tijdig afhandelen van Pre Alerts. Uit Tracking is voor de meetperiode bepaald hoeveel van de bij de Outbound aankomende onderdelen wekelijks eerst op Expeditiepunten van Schiphol Oost locaties gescand zijn. Op basis hiervan is berekend dat 35 procent van de bij de Outbound aankomende onderdelen van interne locaties afkomstig is. De wekelijkse aantallen en percentages zijn te vinden in
Week meetperiode Totaal Interne bestemming Percentage
Week 1 115 71 62% Week 2 62 53 85% Week 3 112 53 47% Week 4 82 47 57% Week 5 81 41 51% Week 6 74 28 38% Week 7 99 44 44% Week 8 100 54 54% Week 9 89 17 19% Week 10 54 58 52% Week 11 80 34 43% Week 12 53 41 77% Week 13 166 31 19%
tabel 3.12. Deze onderdelen horen in een model voor de Outbound afdeling dan ook geen Pre Alert mee te krijgen.
Week meetperiode Totaal Interne afkomst Percentage
Week 1 69 19 28% Week 2 237 92 39% Week 3 282 87 31% Week 4 229 76 33% Week 5 151 65 43% Week 6 196 61 31% Week 7 227 103 45% Week 8 247 121 49% Week 9 295 83 28% Week 10 270 73 27% Week 11 318 110 35% Week 12 329 105 32% Week 13 318 110 35% Week 14 203 75 37%
4 Simulaties: de situatie zonder Pre Alerts
Nu alle voorbereidende werkzaamheden toegelicht zijn, zullen in deze sectie de
simulatiemodellen beschreven worden die zijn gebruikt om de verschillende afdelingen in het LC weer te geven. Ook zullen de doorlooptijden worden besproken die uit deze simulaties naar voren zijn gekomen.
4.1 De CLA stroom
De eerste afdeling die bekeken is, is de afdeling die zich bezighoudt met de vuile CLA onderdelen. Wat volgt is een herhaling van de voor deze afdeling verkregen gegevens en het model dat gebruikt is om deze afdeling te simuleren. Onderdelen komen doordeweeks tijdens werktijd in batches via een Source atoom het model binnen. Om dit te realiseren zijn
Availability Control atomen gebruikt om het Source atoom volgens een bepaald rooster te laten opereren. Dit houdt in dat het Source atoom in het model buiten werktijd en in het weekend geen batches produceert. Time Schedule atomen zijn gebruikt om roosters in te stellen voor de Source. Deze roosters zijn vervolgens gekoppeld aan een Availability Control atoom en dit atoom is gekoppeld aan de Source. De roosters werken op basis van tabellen waarin wordt aangegeven op welk moment het gecontroleerde atoom dient te stoppen met zijn werkzaamheden en ook op welk moment het atoom zijn taken weer moet gaan uitvoeren.
Roosters die aangegeven dat de Source alleen doordeweeks tijdens werktijd producten genereert zijn te vinden in tabel 4.1 en tabel 4.2. De roosters zijn zo ingesteld dat het model start op een maandagochtend om zes uur ’s ochtends. In tabel 4.1 is te zien dat de Source zeventien uur later stopt met het produceren van batches; dit kan men aangeven door
allereerst een tijd van zeventien uur (hr(17)) aan te geven en vervolgens in de cel ernaast een 1 te plaatsen om aan te geven dat de Source na deze tijd moet stoppen met het produceren van
Time Down=1
hr(17) 1
hr(24) 0
Tabel 4.1: specificatie werktijd
Time Down=1
hr(113) 1
hr(168) 0
batches. Het is op dit moment elf uur ’s avonds in het model en dit is de tijd waarop de Expeditiemedewerkers stoppen met werken. Verder is in tabel 4.1 te zien dat de Source vierentwintig uur na de referentietijd weer dient te beginnen met het produceren van batches; dit is aangegeven door de 0 in de tweede rij. De eerste keer dat dit rooster gedraaid wordt gaat het dan om zes uur ’s ochtends op de dinsdag. Door dit rooster elke 24 uur te herhalen, is bereikt dat de Source alleen tijdens werktijd batches produceert. Verder zorgt het rooster uit tabel 4.2 er op vergelijkbare wijze voor dat de Source vrijdagavond om elf uur stopt met het produceren van batches en hier pas weer mee begint op maandagochtend om zes uur. Dit rooster wordt wekelijks herhaald. De roosters leiden tot een correcte weergave van het
aankomstproces, aangezien de Source alleen producten aanmaakt als beide roosters aangeven dat dit op dat moment mogelijk is.
In de periode dat er wel batches aankomen, gebeurt dit met een tussenaankomsttijd van 8,2 uur. Deze tijd is Negatief Exponentieel verdeeld en is gebaseerd op het feit dat er per werkdag van zeventien uur gemiddeld 2,073 batches aankomen. De batches worden
vervolgens door een Server atoom opgesplitst door in het menu van dit Server atoom de Batch Rule zo in te stellen dat van elk binnenkomend product B kopieën worden gemaakt en
doorgestuurd. Deze B kopieën zijn de losse onderdelen van de batch en worden op basis van de gevonden Beta verdeling met gemiddelde 9,2 gegenereerd.
De losse onderdelen komen vervolgens in een wachtrij terecht, waarna ze worden opgepakt door een willekeurige aanwezige Server. De meeste pakketten worden door de Server atomen naar de Sink van het model gestuurd (deze zijn met succes door de
medewerkers verwerkt), maar dertien procent wordt met behulp van de Send to functie naar een Multiservice atoom gestuurd dat de probleemstelling dient voor te stellen. Dit atoom pakt meerdere producten tegelijkertijd op en behandelt deze voor een bepaalde tijd. De producten verblijven hier dan ook een op gegevens uit Tracking gebaseerde tijd en komen daarna in een rij, waarna ze met voorrang door een aanwezige Server worden opgepakt. De tijd die voor dit stellingverblijf is genomen, is zoals eerder beschreven 49,14 uur. De voorrang is
geïmplementeerd door de rij van onderdelen die uit de probleemstelling komen als eerste invoerkanaal van de Servers in te stellen en de Input strategy van de servers vervolgens op Any inputchannel in te stellen.
Eerder is naar voren gekomen dat de gemeten behandeltijd van CLA onderdelen gemiddeld 25,9 minuten is. Deze verwerkingstijden volgen een Lognormale verdeling. De vraag die overblijft, is hoe lang medewerkers over het afronden van een pakket dat uit een
