Incident Management process flow clarification

An open discussion on issues related directly or primarily to the service or help desk.
Post Reply
User avatar
Posts: 13
Joined: Mon Sep 24, 2007 8:00 pm

Thu May 27, 2010 10:58 am

I am developing a flow chart for incident management in our company. In the Service Operation book, figure 4.2 shows the "Incident Management process flow". Section 4.2.5 says "The process to be followed during the management of an incident is shown in Fgiure 4.2."

I know that ITIL is not prescriptive, but I am always sensative with phrases like "The process to be followed". That sounds pretty much like a directive to me.

In our company we have two basic support tracks: datacenter and software. When an incident occurs or is submitted that directly affects the software the ticket is immediately passed to software support. No other "diagnosis" is done.

The way I interpret the flow chart in the context of my company is that the first question asked in the "Initial Diagnosis" process is "Software, yes/no?". If software, there is a functional escalation to 2nd level (software) support.

On the other hand, this could be part of "Incident Categorization", however according to the flow chart, you only have service requests and others. Since a software incident is not a service request, the next step is Prioritization and then determining if a major incident or not. It is not the job of the service desk to determine if a software incident is a major incident or not. So for us, the question of major incident comes after the question whether there is a functional escalation or not.

I know no one is going to get shot if we change the order of these decisions in our flow chart. However, I would like be able to justify any deviations from the official ITIL books, or if my flow chart does not deviated why it does not fit the "old" way of doing things.

User avatar
ITIL Expert
ITIL Expert
Posts: 1894
Joined: Mon Mar 03, 2008 7:00 pm
Location: Helensburgh

Thu May 27, 2010 3:38 pm

Sounds like you have silos.

You'll get in an awful lather if you keep trying to put ITIL in front of requirement. Write your flowchart how you do it. Don't fudge the terminology or twist the meaning to fit some perceived ITIL norm. There is not one. The fact that the flowchart only has "service requests and others" is a big clue that it is not the whole story

Think of the ITIL terms as concepts, not straight-jackets. Since ITIL is absolutely not prescriptive (whatever words you find in the text - and they may just be ill-considered words or you may be taking them out of context), there is nothing to deviate from. You use it to help you, not to rule you.

It's a funny service desk that is not supposed to call major incident when it sees one. After all the first part of a major incident is a major service down and you know this when you get the call. The second part is that it isn't on the way back up a few minutes later and front line will not always be able to work that out when they pass the call to second line whether it is software or infrastructure.

In a way, what you are describing is two service desks with one of them as a common channel for all "incoming". Incident management has to be performed at both of them performed . The process flows are the same but the actors are different. If it works for you, then carry on. I hope that overall responsibility for is clearly identified because a) the customer really doesn't care whether it is software or hardware that has interrupted the service and b) sometimes one looks like the other at first glance and it can even be a combination of the two.

Just as an aside, what you describe is more of a functional transfer than a "functional escalation" whatever that means. If it was escalation you would still be responsible for it.

I can't help thinking that for your organization, a much better use of ITIL would be to pretend that it won't let you continue with your silos and force through an newly improved and integrated service.
"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