Xsoul21: /* Závěr */

2014-06-07T08:52:27Z

‎Závěr

Xsoul21: Vytvoření stránky projektu

2014-06-06T23:40:31Z

Vytvoření stránky projektu

New page

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:''' [http://simprocess.com/products/products.html SIMPROCESS]
* '''Odkaz na zadání simulace:''' [http://www.simulace.info/index.php/Xsoul21 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 [http://mibcon.cz Mibcon a.s.] nalézající se na adrese [https://projekt.mibcon.cz projekt.mibcon.cz].

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

[[File:Simprc model.PNG|center|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)

[[File:Simprc request.PNG|center|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.

[[File:Simprc queve.PNG|center|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ší

[[File:Simprc prc.PNG|center|Ř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ý.

[[File:Simprc solved.PNG|center|Vyřešené požadavky]]

=Výsledky=

Po 31 dnech běhu helpdesk portálu:

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

{| class="wikitable"
|+ align="top" | ''' Využití řešitelů'''
!
! colspan="2" | Bez práce
! colspan="2" | Zaměstnaní
! colspan="3" | 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
|}

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

{| class="wikitable"
|+ align="top" | ''' Celkové doby řešení požadavků v systému (v hodinách) '''
!
! colspan="2" | Celkem v systému
! colspan="2" | Ve zpracování
! colspan="2" | Č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
|-
|}

{| class="wikitable"
|+ align="top" | ''' 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ě
|-
!rowspan="5"| 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
|-
!!!!!!!
|-
!rowspan="5"| 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
|-
!!!!!!!
|-
!rowspan="5"| 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
|-
|}

{| class="wikitable"
|+ align="top" | ''' Jednotlivé počty řešených požadavků u jednotlivých řešitelů'''
!| Jméno Zdroje
!| Jméno Entity
!| Celkem
|-
!rowspan="5"| 1. lvl řešitel
|-
| Vys. požadavek || 3012
|-
| Stř. požadavek || 5630
|-
| Níz. požadavek || 3789
|-
| '''Celkem''' || 12431
|-
!!!!!
|-
!rowspan="5"| 2. lvl řešitel
|-
| Vys. požadavek || 743
|-
| Stř. požadavek || 1413
|-
| Níz. požadavek || 967
|-
| '''Celkem''' || 3123
|-
!!!!!
|-
!rowspan="5"| 3. lvl řešitel
|-
| Vys. požadavek || 71
|-
| Stř. požadavek || 141
|-
| Níz. požadavek || 75
|-
| '''Celkem''' || 287
|}

{| class="wikitable"
|+ align="top" | ''' Počty vyřešených a nevyřešených požadavků'''
!| Proces
!| Jméno Entity
!| Celkem
|-
!rowspan="4"| Neřešitelné
|-
| Vys. požadavek || 1
|-
| Stř. požadavek || 1
|-
| '''Celkem''' || 2
|-
!!!!!
|-
!rowspan="5"| Nevydržel čekat
|-
| Vys. požadavek || 32
|-
| Stř. požadavek || 57
|-
| Níz. požadavek || 35
|-
| '''Celkem''' || 124
|-
!!!!!
|-
!rowspan="5"| Vyřešené požadavky
|-
| Vys. požadavek || 2862
|-
| Stř. požadavek || 5350
|-
| Níz. požadavek || 3586
|-
| '''Celkem''' || 11798
|}

{| class="wikitable"
|+ align="top" | ''' Celkové náklady na zdroje (v CZK)'''
!| Jméno zdroje
!| Jméno Entity
!| Náklady
|-
!| 1. lvl řešitel
| Skup. požadavek
| 578535,49
|-
!!!!!
|-
!rowspan="3"| 2. lvl řešitel
| Vys. požadavek || 147568,65
|-
| Stř. požadavek || 290951,27
|-
| Níz. požadavek || 174179,08
|-
!!!!!
|-
!rowspan="5"| 3. lvl řešitel
|-
| Vys. požadavek || 57708,68
|-
| Stř. požadavek || 110060,97
|-
| Níz. požadavek || 65506,4
|-
| '''Celkem''' || 1424510,55
|}

{| class="wikitable"
|+ align="top" | ''' 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
|-
!rowspan="5"| Vyřešený
|-
| Vys. požadavek || 2862 || 429300
|-
| Stř. požadavek || 5350 || 3210000
|-
| Níz. požadavek || 3586 || 1075800
|-
| '''Celkem''' || 11798 || 4715100
|-
!!!!!!!
|-
!rowspan="4"| Neřešitelné
|-
| Vys. požadavek || 1 || - 6000
|-
| Stř. požadavek || 1 || - 3000
|-
| '''Celkem''' || 2 || - 9000
|-
!!!!!!!
|-
!rowspan="5"| Nevydržel čekat
|-
| Vys. požadavek || 32 || - 192000
|-
| Stř. požadavek || 57 || - 171000
|-
| Níz. požadavek || 35 || - 52500
|-
| '''Celkem''' || 124 || - 415500
|-
!!!!!!!
|-
!colspan="3"| '''Zisk celkem'''
| + 4290600
|}

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

[http://nb.vse.cz/keko/simulace/ www.nb.vse.cz/keko/simulace/]

[http://www.simprocess.net/ www.simprocess.net/]

[https://projekt.mibcon.cz/ projekt.mibcon.cz/]

=Kód=

[[File:Helpdesk portal.spm]]

@@ Line 465: / Line 465: @@
 =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.
+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 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ší.
+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=

Simulace Helpdesk Portálu - Revision history

Xsoul21: /* Závěr */

Xsoul21: Vytvoření stránky projektu