Blade Watch

In the olden days, the typical IT call logging system comprised of requests and incidents, the ‘change process’ came along for changes to production systems, then some companies brought in the problem request.

Defining what we mean by this on a simple level is important.  If a call is logged in correctly from the user viewpoint it might get closed or dealt with incorrectly, from the IT perspective, I might get fined for missing my SLA, my targets for resolving issues.

• An incident is a call that requires immediate attention, it is an in time call which stipulates the issue affecting a user and therefore requests it is fixed.

• The resolution time might be minutes for a business critical incident.

A request is a call that requests an action is performed, it might be important but the resolution time might be days or weeks.

• It might be something like a new share on the filer, or a new laptop for oncall, or even a server install.

A change is a request to change something, for example change the memory configuration in an application or upgrade a servers operating system.

• Changes usually only apply to production systems to monitor production and prevent unnecessary impact to the business users.

A problem tackles ongoing ‘problems’ issues that might get temporarily resolved but need fixed in the long term.

• For example the trading server needs rebooted every day at 8pm due to a memory leak. It’s got a temporary fix, to reboot it, but on a permanent basis we need support to resolve this with the application team if necessary.

How do you manage these different requests?
What is an acceptable time delay in resolving an issue?

They are equally important, but at the same time you want the support teams to focus on incidents, on keeping everything working first, then dealing with requests.

Related posts:

1. Due to organizational change, your call is in a queue I have always loved history. At university it was between...
2. Please end the email debates – life really is too short I had a chat with a service delivery manager who...
3. How to benchmark IT delivery part 2 The IT directors’ replies were as follows: Time taken to...
4. Complexity in the IT part 2 and why we can’t deliver In terms of process and delivery, there are so many...
5. Defining our support model is our business I’ve been speaking with Chris over the last few days...

Related posts brought to you by Yet Another Related Posts Plugin.