Simulace Helpdesk Portálu

Tato stránka slouží jako Výzkumná zpráva simulace "Helpdesk portálu" k semestrálnímu projektu pro předmět 4IT495 Simulace systémů (LS 2013/2014) na VŠE v Praze.

= Zadání =


 * Název simulace: Helpdesk Portal
 * Předmět: 4IT495 Simulace systémů (LS 2013/2014)
 * Autor: Bc. Luboš Souček
 * Typ modelu: Diskrétní simulace - dynamický frontový systém
 * Modelovací nástroj: SIMPROCESS
 * Odkaz na zadání simulace: Zadání Xsoul21

Definice problému
Helpdesk portál, na kterém vznikají požadavky na řešení problému, potřebuje najít a zjistit, kolik bude potřeba uživatelů na daný počet zakládaných požadavků a kolik bude řešení jednoho požadavku stát, jaký bude výdělek a ztráta za nevyřešené požadavky a za požadavky, kde zákazník nevydržel čekat.

Cíl simulace
Cílem simulace je namodelovat cyklus založení požadavku po jeho rozdělení do front a poté jeho řešení. Experimenty by měly ukázat predikci vývoje množství požadavků řešených, nevyřešených a vyřešených a dosažení možných hranic při určitém počtu řešitelů, doby řešení, pravděpodobnosti vyřešení.

Metoda
Celou situaci by šlo realizovat několika způsoby např. v Monte Carlo, mezi dalšími možnostmi bylo vytvořit model v SIMPEOCESSU a nasimulovat ho jako proces. První metodu jsem nevyužil, jelikož by byla pro mě složitější na realizaci a vyžadovala by mnoho náležitostí, jak předělat frontový systém do Excelu. Z toho důvodu jsem se rozhodl využít SIMPROCESSu, kde je možné využít mnoho již vestavěných funkcí a velkou část simulace a procesu lze tzv. jen "naklikat" a není potřeba znát programovací jazyk. Bohužel zkušební verze SIMPROCESSu má spoustu omezení a nelze v něm udělat některé věci, například nelze mít více jak pět Entit, nebo využít funkce, kde entita využívá jen část zdroje. Díky tomuto omezení jsem musel simulaci mírně upravit, protože nešlo přesně určit, kde určitý typ požadavku se řeší určitou dobu a kolik by stálo toto řešení.

= Model =

Model ukazuje pohyb požadavku od zákazníka po frontu, kde každý typ požadavku má určenou dobu čekání než si ho řešitel převezme a dále řeší. Požadavek může projít několika úrovni řešení.

Model se zakládá na reálných číslech a skutečnostech helpdesk portálu firmy Mibcon a.s. nalézající se na adrese projekt.mibcon.cz.

Model jako takový probíhá v intervalu 1 měsíce.



Entity

 * Níz. požadavek - představuje požadavek s nízkou prioritou


 * Stř. požadavek - představuje požadavek se střední prioritou


 * Vys. požadavek - představuje požadavek s vysokou prioritou


 * Kontrola - představuje kontrolu helpdesk portálu


 * Skup. požadavek - představuje skupinu požadavků řešených 1. lvl řešitelem

Ceny Entit

 * Níz. požadavek - 150 Kč / vyřešená entita


 * Stř. požadavek - 300 Kč / vyřešená entita


 * Vys. požadavek - 600 Kč / vyřešená entita


 * Nevyřešené entity - Vždy 10 násobek dané ceny entity jako pokuta za nevyřešení

Resource (Zdroje)

 * 1. lvl řešitel - 20x


 * - Po špičce (od 17h do 9h) dostupný 10x


 * - Náklady na zdroj jsou 100 Kč/h


 * 2. lvl řešitel - 10x


 * - Po špičce (od 17h do 9h) dostupný 5x


 * - Náklady na zdroj jsou 200 Kč/h


 * 3. lvl řešitel - 4x


 * - Po špičce (od 17h do 9h) dostupný 2x


 * - Náklady na zdroj jsou 400 Kč/h

Tímto rozdělením jsem chtěl nasimulovat 2 směnný provoz, kde přes den pracují vždy všichni řešitelé a mimo špičku jen určitá část z nich.

Požadavky
Proces obsahuje generátory požadavků, které jsou generovány exponenciálním rozdělením Exp(X.X,Y.Y), ve kterém jsou generovány ve třech časových intervalech, kde je daný určitý počet požadavků vygenerován jednou za hodinu.


 * Špička - od 9h do 17h


 * Po špičce - od 17h do 7h


 * Před špičkou - od 7h do 9h


 * Založení vys. požadavku - Představuje generátor požadavků s vysokou prioritou s rozdělením:


 * - Špička - Exp(2.0,1)


 * - Po špičce Exp(1.0,1)


 * - Před špičkou Exp(1.0,1)


 * Založení stř. požadavku - Představuje generátor požadavků se střední prioritou s rozdělením:


 * - Špička - Exp(4.0,1)


 * - Po špičce Exp(2.0,1)


 * - Před špičkou Exp(1.0,1)


 * Založení níz. požadavku - Představuje generátor požadavků s vysokou prioritou s rozdělením:


 * - Špička - Exp(2.0,1)


 * - Po špičce Exp(1.0,1)


 * - Před špičkou Exp(1.0,1)



Vygenerované požadavky poté putují do fronty.

Fronta
Příchozí požadavky jsou rozděleny procesem "Rozdělení požadavků", který nám zajištuje podle typu entity správné rozdělení do front.

Frontové procesy Delay simulují dobu čekání zákazníků na to než se začne jejich požadavek řešit. Každý požadavek má určitou dobu čekání vyjádřenou exponenciálním rozdělením Exp (X.X,Y.Y).


 * Fronta vys. požadavku - Zdržení požadavků s vysokou priotou s Exp(30.0,1) v minutách.


 * Fronta stř. požadavku - Zdržení požadavků s vysokou priotou s Exp(1.0,1) v hodinách.


 * Fronta níz. požadavku - Zdržení požadavků s vysokou priotou s Exp(2.0,1) v hodinách.



Po vyčkání ve frontě putují požadavky do procesu "Vydržel čekat?", který simuluje zákazníky, jež nevydrží čekat ve frontě a požadavek zruší. Ten je nastaven pomocí pravděpodobnosti, kde 99 % vydrží a 1 % nevydrží čekat. Ti, co vydrží počkat, tak jdou do procesu řešení.

Řešení požadavků
V procesu řešení je hned ze začátku brána, která simuluje to, že 1. lvl řešitel přebírá a řeší vždy určitý balík požadavků. Tento systém jsem vymyslel proto, jelikož jsem byl limitován zkušební verzí SIMPROCESSU, kde tato verze nedovolí nadefinovat, jak velkou část zdrojů, každá entita využije. Z toho důvodu tento tak trochu zvláštní proces. Do jisté míry je podobný, jelikož počet požadavků seskupovaných do entity skup.požadavků je podle Poissonova rozdělení - Poi(5.0,1). Tato brána je otvírána generátorem "Kontrola" exponenciálním rozdělením Ve špičce - Exp(5.0,1) minut, Mimo špičku Exp(30.0,1) minut, toto simuluje kontroly helpdesk portálu 1.lvl řešitelem, který kontroluje, zda jsou volné a dostupné požadavky. Dále je na bráně nastavení, že požadavky s vyšší prioritou jdou vždy první. Po převzetí skupinového požadavku jde tento požadavek k 1.lvl řešiteli, kde řešení trvá dle Lognormal rozdělení Log(1.0,1.0,1) hodin. Po tomto řešení se skupinový požadavek rozpadne zase na jednotlivé entity a v dalším rozdělení jsou pomocí pravděpodobnosti vytřízeny na vyřešené, pak ty, které se vrátí na začátek před bránu k opětovnému řešení a na nevyřešené, které putují do dalšího levelu řešení.

Každý level má svoji pravděpodobnost:


 * 1.level
 * - 5% na nevyřešené požadavky, které se vrátí zpět na začátek před bránu


 * - 25 % na požadavky, které jdou do dalšího levelu řešení


 * - 70 % na požadavky, které se vyřeší


 * 2. level
 * - 10 % na požadavky, které jdou do dalšího levelu řešení


 * - 90 % na požadavky, které se vyřeší


 * 3. level


 * - 1 % na požadavky, které jsou neřešitelné - entity zde končí (požadavek je uzavřen)


 * - 99 % na požadavky, které se vyřeší



Vyřešeno
Vyřešené požadavky putují do procesu vyřešené, kde jejich cesta končí, požadavek se považuje za uzavřený.



=Výsledky=

Po 31 dnech běhu helpdesk portálu:

=Závěr=

Tento model by určitě šel vylepšit a to minimálně tím, že by šlo lépe rozložit využití zdrojů, což při trial verzi SIMPROCESSu bohužel nejde. Dále je zde omezení na určitý počet procesů v jedné simulaci, ale i tak jsem se do tohoto počtu vešel. Ve svém modelu jsem se snažil co nejvíce zohlednit realitu a co nejvíce jí simulaci přiblížit. Ze simulace a z výsledků je patrné, že se to i podařilo. Aktuálně model věrohodně simuluje procesy a pohyby na helpdesk portálu. Při aktuálních parametrech generování požadavků jsou řešitelé vytížení na 40%. Pokud bychom zvýšili generování požadavků o dvojnásobek, tak využití řešitelů je přes 90%, ale také je vysoké procento zákazníků, kteří nevydrží čekat ve frontě a zvyšuje se tak i penalizace za dané požadavky. Při generování více než 20 požadavků za hodinu se začíná fronta přeplňovat, požadavky stojí na bráně z důvodu přetíženosti řešitelů. Po tom bychom museli zvýšit počet řešitelů, kteří daný problém vyřeší.

=Reference=

www.nb.vse.cz/keko/simulace/





=Kód=