On this blog I have posted many summaries of how even SMB managers can save time and money utilizing ITIL processes . This post is not one of those summaries, but a real world example of how “practicing what I preach” has just saved me an inordinate amount of time.

This is one small example – but scale this small example over time, and you begin to see where the time and productivity savings start to accrue.

The Incident

At my organization we use many of the same make and model of laptop computer. Approximately 6 months ago, one of these computers died. The symptoms were extreme corruption of the video screen and then a failure to boot up properly.

My home built Asset Management system told me that the unit was under warranty, So I called the vendors warranty support line.

The support issue lasted almost 2 weeks and took hours of my time, on phone calls, repair work and shipping;

* the support representatives shipped a new hard drive for the laptop. I had to remove the old drive, return it to the vendor, install the new drive, and start to reinstall the operating system. No luck – still dead – The operating system install died halfway through.

* they then shipped new memory (RAM) chips – I had to remove the old memory and install the new chips – Again no luck – still dead.

* Finally they sent a service technician to replace the Video Processor and Main Board – voila – it was actually the video board that was the problem

So the ITIL Incident Managememt Process has a “failure to boot” of that particular asset

The Problem Management Process documents that the Video Processor card was the culprit that caused that incident.

The Benefit?

I just had another laptop of the same Make and Model fail with the exact same symptoms. Will I have to repeat that 2 weeks and countless hours?

No!

I will be calling the Warranty support line again, but due to my documentation from the first incident and problem, I can reference that first “service Ticket” with the vendors support staff – we know what the fix will be.

They will still have to replace that video processor – but we will avoid the days and days of shipping new parts and hours on the support line.

Duuh Can’t you remember that?

Of course – I personally could remember that first incident – but the point is that regardless of your IT being supplied by a provider, or internally – anyone could avoid that wasted time and effort.

The Caveat

I have written in the ITIL summaries that the process of managing the ITIL framework can be the most difficult. If staff do not follow the framework, all the knowledge captured in that first incident and problem resolution is wasted if the second time it happens some tech just ignores the historical information and picks up the phone to repeat it all over again.

You can subscribe to this blog by clicking the RSS icon on the Home Page!

Advertisements

Parts 1 and 2 of this provided a quick overview of ITIL, and the basics of Configuration Management.

In this one, I will take the same overview of the ITIL Incident Management process. As stated in the earlier posts, all of the ITIL processes are tightly linked, as each process generally accepts information from, and provides information to the others. However pieces can be lifted and customized for your environment. As quoted in this CIO article;

All one has to do is purchase a set of ITIL books, and adopt whatever ITIL practices one wishes.

Again, the goal here is to demonstrate how the basics of ITIL can assist organizations of all sizes reduce costs.

Incident Management VS. Problem Management

The ITIL Incident Management process and Problem Management process can seem to be the “same” at first glance, however there are key differences.

Incidents are deviations from expected operations, and Problems are the root cause of those deviations.

Problem Management will be covered in a later post. However, as a non technical example, lets imagine that you are a distributor, and you have 15 customers that did not get their orders on time. That is 15 incidents, the issue was that your delivery truck broke down – that is the “problem” So in this case, one problem maps to 15 incidents.

In your technology infrastructure, Incidents are then any issues that provide a loss of service; “email not working”, “can’t print invoice”, etc. Larger organizations will most likely track these incidents through standard “Help Desk” type tools, in smaller organizations it can be as simple as a spreadsheet.

This tracking of incidents is the key point in the Incident Management process. whether you are a 10 person shop or 100. Ensure that someone is responsible for ensuring that these are documented. And that includes the typical “Oh wait while you are here, this has not been working…” type requests, these happen all the time.

Having these incidents, and their resolutions, documented will provide visibility into the IT service response you are receiving, either by your own staff, or by contracted staff. And provides improved monitoring of what was performed and why.

The Benfit

Documenting these incidents will have further benefit that I will describe in Problem Management, but on its own, you will have;

– visibility into the issues (incidents) that are ocurring
– reduced business impact through visibility into the timely resolution of incidents
– Better staff utilization through better coordination of effort
– Getting rid of incidents that are lost or “fall through the cracks”

A small business that I have previously referenced on my site, had gone through two outsourced IT services organizations and were on their third. The first two just “were not acceptable, … poor service” etc.

But like most small businesses, if someone had a problem, they called the provider, who then responded and was to take care of the problem, and then sent an invoice. However the “perception” was always negative. And without concrete information, neither they or their providers really have any evidence on way or the other.

My recommendation? Have one person responsible for the calls, document the issue (incident) and document when it was fixed.

The immediate benefit?

Was it fixed? – yes or no
Was it fixed quickly? – yes or no
was the number of incidents equal to what is appearing on that invoice? yes or no – and why?

The concept of these processes is very simple, the discipline required in ensuring that it happens is the hardest part.

UPDATE: Part 4 is now here:

You can subscribe to this blog by clicking the RSS icon on the Home Page!