Simulace výběru pokladny na prodejně (SIMPROCESS)
Contents
Zadání
Název simulace: Simulace výběru pokladny na prodejně
Předmět: 4IT495 Simulace systémů (LS 2017/2018)
Autor: Jan Hazdra
Typ modelu: Diskrétní simulace
Modelovací nástroj: SIMPROCESS
Definice problému
Pracuji v Makru, jde o společnost zaměřenou na velkoobchodní prodej nejen potravinářského spotřebního zboží. V centrálním obchodě používáme několik různých typů pokladních systému a druhů pokladen.
Cílem je nasimulovat běžný provoz prodejny za jeden den s třemi druhy pokladních systémů.
Metoda
Problém bude řešen jako diskrétní simulace v programu Simprocess, jelikož jde o variaci na problém front, který se v Simprocessu řeší nejsnadněji.
Při simulaci vycházím z reálných dat posbíraných za jeden den na jedné z prodejen v České Republice. Data se během jednotlivých dnů příliš neliší, proto budu vycházet ze vzorku z jednoho dne.
Jsou zde pokladny klasické s obsluhou, samoobslužné a nově v pilotním provozu tzv. selfscan pokladny. Ve skutečnosti jde pouze o váhu, samotné markování artiklů probíhá přes mobilní aplikaci. Váha pak jen několika způsoby porovnává obsah košíku s obsahem virtuálního namarkovaného košíku v aplikaci a při shodě přechází k placení.
Model
Parametry:
typ pokladny - běžná pokladna (16), samoobslužná pokladna (4), selfscan pokladna (1)
počet pokladen - 21
počet zákazníků - 1937
zdržení na prodejně - 30min
Detailní přehled dat z pokladen za den:
Detailní přehled dat ze vstupů za den:
Předzpracování dat zde bylo klíčovým bodem. Nastavení v simprocesu je následovné:
Příchod:
Nákup:
Platba:
Jedinou entitou je zde zákazník, k jehož generování dochází při vstupu. Zdroje jsou zde tři a to jeden na každý druh pokladny.
Popis procesu
Příchod - dochází ke generování zákazníků periodicky z poissonova rozdělení se střední hodnotou 120
Nákup - zdržení zákazníků na obchodě v minutách podle exponenciálního rozdělení se střední hodnotou 30
Platba - dochází zde k větvění = výběru pokladny. Běžnou pokladnu si zvolí 86,5% zákazníků, samoobslužnou zvolí 12,6% zákazníků a selfscan pouze 0,9%. Zdržení na pokladnách se liší podle typu pokladny, z dat vychází průměr 204,8 sekundy na běžnou pokladnu, 183,3 sekund na samoobslužnou pokladnu a 49,4 sekund na selfscan.
Simulace běží jeden den.
Výsledky
Nejzajímavější část je využití pokladen:
| Resource Names | Idle | Busy |
|---|---|---|
| Pokladna_bezna | 28,425% | 71,575% |
| Pokladna_samoob | 80,332% | 19,668% |
| Pokladna_selfscan | 99,028% | 0,972% |
Kompletní výsledky:
Z výsledků je patrné, že pokladny jsou většinu času volné. Většinu provozní doby však nejsou dostupné všechny pokladny, proto jsem zkusil počet běžných pokladen snížit na polovinu.
| Resource Names | Idle | Busy |
|---|---|---|
| Pokladna_bezna | 63,980% | 36,020% |
| Pokladna_samoob | 81,058% | 18,942% |
| Pokladna_selfscan | 98,747% | 1,253% |
Kompletní výsledky:
Závěr
První důvod, proč jsou výsledky zkreslené jsou data vstupů, vstupy nejsou narozdíl od faktur (plateb) přesné. Někteří zákazníci vstupují ve skupinách nebo bez načtení karty (například z garáží) a nemusí být zaznamenáni. Druhý důvod je, že zákazník může vytvořit více faktur za jeden nákup a to z důvodu rozdělení zboží, jiný zákazník naopak nemusí nakoupit vůbec. Tyto dva faktory by však měli tvořit jen nepatrné odchylky. Největší odchylku bude tvořit právě neznámý počet aktuálně otevřených běžných pokladen, který se během dne často mění. Dalším faktorem je doba strávená na prodejně. Tento údaj se mi nepodařilo v datech dohledat, takže jsem mimo jiné na základě vlastní zkušenosti tento údaj odhadl.
Simulací jsem se snažil co nejvíce přiblížit realitě, stejné data by šlo dohledat za jiný den a simulaci opakovat, namátkově jsem zkoušel několik dalších dnů, ale výsledky se přiliš neliší.
Možným rozšířením by mohlo být přidání zdroje nákupních košíků, což ale na výběr pokladny nemá vliv. Dalším faktorem, který v simulaci není zahrnut je, že pro selfscan pokladnu se zákazník musí rozhodnout už na začátku nákupu, protože musí naskenovat košík a každý artikl který nakupuje (ve skutečnosti je možné provést skenování dodatečně před samotným vážením, ale to značně nepohodlné, zdlouhavé a složité - nastává pravděpodobně jen zřídka). Pokud rozhodování probíhá na začátku nebo na konci simulace, nebude mít až tak velký dopad.
Dalším zajímavým faktorem na rozšíření by mohlo být to, že u selfscan pokladen, jelikož jde o pilotní projekt, občas docházelo k větším prodlevám při platbě. Problém byl v přesnosti vážení nákupního košíku a při neshodě k nutnosti košík obsluhou překontrolovat a často i přemarkovat. Množství těchto případů však s časem a vylepšováním aplikace klesá, dále data tohoto typu nejsou zaznamenávána a jejich začlenění do simulace by muselo být založeno na hrubých odhadech.
Využití výsledků
Z dostupných výsledků je patrné, že množství fyzických pokladen na obchodě je více než dostačující. Otázkou je jejich obsazenost během dne. Ta se mění podle potřeby a dynamicky se přizpůsobuje počtu příchozích zákazníků a vznikajícím frontám. Počet pokladen by ani tak neměl být snížen, jelikož o víkendech a před svátky dochází k většímu vytížení z důvodu nárůstu počtu zákazníků.
Reference
Byla použita anonymizovaná data z Makra (společnost Makro Cash&Carry CZ).
