The document discusses the incident and problem management processes within IT service management, emphasizing the differences and objectives of both areas. It presents findings from a questionnaire about the importance of various objectives and offers suggestions for enhancing incident management efficiency, including automatic ticket creation and prioritization based on urgency and impact. Additionally, it outlines proposed implementation strategies for creating a more structured problem management process that engages employees while monitoring performance through key performance indicators (KPIs).

1. Scenario 5:
Incident and Problem Management
Business Process Management and
Modelling
A.Y. 2015/16
Group: 5 Forces
Selin Akkaya
Isacco G. Bombelli
Monica Gallerani Guidetti
Denis Karaman
Anna Sadokhina

2. Agenda
2
Introduction and the Itil v3 Framework
• Incident vs. Problem
• Incident management vs. problem management
Incident management IT in Leroy Merlin
• Questionnaire
• Analysis on the current Incident Process Flow
• Way of prioritizing incidents
New Problem Management for LM
• Objectives of Problem management
• The process from scratch
• Integration Interfaces
Implementation
• 3 scenarios on how to deal with implementation

3. Problem management
• Incident management deals with the resolution of an incident which has caused a service interruction
• Problem Management copes with the analysis of the infrastructure and uses all the information to
identify and understand the causes which determined the occurrence of an incident.
• Incident management indeed does not want to understand and solve the problem underlying the
dysfunction, but its aim is to solve the dysfunction as quickly as possible.
• A known error is the known cause of an incident for which a workaround also exists
→ The Problem Management is based on the assumption that incidents may be linked among each other
and the causes underlying them may be not so evident to spot
Problem Known Error Request of Change Error Elimination
3Source: A. Teti, Management dei servizi IT

4. Questionnaire on the Objectives of LM
4
SPEED
RESPONSE TIME
TRANSPARENCY
QUALITY
Objectives
We asked LM to prioritize these objectives with reference to
their importance for the Incident and Problem Management
and to rank them (scale 1-7)
SPEED: time required to find a solution → 7
QUALITY: the solution is sustainable → 6
RESPONSE TIME: time required to inform the employee that
the ticket has been processed → 5
TRANSPARENCY: who deals with a dysfunction has to know
who would be responsible to solve it → 7
According to our findings we are now going to present some
possible suggestions to improve the Incident Management
and to build an effective Problem Management process

5. Agenda
Administration
and Stakeholders
Configuration:
System Selection
Implementation
Test and
Deployment
Evaluation:
Process Mining
Business Analysis
Monitoring
Design:
Business Process
Identification and
Modelling
Analysis:
Validation
Simulation
Verification
Enactment:
Operation
Monitoring
Maintenance
5
Source: M. Weske, Business Process Management

6. Agenda
Administration
and Stakeholders
Configuration:
System Selection
Implementation
Test and
Deployment
Evaluation:
Process Mining
Business Analysis
Monitoring
Design:
Business Process
Identification and
Modelling
Analysis:
Validation
Simulation
Verification
Enactment:
Operation
Monitoring
Maintenance
Evaluation
Design &
Analysis
Configuration
Enactment
Evaluation
6

7. Incident Management: Actual Process

8. 1° Improvement: let’s start automatically
• Nowadays incidents pointed out
automatically only for the Financial
Department
• If all departments could create tickets
automatically the process will improve its
efficiency
• This is consistent with an increasing level
of employees empowerment
• In case of urgency, especially during non-
operating hours, a proper communication
channel will be provided
SPEED ↑
QUALITY ≈
RESPONSE TIME ↓
TRANSPARENCY ≈

9. Incident Management: Actual Process

10. 2° Improvement: ask the Resolutor
Tickets are today assigned manually to each level. If the assignment could take place during
categorization, several steps would be saved. Also in the current flow the resolutor is not
asked for feedback. In case the resolutor was wrongly assigned, it will be noticed only after
going through the whole process unnecessarily. Therefore the resolutor’s immediate
feedback would improve the flow.
Moreover, success resolution should be recorded in order to assign future incident.
SPEED ↑
QUALITY ≈
RESPONSE TIME ↓
TRANSPARENCY ↑

11. 3° Improvement: Set Priorities
LOW MEDIUM HIGH
SINGLE USER MORE USERS AREAS
HIGH
UNABLE TO DO THE
OWN JOB
MEDIUM
JOB PARTIALLY
BLOCKED
LOW
JOB SLOWED
DOWN
URGENCY
IMPACT
The system should be flexible to consider escalation mechanism in order to fix the incidents
according to their relevance. That relevance depends on two dimensions:
- IMPACT: measure the spread of the incident considering how many people are affected by it
- URGENCY: expresses how the incident threatens work activities
SPEED ↑ ↓
QUALITY ≈
RESPONSE TIME ≈
TRANSPARENCY ↑

12. KPI: You Cannot Improve What You Cannot
Measure
Urgency Priority Category Users Business
area
Help Desk 1st / 2nd / 3rd /
external level By time of day
Average time taken to restore the incident
How many of these incident were first time resolution
The percentage of incidents assigned more than twice
Number and percentage of incidents incorrectly assigned
Number and percentage of Incidents incorrectly categorized
N° of Incident received in a month
N° of repetitive incident received (in a month)
How often you have received similar incidents for a particular device or
data center.
The number or percentage of major incidents
Number and type of reoccurring incidents.
This will indicate the accuracy of correct resolution offered at very
first go. Recording that will improve future resolution
Linked to the Problem
Management
Nowadays there is not a KPI system for each level. There are KPIs for the whole proccess but they are used only a little and
not to improve the performance but just to measure the level of service from external level.

13. KPI: You Cannot Improve What You Cannot
Measure
Urgency Priority Category Users Business
area
Help Desk 1st / 2nd / 3rd /
external level By time of day
Average time taken to restore the incident
How many of these incident were first time resolution
The percentage of incidents assigned more than twice
Number and percentage of incidents incorrectly assigned
Number and percentage of Incidents incorrectly categorized
N° of Incident received in a month
N° of repetitive incident received (in a month)
How often you have received similar incidents for a particular device or
data center.
The number or percentage of major incidents
Number and type of reoccurring incidents.
Linked to the Score
System
Nowadays there is not a KPI system for each level. There are KPIs for the whole proccess but they are used only a little and
not to improve the performance but just to measure the level of service from external level.
To help pinpoint peaks and
ensure matching of resources

14. Agenda
Administration
and Stakeholders
Configuration:
System Selection
Implementation
Test and
Deployment
Evaluation:
Process Mining
Business Analysis
Monitoring
Design:
Business Process
Identification and
Modelling
Analysis:
Validation
Simulation
Verification
Enactment:
Operation
Monitoring
Maintenance
14

15. Problem Management
Administration
and Stakeholders
Configuration:
System Selection
Implementation
Test and
Deployment
Evaluation:
Process Mining
Business Analysis
Monitoring
Design:
Business Process
Identification and
Modelling
Analysis:
Validation
Simulation
Verification
Enactment:
Operation
Monitoring
Maintenance
Evaluation
Design &
Analysis
Configuration
Enactment Design &
Analysis
15

16. 16

17. Designed from scratch
17

18. Problem Management process flow
Based on ITIL v3
Notification
Problem
Determination
Workaround
Problem Resolution
Tracking
Reporting/Control
18
1. 2. 3. 4.

19. Problem Management process flow
1. Notification
19
1. User sends the request to 1st level of Help Desk
2. Help Desk decides if the request can be categorised as
an Incident or a Problem
IF it is a PROBLEM  Problem Management BEGINS
3. Problem is logged by Help Desk

20. Distinguish between
Open Known Error Non known Error
1. Link Problem to existing
tickets
2. Assign the Resolutor
• Third Level Help Desk
• External Suppliers
1. Categorize the Problem
2. Assign the Resolutor
• Third Level Help Desk
• External Suppliers
3. For third Level Helpdesk
perform Diagnosis
4. For external supplier
follow existing path
Problem Management process flow
2. Problem determination
20

21. Problem Management process flow
3. Workaround and Problem Resolution
21
Define, what should be applied
Workaround Permanent solution Change
1. Recognize a workaround 1. Recognize a permanent solution 1a. Analyse, where change is needed
1b. Raise RfC
1c. Change management
2. Raise known-error record
3. Apply recognized solution

22. Problem Management process flow
4. Tracking/Reporting/Control
AND put the communication as
well
22
Result of solution application
Problem not resolved Problem resolved/Solution not feasible
1. Go back to Problem Determination 1. Close the tickets and update the
status of the problem/close the
problem
2. Communicate problem resolution to
the users
3. Receive user feedback

23. Agenda
Administration
and Stakeholders
Configuration:
System Selection
Implementation
Test and
Deployment
Evaluation:
Process Mining
Business Analysis
Monitoring
Design:
Business Process
Identification and
Modelling
Analysis:
Validation
Simulation
Verification
Enactment:
Operation
Monitoring
Maintenance
23

24. Implementation
Administration
and Stakeholders
Configuration:
System Selection
Implementation
Test and
Deployment
Evaluation:
Process Mining
Business Analysis
Monitoring
Design:
Business Process
Identification and
Modelling
Analysis:
Validation
Simulation
Verification
Enactment:
Operation
Monitoring
Maintenance
Evaluation
Design &
Analysis
Configuration
Enactment
Configuration
24

25. Implementation Strategies
Problem: Most employees skip formal procedure to get their problem solved quickly
Scenario 1- Flexible Approach
No additional solution
Continue in current situation
Scenario 3- Semi-flexible Approach
Employees are attribute points each month.
When they don’t comply with the procedure,
they lose points
Prize for the employee with highest points
Scenario 2- Non- Flexible Approach
Only formal process will be allowed for
incident management
25
1st level HD
3rd level HD

26. Implementation Strategies
Problem: Most employees skip formal procedure to get their problem solved quickly
Scenario 1- Flexible Approach
No additional solution
Continue in current situation
 Fits company culture
Allows interdepartmental
connections
Do not require further cost
×Difficult to record incidents
×Difficult to measure
×No possibility for improvement
×Prioritization is justified
Scenario 3- Semi-flexible Approach
Employees are attribute points each month.
When they don’t comply with the procedure,
they lose points
Prize for the employee with highest points
Scenario 2- Non- Flexible Approach
Only formal process will be allowed for
incident management
26
1st level HD
3rd level HD
X

27. Implementation Strategies
Problem: Most employees skip formal procedure to get their problem solved quickly
Scenario 1- Flexible Approach
No additional solution
Continue in current situation
 Fits company culture
Allows interdepartmental
connections
Do not require further cost
×Difficult to record incidents
×Difficult to measure
×No possibility for improvement
×Prioritization is justified
Scenario 3- Semi-flexible Approach
Employees are attribute points each month.
When they don’t comply with the procedure,
they lose points
Prize for the employee with highest points
Scenario 2- Non- Flexible Approach
Only formal process will be allowed for
incident management
Easy the track the whole process
Introduce KPIs to improve the efficiency
of IT department
Creates a database for past incidents
× Non-flexibility may lead to resistance
×All employees must be educated.
×Costly and requires time
27
1st level HD
3rd level HD
X

28. Implementation Strategies
Problem: Most employees skip formal procedure to get their problem solved quickly
Scenario 1- Flexible Approach
No additional solution
Continue in current situation
 Fits company culture
Allows interdepartmental
connections
Do not require further cost
×Difficult to record incidents
×Difficult to measure
×No possibility for improvement
×Prioritization is justified
Scenario 3- Semi-flexible Approach
Employees are attribute points each month.
When they don’t comply with the procedure,
they lose points
Prize for the employee with highest points
Gamification of the system for motivation
Increase the amount of employees who will
use formal procedure
Easier to measure the process
×Less flexible
×Requires a system for tracking points
×May create conflict with IT department
Scenario 2- Non- Flexible Approach
Only formal process will be allowed for
incident management
Easy the track the whole process
Introduce KPIs to improve the efficiency
of IT department
Creates a database for past incidents
× Non-flexibility may lead to resistance
×All employees must be educated.
×Costly and requires time
28

29. Thank you for your attention
Five Forces
Isacco G. Bombelli Monica Gallerani
Guidetti
Denis Karaman Anna SadokhinaSelin Akkaya
Student Consultant
HEC - Paris
Student Consultant
Bocconi University - Milan
Student Consultant
Bocconi University - Milan
Student Consultant
Koc University - Istanbul
Student Consultant
Bocconi University - Milan

30. Sources
30
1. Teti, A. "Management dei servizi IT." il Sole 24.
2. Weske, Mathias. Business process management: concepts, languages,
architectures. Springer Science & Business Media, 2012