Hoorcollege 4 Bespreking casus 2 (supermarkt). Enterprise Dynamics: het availability atoom. Enterprise Dynamics: Batch verwerking.

Casus 2: de supermarkt Lezen: In de plaatselijke supermarkt staan 8 kassa’s voor het afrekenen van de boodschappen opgesteld. Op zaterdag, de dag van onderzoek, is de winkel –en daarmee het kassasysteem- van 9.00 tot 17.00 uur open (de afloopperiode na 17.00 uur blijft buiten beschouwing) en komen gemiddeld 1400 klanten volgens een Poissonproces binnen.

Casus 2: de supermarkt Dit betekent: 1400 klanten per 8 uur? Dat is 1400 klanten per 28800 seconden, oftewel 28800/1400= gemiddeld 1 klant per 20,51 seconden.

Casus 2: de supermarkt Dit betekent voor de source: (zie pag. 18 van de reader!)

Casus 2: modelbouw Lezen: Nadat klanten hun boodschappen hebben gedaan, gaan ze naar de kassa’s en kiezen een wachtrij. Wanneer andere rijen sneller gaan, vindt in de praktijk wisselen van rij plaats. Dit verschijnsel (`jockeying’) zorgt ervoor dat er geen wachtrijen enerzijds en tegelijkertijd vrije kassamedewerkers anderzijds kunnen optreden.

Casus 2: modelbouw Dit betekent: 1 wachtrij in het simulatiemodel i.p.v. 8. Capaciteit van die wachtrij? Groot! Immers: we willen meten hoe lang een gemiddelde klant in de rij staat en hoe lang de wachtrijen voor de kassa’ s zijn.

Casus 2: variant 1 Lezen: vaste personeelsinzet, bedieningstijd onafhankelijk van het aantal boodschappen Hierbij worden alle kassa’s gebruikt en heeft iedere klant een exponentieel verdeelde bedieningsduur met een gemiddelde van 2.5 minuten.

Casus 2: variant 1 Eerst het natte vingerwerk: 1400 klanten per dag 8 kassa’ s die gemiddeld 2,5 minuten doen over het afwerken van een klant. Derhalve: 2,5 minuten per klant: dat is 24 klanten per uur. 24 x 8 kassa’ s x 8 uur per dag = 1536 klanten per dag. 1400 / 1536 = 0.91 Een gemiddelde kassa zal op ruim 90% van zijn capaciteit draaien.

Casus 2: modelbouw Een en ander leidt tot het volgende model:

Casus 2: het experiment Een experiment duurt 8 uur. Het aantal ronden moet groot zijn; bijv. 50. Performance measures: Gemiddelde wachttijd Gemiddelde wachtrijlengte

Casus 2: het experiment Resultaten:

Casus 2: variant 2 Lezen: vaste personeelsinzet, bedieningsduur afhankelijk van het aantal boodschappen Scantijd per artikel: 6 seconden Afrekenen: 30 seconden Aantal boodschappen per klant: gemeten in praktijk, derhalve een empirische distributie gebruiken.

Casus 2: modelbouw Het model blijft hetzelfde, maar wordt op enkele punten uitgebreid: Empirische distributie toevoegen Cycletime in iedere server (kassa) veranderen in onderstaande instructie: 6*groceries+30

Casus 2: het experiment Resultaten:

Casus 2: variant 3 Lezen: vaste personeelsinzet, bedieningsduur afhankelijk van het aantal boodschappen en onderscheid naar klanttypen Kassa 1 = snelkassa: aantal boodschappen < 11

Casus 2: modelbouw Aantal boodschappen per klant moet worden bijgehouden. Oplossing: aan iedere klant een label hangen Klanten met minder dan 11 boodschappen gaan naar een snelkassa. Oplossing: gebruik een extra wachtrij en selecteer de klanten bij de source.

Casus 2: modelbouw Het model:

setlabel([items],groceries,i) Casus 2: modelbouw Labels toekennen geschiedt in de source: setlabel([items],groceries,i) Klanten op label naar de juiste wachtrij sturen geschiedt eveneens in de source: By label value (conditional): if the value on the label named items of the 1st atom in the queue is < the value 11 then send to channel 1 else 2.

Casus 2: het experiment Aan het experiment zullen 2 performance measures moeten worden toegevoegd:

Casus 2: het experiment Resultaten

Casus 2: variant 4 Lezen: vaste personeelsinzet, bedieningsduur afhankelijk van het aantal boodschappen, met voorrang voor de klanten met de minste boodschappen. Uiteraard niet erg realistisch…maar wel leuk om te zien…

Casus 2: variant 4 Deze variant grijpt terug op een eerder model zonder snelkassa. De klanten in wachtrij dienen nu gesorteerd te worden op basis van het aantal artikelen: Sort by Label Ascending: The atoms with the lowest value of the label named items are put in front

Casus 2: het experiment resultaten

Casus 2: conclusies De verschillende varianten spreken elkaar niet tegen. Oplopend sorteren is het best maar helaas niet reëel. Een snelkassa kan werken, maar doet dat in deze situatie niet.

E.D. het availability atoom Soms is het nodig atomen aan of uit te zetten op basis van een tijdsschema. Gebruik hiervoor: Availability control In combinatie met: Time schedule availability atoom Switch availability atoom Mtbf & mttr availability atoom

E.D. het availability atoom Voorbeeld van gebruik:

E.D. het availability atoom In de time schedule wordt een tijdschema voor aan- en uitschakelen vastgelegd.

E.D. het availability atoom In het availablity atoom wordt aangegeven wat specifiek wordt aan- en uitgeschakeld:

E.D. het availability atoom Met het switch availability atoom kun je specifieke atomen handmatig aan- en uitschakelen…

E.D. Batch verwerking Vindt plaats in servers Stelt je in staat atomen te bundelen of scheiden

E.D. Batch verwerking Geeft aan hoeveel atomen er binnekomen, voordat er 1 wordt afgeleverd Bepaalt de conversieregel: X in, Y uit