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

Xhazj03: Upřesnění definice problému, rozšíření závěru a doporučení

2019-06-11T15:45:38Z

Upřesnění definice problému, rozšíření závěru a doporučení

Xhazj03: 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..."

2018-06-10T21:21:25Z

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..."

New page

=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:

[[File:Tabulka1.png]]

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

[[File:Tabulka02.png]]

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

[[File:Tabulka03.png]]

Příchod:

[[File:Tabulka04.png]]

Nákup:

[[File:Tabulka05.png]]

Platba:

[[File: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:

{| class="wikitable"
|+ align="top" | ''' 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:

[[File: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.

{| class="wikitable"
|+ align="top" | ''' 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:

[[File: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]]

@@ Line 5: / Line 5: @@
 '''Název simulace:''' Simulace výběru pokladny na prodejně
-'''Předmět:''' 4IT495 Simulace systémů (LS 2017/2018)
+'''Předmět:''' 4IT495 Simulace systémů (LS 2018/2019)
 '''Autor:''' Jan Hazdra
@@ Line 15: / Line 15: @@
 =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.
+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ů.
+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=
@@ Line 23: / Line 23: @@
 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.
+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.
-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í.
+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=
@@ Line 122: / Line 122: @@
 =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.
+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ý.
-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ší.
+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. 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.
+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. 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ů.
+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ů.
 =Reference=
-Byla použita anonymizovaná data z Makra (společnost Makro Cash&Carry CZ).
+Byla použita anonymizovaná data ze společnosti Makro Cash&Carry CZ.
 =Kód=
 [[File:Model-1-xhazj03.spm]]