Incidents and Changes, and differentiating between the Two
Customer Steve asks: ‘I know it’s a basic question, but could you write something about Incidents and Changes, this is now my responsibility and we have Changes logged as Incidents. Are there any advantages of doing it this way? Also, what about SLA target times with Changes?’
Time for a few definitions first. An Incident…
is something that is not part of the standard operation of a service we provide and that may cause disruption to that service, or cause it’s operation to be degraded.
Whilst a Change is…
something we (an amendment to a service we deliver to users) resulting from Incidents or Problems, or something we do simply to deliver business benefits or efficiency savings.
Steve asks if there are any benefits of logging Incidents as Changes? To be honest, I can’t think of any, and I’d probably go further and say it’s simply the wrong approach. If this were my Service Desk I’d want a clear division between the two – a list that was comprised solely of Incidents (as defined above) and a list solely of Changes (linked as appropriate to both Incidents and Problems). I’d then have a distinct management process to deal with both.
Applying SLA timings (for instance, target completion) to Changes in just the same way as Incidents seems to be an instinctive response by many people – just because it’s an obvious and easily understood statistic. My advice is to stop and pause for a second and ask yourself why you’d want to do that. Do you have an agreement with customers that requires this, or is this something you want to impose yourself?
Whilst it could be OK to handle routine and predictable Changes this way, it might be that imposing fixed, rule-based resolution targets to Changes that can be both large in scale and ‘one-offs’ serves no useful purpose. If you are concerned that without targets the Changes will ‘sit’ and go nowhere, make sure progressing them is part of what your Change Management process is concerned with, and what your Change Manager reviews as part of his set of Key Performance Indicators.
Coming back to Incidents v Changes Steve gives an example. ‘We want to sell to a foreign country, but don’t have VAT data for that country in the sales system, so when someone wanted to process an order it raised an error (no VAT data). Is that an Incident?’
Here’s how I would handle this. Log the Incident and record the details carefully. Analysis reveals the system lacks some data it needs, and I would then raise a Change linking the two, giving the Change reference number to the customer. I’d then close the original Incident, but schedule a reasonably urgent delivery date for the Change, which presumably involves finding out about VAT in our target country.
An alternative approach would be to keep the original Incident open until the Change completes and resolves the Incident for us – I think either approach will work, it’s just a question of preferences.
I read with interest your article on Incidents and Changes. However, I would like to add a third category of Projects. Some requests when submitted to the helpdesk are treated as incidents and end up with default priority settings and unrealistic SLA times. They tend to end up in the tail of outstanding tickets and constantly get mentioned in Breached Calls meetings. The request could be something as simple as “consider implementing a wireless network in the factory” or “carry out an audit of software on site”, but in reality will take some time to complete. Although you may prefer to have this on a spreadsheet or within a Microsoft Project file, the customer still wants to have visibility of the request with the helpdesk system. So do we convert it to a change request?
Comment by abowker — June 13, 2007 @ 8:17 am
I am that Steve – I have read with interest the 1st comment as this is the exact discussion (somewhat heated) about some of our calls. It is very difficult to be that black and white and wanting to use Serio as our main tool. The use of a “Project” category would be useful. Whilst not wanting to detract from proper project processes, it would be useful, for general information, to have knowledge of any projects within the section.
The mention of a time SLA for changes is also interesting as I have been advised not to have a time schedule that is not mentioned within our SLA’s for the company. The issue arrives that when I make an Incident into a change it takes 2 days to set the times of the new Change when you have to keep the mouse pressed down to set the various callback time etc.
Comment by herridges — June 14, 2007 @ 9:03 am
I liked this article George as we work in a similair way to what you have suggested and it is always nice to know you are on the right track. I am not too sure about abowker’s comment of adding a Projects category. Project management is something completely different and the ITIL books suggest this should be closely linked to change management, including processes to control programs and projects and allowing visibility to the customer. Quick requests (like a password reset) should be okay as incidents but any time consuming requests should be linked to or recorded as a change. It is one of the responsibilities of the incident manager to monitor for and action incidents that may breach and time consuming requests will be spotted during this task.
I was confused by what Steve is trying to say, the same general information would be available if the ticket raised was an incident or a change. Changes do not normally have a time schedule mentioned in the SLA’s as there is a need for scheduled implementation after the CAB has assessed importance and timescales. We also use Serio and any SLA completion times set on a change are decided by issue type or priority. I think Steve may be making an incident into a change without changing one of these which would keep the same (now unrealistic) SLA time as the incident – sorry if I have misunderstood Steve.
Comment by Russ — June 21, 2007 @ 4:44 pm