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.