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.

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)

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:

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

Model jako takový 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 procesu v jedné simulaci, ale i tak jsem při menších úpravách modelu vešel. Ve svém modelu jsem se snažil co nejvíce zohlednit realitu a co nejvíce jí simulaci přiblížit a 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ále. 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 tomto 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