The IT Skeptic - Comments for "ITIL Version 3"

ITIL v3 - SLM compared to CSI

Matt Craig — Thu, 17 Jul 2008 15:18:56 +0000

At a high level, SLM objectives and activities seem almost the same as CSI - would anyone care to explain why and how these are distinct? Perhaps I look at SLM as broader in scope and objective than it is meant to be.

Super Users

Bordewijk — Wed, 06 Feb 2008 09:35:14 +0000

ITIL v3 (Service Operation 6.2.4.5) actually points out another element in 1st line Customer Service that should more often be considered: The Super User! This role is played by a user with more than avarage skill and experience with a particular information system. In your Incident Management process you will simply add these people to your list of 1st line agents (with the possibility to escalate) and make sure they register issues (incidents and knowledge) of interest for the other processes. Also, make sure they are invited to attend meetings with other 1st line agents. It may actually be more cost effective than implementing another Service Desk. And...don't be afraid to loose some control. You really don't need to know and influence everything that occurs in support of users...
In addition to ITIL, the Business information Services Library (BiSL) describes the Super User more clearly as an important role in user support.

Maarten Bordewijk
Getronics PinkRoccade

And other "activities"

Maarten Bordewijk — Thu, 17 Jan 2008 13:56:35 +0000

Yes certainly, Data & Information Management. I think that other "activities" in ITIL v3, such as Requirements Engineering (Service Design) and Managing Communications and Commitment (Service Transition), could also be implemented as processes in an IT Service Management Orgnazation.

Maarten Bordewijk
Getronics PinkRoccade NL

Why leave out Data & Information management?

Charles T. Betz — Mon, 07 Jan 2008 04:01:26 +0000

Why have all the counts to date left Data & Information Management out?

Given that "define the information architecture" is (PO2) the second Cobit objective (a good reason for restoring this process in ITIL), I think that it merits classification as an ITIL "process" (function, really, but that's another discussion).

Charles T. Betz
http://www.erp4it.com

COBIT Review Process

Robert Stroud — Sat, 29 Dec 2007 13:35:39 +0000

COBIT, the IT Governance framework, is developed according to a strict development process that is managed by the COBIT Steering Committee, which I am the current chair. Although going through an exhaustive review process for each component that includes both industry and subject matter expects, often with open public reviews, we realize that from time to time there are area's for further refinement. That’s one of the exiting aspects is like business and life, the framework is evolving (tell me the last time the laws of your country stayed the same for 6 months, let alone a year). For example, presently, based on feedback, we are currently embarking on a development effort to enhance our Application Controls, when complete, mid 2008, we will pass them through a review process prior with industry and domain experts prior to publication. The same is true for the COBIT 4.1 and ITIL V3 mapping which is currently being reviewed by an number of ITIL and COBIT industry representatives and should be published in the first quarter of 2008.

By the way, we are always looking for additional subject matter experts to comment and review.

Robert Stroud
Chair, COBIT Steering Committee

COBIT will have its day

skeptic — Sat, 29 Dec 2007 08:40:00 +0000

COBIT isn't being adopted or contemplated for adoption by over half the world's IT shops right now, like ITIL is. That's why ITIL gets the skeptical attention. COBIT will have its day and when it does, the IT Skeptic will be there commentating.

Substance abuse

Ltrzpo — Sat, 29 Dec 2007 02:59:04 +0000

I recently met one of the ITIL v3 authors. I asked him about this process v/s function debate. Asking not to be quoted he expressed his disappointment at the way ITIL v3 missed an opportunity to clarify this space. His view is consistent with what some of you have expressed here: that many of what are called processes in ITIL v2 and ITIL v3 are actually more like functions. However, the problem is that people are so used to the term "process" that it is hard to get them to stop using it loosely. It is almost out of habit that people refer to organizational capabilities as processes, even if they are functions. The Service Strategy book does stay away entirely from calling any of the capabilities either a process or function. It should be noted that nowhere in the book is any process defined. The four processes attributed to the book were defined elsewhere; not by the book or its authors. That is a good example of people looking for processes and finding them where they can. That's like substance abuse. Interesting that nobody questions COBIT for calling everything a process. Take a close look and apply the same logic to COBIT and many of what are called Processes are indeed functions. Somehow, COBIT is viewed in a more favorable light and therefore exempt from skepticism.

Re: Risk Management vs Problem management

vinodka — Sun, 18 Nov 2007 13:38:38 +0000

Jan and Charles,

I just happened to read this topic now - though it is a bit old one. It was a pretty interesting dialogue about Risk and Problem.

In the context of ITIL definition of Problem, I think you can clearly differentiate Risk and Problem - though there is clear overlap, as Charles pointed out.

In risk management, we look at 'known' threats and how to mitigate them (or manage them).
In Problem management, we are predominantly dealing with 'unknown' underlying cause (by definition).

I also tend to disagree here to the point here that once risk materials it becomes a problem.
If the risk materializes (in other words, threat manages to beat the mitigation/controls we have put in) , then it has an impact.

Most of the cases, a materialized risk creates an Incident (I am assuming we are talking about threats within the scope of "Normal Business conditions")- and Not directly a problem.
Because the threat ( and hence the cause) is some thing known.

Just an example - I am doing risk assessment and management on my services (say, as part of availability management). I identify Power failure in my server room as one of the risk and make counter measures against this risk/threat.
Even after these counter measures, if the risk materializes (both the power and UPS failed!) - then we have an incident in hand - and not a problem.
If the cause of this is obvious- then it just get resolved as a part of incident management itself.
If we are not sure why the UPS failed, (thus have some thing 'unknown'), then we go for problem management. And the objective of problem management will be to find 'why the countermeasure to risk failed'.

Does this make sense?

If yes, then there is a clear differentiation between Risk management and Problem management.

And even on a broader perspective, Risk management is a concept which is important from strategy to operations management - where as Problem management (of ITIL) is mainly coming in the operations stage.

Vinod

Don't think Service Desk - Think X-Desk!

Ian Clayton — Thu, 01 Nov 2007 15:34:35 +0000

Peter, Visitor - I'm not sure how many folks the visitor is thinking of training in any solution or for what reason - so we need tthe visitor to revisit and give us a little more background..... The reality is that ITIL has done an abysmal job on all things Service Desk. It has generally copy pasted its original and dated Help Desk philosophies into the new publications and failed to associate this key operation with designing support based upon requirements.

As you rightfully indicate Peter, it is not a matter of Help Desk or Service Desk - its all a matter of carefully designing the support each customer community, or customer needs, as part of each service they use. The support should be designed as part of the service design and may have to compensate for frailties in the service. This is by far the most efficient way to go as a service desk that 'hugs a customer' with a higher percentage of outbound to inbound calls, will likely cost 3x more money at the very least than a 'wait for the customer to call' driven Help Desk.

The plain fact is you may have some customers who don't want to be hugged and some that do, all dependent on the service and service feature in play. Its also a factor that you may not wish to spend money on certain customers. In our practice we try and dumb down this Help Desk or Service Desk question and use X-Desk to move the focus onto what support is required, what the service provider can afford, and not what organizational structure and broad brush strategy is in ITIL, or any other book.

These aspects, and the concept of service access points (points from which a service is designed to be accessed), all drive cost and how support is to be designed. Back to Visitor for a moment - what do your customers need?

Help desks, Service desks, definitions and so forth

Peter Brooks — Wed, 31 Oct 2007 17:16:37 +0000

That's a lot you're asking in a simple question!

For a Service Desk, the 'definitions and things' are actually pretty important. If different people in your organisation mean different things when they use the same words that leads to a lot of time wasted. It doesn't much matter what the definitions actually are, as long as everybody uses the same ones.

There are huge differences between the Service Management approach, and how parts of it are captured in ITIL, and the idea of a Help Desk. Many of the differences may seem indirect, and indeed they are. As a matter of experience, it is known (it would be nice to have real research into all this, and I hope we will help foster some of that in the not too distant future) that getting things to work for your Customers is a much bigger job than making a Help Desk work.

Service Management is a much bigger topic and shows how things like availability, capacity, financial and even event management can help you deliver a better service - these all support a Service Desk. Trying to create a Help Desk in isolation from all of that, without some Service Level and Configuration management (note: I didn't say CMDB...) is not going to work very well.

In short, give ITIL a whirl. Just now I personally would recommend that, for you, ITIL v2 foundations is more likely to be the ticket than v3, but that's just me, and just now, and for you. There is, of course, more to Service Management than just ITIL - but there should be quite enough for you to chew on given the brief sketch you give of your position.

I completed the HDI

Visitor — Wed, 31 Oct 2007 15:56:31 +0000

I completed the HDI (helpdesk international) certifications- which I think was a lot of "English" and not a bit useful. Theoretically the ideas are great, but similar to HDI, When I look at ITIL I think I see a lot of "definitions of terms" and stuff that no manager will spend time or money on.. yea i agree that it sounds nice to be "certified" but like someone said sometime ago, it reminds me of the "emperors new clothes"..no one will risk saying the truth

I have a mandate to get my org and all team members "certified" but your views can help me decide if there is a better alternative. Can someone guide me on how similar ITIL is when compared to HDI? Do write in to me..jollypj99@yahoo.com

BPM best practices

Charles T. Betz — Sun, 23 Sep 2007 19:00:27 +0000

The three references on BPM that I turn to are

Improving Performance: How to Manage the White Space in the Organization Chart by Geary Rummler and Alan Brache

Business Process Change: A Manager's Guide to Improving, Redesigning, and Automating Processes by Paul Harmon (also the editor of BPTrends)

Workflow Modeling: Tools for Process Improvement and Application Development by Patrick McDermott and Alec Sharp

All of them emphasize that a processs starts with an event, which is obscured in the ITIL definition.

Charles T. Betz
http://www.erp4it.com

process & function

jvbon — Sat, 22 Sep 2007 23:10:35 +0000

It's not so difficult and you can find your own answer. But there are many answers, and as usual they depend upon definitions used. So the crucial question to answer first is: 'what is a process?'
I've seen several definitions/perceptions of that.

If it's a loosely organized group of activities that are grouped because they serve some common goal, and you're not really interested in their interdependece, then you can work with the ITIL definitions, and you'll end up with something between 20 and 30 processes.

If it's a high-level definition, using lineair-organized workflow-like set of activities, then you may end up with no more than 6 processes for the entire ITIL domain. The rest of what is described there will then be functions using these processes.

If it's a more detailed definition based on the same approach, you will recognise some of these 'processes' to be in fact process groups. Like Configuration Management: if you look at that closely, it's just a set of 4 or 5 processes that are grouped together. This will lead to something like 10 processes.

So you see: there are many answers. And as long as you choose your own definition, and work straight ahead using that, you'll build a coherent system.

A question that would be interesting now, is 'what can we learn from other disciplines like BPM, and is the one approach "better" than the other?' Is there any of these approaches that would be able to gain the majority of the support in the field? If that would be so, then we may finally get some architecture in sight.

To get one step closer to answering your question, you may take a closer look at ITIL's definition of 'process', and then see what the consequence of that definition would be in terms of the scenarios above.
The official ITIL Glossary says: "A structured set of Activities designed to accomplish a specific Objective. A Process takes one or more defined inputs and turns them into defined outputs. A Process may include any of the Roles, responsibilities, tools and management Controls required to reliably deliver the outputs. A Process may define Policies, Standards, Guidelines, Activities, and Work Instructions if they are needed."
In the books you will find quite another definition of process.

Is there anyone who can explain what this means?
Is it the 'workflow string'? Or is it much wider, including organization and tools? Is there any 'best practice on process management' that can help us out here?

It's 24 processes for me!

deaf-llama — Sat, 22 Sep 2007 21:00:06 +0000

Rumagoso

You said
>At chapter 10 "The ITIL Service Management Model" there's a diagram showing the 47 >processes superimposed on the five Service Lifecycle phases (well, except for the >omnipresent Continual Service Improvement processes).

I assume you meant 27 processes, as shown in Fig 10.2 in the Official Introduction to the ITIL Service Lifecycle?

But there is an conflicting view in that same book, too.
Fig 10.6 shows "Basic Service Management Model process elements" and shows 29 processes.

However, to me, not all of these are actually processes. e.g Operations Management is shown. The Service Operations book makes it very clear this area called "Common Operations Management" is a set of Functions e.g. Service Desk, Technical Management, Applications Management, Operations Management.

In Fig 10.6 Technology Management is shown as a process in Service Operations; isn't that a Function, too?

Also 4 processes are shown in CSI as:
Service Measurement
Service Analysis
Service Reporting
Service Improvement

While I can see Service Improvement is a process, relying on the 7-step Service Improvement Model, I'm unhappy with the other 3.

Then again, there's conflicting information about Capacity Management:

Service Strategy p.26 says " there are misconceptions about Capacity Management being a Service Management process...whether or not it is a function or a process depends entirely on organisational design. It is a mistake to assume that Capacity Management can only be a process."

Service Design discusses it solely as a process in Chap 4.3, seemingly unaware of the SS viewpoint.

So I reduce the 29 to 24 processes.

Any views on this, fellow bloggers?

Theoretically, yes, but...

Charles T. Betz — Fri, 14 Sep 2007 21:45:54 +0000

It's not that I have a problem with the theory, it's just that when a risk is negligible, it's not a risk by my (admittedly operational) definition. Risk to me means that you have identified it as such and put it into a systematic process for managing it.

There are Incidents and Problems where, in hindsight, one might say "I wish I had managed that as a Risk." But one didn't. It happened. It's still not a risk because it's now been fixed and every expectation is that it really won't happen again.

A Known Error - now, as I think about it, I believe am OK with *that* equating to a Risk. We wouldn't be bothering to track it unless we thought it might happen again.

Charles T. Betz
http://www.erp4it.com

Not the only one...

kengon — Fri, 14 Sep 2007 15:31:34 +0000

Hi Christophe,

I wholeheartedly agree that BRM does get engaged throughout the lifecycle. I also think it's important to note that it's not the only component that shares this need. Security and quality are both good examples of themes that slices across the lifecycle.

I would assert that if you say you want to "design for x" (as in design for quality, performance, avaiability, etc.), you're examining a candidate that does indeed have a need to get engaged (at various points) along/throughout the lifecycle. Each will have needs that show up there somewhere.

There are other ways to apporach this that illustrate the relationship between these components and the lifecycle. A good rule of thumb I've always had has been "when in doubt, break it out". You can always stitch the connections between components together. Once you've created a monolith, it can be a real pain to break it apart and retain the qualities that appeared to hold it together.

kengon

BRM

Christophe De Boeck — Fri, 14 Sep 2007 12:52:53 +0000

just fyi: during a recent webinar (last wednesday) Sharon Taylor was asked the same thing about BRM and she answered that this "issue" arose when writing the books but that they had preferred to embed the idea in all five phases of the lifecycle. BRM should be part of each and every phase, and is not the subject of a separate process ...

[edit] I only realized it after posting this but now that Sharon is guest blogger here, she might confirm it here

too nice to quit

jvbon — Fri, 14 Sep 2007 09:47:56 +0000

Charles, it's not only fun, it's also important, since I guess we are contributing to a better interpretation of some core values in ITIL, Risk management, etc.
So I'll look into your example:
- a risk is based on severity and likelihood
- there is always a risk that hinges break and that doors will fall on your head
- the severity of that risk would be moderate and the likelihood extremely small BUT the risk would exist anyway
- now it happens tree times in 10 minutes: that would boost the factor 'likelyhood'!
- result: the risk that was way down at the Risk list, suddenly is very high on the same Risk list - and consequently you approach it... the same way you would approach it if you had called it a 'reactive problem'.

Can you agree to that?
Jan

Depends on the example

Charles T. Betz — Fri, 14 Sep 2007 01:58:16 +0000

Counter-example:

You've had a new house built. You go to open the door and it falls off the hinges. Your son opens the back door and it falls off the hinges and hits him on the head. You now have two Incidents and when the bathroom door falls off the hinges and breaks the mirror, you're beginning to suspect you have a Problem. The contractor was reputable and used a good brand of hinges; apparently, you just got a very bad batch - a completely unforeseen anomaly. In what way did you anticipate or manage this as a Risk? It moved through a reactive Problem lifecycle and was solved, and now that it's rectified, are you going to manage it as a Risk? You're not building another house any time soon. The Problem was never a Risk, so you cannot equate in the general case.

The full V2 definition of Incident starts with "an Event..." This means that something happened, some discrete state change that was notable. Risk management is not functionally dependent on state changes - anticipating state changes is part of its duties.

This has been a fun discussion even if we'll have to agree to disagree.

Respectfully,

Charles T. Betz
http://www.erp4it.com

Another take on the infamous 27 processes

Rumagoso — Tue, 11 Sep 2007 22:31:00 +0000

I've been reading with delight the risk/problem talk (and the previous process/function debate) and it does show that ITIL is not dealing with easy matters (at least we've got Charlie, Ian, Jan and Rob and many others tackling the beast).

Going back to my previous intermission, after reading the “The Official Introduction to the ITIL Service Lifecycle Book” from Sharon Taylor, I got myself counting again...

At chapter 10 "The ITIL Service Management Model" there's a diagram showing the 47 processes superimposed on the five Service Lifecycle phases (well, except for the omnipresent Continual Service Improvement processes).
(BTW, the book does a great job on introducing ITIL v3 - wish it had been published a few months back!).

Business Relationship Management is not there (so much for playing Nostradamus http://en.wikipedia.org/wiki/Nostradamus). Maybe I should have been more obscure like him (or quieter).

One thing puzzled me: There's a Service Operation entry called "Operation Management" (it does not look like a process)... Any thoughts or facts about this, anyone?

I've listed the 47 ones with another lengthy post here http://itilblues.wordpress.com/?p=46.

Be Well,
Rui