Difference between revisions of "Fronty na občerstvení"
(→Závěr) |
|||
| Line 138: | Line 138: | ||
=Závěr= | =Závěr= | ||
| − | Výsledky jsou poměrně překvapující. Pokud je umožněno předbíhání a předávání, prodá se více limonád ale více lidí také odejde z fronty. Při zakázání předávání a snížení prevalence "skupinových" nákupů je sice odbavení plynulejší ale nedojde k využití plného potenciálu obsluhy. Zvyšování intervalů mezi vlnami skupinových nákupů vede do překročení určité hranice k růstu počtu prodaných limonád a ale také rapidnímu růstu potenciálních zisků (UslyZiskCounter). To je možné učinit např. změnou rozsahu rozdělení v aktivitě '''Rozestupy'''. Nastavení rozestupů, tak jak je popsané v části [[Model]] se poměrně blíží optimu. Vzhledem k tomu, že v trial verzi SIMPROCESS nelze realizovat Experimenty a parametry modelů nelze měnit tak snadno jako např. v NetLogo je hledání optimálního nastavení prodlev a hromadných nákupů obtížnější. | + | Výsledky jsou poměrně překvapující. Pokud je umožněno předbíhání a předávání, prodá se více limonád ale více lidí také odejde z fronty. Při zakázání předávání a snížení prevalence "skupinových" nákupů je sice odbavení plynulejší ale nedojde k využití plného potenciálu obsluhy. Zvyšování intervalů mezi vlnami skupinových nákupů vede do překročení určité hranice k růstu počtu prodaných limonád a ale také rapidnímu růstu potenciálních zisků (UslyZiskCounter). To je možné učinit např. změnou rozsahu rozdělení v aktivitě '''Rozestupy'''. Nastavení rozestupů, tak jak je popsané v části [[#Model]] se poměrně blíží optimu. Vzhledem k tomu, že v trial verzi SIMPROCESS nelze realizovat Experimenty a parametry modelů nelze měnit tak snadno jako např. v NetLogo je hledání optimálního nastavení prodlev a hromadných nákupů obtížnější. |
Otázkou je, zda se výsledky mohou shodovat s realitou. Pokud lidé kupují víc nápojů najednou, obsluha může ušetřit čas při přijímání plateb i objednávek. To je znatelné zejména pokud je obsluhující jeden (zároveň točí a zároveň přijímá platby a vrací). Výsledky modelu však spíš ukazují na efektivitu spojenou s četností odběru kontinuálně natáčených limonád. | Otázkou je, zda se výsledky mohou shodovat s realitou. Pokud lidé kupují víc nápojů najednou, obsluha může ušetřit čas při přijímání plateb i objednávek. To je znatelné zejména pokud je obsluhující jeden (zároveň točí a zároveň přijímá platby a vrací). Výsledky modelu však spíš ukazují na efektivitu spojenou s četností odběru kontinuálně natáčených limonád. | ||
Revision as of 15:12, 14 June 2012
Popis modelu simulace fronty na občerstvení vyskytují se často na hudebních festivalech a dalších kulturních akcích. Simulace je realizována v software SIMPROCESS. Model simuluje situaci kdy lidé předávají svou objednávku těm, co stojí ve frontě více vpředu.
Contents
Definice problému
Model by simuloval tvoření front u stánků na občerstvení, které je možné často vidět na hudebních festivalech a dalších kulturních akcích akcích. Nejdříve si lidé kupují 1 až 2 položky (limonády, pivo...) a fronta poměrně ubývá. Postupem času, nebo při určité kritické velikosti fronty začne docházet k následujícím jevům:
- Lidé stojící ve frontě víc vepředu začínají být žádáni, aby vzali občerstvení i pro kamarády, ale i pro cizí lidi. Může to být za úplatu př. “Kup nám 3 točené limonády a tady máš ještě na jednu navíc pro tebe” => to má za následek delší čekání lidí stojících vzadu. Obsluha jednoho člověka trvá déle hlavně v případě piva, kdy je jedna pípa a je třeba čekat na natočení např. šesti kelímků.
- Může se objevovat předbíhání
- Může dojít i ke kombinaci předbíhání a kupování více kelímků.
Účelem simulace je zachytit dynamiku tvorby těchto front a zjistit kdy začne být odbavení velmi pomalé. Výsledkem by mohlo být doporučení pro způsob jak zajistit rychlejší obsloužení zákazníků. Dále model může sledovat při jakém nastavení frontu je prodáno nejvíce občerstvení.
Metoda
Model by bylo možné realizovat jako multiagentní simulaci např. v Netlogo. Další možností je model simulovat jako proces v SIMPROCESS. První metoda by byla složitější na realizaci a vyžadovala by mnoho náležitostí "frontového" chování programovat [1]. V SIMPROCESS je možné využít mnoho již vestavěných funkcí a velkou část simulace lze realizovat jen v editoru bez nutnosti programování (např čekání, spotřeba zdrojů atd.). Na druhou stranu je v SIMPROCESS obtížnější realizovat některé věci, jako např. předbíhání nebo změnu chování čekajících na základě rostoucí nervozity či netrpělivosti. Pro realizaci bylo nakonec zvolen SIMPROCESS také z důvodu snažšího zpracování výstupů z velmi podrobných reportů. [2]
Model
Celá simulace běží 48 hodin, tedy dva festivalové dny.
Entity:
- limo - představuje natočenou limonádu, je generována bránou obsluha.
- clovek - reprezentuje čekající zákazníky.
Zdroje (Resource)
- Limonada - slouží k počítání zisku za prodané limonády
- UslyZisk - počítá ušlý zisk za člověka, který odejde bez nákupu, uvažuje se, že člověk by si koupil alespoň jednu limonádu.
- Obsluha - Zdroj má pouze 1 dostupnou jednotku. Její uvolňování/zabrání umožňuje simulovat různé dobu zaměstnání obsluhy při různě velkých objednávkách. Pokud je zdroj volný, zákazník odchází s objednanou dávkou a obsluha pracuje na obsloužení (točení) limonád pro dalšího zákazníka. Před odebráním se limonády hromadí u Aktivity ObjednavkaDavka.
Popis Aktivit modelu
Zrod - lidé se do modelu generují dle normálního rozdělení v intervalu počtu sekund: Nor(16.0,2.0,1)
Nervozita - určuje prahovou hodnotu, kdy pohár trpělivosti (žízně) účastníků fronty přeteče a rozhodnou se pro předběhnutí a nebo požádají někoho více vepředu aby jim koupil limonádu (předají mu peníze, dále tedy jen "předávající"). Počet entit Clovek který musí do brány přijít aby začala generovat předbíhající/prosící se řídí dle: Nor(50.0,20.0,1)
Dále je na bráně Nervozita přidán výraz Expression spouštěný při události Accept Entity. Výraz upravuje chování brány tak, aby při větších frontách u pípy začala častěji vpouštět dávky předbíhajících a předávajících:
IF Model.Odchodovost <= 0.4
TrigFutureRelCount := DrawIntegerSample("Nor(30.0,15.0,1)");
IF Model.Odchodovost <= 0.2
TrigFutureRelCount := DrawIntegerSample("Nor(20.0,10.0,1)");
END IF
ELSE
TrigFutureRelCount := DrawIntegerSample("Nor(50.0,20.0,1)");
END IF
DeleniPredbehnuti Pro zjednodušení modelu je uvažováno, že 15% lidí se rozhodne předběhnout, zbytek bude předávající. Pravděpodobnost větve vedoucí do prodlevy RozestupyDopredu je tedy 0.85.
RozestupyDopredu
Slouží pro rozprostření předávajících v čase (sekundy) dle rozdělení Uni(5.0,25.0,1)
KupovaniZaOstatni Brána slučuje požadavky lidí na limonády do dávek. Jeden sloučený člověk reprezentuje stojícícho ve frontě, který byl lidmi požádán o to aby jim koupil Limonádu. Brána se otvírá po dosažení počtu lidí dle rozdělení Nor(8.0,5.0,1).
Rozestupy Určuje náhodně rozestupy, tak aby byli lidé co kupují velké dávky limonád lépe promícháni s ostatními. Opět dle rozdělení Uni(40.0,90.0,1)v sekundách.
GetObsluha Zajistí obsazení zdroje Obsluha, to má za následek hromadění limonád v Aktivitě ObjednavkaDavka. Tímto způsobem se simuluje větší zaneprázdněnost obsluhy, když si jeden člověk objednává více limonád.
NatoceniHodneLimonad je prodleva počítající delší prodlevu při větší objednávce v sekundách dle Uni(10.0,30.0,1). Aktivita Platba pak uvolní zdroj Obsluha. Aktivita objednavkaCheck pak může pustit čekající dávku entit Limo do brány ObjednavkaDavka, kde se sloučí (batch) a umožní odchod čekajícího zákazníka (entita Clovek) na bráně Pipa.
Obsluha Generátor slouží ke vytváření entit Limo představujících limonády které obsluha neustále točí v počtu sekund dle rozdělení Nor(20.0,15.0,1). kPipeProsim slouží jako Trigger pro bránu Cekani, která vpouští čekající zákazníky (Clovek) k pípě, kde mohou být obslouženi. LimoProdejCounter slouží k počítání prodaných limonád, objednavkaCheck slouží k zadržení dávky limonád, pokud není volná kapacita zdroje Obsluha.
Brana Cekani slouží k tomu, aby bylo možné zajistit odchod lidí, kteří ztratili trpělivost čekat. Při příchodu signálu z kPipeProsim. Lidé se dělí na větvení OdchodNetrpelivych dle hodnoty globální modelové proměnné Odchodovost. Tato proměnná je nastavována pomocí výrazu na bráně Pipa :
IF NumberOnHold >= 10
Model.Odchodovost := DrawRealSample("Nor(0.5,0.4,1)");
IF NumberOnHold >= 20
Model.Odchodovost := DrawRealSample("Nor(0.4,0.3,1)");
END IF
ELSE
Model.Odchodovost := DrawRealSample("Nor(0.6,0.1,1)");
{OUTPUT("Odchodovost 1"); }
END IF
UslyZiskCounter počítá možné ušlé zisky lidí, co opustili frontu, jedna limonáda má cenu 10 jednotek.
Výsledky
Pokud je v modelu umožněno předbíhání je zisk z prodaných limonád větší (38030 oproti 37410) ale výrazně vzrostou také potenciální ztráty 10160 oproti 7620.
| Activity Names | Entity Names | Absorption cost |
| LimoProdejCounter | limo | 38030,00 |
| UslyZiskCounter | clovek | 10160,00 |
| Total | 48190,00 |
| Activity Names | Entity Names | Absorption cost |
| LimoProdejCounter | limo | 37410,00 |
| UslyZiskCounter | clovek | 7620,00 |
| Total | 45030,00 |
| Model s umožněným "předáváním" | Model bez předbíhání | |
| Počet lidí, kteří vzdali čekání | 1016 | 762 |
| Průměrná doba obsloužení | 0.117 hod | 0.091 hod |
Průměrná doba obsloužení v modelu s předáváním je 0.117 hod, v modelu bez předávání je to 0.091.
Závěr
Výsledky jsou poměrně překvapující. Pokud je umožněno předbíhání a předávání, prodá se více limonád ale více lidí také odejde z fronty. Při zakázání předávání a snížení prevalence "skupinových" nákupů je sice odbavení plynulejší ale nedojde k využití plného potenciálu obsluhy. Zvyšování intervalů mezi vlnami skupinových nákupů vede do překročení určité hranice k růstu počtu prodaných limonád a ale také rapidnímu růstu potenciálních zisků (UslyZiskCounter). To je možné učinit např. změnou rozsahu rozdělení v aktivitě Rozestupy. Nastavení rozestupů, tak jak je popsané v části #Model se poměrně blíží optimu. Vzhledem k tomu, že v trial verzi SIMPROCESS nelze realizovat Experimenty a parametry modelů nelze měnit tak snadno jako např. v NetLogo je hledání optimálního nastavení prodlev a hromadných nákupů obtížnější.
Otázkou je, zda se výsledky mohou shodovat s realitou. Pokud lidé kupují víc nápojů najednou, obsluha může ušetřit čas při přijímání plateb i objednávek. To je znatelné zejména pokud je obsluhující jeden (zároveň točí a zároveň přijímá platby a vrací). Výsledky modelu však spíš ukazují na efektivitu spojenou s četností odběru kontinuálně natáčených limonád.
Mým závěrem tedy je, že výskyt skupinových nákupů nemusí být nutně nežádoucím jevem, pokud nepřekročí určitou kritickou hranici. V mém modelu je to zhruba rozmezí vln skupinových nákupů v sekundách: Uni(40.0,90.0,1). Právě realizace předávání míst a předbíhání se v SIMPROCESSU ukázala jako poměrně obtížná, řešením by mohlo být udělat model s menším počtem Aktivit a více využít výrazy (Expressions).
Reference
- ↑ WILENSKY, Uri. NetLogo [online]. Center for Connected Learning and Computer-Based Modeling, Northwestern University, Evanston, IL., 2011, c2011 [cit. 2012-01-17]. Dostupné z: http://ccl.northwestern.edu/netlogo/
- ↑ SIMPROCESS, © 2002-2012
Další odkazy:
- http://www.yousimul8.com/search.php?search_text=queue&x=0&y=0
- http://www.yousimul8.com/search.php?search_text=row&x=0&y=0
- http://en.wikipedia.org/wiki/Queueing_model
