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

From Simulace.info
Revision as of 22:21, 10 June 2018 by Xhazj03 (talk | contribs) (Created page with " =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 model...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


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:

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ě. 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).

Kód

File:Model-1-xhazj03.spm