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

probleemstelling komt doen. Metingen uitvoeren om deze tijd te bepalen bleek niet mogelijk, aangezien het relatief weinig voorkomt dat medewerkers deze handeling uitvoeren. Vijftig metingen verkrijgen zou een zeer tijdrovend proces zijn. Op basis van indicaties van de medewerkers van deze afdeling is besloten om een afrondtijd van gemiddeld tien minuten te nemen. Deze handeling heeft in het model ook een Lognormale verdeling gekregen. In het model krijgen onderdelen die de rij na de probleemstelling verlaten een label met de naam Type en het nummer één. Dit is gespecificeerd in het Trigger on exit veld van deze rij. De onderdelen die uit de reguliere wachtrij komen krijgen ook een label met de naam Type, maar dit label heeft het nummer twee. Op deze manier kunnen de Servers onderscheid maken tussen de verschillende soorten onderdelen en hun bijbehorende verwerkingstijd uitvoeren. Dit onderscheid wordt gemaakt met een If functie in het Cycletime veld van de Servers.

Zoals eerder besproken is er een verdeling gevonden voor hoe vaak er nul, één of twee medewerkers aan de CLA onderdelen hebben gewerkt in de meetperiode. De bijbehorende tabel is voor de overzichtelijkheid in tabel 4.3 nog een keer gepresenteerd. Deze percentages zijn in het gebruikte simulatiemodel verwerkt door weer gebruik te maken van Availability Control atomen die werken op basis van roosters. Het model bevat twee Servers (er zijn maximaal twee medewerkers bij de CLA afdeling aanwezig). Door de roosters van deze Servers correct in te stellen, zijn de bovenstaande percentages voor hun aanwezigheid gerealiseerd. Bovendien zijn deze roosters gebruikt om de werktijden van de medewerkers van het LC in te stellen. Tussen elf uur ’s avonds en half zeven ’s ochtends wordt er door de bekeken afdelingen niet gewerkt. In de roosters is verwerkt dat de Servers tijdens de simulatie ook in deze periodes geen producten verwerken.

Dat er in de rest van de tijd wel mogelijk mensen op dienst zijn, betekent niet dat deze medewerkers hun volle dienst gebruiken voor het behandelen van pakketten. Medewerkers nemen pauzes, praten met andere collega’s, hebben vergaderingen en zo zijn er nog veel meer redenen te bedenken waarom men niet de volle tijd met het verwerken van

vliegtuigonderdelen bezig is. Het is om deze reden dat de roosteratomen in ED ook zijn gebruikt om de Servers een bepaalde productiviteit te geven. Er is gekozen om deze

Aantal medewerkers Dag Avond

0 17% 50%

1 23% 13%

2 60% 37%

productiviteit op 75 procent van de werktijd te zetten. Dit houdt in dat een werknemer tijdens een dienst van acht uur vier keer een half uur pauze neemt waarin geen pakketten verwerkt worden.

Het beschreven model is in ED opgesteld om experimenten te kunnen doen die een beeld geven van de doorlooptijd van producten in dit systeem. Een screenshot van dit model is te vinden in figuur 4.1. Te zien zijn onder anderen de atomen die het aankomstproces voorstellen (Aankomsten en Batcher), wachtrijen voor de binnenkomende onderdelen (Wachtrij) en de TSO onderdelen (RijTSO) en atomen die medewerkers voorstellen (Repair Administrators). Ook is er een Sink waar de pakketten het model verlaten (Pakkettenklaar), een Multiservice atoom als TSO en groene atomen die de roosters van de Servers bepalen.

Voor een indicatie van de doorlooptijd is tijdens de simulatie in dit geval de wachttijd gemeten van de producten die voor het eerst door een Server behandeld moeten worden, oftewel de gemiddelde verblijftijd van producten in de rij voor reguliere onderdelen. Deze wachttijd is niet een exacte benadering van de werkelijke doorlooptijd. Bij het meten van de werkelijke doorlooptijden wordt ook de verwerkingstijd van een pakket meegenomen, evenals de tijd die een pakket na verwerking wacht totdat het door de Expeditie opgehaald wordt. Vooral deze tweede toevoeging kan de daadwerkelijke doorlooptijd significant langer maken dan de wachttijd, aangezien medewerkers van de verschillende afdelingen verwerkte

pakketten verzamelen op een kar en deze kar dan vervolgens na verloop van tijd aan de Expeditie aanbieden. Hierdoor kan de werkelijke doorlooptijd van pakketten in het model wel een paar uur hoger zijn dan de wachttijd. Deze werkelijke doorlooptijd is echter niet met een simulatie te meten, omdat niet te modelleren is dat de Expeditie karren ophaalt en niet individuele onderdelen.

Met het opgestelde model is een simulatie uitgevoerd om de wachttijd van CLA onderdelen op basis van het verkregen beeld van het geanalyseerde proces te bepalen. De simulatie is zo ingesteld dat er 150 runs van 100.000 producten zijn uitgevoerd. De resultaten van dit proces zijn voor de hier beschreven CLA afdeling te vinden in tabel 4.4. Vermeld zijn de gemiddelde wachttijd, de standaardafwijking hiervan en het bijbehorende

betrouwbaarheidsinterval (BI). Alle gegevens worden in uren vermeld. Er is voor de

beschreven lengte van de simulatie gekozen omdat deze lengte garandeert dat de halfbreedte van het verkregen betrouwbaarheidsinterval minder dan vijf procent is van de gemeten grootheid (de gemiddelde wachttijd). De halfbreedte van een betrouwbaarheidsinterval wordt gedefinieerd als de helft van het verschil van de bovengrens en de ondergrens van dit interval. De gekozen simulatielengte voldoet bovendien voor alle modellen waar geen Pre Alerts worden gebruikt aan de genoemde voorwaarde.

De resultaten uit tabel 4.4 komen niet in de buurt van de voor de CLA onderdelen berekende doorlooptijd van 43 uur. Dit kan verschillende oorzaken hebben. Zo kan het zijn dat er veel meer onderdelen naar de probleemstelling gaan dan aangenomen en dat de werkelijke doorlooptijd dus bij deze afdeling dus veel korter is. Ook kan het zijn dat de onduidelijkheid over het aantal medewerkers dat bij deze afdeling heeft gewerkt in de

meetperiode voor een verkeerde invulling van de roosters van de Servers heeft gezorgd, of dat de gekozen productiviteit van 75 procent een overschatting is.

Aangezien er bij het LC zelf al een onderzoek is gedaan naar deze afdeling, is er besloten om te wachten met een eventuele heroverweging van de correctheid van de gebruikte gegevens tot er ook resultaten voor de andere afdeling bekend waren. Dit omdat Logistiek dus al een beeld heeft van het effect van Pre Alerts bij deze afdeling en omdat er voor deze

Gemiddelde Standaardafwijking Ondergrens BI Bovengrens BI

18,39 0,52 18,30 18,47

Gemiddelde Standaardafwijking Ondergrens BI Bovengrens BI

38,09 1,95 37,78 38,41

Tabel 4.5: resultaten CLA stroom, geen Pre Alerts

specifieke afdeling veel problemen waren met betrekking tot de gebruikte gegevens. Deze problemen zijn namelijk bij de andere afdelingen niet allemaal ondervonden. Wel zijn er enkele simulaties uitgevoerd om te bepalen welke verwerkingstijden wel realistische doorlooptijden geven. Hieruit is naar voren gekomen dat verwerkingstijden van 35 minuten doorlooptijden opleveren die in de buurt van de 43 uur komen. Dit zijn verwerkingstijden die niet overeenkomen met wat er gemeten is. Ze kunnen echter wel gebruikt worden om te controleren of de invoering van Pre Alerts op dit systeem (met onrealistische

verwerkingstijden) resultaten oplevert die lijken op die van het bij het LC uitgevoerde

experiment. De resultaten van het experiment met een verwerkingstijd van 35 minuten zijn te vinden in tabel 4.5. Met de opmerking dat er nog enkele uren bij de wachttijd moeten worden opgeteld om er een doorlooptijd van te maken en het feit dat 43 uur geen zekere indicatie van de doorlooptijd is op deze afdeling, is er gekozen om in het vervolg van deze

verwerkingstijden uit te gaan voor de CLA onderdelen.