Home �   ITIL�  Index

What You Need to Know About "ITIL Compliant"

Nov 17, 2006

The IT Skeptic


Since ITIL is all about quality management, ask your vendor how their tool supports this out-of-the-box (OOTB)? For instance, how does it support determining targets? How does it measure and report improvement over time? Does it explicitly implement a Deming Cycle (Plan, Do, Check, Act) in the tool?

Service Management is nothing without Service Level Management. Regardless of whether it is a tool for Availability, Capacity, Service Desk, Configuration, whatever … ask them how it is SLA-aware and how it contributes to the monitoring and reporting of SLAs.

SLAs are multi-item written contracts. The contract defines who it is with, what period, who are the key people, what the vertical escalation path is. Each item can define support response times, time-to-repair, percentage availability, performance, resource usage, etc.

Setting a threshold time in which an Incident should be picked up or closed or whatever is not an SLA. It is one service level objective that might form part of an SLA if it could be defined on a per-customer basis. Do not allow vendors to redefine the term SLA to suit their own purposes.

SLAs relate to a service. This may seem obvious, but SLAs are not related to an asset or anything else: they define the levels for the service. One individual objective within an SLA might relate to a metric for an individual asset. SLAs don’t.

Does the tool support workflow? (Pretty odd if a process-compliant tool doesn’t). Does it come with the “standard” ITIL workflows (clearly flowcharted in the red book and blue book) pre-defined? How does the documentation explain implementing the tool in support of ITIL process?

Pretty much every one of the larger players provides services to implement their tool in an ITIL environment, but check what comes OOTB and what is in the manuals. If there is hardly a mention of ITIL then you know their service guys have the tough job of putting lipstick on a pig.

Does the tool consolidate information to a service view? Tools that cannot measure and communicate in terms of a service are not ITIL tools (though they can provide a foundation of data for ITIL tools).

For example, a monitoring tool should show current status of a service; a Service Desk should show current status of a service based on incidents, problems and changes; a Service Desk and/or SLA tool should provide historical reporting of consolidated availability information and cumulative statistics by service.

How many of their field implementation staff or partners have certification beyond ITIL Foundation? Foundation training is known in my part of the world as “sheep dipping." It is a basic process that everyone in IT operations should undergo. It provides just enough knowledge to be dangerous (I should know, being a Foundation practitioner himself).

If your organization is of any size or complexity, you probably want more highly trained people, although you should look at the broader skills and experience of the individuals involved. Nevertheless, their overall level of training is a good measure of their genuine commitment to ITIL.

The big vendors generally excel here. The small players often pay lip service. Or worse they have no field support at all beyond one product tech at the local distributor. ITIL is about process not tools: you need process people on the ground to help you implement it.

Specifically for Service Desks

Are Incident and Problem and Change all separate entities? (i.e., An Incident does not morph into a Problem: it spawns a Problem.) The Incident must continue to exist (and be resolved) as a distinct entity from the Problem. Changing the type of a record from Incident to Problem is not ITIL.

Do they provide Incident Matching OOTB? Incident Matching does not mean simple keyword searching—it is a clearly-defined ITIL process. (See the Service Support manual, page 102.)

Do they support Known Error and Workarounds as entities with associated workflow OOTB? Many tools have never heard of these. Some have them as categories of Problem, which is probably okay though strictly they should be another entity spawned from the Problem. Service Desk Level 1 staff need to be able to look for Known Errors and find the Workaround.

Do they assess impact and report it meaningfully? Displaying the CMDB tree in a pretty GUI is not impact assessment.

Finally, ask around. Many ITIL professionals will have additional important criteria from their own experience. If you have one you would like to add to the list, let me know at www.itskeptic.org. I would also love to hear your stories of the responses you got to some of the questions.

The IT Skeptic is an ITIL professional and active itSMF member who, for obvious reasons, prefers to remain anonymous. More thoughts from the IT Skeptic can be found at IT Skeptic.