Simulation optimalization of incident solving
Contents
Project Information
- Project name: Simulation optimalization of incident solving
- Subject: 4IT496 (WS 2020/2021)
- Author: Bc. Natalya Glybyshen
- Model type: Discrete-event simulation
- Software used: SimProcess
Problem definition
The IT firm providing the maintanence and also bug fixes of the developed RPA processes. The support is provide throught HelpDesk tool ServiceNow. IT have limited soureces for the solving of the issues (4 resources specified in Entities). Simulation is created to simulate optimalization of the distibution and solving of the incidents with limited recources, effectively, without an overloading of the recources. As incidents are differed by importance and also depends on SLA agreement between IT firm and customer. Also we have to find out how much it will cost to solve one request, what will be earnings and loss for requests which are overtimed SLA agreement.
Method
The problem specified could be implemented in several ways, I choosed to simulate it in SIMPROCESS as a process.
Model
The model is kind of simple as size of the maintanence team not so big (only 4 resources). The model consists really easy model.
Fist process Incidents it's getting tickets from the customer. Then follows adding the tickets to the queue according to the different severity. And then solving of the incidents, by different resources.
Entities
Incidents
There are four severity of incidents, represented as different types of entities. The severity of incident, apart from having different SLA requirements, differ in their flow throughout their process. Different severity incidents are generated using different rules.
| Incident Type | Severity (lower is less severe) | Probability of Occurrence (per hour) |
|---|---|---|
| Critical | 1 | Nor(0.4, 0.25, 1) |
| High | 2 | Nor(0.2, 0.25, 1) |
| Medium | 3 | Nor(0.075, 0.25, 1) |
| Low | 4 | Nor(0.05, 0.25, 1) |
Resources
There are four resources. Maintenance clerks: Needed for Changre reguests and Bug Fix stages. As we have four different resources placed in a diffirent locations. Working hours are only on working days:
- CZ : from 8:00 till 16:00 CET, costs 260 czk per hour.
- BR : from 12:00 till 20:00 CET, costs 300 czk per hour.
- IN : from 02:00 till 10:00 CET, costs 150 czk per hour.
- RUS : from 10:00 till 18:00 CET, costs 200 czk per hour.
Results
According to the simulation, we have found out that our resources handling incidents quite well, we can see that only 3 ticket left in the queue and all critical ticket are handled, it means that we are using our resources without overloading. Also for comparation and saving of cost I simulated incident solving in case we will need to fire one of the resources. Files will be attached. I have found out the 3 resources is not enough for handling such massive number of incidents and for us it's optimal number of resources is 4.
Also for saving firm money we can analyze how busy was each resource during it's working our and from the results we see that RUS resource have some capatity left and for the saving money we can assign incident to this resource to make some savings.
As we see according to the capaticy of incident could be solved during the day RUS and BR resources have some free and not maximaxing it, in this stage we also could save some our spendings, maybe by cutting the working shift.
According to the cost of the resources we see from the results below, that by realokating of some BR cases to the RUS resource we also could do some saving. And optimize workforce of resources.
Conclusion
This model would certainly be able to be improved, at least by better distributing the use of resources. In my model, I tried to take reality into a simulation. The simulation and the results show that it worked. Currently, the model reliably simulates processes and movements on the helpdesk portal. With the current requirements of generating requests, the solvers are avr. 95% busy. It's for now an ideal situation of incident solving.
Code
File:Optimalization of incident solving.spm
