Page 1 of 1

Incident Management process help

Posted: Thu May 27, 2010 4:21 am
by DJLong
Hi All,

I have just taken on a role as Incident Manager and I am starting to write up the IM process, I have drafted up the below and I was wondering if anyone else who is an IM could give me some advise/guidance to see if this is correct?

The key goals of the incident management process is to restore a normal service operation as quickly as possible and to minimize the impact of Incidents on the business, ensuring that the best possible levels of service quality and availability are maintained.

Goal Of Incident Management
The first goal of the incident management process is to restore a normal service operation as quickly as possible and to minimize the impact on business operations, thus ensuring that the best possible levels of service quality and availability are maintained.

There are 7 key steps to the Incident Management process, these are:
Logging (Raise Incident)
Investigation and Diagnosis
Within Incident Management, the Service Desk are the first point of contact and support for our customers. The Service Desk also route all incident to the relevant Support teams (local desktop or infrastructure teams).

I am not going to go through each key step of the Incident Management process.

1. Logging (Raise Incident)

The first step of this process is to 'raise an incident'. ITIL defines as an unplanned interruption or reduction in service to an IT Service (E.G. Hardware error). Customers have the ability to raise an incident via our self service portal or they can call the Service desk who will log the incident on there behalf.

2. Categorization

It is very important that the Service Desk are able to categorize the incident correctly. Also, it is equally important that the Service Desk are able to gather the relevant information to determine which Service or Configuration Item (CI) is affected.

3. Prioritization

After Classification, it's important that the Service Desk correctly prioritize the incident correct. There are a few key questions that you could ask to ensure that you fully understand the priority of the incident:
- Is anyone else around you having the same problem?
- Is this stopping you from working?

The Service Desk Analyst will then check the knowledge centre for an known solutions, if there is a solution available then they will need to provide the fix.

4. Investigation and Diagnosis
Before the Service Desk would escalation the Incident (if need be), they will need to use their troubleshooting skills to investigate the problem throughly, ensure that they gather a screen shot of the error, error message, how the problem occurred or if they can replicate the problem. If the Analyst is user of the solution then they will need to check the Knowledge Centre, if there is an article with the know fix then the Service Desk will provide the resolution. Informa have already implemented the below process to help our staff in this area:
Knowledge Centre where our Analysts and customers can self help themselves
Ticket escalation process, we have identified the common incidents and have provided which support team this needs to be escalation to and what information is required
Flexible routing of Incident Management data according to geographic region
5. Escalate

Having finished investigating and diagnosising the Incident, you are now at the stage to whether or not to escalate or resolve the Incident. If you know the fix and are able to provide resolution, please got to step 6. If you need to escalate the Incident, you need to ensure that you know who the correct support team this needs to go. The key step when escalating the ticket is to ensure that you get it right first time, if you fail to escalate the ticket to the right team, then there is a chance that the ticket will be bounced around different teams, which increases the likelihood of breeching SLAs. To ensure that we reduce this as much as possible, we have create a escalation process map which is available to all the Service Desk so that they are able to send the ticket to the correct support team.

6. Resolution

Now you are at the final stage of the Incident Management process, your main activity now is to resolve the incident with the solutions or workarounds obtained. If the resolution is provided by another support team, then they would also provide the resolution to the incident.

7. Closure

Once you have provided the resolution and resolved the incident, the customer will have the option to accept or reject the incident, if they request the resolution then the Incident will automatically reopen and will sit in the queue of the Analyst who resolved the ticket. If the customer accepts resolution, then the ticket will close.

Thanks DJL

Posted: Thu May 27, 2010 7:21 am
by Diarmid

I have an 8 process diagram, including three proccesses that you do not have in your list.

Your elaborations are not all strong, but the one I will mention now is priority: the key to priority is cost and risk and the questions you suggest as useful do very little to establish either of those. You have to find out what the cost of the lost service is at that time to the customer, what the cost will be over time until it is fixed, what time points exist at which the cost will become greater, what business risks exist while the service is unavailable. counting numbers affected does little for that until you have established if the way they are affected is high cost or risk. Asking someone if they can get on with other work does not put a value on the difference between the two pieces of work.

Posted: Thu May 27, 2010 9:36 am

Have you thought to consult the ITIL books before writing this ?

Posted: Thu May 27, 2010 2:40 pm
by Diarmid
Are you calling me curious?

Posted: Fri May 28, 2010 1:09 am


Incident Management process help

Posted: Fri May 28, 2010 3:39 am
by DJLong
Thanks for all your comments.


Would you be able to elaborate on the 8 process diagram that you currently use?


Posted: Fri May 28, 2010 5:31 am
by Diarmid

I don't use them. I am currently unemployed (so maybe they are not very good 8) )

The detail is of no value to you because they were not designed for your situation.

The key components that you have not included are: escalation (in the proper meaning, not just engaging to the appropriate team), call tracking (keeping on top of progress and keeping the customer and users informed), review, and reporting.

There was also call re-opening, which may seem strange but it was wanted to be able to re-open a call if the fix turned out not to have worked in some circumstances. This was a bit silly because a) it should not happen (or only on blue moon day) and b) it was not very easy to be sure it was not a new incident - it probably was most times!

The sequential processes are:

1. call setup
2. call assignment
3. call processing
4. call closure

The other processes mentioned above are not in the main line because they do not always occur. The review process was not designed to be applied to each individual call, but to be done periodically, or as a consequence of things going wrong.

I would say more, but do not want to do myself out of a job opportunity.

Posted: Wed Jun 09, 2010 1:52 am
by vz-r_Dave
Go and buy yourself the ITIL Service operation and analysis publication dude.

It has all of your answers and you can build on it from there.

It is a must.