Process mining in IT Service Management: to understand and optimize the resolution times

IT Service management systems could benefit from  factual process data to understand the dynamic of the many changes underlying the current status quo . How long does improvement of existing features take? What is the communication process among developers for bug fixing? What is the average resolution time, end-to-end? Are there several resolved | closed  → reopened loops?

Discover 

Chart the stories (pathways) associated with the entities in your system, as they flow in reality: the status | resolution states that tickets go through successively. 

• To understand the communication process among developers, and how this aspect affects the development process (the working habits)
• To transfer knowledge easily. Help new employees get a thorough understanding of the company working culture,  by showing them a snapshot of the existing modus operandi. 

 

Measure 

Quantify the stories (end-to-end average time delays, frequencies, fitness) 

• To calculate the cost of an IT management process.

• To identify end-to-end processes that cause the greatest amount of additional work.

 

Pinpoint oddities: inefficiencies and noncompliance

• Inefficiencies with respect to: 
  • cost: repetitive tasks (re-work cycles, queues at a specific successions of ticket states CLOSED >> REOPENED or RESOLVED >> REOPENED )
  • time: long resolution  times; time demanding activities on  developer side
• Mismatches (expectations versus reality), for single process steps, or for entire journeys
  • activities that were expected to happen, but didn’t
  • activities (process steps) that occurred, but were not expected to happen
  • noncompliance to specified guidelines (e.g. ITIL assessments – a laborious task, that require business processes to be monitored and reinterpreted in terms of ITIL guidelines)

 

Optimize

Have your expert investigate possible causes of oddities found, and identify opportunities to minimize waste, reduce costs and increase customer satisfaction. Bring digital transformation to maximize asset utilisation and transparency into your systems.

• Expectations versus reality: Are there mandatory activities that in reality could be skipped (and are skipped on a regular basis by developers)? In which situations is it possible to skip these activities? Are they related to a certain type of tickets?
• Workload. Are resources incapacitated because of too much workload? 
• Workload distribution.  Is the workload well distributed among resources (developers / departments)?  
• Habits. Look into the modus operandi across projects / departments:Are there more long-running tickets in  one project / department versus another? If yes, is there a valid reason for this?
• Resource availability. Are there enough resources? Will adding more developers solve the problem?
• Process complexity. Is it possible to simplify processes to some extent?
• Demand. Is there an ever increasing number of tickets that are repeatedly closed and then reopened?
• Islands of expertise / know-how (Bus Factor). Are there activities with a small user set?

 

ThiaperProcess for a sample issue tracking dataset

The dataset was extracted from the Jira ITS of four popular open source ecosystems (as well as the tools and infrastructure used for extraction): the Apache Software Foundation, Spring, JBoss and CodeHaus communities. The dataset hosts more than 1K projects, containing more than 700K issue reports and more than 2 million issue comments. A full description is documented here.

The data was preprocessed to identify the project with the largest number of changes in ticket status | resolution.