Simulace Helpdesk Portálu

From Simulace.info
Revision as of 09:52, 7 June 2014 by Xsoul21 (talk | contribs) (Závěr)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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.

Náhled modelu v SIMPROCESSu

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.

Procesy

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)


Generování požadavků


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.


Fronta požadavků


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ší


Řešení požadavků


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


Vyřešené požadavky


Výsledky

Po 31 dnech běhu helpdesk portálu:

Počet vygenerovaných požadavků
Jméno Entity Vygenerováno
Níz. požadavek 3623
Stř. požadavek 5411
Vys. požadavek 2895
Celkem 11929


Využití řešitelů
Bez práce Zaměstnaní Plánovaně mimo
Jméno Zdroje Průměrně Maximum Průměrně Maximum Průměrně Maximum
1. lvl řešitel 5,680738147 20 7,776014612 18 6,543247241 10
2. lvl řešitel 2,613803118 10 4,117600812 10 3,26859607 5
3. lvl řešitel 1,909826458 4 0,783857721 4 1,306315821 2


Využití řešitelů v %
Jméno Zdroje Bez práce Zaměstnaní Plánovaně
1. lvl řešitel 28,40% 38,88% 32,72%
2. lvl řešitel 26,14% 41,18% 32,69%
3. lvl řešitel 47,75% 19,60% 32,66%


Celkové doby řešení požadavků v systému (v hodinách)
Celkem v systému Ve zpracování Čekající na zdroje
Jméno Entity Průměrně Maximum Průměrně Maximum Průměrně Maximum
Níz. požadavek 3,762 21,753 3,367 20,953 0,299 15,615
Stř. požadavek 2,630 17,890 2,377 17,863 0,167 6,478
Vys. požadavek 2,003 15,516 1,839 15,434 0,086 1,578


Doby řešených jednotlivých požadavků u jednotlivých řešitelů (v hodinách)
Jméno Zdroje Jméno Entity Průměrně Maximálně
1. lvl řešitel
Vys. požadavek 1,059023508 10,38681246
Stř. požadavek 1,074872227 13,26326076
Níz. požadavek 1,08992015 13,26326076
Celkem 1,07906982 13,26326076
2. lvl řešitel
Vys. požadavek 1,069838428 7,3800133
Stř. požadavek 1,389640826 12,71801442
Níz. požadavek 1,736152673 18,0543077
Celkem 1,420849207 18,0543077
3. lvl řešitel
Vys. požadavek 2,119432716 4,414800688
Stř. požadavek 2,119708489 5,934125215
Níz. požadavek 2,408475933 8,575380502
Celkem 2,195102142 8,575380502


Jednotlivé počty řešených požadavků u jednotlivých řešitelů
Jméno Zdroje Jméno Entity Celkem
1. lvl řešitel
Vys. požadavek 3012
Stř. požadavek 5630
Níz. požadavek 3789
Celkem 12431
2. lvl řešitel
Vys. požadavek 743
Stř. požadavek 1413
Níz. požadavek 967
Celkem 3123
3. lvl řešitel
Vys. požadavek 71
Stř. požadavek 141
Níz. požadavek 75
Celkem 287


Počty vyřešených a nevyřešených požadavků
Proces Jméno Entity Celkem
Neřešitelné
Vys. požadavek 1
Stř. požadavek 1
Celkem 2
Nevydržel čekat
Vys. požadavek 32
Stř. požadavek 57
Níz. požadavek 35
Celkem 124
Vyřešené požadavky
Vys. požadavek 2862
Stř. požadavek 5350
Níz. požadavek 3586
Celkem 11798


Celkové náklady na zdroje (v CZK)
Jméno zdroje Jméno Entity Náklady
1. lvl řešitel Skup. požadavek 578535,49
2. lvl řešitel Vys. požadavek 147568,65
Stř. požadavek 290951,27
Níz. požadavek 174179,08
3. lvl řešitel
Vys. požadavek 57708,68
Stř. požadavek 110060,97
Níz. požadavek 65506,4
Celkem 1424510,55


Zisky z vyřešených a náklady z nevyřešených požadavků (v CZK)
Status Jméno Entity Počet Zisk
Vyřešený
Vys. požadavek 2862 429300
Stř. požadavek 5350 3210000
Níz. požadavek 3586 1075800
Celkem 11798 4715100
Neřešitelné
Vys. požadavek 1 - 6000
Stř. požadavek 1 - 3000
Celkem 2 - 9000
Nevydržel čekat
Vys. požadavek 32 - 192000
Stř. požadavek 57 - 171000
Níz. požadavek 35 - 52500
Celkem 124 - 415500
Zisk celkem + 4290600


Zisk - Náklady (v CZK)
Náklady 1424510,55
Zisky 4290600
Celkem 2866089,45

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/

www.simprocess.net/

projekt.mibcon.cz/

Kód

File:Helpdesk portal.spm