Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Vyšší odborná škola informačních služeb v Praze. Klára Saňková.

Transkript

1 Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Vyšší odborná škola informačních služeb v Praze Klára Saňková Využití diskrétní číslicové simulace pro konstrukci stochastických modelů zaměřených na obsluhu zákazníka Bakalářská práce 2010

2

3 Prohlašuji, že jsem bakalářskou práci na téma Využití diskrétní číslicové simulace(metoda Monte Carlo)pro konstrukci stochastických modelů zejména zaměřených na obsluhu zákazníka zpracovala samostatně a použila pouze zdrojů, které cituji a uvádím v seznamu použité literatury. V Praze dne Podpis

4 Abstrakt Tato pr{ce je zaměřena na diskrétní číslicovou simulaci. Jejím z{měrem je uk{zat, že tato metoda může být pro efektivnost firmy velice užitečn{. Zvl{ště proto, že poskytuje informace, které bychom analytickou cestou získat nemohli. Souč{stí pr{ce je teoretick{ a praktick{ č{st. Abstract This work dissertates about discrete event simulation. Its intention is to show that this method may be very helpful for company efficiency. Especially because it provides information that we could not obtain an analytical way. Work contains both theoretical and practical part.

5 Obsah Obsah Úvod Operační výzkum Jak operační systém řeší problémy Úloha modelů pro operační výzkum Vědecké metody Výhody řešení problémů pomocí operačního výzkumu Diskrétní číslicov{ simulace Podstata diskrétní číslicové simulace (gener{tor n{hodných čísel) Statistické aspekty přesnosti diskrétní číslicové simulace Aplikace diskrétní číslicové simulace Řízení projektů Možnost aplikace metody Monte-Carlo na řízení projektů Teorie hromadné obsluhy Možnost aplikace metody Monte-Carlo na teorii hromadné obsluhy Programy pro zpracov{ní dat metodou Monte-Carlo WinQSB Příklad využití DSI Z{kladní ovl{d{ní Příklad využití Praktick{ aplikace diskrétní číslicové simulace na teorii hromadné obsluhy ve společnosti Chronos s.r.o Společnost Chronos s.r.o. Business Centre Vstupní data

6 6.3. Zpracov{ní Období A Období B Doporučení pro společnost Chronos s.r.o Z{věr Použit{ literatura Knižní zdroje Akademické pr{ce Online zdroje Rešerše Operační výzkum a manažersk{ věda: Metoda Monte Carlo: Pravděpodobnost a fronty Ostatní

7 1. Úvod Rozhodnutí pro téma bakal{řské pr{ce pro mě nebylo těžké. K diskrétní číslicové simulaci m{m osobní vztah. Připad{ mi nesmírně zajímavé, že díky ní mohu vyzkoušet fungov{ní systému za dlouhé roky a přitom mít výsledky během několika vteřin. R{da bych proto na těchto několika stran{ch shrnula, co vlastně diskrétní číslicov{ simulace je a jak užitečn{ může být pro optimalizaci procesů a systémů ve firm{ch. Nejprve uvedu širší kontext manažerské vědy, kde se tato metoda využív{. Poté představím dva programy, které díky diskrétní číslicové simulaci umožňují optimalizovat systémy hromadné obsluhy. Na z{věr předvedu praktickou aplikaci metody na teorii front pro potřeby společnosti Chronos s.r.o. 7

8 2. Operační výzkum Operační výzkum, nebo též manažersk{ věda, je vědní obor zabývající se především rozhodov{ním a optimalizací operací v r{mci konkrétního systému a za daných omezení. Jeho podstatou je přesné specifikov{ní a zmapov{ní daného rozhodovacího problému, konstrukce matematického modelu a zvolení spr{vné vědecké metody řešení, kter{ bude na problém aplikov{na. Přestože poč{tky operačního výzkumu lze jen stěží přesně datovat, s určitostí lze říct, že jeho rozvoj nastal v průběhu druhé světové v{lky, kdy byla takto řešena složit{ taktick{ rozhodnutí. Později, díky ekonomickému a technickému rozvoji, došlo k rozšířenému využití metod manažerské vědy. A se st{le většími možnostmi výkonnější výpočetní techniky i díky univerz{lnosti použití operačního výzkumu naléz{ tento obor st{le širší uplatnění i dnes. Již z n{zvu manažersk{ věda lze usuzovat, že problémy, které tato disciplína řeší, se týkají zejména manažerských rozhodovacích procesů. Operační výzkum je často aplikov{n v situacích, kde nelze použít pouze samostatného lidského logického usuzov{ní, ale je třeba využít také systematizace a možností, které nabízí matematické modelov{ní a statistické zpracov{ní dat. Výsledky operačního výzkumu jsou využív{ny i na nejvyšších pozicích firem a díky tomu mají dopad na výsledky celých společností. Řešené problémy se mohou týkat například četnosti z{sobov{ní, časového rozvržení projektů, minimalizace n{kladů pro n{kup surovin či nejrůznějších 8

9 rozhodnutí v oblasti logistiky. Dle Jablonského 1 je obecně možné rozdělit disciplíny manažerské vědy na matematické programov{ní, vícekriteri{lní rozhodov{ní, teorii grafů, teorii z{sob, teorii hromadné obsluhy, modely obnovy, Markovovy rozhodovací procesy, teorii her a v neposlední řadě (diskrétní číslicovou) simulaci. Z{kladní postupy, které operační výzkum využív{, jsou buď matematické výpočty anebo simulace. Podstatou obou je sestavení modelu, který popisuje celou situaci. Model jako zjednodušené zobrazení reality v případě matematických modelů pomocí rovnic a nerovnic, omezení a jiných vztahů musí vystihovat klíčové proměnné. Těch musí být pr{vě takový počet, aby i po vynech{ní podružných detailů model odpovídal realitě do té míry, že využití modelu nepovede ke klamným výsledkům Jak operační systém řeší problémy Pro operační výzkum je typický systematický přístup k řešení rozhodovacího problému a využití vědeckých metod. Jak uv{dí Ing. P{tek ve své publikaci Manažersk{ věda I 2, vědecký přístup m{ tyto z{kladní kroky: 1. Pozorov{ní 2. Definice problému 3. Formulace hypotézy 4. Experimentov{ní 5. Verifikace 1. JABLONSKÝ, Josef. Operační výzkum. Praha: Vysok{ škola ekonomick{, ISBN PÁTEK, Jiří. Manažerská věda - I. Praha : VOŠIS, s. 9

10 Ve f{zi pozorov{ní je nutné zjistit, že nastal nějaký problém, a d{le touto metodou, tedy pozorov{ním, o něm nashrom{ždit dostatek potřebných informací. Samotn{ detekce výskytu problému je úkol pro vedoucí pracovníky. Shromaždov{ní informací již může zastat analytik. Vůbec nejdůležitější č{stí řešení problémů je jeho samotn{ formulace. Nepřesně formulovaný problém, neboli kvaziproblém m{ za příčinu, že se síly výzkumu napřou špatným směrem a doch{zí tak v lepším případě ke značným finančním i časovým ztr{t{m. V tom horším i k poškození dobrého jména firmy, například při nedodržení smluvních termínů, kvůli nespr{vnému určení kritické cesty nebo hromadění se obrovského množství nespokojených z{kazníků ve front{ch při špatné aplikaci teorie front. Tyto první dvě f{ze se v procesu řešení problému prolínají. Nelze totiž zjistit, že existuje problém, aniž bychom pozorovali. D{le však je nutné definovat, jaký problém nastal a jaké informace o něm budeme potřebovat, tak, aby data kter{ se snažíme získat, byla relevantní. A n{sledně opět pozorujeme a zaznamen{v{me požadované aspekty reality. Prov{dět důkladný sběr informací bez definice problémů může být také ztr{tou času, neboť ne všechny informace, které se zdají být na první pohled důležité, ve skutečnosti potřebujeme. Na z{kladě získaných dat a informací analytik sestaví příslušné modely a formuluje hypotézy. Např. že při jiném rozložení bude logistický systém firmy efektivnější a levnější. Poté je třeba připravit vstupní data, a to buď přímo měřením v terénu, nebo transformací vstupních údajů, získaných například z účetnictví, do podoby použitelné ve vytvořených modelech. Pro n{sledné vyhodnocení úspěšnosti celého řešení problému je třeba již na zač{tku stanovit kritéria, podle kterých se bude zjišťovat, zda bylo aplikované 10

11 doporučení ve svém působení přínosem a zda skutečně odstranilo problém. Pokud je problémem, že z{kazníci čekají řady delší než 30 čekajících jednotek, je třeba nastavit jako kritérium snížení tohoto čísla například na 14, a to v souladu s oček{v{ními firmy. Poté, co m{ pracovník k dispozici vešker{ potřebn{ data, může aplikovat na problém jednu z vědeckých metod, využívaných operačním výzkumem. Tato aplikace v dnešní době bude v praxi prov{děna tak, že zad{ data do specializovaného programu. Ten provede příslušné výpočty nebo simulace a vr{tí výsledky. Úloha analytika spočív{ nejen v tom, že problém vyj{dří v číslech, zad{ programu příslušné instrukce, ale především konečné výsledky spr{vně interpretuje a možn{ řešení testuje z hlediska přesnosti, stability a vhodnosti pro danou situaci. Na z{věr vypracuje zpr{vu, kter{ je doporučením pro vedoucí pracovníky společnosti, v níž se problém vyskytoval. Konečnou f{zí je rozhodnutí společnosti, zda dan{ doporučení bude aplikovat v praxi a také vyhodnocení, zda doch{zí ke splnění kritéria stanoveného již v poč{tečních f{zích řešení problému. Pokud hodnoty skutečných výstupů po značnou dobu neodpovídají požadovaným výsledkům dle kritéria, je třeba celý proces opakovat Úloha modelů pro operační výzkum Existují dva typy modelů, které se v manažerské vědě využívají. 11

12 Nejprve je to model ekonomický. Ekonomický model lze charakterizovat jako zjednodušený popis re{lného objektu, který obsahuje s ohledem na analyzovaný problém pouze nejpodstatnější prvky a vazby mezi nimi. 3 Model slouží jako slovní a numerické zad{ní. Dle Jablonského by měl obsahovat především cíl analýzy, tedy jednoznačné vytyčení cílového stavu systému. Tento cíl musí být kvantifikovatelný. Např. minimalizace n{kladů na obsluhu výrobní linky, maxim{lní zisk díky vyv{žení poměru vyr{běných výrobků atd. D{le m{ takovýto model obsahovat popis re{lných aktivit, které v systému probíhají, tedy procesů, ze kterých se systém sest{v{, činitelů a jejich vz{jemných vztahů. Činiteli rozumíme zejména rozličn{ omezení, kter{ systém m{, anebo kter{ mu přisuzujeme. Např. m{me omezený strojový čas či požadujeme, aby bylo ve frontě vždy maxim{lně 15 z{kazníků. Každ{ z aktivit m{ také svou intenzitu a podíl vlivu na celkové výsledky analýzy. Druhým modelem je model matematický. Aby bylo možné daný problém řešit, je třeba jej nějakým způsobem formalizovat převést tedy ekonomický model na model matematický, který je potom řešitelný standardními postupy. Matematický model obsahuje stejné prvky jako model ekonomický, samozřejmě však v jiném vyj{dření JABLONSKÝ, Josef. Operační výzkum. Praha: Vysok{ škola ekonomick{, ISBN 12

13 V matematickém modelu je cíl analýzy vyj{dřen většinou pomocí line{rní či neline{rní funkce. Tyto funkce mají několik proměnných, které zastupují aktivity a jejich číseln{ hodnota vyjadřuje intenzitu jednotlivých procesů. Omezení nastaven{ n{mi či dan{ samotným systémem jsou zajišťov{ny rovnicemi a nerovnicemi spolu s omezujícími podmínkami. Matematický model může mít deterministický nebo stochastický charakter Vědecké metody V operačním výzkumu je využív{no mnoho různorodých n{strojů pro řešení problému. Zde jsou hlavní z nich. Matematické programov{ní řeší optimalizační úlohy nalezením jejich extrému daného kritéria. Například je možné maximalizovat zisk změnou skladby výroby za daných omezení. Jak uv{dí Jablonský v knize Operační výzkum 4 : Matematický model úlohy matematického programov{ní lze zapsat n{sledovně: maximalizovat (minimalizovat) z = f(x1, x2,..., xn), za podmínek g1(x1,x2,...,xn) 0, g2(x1,x2..,xn) 0, : gm(x1,x2,...,xn) 0, JABLONSKÝ, Josef. Operační výzkum. Praha: Vysok{ škola ekonomick{, ISBN 13

14 xj 0, j=1,2,...,n, kde n je počet proměnných modelu, m je počet jeho omezujících podmínek a f(x), gi(x), i=1,2,...,m jsou obecné funkce n proměnných. Vícekriteri{lní rozhodov{ní je disciplína, kter{ řeší rozhodovací úlohy, ve kterých se vyskytují několiker{ protichůdn{ kritéria. Teorie grafů je v operačním výzkumu použív{na zejména pro řízení projektů, jednotlivé uzly obvykle představují činnosti projektu, hrany mezi nimi reprezentují n{vaznosti mezi nimi. Ohodnocení hran může vyjadřovat například dobu trv{ní nebo n{klady na činnost. Teorie z{sob slouží k optimalizaci objemu dod{vek a doby mezi novými objedn{vkami (vzhledem k n{kladům). Teorie hromadné obsluhy nebo také teorie front zkoum{ souvislosti mezi střední dobou příchodu požadavků na obslužné stanice a střední dobou jejich vyřízení. Diskrétní číslicov{ simulace využív{ statistických z{konitostí a pomocí gener{toru n{hodných čísel simuluje statisticky významné množství pokusů na daném systému. Samotn{ simulace probíh{ v ř{dech minut, a tak je možné jich prov{dět dostatečný počet pro n{sledné statistické zpracov{ní Výhody řešení problémů pomocí operačního výzkumu Operační výzkum přin{ší vedení firem doporučení, kter{ mohou značně usnadnit a podpořit n{sledn{ rozhodnutí. Nespornou výhodou přitom je, že veškerý výzkum probíh{ na papíře. Není třeba n{kladných a dlouhých praktických testů, které by měly za úkol zjistit, 14

15 jak by se systém choval při změně vstupních parametrů. Důsledky takových změn je možno zjistit, aniž by bylo třeba do existujícího systému jakkoliv zasahovat. Přestože mohou být tyto analýzy n{kladné, budou pro zadavatelskou společnost představovat s největší pravděpodobností menší n{klady, než kdyby tyto experimenty prov{děla v praxi. Jsou situace, kdy n{sledky změn v systému mohou být nevratné i nebezpečné. Z těchto důvodů také zaznamenal operační výzkum takový rozmach během druhé světové v{lky, kdy byly za jeho pomoci řízeny vojenské operace. Další nespornou výhodou je, že díky zjednodušené strukturalizaci systému do matematického modelu lze specifikovat jakoukoli z jeho možných variant. Značn{ je také úspora času. Pokud je spr{vně zvolen{ metodika zpracov{ní problému, výpočetní systém zpracov{v{ informace ve zlomcích vteřin. Zatímco pokud bychom chtěli, aby stejný proces proběhl v praxi, museli bychom čekat roky. Díky tomuto lze také ověřit dané hypotézy na podstatně větším počtu případů. Při simulaci obslužného systému není problém zadat příchod z{kazníků a během p{r vteřin m{me výsledek před sebou. Zato v re{lném světě, pokud by vedení společnosti rozhodlo vyzkoušet zatížení obslužných linek na z{kaznících, mohlo by mezitím dojít i ke krachu celého podniku. Spr{vnost řešení problému samozřejmě ztěžují aspekty jako neprůhlednost prostředí, či nemožnost skutečně přesně řídit mnohé jevy v re{lném světě. I přesto je způsob řešení problémů pomocí metod manažerské vědy v nemalém počtu případů úspěšný. 15

16 3. Diskrétní číslicová simulace Diskrétní číslicov{ simulace je jedním s nejsilnějších a nejpoužívanějších n{strojů operačního výzkumu s poněkud výsadním postavením mezi ostatními. Je totiž při spr{vném zach{zení aplikovateln{ na velice širokou šk{lu problému. Její užív{ní je omezeno zejména n{kladností programů pro její realizaci a také tím, že je pro ni potřeba odborníka, který ji umí aplikovat a její výsledky spr{vně vyhodnotit. Její podstatou je generov{ní n{hodných (resp. Pseudon{hodných) čísel a konstrukce stochastického modelu. Diskrétní číslicov{ či též počítačov{ simulace býv{ tedy využív{na v případech, kdy experimenty na re{lném systému jsou nemožné či nepraktické, ať už z finančního či bezpečnostního hlediska. Druhým důvodem pro její využití může být též přílišn{ složitost re{lného systému. Konkrétně se tato metoda využív{ v např. v letectví pro řízení letového provozu, ve zdravotnictví k efektivnímu rozmístění stanic první pomoci, či predikci využití nemocničních lůžek. Jak píše Ing. Jiří P{tek ve své publikaci Manažersk{ věda II: Obecně je simulace spíše popisn{ metoda než metoda optimalizační a vyžaduje existenci modelu nějakého re{lného jevu. Při takto široce pojaté definici můžeme jako příklady simulace uvést letecký trenažér, aerodynamický tunel, model automobilu, analogovou simulaci spojitých procesů. Všechny uvedené příklady jsou z{sadně odlišné od diskrétní číslicové simulace používané v manažerské vědě. 16

17 A skutečně, dosahovat optimalizace pomocí diskrétní číslicové simulace by bylo poněkud obtížné. Obn{šelo by to znovu a znovu vkl{dat data do systému a zjišťovat, kter{ z možných variant je nejlepší. Problém by nast{val nesporně v tom, že pokud bychom skutečně chtěli takto optimalizovat tedy najít vůbec nejlepší možné řešení, byli bychom nuceni vyzkoušet téměř všechny kombinace. Což by mohlo být u některých systémů i nemožné. Navíc to není ani hlavním z{měrem použív{ní diskrétní číslicové simulace. Síla diskrétní číslicové simulace je pr{vě v tom, že při jakýchkoliv vstupních datech a při dostatečném počtu simulací je schopn{ poskytnout dostatečně přesnou predikci chov{ní systému. Samozřejmě za předpokladu, že naměřené hodnoty jsou spr{vné. Můžeme díky ní například zjistit, že v systému hromadné obsluhy při určitém počtu simulací dojde k nahromadění neúnosného množství požadavků ve frontě, či že požadavek bude ve frontě čekat v průměru až příliš dlouho. Na z{kladě takových informací lze vidět, zda se systém bude chovat tak, aby vyhovoval požadavkům, či zda je nutné hledat jin{ východiska a jin{ z{kladní nastavení systému. Použití diskrétní číslicové simulace umožňuje zjistit, jak by se systém choval za dobu mnohon{sobně delší, než jakou trv{ samotn{ simulace. Přesto mohou výpočty v případě složitých systémů být poměrně časově n{ročné. Důvodem je, že přesnost výsledků je přímo úměrn{ druhé odmocnině z počtu realizací. Pokud tedy m{me zvýšit přesnost získaných údajů desetkr{t, musíme ston{sobně zvětšit objem pokusů. Dalším nevýhodou býv{ také nemožnost skutečně předvídat a modelovat chov{ní člověka v systému. Z těchto a dalších důvodů, přestože sestavov{ní modelu i samotné simulaci věnujeme mnoho úsilí i prostředků, není možné zajistit spr{vnost odpovědi k formulovanému problému. Bohužel také st{le neexistuje 17

18 standardizovaný postup pro simulační techniku a je možnost sestavit různé modely pro jedno zad{ní systému Podstata diskrétní číslicové simulace (generátor náhodných čísel) Tato metoda si vysloužila též n{zev metoda Monte-Carlo, neboť její podstatou je využití gener{toru n{hodných čísel (random number generator), který je využív{n také pro účely hazardních her. Je to program založený na algoritmu, který produkuje pseudon{hodn{ čísla s rovnoměrným rozdělením. Pseudon{hodn{ jsou čísla, kter{ vykazují vlastnosti n{hodných čísle, kter{ se však s jistou velkou periodou začínají opakovat. Proto je třeba zabezpečit tuto periodu dostatečně dlouhou, aby výsledky pokusů nebyly ovlivněny. Pokud požadujeme čísla s určitým rozdělením, například exponenci{lním, můžeme je získat z hodnot produkovaných gener{torem inverzní transformací za využití distribuční funkce Statistické aspekty přesnosti diskrétní číslicové simulace Ne všechny dostupné gener{tory n{hodných čísel produkují skutečně čísla n{hodn{. Přestože vygenerovan{ čísla obstojí v několika z{kladních testech, je možné, že při podrobnějším zkoum{ní objevíme určitou periodu. V tom případě se jedn{ o pseudon{hodn{ čísla. 18

19 Existují certifikační autority, které svými potvrzeními zajišťují, že ověřený gener{tor produkuje skutečně n{hodn{ čísla. Gener{tory jsou testov{ny na počtu čísel v ř{du stovek milionů. Z{vislost je zkoum{na nejen u celé množiny, ale i u vybraných podmnožin. Například jestli všechna čísla se sudým pořadovým číslem jsou také n{hodn{. Ověření gener{toru n{hodných čísel je velice důležité. V případě, že by nebyl v poř{dku, nemohou v modelovaném systému fungovat statistické z{vislosti jako v re{lném životě. To by ohrozilo nejen průběh simulace, ale i n{sledné zprovoznění systému optimalizovaného dle chybných výpočtů. 19

20 4. Aplikace diskrétní číslicové simulace 4.1. Řízení projektů Projekt je sled činností prov{děných za určitým cílem ve vymezeném časovém úseku s n{roky na person{lní i hmotné zajištění. Charakteristick{ je pro něj zejména jedinečnost. Ust{lené a pravidelně prov{děné činnosti nejsou projektem. Dle Jablonského 5 je možné každou činnost v projektu charakterizovat: předpokl{danou dobou trv{ní, předpokl{danými n{klady na její realizaci, požadavky na technické, materi{lové, person{lní a jiné zajištění, výčtem činností, které musí být provedeny dříve, než začne její realizace atd. Kvůli vz{jemné n{vaznosti jednotlivých činností je nutné projekt důsledně řídit, aby nedoch{zelo ke zbytečným finančním ztr{t{m. Pro odhalení č{stí, ve kterých by mohlo doch{zet k než{doucím prodlev{m, je použív{na metoda CPM neboli metoda kritické cesty (Critical Path Method). Ta pro každou činnost vymezuje nejdříve možný zač{tek a nejpozději 5. JABLONSKÝ, Josef. Operační výzkum. Praha: Vysok{ škola ekonomick{, ISBN

21 přípustný zač{tek, nejdříve přípustný konec a nejpozději možný konec. Na z{kladě toho lze vypočítat časové rezervy pro jednotlivé činnosti. Ty, které nemají ž{dné časové rezervy, jsou takzvané kritické činnosti a tvoří kritickou cestu. Jakékoli zpoždění těchto činností vede ke zpoždění celého projektu. Dalším přístupem je řízení projektu metodou PERT (Project Evaluation and Review Technique), kter{ oproti CPM předpokl{d{, že doby trv{ní činností nejsou stanoveny pevně. Uvažuje tedy, že je to n{hodn{ veličina s určitým rozdělením. Vlastní výpočty v PERT se nijak neliší od výpočtů v CPM. Místo pevných hodnot však počít{me se střední dobou trv{ní činnosti. Výsledkem výpočtu je oček{van{ kritick{ cesta s oček{vanou dobou trv{ní získanou jako součet středních dob trv{ní kritických činností Možnost aplikace metody Monte-Carlo na řízení projektů V praxi řízení projektů jsou střední doby trv{ní činnosti n{hodné veličiny většinou s β rozložením. Proto je elegantním řešením použít při rozhodov{ní výsledky z diskrétní číslicové simulace, tedy propojit tento způsob modelov{ní s metodu PERT. Pomocí generovaných n{hodných čísel simulujeme délky dob jednotlivých činností dle zadaných vstupních hodnot. 6. PÁTEK, Jiří. Manažerská věda - I. Praha : VOŠIS, s. 21

22 Programy jako například WinQSB ve svém modulu PERT/CPM umožňují na z{kladě vložených hodnot přímé výstupy i v grafické podobě Teorie hromadné obsluhy Teorie hromadné obsluhy býv{ též nazýv{na teorií front. V mnoha případech je možno procesy odehr{vající se v re{lném životě zjednodušit na entity, které čekají na obsloužení a entity, které jejich požadavky vyřizují. Pokud víme, jak často se v průměru objevuje další z{kazník, tedy zn{me interval mezi dvěma bezprostředně po sobě n{sledujícími požadavky a také jak{ je průměrn{ doba obsluhy, můžeme sestavit model. Velmi jednoduše lze takový model vytvořit na z{kladě tzv. Kendallovy klasifikace systémů hromadné obsluhy. Tento ve své z{kladní podobě zahrnuje tři položky: Písmeno vyjadřující typ stochastického procesu, který popisuje příchod požadavků Písmeno zastupující z{kon rozložení délky obsluhy Číslo označující počet obslužných míst Nejčastěji býv{ na obou pozicích pro písmeno znak M, který zastupuje exponenci{lní rozložení příchodů i obsluhy. Modelem systému hromadné obsluhy tedy většinou je model M/M/n, kdy za proměnnou n je dosazeno konkrétní číslo. 22

23 4.4. Možnost aplikace metody Monte-Carlo na teorii hromadné obsluhy Firmě, jejíž souč{stí je jakýkoliv proces, který je možno modelovat jako systém hromadné obsluhy, d{v{ diskrétní číslicov{ simulace možnost tento proces optimalizovat podle zadaných kriterií. Při simulaci program transformuje čísla z gener{toru dle požadovaného rozdělení a daných středních hodnot a výsledn{ čísla dosazuje do modelu, čímž simuluje jak doby příchodu, tak obsluhy. Je třeba, aby ve virtu{lním systému proběhlo statisticky významné množství časových jednotek, aby bylo možné získat relevantní výsledky. Na z{kladě několika roků virtu{lního chodu systému, může analytik např. zjistit, že se bude místy tvořit fronta, kter{ je příliš velk{. V z{jmu spokojenosti z{kazníků pak budou n{sledně posíleny možnosti obsluhy. 23

24 5. Programy pro zpracování dat metodou Monte- Carlo Programů, které využívají možnosti diskrétní číslicové simulace, je cel{ řada. Z{kladem všech však musí být kvalitní gener{tor n{hodných čísel. dat simulací. WinQSB a DSI poskytují svému uživateli mnoho možností pro zpracov{ní 5.1. WinQSB Program Quantitative Systems for Business verze pro Windows (d{le jen WinQSB) je volně šířený na internetu. Obsahuje několik modulů pro nejrůznější výpočty z oblasti manažerské vědy. Analýza rozhodov{ní (Decision Analysis) Analýza Markovových procesů (Markov Process) Analýza PERT_CPM (PERT/CPM) Dynamické programov{ní (Dynaming Programming) Kontrola kvality (Quality Control Chart) Line{rní programov{ní (Linear and Integer Programming) Modely hromadné obsluhy (Queuing System Simulation) Neline{rní programov{ní (Nonlinear Programming) Pl{nov{ní výrobních zdrojů (Facility Location and Layout) Předpovědi a line{rní regrese (Forecasting and Linear Regression) Pl{nov{ní materi{lových zdrojů (Material Requirements Planning) Rozvrhov{ní pracovních úkolů (Job Scheduling) 24

25 Síťov{ analýza (Network Modeling) Teorie front (Quiening Analysis) Modul Queuing Systém Simulaton slouží pro simulaci činnosti modelu hromadné obsluhy. pozice v ostrých z{vork{ch jsou v praxi dosazeny konkrétní hodnoty Na V úvodní obrazovce zad{ní nového problému zad{me jeho n{zev (Problem Title), počet komponent, které se jsou souč{stí systému (Number of Systém Components) a jednotky, v jakých bude simulace prov{děna. 25

26 Na pozice v ostrých z{vork{ch jsou v praxi dosazeny konkrétní hodnoty V další f{zi je třeba zadat n{zvy komponent a ke každé z nich přiřadit její typ. Typy komponent: C Zdroj příchodu z{kazníků (Customer arriving source) S Obslužn{ stanice (Server) Q Fronta (Queue) G Sklad odpadu (Garbage collector) Na pozice v ostrých z{vork{ch jsou v praxi dosazeny konkrétní hodnoty 26

27 Po zad{ní příslušných dat a stisknutí tlačítka se znakem hrací kostky pro simulaci je potřeba ještě určit, zda se budou poč{teční n{hodn{ čísla odvíjet od přednastavených algoritmů pro získ{ní n{hodných hodnot (Use default random seed), či zda je zad{me ručně (Enter a seed number), popřípadě je možné použít i systémový čas (Use system clock). D{le je třeba zadat, kolik přednastavených jednotek času m{ simulace probíhat. Po spuštění simulace získ{me výsledky konkrétního případu. Zde je několik z{kladních pojmů z výstupu: Total Arrival - celkový počet z{kazníků v systému Mean Number in Systém průměrný počet z{kazníků v systému 27

28 Maximum Number in Systém maxim{lní počet z{kazníků v systému v jednu chvíli Number Finished počet obsloužených požadavků Average Process Time průměrn{ doba vyřízení požadavku Average Waiting Time průměrn{ doba ček{ní z{kazníků Average Flow Time průměrn{ doba, jakou požadavek str{ví v systému Maximum Flow Time nejdelší čas str{vený požadavkem v systému Utilization - využití obsluhy 5.2. Příklad využití Uvažujme jednoduchý příklad. Obchod, do kterého přijde 12 z{kazníků za hodinu a obsloužit jednoho z nich průměrně trv{ 6 minut. Obchod m{ dva prodavače. V prodejně nemůže být více jak 50 z{kazníků. 28

29 Je potřeba čtyř komponent, abychom mohli mít v systému oba prodavače. Čas budeme ud{vat v hodin{ch. Ke každé komponentě přiřadíme její typ. Po spuštění simulace získ{me tabulku s daty. 29

30 Informace o simulaci vzhledem k z{kazníkům Za hodin, po které jsme systém virtu{lně provozovali, přišlo z{kazníků. Průměrn{ doba, za kterou byli obslouženi je 0,09 hodiny, tedy 5,4 minuty. Průměrně z{kazník čekal 3,6 minuty na obsloužení. Informace o simulaci vzhledem k obsluze Využití systému je okolo 63%. Každý z prodavačů obsloužil polovinu příchozích požadavků. Informace o simulaci vzhledem k frontě 30

31 Nejvíce se ve frontě nahromadilo 25 požadavků. Nejdéle čekal z{kazní okolo 90 minut na obsluhu DSI Program DSI je komplexní n{stroj pro simulaci složitých obslužných systémů. Je zde možnost modelovat nekonečně mnoho situací, neboť dok{že propojovat více z{kladních obslužných systémů (z{kazník, obsluha) dohromady. Zapojovat je sériově či paralelně, přid{vat místa, ve kterých se entity rozhodují, kam se vydají, a simulovat rozmanité podmínky. Přestože je tento program pro diskrétní číslicovou simulaci velmi univerz{lní pro modelov{ní, jeho ovl{d{ní, které zcela neodpovíd{ standardům v současnosti vyvíjených software zřejmě mnohé uživatele odradí. Program DSI využív{ specializovaného programovacího jazyka. Některé č{sti jeho syntaxe vych{zejí z příkazů zn{mějšího jazyka Pascal. Z{kladní klíčov{ slova programu DSI: pool neomezený zdroj entit entity - zavedení entity a její pojmenov{ní queue - definice fronty, nabízí varianty fifo, lifo, random, prior aktivity - definice aktivity, je do ni možno zapojit více entit a určit, kam kter{ entita bude n{sledně pokračovat channels - počet kan{lů obsluhy switch výhybka, kter{ určuje na z{kladě podmínky další trasu entity Obecný z{pis jednoduchého modelu v jazyku DSI: entity NazevEntity; 31

32 queue NazevFronty of NazevEntity TypFronty; activity NazevAktivity channels PocetKanalu load PocetEntitVstupujicichDoAktivity NazevEntity from NazevZdrojeEntit after StatistickeRozdeleni (StredniHodnota) :: eject NazevEntity to NazevFronty; end; activity NazevAktivity channels PocetKanalu load PocetEntitVstupujicichDoAktivity NazevEntity from NazevZdrojeEntit after StatistickeRozdeleni (StredniHodnota) :: eject NazevEntity to NazevFronty; end; switch NazevVyhybky for NazevEntity case Podminka :: NazevFrontyNeboAktivity, otherwise NazevJineFrontyNeboAktivity; end; end. Každou entitu či frontu je třeba před jejím použitím definovat. Za klíčovým slovem je uveden jejich n{zev a v případě fronty i typ entit, který se v nich řadí a pořadí odchodu entit z fronty. Aktivitu definujeme pomocí n{zvu a počtu obslužných kan{lů. Tyto vyjadřují, na kolika místech je možné vyřizovat požadavky z{kazníků. Například počet pokladen. Ne všechna tato místa musí být nutně obsazen{. Například pokud 32

33 by obslužný person{l pracoval z{roveň ještě na jiných úkolech, či pokud by výrobní stroj musel být po několika kusech výrobků kontrolov{n. Za klíčovým slovem load n{sleduje číslo, vyjadřující kolik entit jednoho druhu vstupuje najednou do dané aktivity, spolu s n{zvem požadované entity a jejího zdroje. Tím může být buď fronta anebo výhybka. Po klausuli after je třeba specifikovat dobu, kterou entita str{ví v aktivitě. Na výběr je několik statistických rozložení například Random, tedy n{hodné rozložení nebo NegExp tedy exponenci{lní rozdělení. Po klíčovém slově eject n{sleduje n{zev fronty nebo výhybky, kam mají obsloužené entity pokračovat. Switch nabízí možnost rozhodnout na z{kladě podmínky, kam bude entita pokračovat. Je specifikovan{ pomocí svého n{zvu a typu příchozí entity. Klausule case umožňuje z{pis podmínky dle jazyku Pascal. Po dvojí dvojtečce je třeba udat, kam míří entity splňující tuto podmínku. Po otherwise n{sleduje určení směru ostatních entit. Podmínka, kter{ je zaps{na jako první, bude také jako první vyhodnocena. Každ{ aktivita i výhybka je ukončena pomocí end a středníku. Koncové end uzavír{ celý program. 33

34 Základní ovládání Na z{kladní obrazovce je důležit{ zejména volba file, díky které je možné nahr{t připravený zdrojový soubor. Druhou možností je kód napsat přímo do modré plochy okna programu. Dalším krokem je volba simulate. V případě, že zdrojový kód není zaps{n syntakticky spr{vně, hl{sí program chybu. Pokud je vše v poř{dku dostaneme se do ovl{d{ní simulačního prostředí. 34

35 Zde se ocitneme v nabídce, kterou je možno ovl{dat pouze pomocí kl{vesnice. Pokud vybereme Step, pokročí program o jeden krok simulace. Při volbě Steps můžeme zadat kolik dalších kroků, které m{ program provést. Možnost Till nabízí zapsat konkrétní čas, ve kterém m{ být simulace přerušena. Next zajišťuje pokročení systému o udaný časový interval. Pro simulaci stačí použít pouze některou z těchto možností. D{le zvolíme Write a program zapíše dosavadní stav do protokolu. Pomocí Quit se dostaneme k výsledkům celé simulace. 35

36 Významy údajů přejaté s drobnými úpravami ze souboru ov-dsi.pdf přiloženého k programu DSI: 7 význam údajů pro frontu: #i počet entit, které vstoupily do fronty #d počet entit, které byly odebr{ny z fronty max maxim{lní počet entit ve frontě μ# průměrný počet entit ve frontě μt průměrn{ doba pobytu entity ve frontě význam údajů pro pool: #i počet entit, které byly odebr{ny z poolu, tj. přišly do systému #d počet entit, které byly odesl{ny do poolu, tj. odešly ze systému max maxim{lní počet entit daného typu v systému μ# průměrný počet entit daného typu v systému μt průměrn{ doba života entity v systému význam údajů pro aktivitu: #i počet, kolikr{t byl nastartov{n některý kan{l aktivity #d počet, kolikr{t byla činnost kan{lu ukončena max maxim{lní počet paralelně pracujících kan{lů μ# průměrný počet paralelně pracujících kan{lů μt průměrn{ doba činnosti kan{lu 7 Bohužel v tomto materiálu není uveden autor, ani žádný jiný bibliografický údaj. Tento soubor je přiložen k verzi, kterou jsem dostala k dispozici ve výuce předmětu Systémy hromadné obsluhy na Vošis od pana RNDr. Tomáše Vaníčka, Ph.D. 36

37 5.4. Příklad využití Tento příklad využití programu DSI simuluje činnost obchodu, který přijím{ pouze elektronické objedn{vky ze svých internetových str{nek. Požadavky si mezi sebou jednotliv{ pracoviště před{vají v předem daném pořadí až k zasl{ní balíku k z{kazníkovi. Grafické zn{zornění systému Na zač{tku procesu je z{kazník, který si objedn{ zboží. Poté, co odešle vyplněný formul{ř, je tento zpracov{n počítačem, který objedn{vku okamžitě před{v{ pracovníkům skladu. Po dohled{ní příslušného zboží skladník ve firemním systému zad{, že vyskladnil jednu krabici n{řadí a vyřídí i další form{lní n{ležitosti, jako například výdejku. Zboží putuje ke kontrole, kter{, pokud je objedn{vka z jakéhokoliv důvodu vyřízena nespr{vně, vr{tí požadavek zpět skladníkovi. Jestliže je zboží připraveno dle potřeby, je přesunuto na další stanoviště, kde je pečlivě zabaleno, označeno adresou a odesl{no z{kazníkovi. 37

38 Systém přepsaný do kódu zpracovatelného v programu DSI bude vypadat takto: entity Obj; queue FrO of Obj FIFO; activity Vstup channels 1 load 1 Obj from pool after negexp(19) :: eject Obj to FrO; end; queue FrS of Obj FIFO; activity Zprac channels 50 load 1 Obj from FrO after uniform(0.3, 0.5) :: eject Obj to FrS; end; queue FrK of Obj FIFO; activity Sklad channels 2 load 1 Obj from FrS after uniform(17, 30) :: eject Obj to FrK; end; activity Kontr channels 1 load 1 Obj from FrK after uniform(5, 13) :: eject Obj to Roz; end; 38

39 queue FrZ of Obj FIFO; switch Roz for Obj case Random < 0.09> :: FrS, otherwise pool; end; end. Pro potřeby tohoto příkladu předpokl{d{me, že požadavky na systém nemají omezený počet. První aktivitou systému je samotný vstup objedn{vky do systému. V tomto konkrétním případě je systém nastaven tak, že objedn{vky přich{zejí stochasticky s Poissonovým rozdělením se střední hodnotou 19 minut. Tedy průměrně každých 19 minut z{kazník odešle vyplněný formul{ř. Poté se zařadí do fronty a čekají na první obsloužení. Počítač může zpracov{vat až 50 objedn{vek najednou. Tyto jsou obsluhov{ny v pořadí, v jakém se zařadily do fronty (tak tomu bude n{sledně u všech dalších front v systému). Doba trv{ní vyřízení jednoho požadavku se pohybuje mezi 0,3 až 0,5 minuty. Poté se opět vytv{ří řada, tentokr{t mířící do skladu. Sklad je uzpůsoben pro dva pracovníky, jsou tady dvě pracovní místa, tedy dva kan{ly obsluhy. Požadavky z fronty jsou obsluhov{ny 17 až 30 minut. Do této doby je započten veškerý čas, který skladník musí vynaložit, aby mohl jednu objedn{vku poslat d{le, tedy do fronty ke kontrole. Při kontrole býv{ zjištěno, že 9% objedn{vek je nespr{vně připravených. Tyto jsou posíl{ny k opravě zpět na sklad a mísí se ve frontě s objedn{vkami zcela 39

40 novými. Zbylých 91% bezproblémově vyřízených požadavků putuje do další fronty k z{kazníkům. Výsledky simulace v programu DSI. Ze získaných dat vidíme, že největší fronty se tvořily před skladem, neboť zde je doba obsluhy nejdelší. Přesto maxim{lní fronta zde byla šest objedn{vek a v průměru každ{ z nich čekala necelých sedm minut. Průměrn{ doba obsluhy ve skladu byla více než 23 minut. U prvotního zpracov{ní počítačem doch{zelo k využití maxim{lně dvou kan{lů obsluhy, přestože kapacita byla minut. Průměrn{ doba, kterou objedn{vka str{vila celkově v systému je necelých 40

41 6. Praktická aplikace diskrétní číslicové simulace na teorii hromadné obsluhy ve společnosti Chronos s.r.o Společnost Chronos s.r.o. Business Centre Společnost Chronos s.r.o. Business Centre se specializuje na pronajím{ní vybavených kancel{ří v reprezentativních prostor{ch v centru hlavního města Prahy, a to včetně potřebné techniky. D{le poskytuje recepční služby, pron{jem konferenčních místností, sekret{řské služby zahrnující mimo jiné znalost cizích jazyků, možnost virtu{lní kancel{ře, telefonní servis, mnoho typů administrativních služeb, popřípadě také vedení účetnictví a pr{vní služby. Chronos s. r. o. také úzce spolupracuje s dalšími společnostmi, u nichž objedn{v{ doplňkové služby podporující pr{ci svých klientů. Firma m{ dvě pobočky na V{clavském n{městí. První, sídlící v domě číslo 66, býv{ více zahrnov{na požadavky ze strany z{kazníků a také se zde vyřizuje většina administrativní pr{ce. Z tohoto důvodu zde býv{ více person{lu než v druhé pobočce v domě číslo 19. Ze strany jednatelek společnosti je kladen důraz zejména na stoprocentní plnění požadavků klientů, tedy i na to, aby klient téměř nemusel na obsloužení čekat. 41

42 6.2. Vstupní data Ze všech činností, kterými se společnost zabýv{, je pro účely optimalizace uvažov{na pouze ta č{st požadavků klientů, které přich{zejí jednor{zově a naléhavě. Jmenovitě je to například: ohl{šení, občerstvení a uvedení příchozího hosta do kancel{ře firmy, služby jako je tisk, scanov{ní a kopírov{ní, urgentní objedn{v{ní doplňkových služeb u jiných společností a další drobné služby. Vzhledem k tomu že je hlavním optimalizačním kriteriem požadavek, aby klient nemusel čekat, nejsou zde uvažov{ny služby dlouhodobějšího charakteru. Tyto bývají zpravidla vyřizov{ny v době nevytížení obslužných míst požadavky urgentními a především býv{ jejich zpracov{ní přerušov{no ve prospěch uvažovaných naléhavých požadavků. Optimalizace je v tomto případě netypick{. Standardním požadavkem býv{ minimalizace n{kladů vynakl{daných na obsluhu. Společnost Chronos s.r.o. m{ především z{jem, aby byla minimalizov{na zejména doba ček{ní klienta. Je zřejmé, že pro zisk firmy je podstatné i to, aby v těchto podmínk{ch nedoch{zelo k plýtv{ní obslužnými zdroji. Proto je třeba najít optim{lní hodnoty obsluhy splňující obě tato kritéria. Celkov{ provozní doba business centra je 9 hodin za den. Vzhledem ke zkušenostem, že v ranních a večerních hodin{ch býv{ intenzita příchodu požadavků menší, jsou směny pracovníků dohodnuty tak, aby i počet obsluhujícího person{lu byl největší v průběhu dne. Pro účely výpočtů je tedy vhodné rozdělit den na dvě výpočetní období. První z nich je období A, do něhož patří první dvě a poslední dvě hodiny provozu business centra. A d{le na období B, které zahrnuje příchody v průběhu dne. 42

43 Intenzita příchodu požadavků v období A je 13,9 minuty a pro období B 9,6. Intenzita obsluhy je 4,2 minuty. V období A pracuje v systému jedna obslužn{ jednotka, v období B jednotky tři Zpracování Období A Data byla takto zad{na do programu WinQSB. Model obsluhy ve společnosti Chronos s. r. o. sest{v{ z požadavků z{kazníků, z obslužného místa na recepci a z fronty z{kazníků, kterou budeme minimalizovat, tedy ze tří komponent (Number of Systém Components). Čas bude ud{v{n v minut{ch (Time Unit). Data budeme budeme vkl{dat v režimu Spreadsheet. 43

44 Pojmenov{ní komponent Vstupní data v zad{vací tabulce programu Simulační čas byl zad{n hodin. 44

45 Výstup ze simulace Z výsledků simulace vyplýv{, že za dobu, po kterou proces probíhal, přišlo 7022 z{kazníků a všichni odešli ze systému obslouženi. Maxim{lní počet z{kazníků, kteří se z{roveň vyskytují v systému, je 6. Systém byl využit téměř na 30%. Maxim{lně čekalo ve frontě 5 klientů. Průměrně čekali 1,6 minuty. 45

46 Protože požadavkem společnosti je, aby z{kazníci nečekali, zkusíme v příštím kroku přidat do modelu jednoho pracovníka obsluhy. Vstupní data v zad{vací tabulce programu Výstup ze simulace V případě, že jsou v tomto systému dvě obsluhující jednotky, průměrn{ doba, po kterou jednotky čekají, se zkr{tí na 0,1 minuty. 46

47 Využití systému je za těchto podmínek přibližně 16%. Maxim{lní délka fronty je 3 požadavky. Období B V období B figurují v systému tři obslužné jednotky. Data byla takto zad{na do programu WinQSB. 47

48 Systémem za stejnou dobu jako v období A projde dle simulace okolo z{kazníků. Jeden z nich zůstal v systému pr{vě ve chvíli, kdy byla simulace přerušena. Průměrně požadavky na obsluhu čekají 0.2 minuty. Maxim{lní počet z{kazníků v systému v jednu chvíli je 7. Využití systému je okolo 15%. 48