Simplifying (joining) Incident and Problem Management?

General discussion on all aspects of the IT Infrastructure Library (ITIL)
Post Reply
User avatar
Eivind
Newbie
Newbie
Posts: 4
Joined: Mon Mar 23, 2015 8:00 pm

Wed Mar 25, 2015 6:05 am

Hello everyone!

I am currently working as a Project Leader on a Service Desk and ITIL processes implementation project in a small company.

As of now there are no ITIL processes in use, and they don`t have a Service Desk system either, so it is really a blank slate for me to work on.

Since they only have 3 guys + boss in their internal IT dept, I want to make the processes as simple as possible to ensure they will actually be used.

The guys working on the Incidents are the same ones that would handle the Problems too, and the IT Manager will be both Problem Manager and Change Manager.

So I was thinking; Could I join the Incident and Problem Management processes, so that escalating an Incident tickets severity level to "Problem" status would invoke the part of the Problem Management process we would need?

The processes are pretty similar after all.

Any advice, or better ideas?


User avatar
Eivind
Newbie
Newbie
Posts: 4
Joined: Mon Mar 23, 2015 8:00 pm

Wed Mar 25, 2015 6:25 am

BTW, a decision to use SysAid as the cloud based Help Desk system has been made.
User avatar
UKVIKING
ITIL Expert
ITIL Expert
Posts: 3639
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Thu Mar 26, 2015 5:46 am

Elvind


Incident Management and Problem Management are similar only in the fact that there is the letter E in both of them and the word management appears in both of them

However, they have two diametrically opposed purposes and goals

Incident management's sole purpose is returning service to the customer / user as quickly as possible. IM does not care about why the service was impacted; only that it was and will do what is needed to return the service to what it was before.

Problem management does not care whether the service is being delivered. It only cares about finding out why the service had the service incident and how so as to prevent another occurence.

So, yes in such a small shop; you can have the same team do both Incident and Problem as well as the line manager being both the IM Mgr and PM Mgr;
BUT
you need to make sure that they understand the difference and do not mix the two processes to the point of not restoring the service

If the email server crashes, the goal is to restore the mail service while trying to find out why it went down in the first place
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
User avatar
Eivind
Newbie
Newbie
Posts: 4
Joined: Mon Mar 23, 2015 8:00 pm

Fri Mar 27, 2015 3:34 am

UKVIKING wrote:Elvind


Incident Management and Problem Management are similar only in the fact that there is the letter E in both of them and the word management appears in both of them

However, they have two diametrically opposed purposes and goals

Incident management's sole purpose is returning service to the customer / user as quickly as possible. IM does not care about why the service was impacted; only that it was and will do what is needed to return the service to what it was before.

Problem management does not care whether the service is being delivered. It only cares about finding out why the service had the service incident and how so as to prevent another occurence.

So, yes in such a small shop; you can have the same team do both Incident and Problem as well as the line manager being both the IM Mgr and PM Mgr;
BUT
you need to make sure that they understand the difference and do not mix the two processes to the point of not restoring the service

If the email server crashes, the goal is to restore the mail service while trying to find out why it went down in the first place
Thank you for an insightful comment.

What I meant was the processes of Incidents and Problem Management are similar in the way that finding the reason it went down is often one of the first, if not THE first, step in finding the quickest way to restore the service.

At least for a small company it is, a big Enterprise would have other backup systems to fall back on, like manually failing over to another datacentre.

So my idea is to simplify Incident and Problem Management by only having one Incident template in the Service Desk system, but make it possible to escalate the Incident status from let`s say "Major" to "Problem" via a drop down menu if the need arises.

This might then trigger some new fields that can be used in the Problem process, but negating the need to fill out a separate form and thus adding to the feeling that ITIL processes are just another useless form of New Public Management.

The history field would show that it started out as an Incident, but was escalated and closed as a Problem.

I will of course as part of my job document the Problem part of the process, and thoroughly explain them the difference.

:)
User avatar
UKVIKING
ITIL Expert
ITIL Expert
Posts: 3639
Joined: Fri Sep 15, 2006 8:00 pm
Location: London, UK

Fri Mar 27, 2015 3:43 am

Elvind,

There is a vast difference in finding the reason the service is down and restoring the service and fixing the reason the service is down

That is the key difference between IM & PM.

The easiest IT example is the Web service on a windows platform

The web service stops.

The actions taken to restore service are
1 - stop and restart the web service
2 - if that fails, reboot the service
3 - verify web site is up

That is all IM cares about. Done. Service restored. SLA still in place

PM would not restart the service or reboot the service but read logs, look at this that and the other - while the service and the customers are screaming

SLA be damned

Make sure they understand the difference.

Pretty much most IM and simple PM actions is either clear cache, increase memory, CPU, cache, storage and reboot server (if windows o/s)
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
User avatar
Eivind
Newbie
Newbie
Posts: 4
Joined: Mon Mar 23, 2015 8:00 pm

Tue Apr 07, 2015 2:22 am

Hello
Yes, I do know the difference between restoring and fixing, I have more than 20 years experience as an IT technician/consultant in many companies from 100 employees to around 30 000, and I have yet to see anyone NOT trying to restore the service ASAP before focusing on solving the underlying problem.

I can see this would be a problem in a big company with separate Incident and Problem Management groups, but not in smaller ones where the information about the status of incidents spread like wildfire anyway.

So I feel very confident that this would not be a problem in a small company like I`m working for now, but I will make sure they know the difference.

Thanks for your input.
User avatar
Diarmid
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Wed Apr 15, 2015 2:16 pm

Elvind,
So my idea is to simplify Incident and Problem Management by only having one Incident template in the Service Desk system, but make it possible to escalate the Incident status from let`s say "Major" to "Problem" via a drop down menu if the need arises
Since there is not a 1to1 relationship between incidents and problems, this will not work or even make sense.
Since incident status ought to say "resolved" as soon as the incident is resolved, you can't logically set it to "problem".
How can it help problem management to to have problems identified through some arbitrary incident?
The history field would show that it started out as an Incident, but was escalated and closed as a Problem.
There is no sense in which a problem is an escalated incident.

Not only will you blur the distinction, which as John said is fundamental, but you will also be faced with a growing and unwieldy set of artificial constructs which will make the management of problem management and incident management increasingly difficult. In other words you soon would not be able to say how effective your processes were.
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Post Reply