Simulace výběru pokladny na prodejně (SIMPROCESS)

From Simulace.info
Jump to: navigation, search


Zadání

Název simulace: Simulace výběru pokladny na prodejně

Předmět: 4IT495 Simulace systémů (LS 2018/2019)

Autor: Jan Hazdra

Typ modelu: Diskrétní simulace

Modelovací nástroj: SIMPROCESS

Definice problému

Pracuji ve společnosti Makro Cash&Carry, jde o společnost zaměřenou na velkoobchodní prodej a distribuci převážně potravin a potravinářského a gastronomického zboží. V centrálním obchodě v Praze na Stodůlkách používáme několik různých pokladních systému a druhů pokladen. Spoustu zákazníků je stále konzervativních a odmítají využívat nové druhy pokladen. Z toho důvodu často dochází k nedostatku nebo naopak přebytku otevřených pokladen.

Cílem je nasimulovat běžný provoz prodejny za jeden den s třemi druhy pokladních systémů. Na základě těchto výsledků lze navrhnout doporučení k optimalizaci počtu otevřených pokladen v průběhu dne, v závislosti na dalších parametrech nebo druhu pokladny.

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.

V obchodě jsou pokladny klasické s obsluhou, samoobslužné a nově v pilotním provozu tzv. selfscan pokladny. Jde o velkou zabudovanou váhu pro nákupní košík, samotné načítání artiklů probíhá přes mobilní aplikaci. Váha pak několika způsoby porovnává obsah košíku s obsahem virtuálního naskenovaného košíku v aplikaci a při shodě přechází k placení. Tyto váhy umožňují vážení všech druhů pojízdných nákupních košíků a jsou vybaveny platebními terminály. Počet samoobslužných a selfscan pokladen je neměnný (v případě, že nedojde k poruše nebo výpadku) - jsou otevřeny nepřetržitě, počet otevřených běžných pokladen se odvíjí podle vytíženosti.

Při simulaci vycházím z reálných dat posbíraných za jeden den na jedné prodejně v České Republice. Data se během jednotlivých dnů příliš neliší, proto budu vycházet ze vzorku z jednoho dne. Nejprve bylo nutné data získat a předzpracovat, což byl poměrně složitý krok, avšak pro samotnou simulaci nezbytný. Samotná data, s kterými se pracuje níže, jsou uložena v různých databázích a systémech, do některých jsem osobně ani neměl přístup. Data bylo nutné předzpracovat, očistit a upravit do srozumitelné formy. Počet zákazníků vychází z databáze vstupů na prodejnu, počet nákupů vychází z fakturace na pokladnách a zdržení zákazníka na prodejně je odvozeno průměrem mezi časem vstupu a časem fakturace.

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:

Tabulka1.png

Detailní přehled dat ze vstupů za den:

Tabulka02.png

Předzpracování dat zde bylo klíčovým bodem. Nastavení v simprocesu je následovné:

Tabulka03.png

Příchod:

Tabulka04.png

Nákup:

Tabulka05.png

Platba:

Tabulka06.png

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 : Percent Utilization By State
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:

Tabulka08.png


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 : Percent Utilization By State
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:

Tabulka07.png

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ě, nebylo snadné tento údaj přesně stanovit na základě dat (právě z důvodů viz výše), podařilo se ho dohledat vždy jen pro určitý vzorek zákazníků, tudíž nemusí být přesný.

Simulaci 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ší. Stejně tak by bylo možné simulaci opakovat s daty z jiného obchodů napříč Českou nebo Slovenskou republikou, avšak samotné získání a předzpracování dat bylo tak náročné, že jsem další vzorky nehledal.

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. Počet těchto případů však s časem a vylepšováním aplikace ubývá, dále data tohoto typu nejsou zaznamenávána a jejich začlenění do simulace by muselo být založeno na velmi 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, často však s velkým spoždění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ů.

Další zjištěný fakt je nevyužitý potenciál selfscan pokladen. Jde o pilotní provoz - novinku, tudíž se nelze příliš divit, že spoustu zákazníků tento způsob nákupu a platby zatím nevyzkoušelo a nepoužívá, přesto bych navrhoval větší osvětu a přiblížení zákazníkům. Jde o poměrně hodně odlišný způsob nákupu, jelikož zákazník musí mít mobilní aplikaci a skenovat každý artikl sám. Za sebe ale musím říct, že po pár vyzkoušeních jsem došel k zjištění, že to není vůbec složité a ušetření času oproti běžnýcm pokladnám je výrazné. Počet tohoto typu pokladen je v plánu zvýšit a zároveň rozšířit na další obchody v rámci Makra po České a Slovenské republice.

Reference

Byla použita anonymizovaná data ze společnosti Makro Cash&Carry CZ.

Kód

File:Model-1-xhazj03.spm