Cobit / ITIL mapping

If you read a one paragraph sum-up of ITIL and COBIT (see below), it is clear that those two guys should have a lot in common. But are they really competing?

Well, I'd say they both provide very solid and valid views over the same problems.

When used together, the power of both approach is amplified.

A very interesting approach to dig here.

COBIT: Released as an IT process and control framework linking IT to business requirements, COBIT initially was used mainly by the assurance community in conjunction with business and IT process owners. With the addition of management guidelines in 2000, COBIT was used more frequently as a management framework, providing management tools, such as metrics and maturity models, to complement the control framework. With the release of COBIT 4.0 in 2005, it became a more complete IT governance framework. Incremental updates to COBIT 4.0 were made in 2007; they can be seen as a fine-tuning of the framework, not fundamental changes. The current version is COBIT 4.1.

ITIL v3: Released by the UK Office of Government Commerce (OGC), ITIL it is the most widely accepted approach to IT service management in the world. Version 3 consists of 27 detailed processes organized into five high-level processes described in five core books—Service Strategy, Service Design, Service Transition, Service Operation and Continual Service Improvement—that comprise one function: effective IT service management. In addition, ITIL v3 introduced the concept of the service life cycle and this is described in the book Official Introduction to the IT Service Lifecycle.
The mapping is performed in two layers. A high-level mapping compares the components of ITIL V3 with the components of COBIT and shows the coverage of IT governance focus areas.

a bad call?

Recently I read an interesting comment about calls and incidents: "From time to time, a consultant is in the position of explaining and justifying fundamentals. Recently I was describing how incidents are not the same thing as calls, that every call is not a new incident if the same user has already called about the same incident previously, that it is more effective to record the call history on the same incident. I went to three sources of "best practice" for support - there isn't any."

Well, well, well… this is what happens when mixing concepts and vocabulary.

First ITIL v3, makes it clear: all calls to the Service Desk are not incidents, service requests and RFC (Request For Changes) have their own process and do no longer follow the incident management route.

This being said, a server is down and you receive 20 calls. Which user will you ask to confirm that the service is restored? only one? the first one? all the users? all those who have complained? And what if the service is partially restored, operational for some but not for everybody? how do you know for sure all users are experiencing the same problem?

At this point, we are not talking about technology any more but communication.

There are different approaches and since there is no real common ground for ITIL, COBIT and ISO/CEI 2000, vendors choose to handle this "their way".

You'll see ITIL solutions where all SD calls reporting an incident are creating a ticket that will be related to a master incident.

You'll see solutions where you have no choice but to create one incident per call (if you want/need to log everything and handle resolution notification properly) without this "inheritance" concept.

As I always say, common sense should always supersede ITIL best practices.

Use your first callers to confirm the restoration of the service and the incident closure. Send all callers (or all users in certain cases) a notification about the incident and its resolution. Anyone who disagree can then reopen the incident, or open another one.

ITIL Design Guidelines

I recently discovered "ITIL Design Guidelines" and, you know me, started my reading on the Service Operations chapter.

I've read a lot of ITIL books in the past and I must admit I wish this one would have been my first.

I don't know for you, but for me, when I'm in a new playground, I'm looking for pragmatism; and that is all this paper is about, briefly describing the concept of using guidelines when designing ITIL services. It then presents a starter set of design

guidelines an 46 concrete examples that can be used by IT Service Management Implementation teams.

And the cherry on the cake, download it for free: http://www.itilversion3.com/