What ITIL V3 means by Process

Since the release of ITIL version 3 (v3) there is much “Ding! Dong! The Process is dead!” but I don’t think so. There is a burgeoning market for third-party process charts for v3. Authors are interpreting the new “v3-speak” back into the process-centric frame of reference where most users are still comfortable. We just got over the wrench away from techno-centric towards process-centric with ITIL Version 2 (v2). Many people aren’t ready for service-centric yet.

While V3 certainly is trying to move away from process, there is still debate about just how many processes there are in v3. The five core books never say. The official introduction says 27. itSMF says 26. There are many more “functions” in v3 that v2 would probably have called a process. The v3 Qualification Scheme offers 35 "subject areas".

Originally an official v3 process model was promised (for example “ITIL Process Maps” worked on by Jeroen Bronkhorst of HP and Sharon Taylor, Chief Architect of ITIL, were in the June 2006 scoping of v3) but it seems to have quietly disappeared, or is at least taking a while. Quite a while. There is an unconfirmed rumour going around that they have quietly disppeared into TSO's ITIL Live website where you get to pay for them.

So, V3 is trying to bury the idea of process in favour of the new improved concept of service. ITIL has always only had a vague concept of what constitutes a process. ITIL authors have never felt constrained by the tighter definitions of “process” used by say process re-engineering or business analysis.

The ITIL V3 Glossary does define a process as:

"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."

The five core ITIL V3 books have a different definition of process (they all have alomost identical text in their introductory section):

"Processes are examples of closed-loop systems because they provide change and transformation towards a goal and utilize feedback for self-reinforcing and self-correction … "

The ITIL V3 core books go on to say that processes are measurable; that they deliver a specific result “individually identifiable and countable”; deliver their primary result to a customer; and respond to a specific trigger.

Amusingly four of the five core books go on to say that functions are often confused with processes and use capacity management as an example where “it is a mistake to assume that capacity management can only be a process … with discrete countable outcomes", whereas the one book that owns capacity management, Service Design, says nothing of the sort, and does not even mention capacity management in this introductory section.

Dissent amongst the ranks?

Squabbles aside, the definition in the glossary and the definition in the core books differ somewhat. What they have in common is that many of the 24 or 26 processes listed by the Official Introduction or by itSMF do not fit the definitions. A number of activities defined as processes do not fit well with the concept of a clear sequence of looping tasks that respond to a trigger to take inputs and turn them into countable outputs: IT financial management, service continuity management, configuration management, availability management, strategy generation, etc.

Let us accept that V2 was sloppy about what constitutes a process and used the word to label all the domains or functions or activity areas of ITIL. Despite brave attempts to introduce a crisper, more generally accepted usage of the word in v3, the historical legacy has lived on and the word still gets a rough ride. When ITIL talks about process, they mean defined people doing defined stuff in a defined area—nothing more. (Except in some instances where they mean a process.)


ITIL v3 Definition of process

You have to admire the ITIL books for their consistency (tongue firmly planted in cheek)...

I think the notion that a service is devoid of process is an empty argument. Isn't a service the "final output" of a process (or set of processes)? If it isn't, what is it? I have heard the argument that apps and technologies are services, and argue they themselves are not. It's the delivery, provisioning and support, as well as costing and adminstration of a technology that is the service (not a complete list)- ergo, a process if you want to measure and manage it.

Am I off base here?

Interface vs. implementation

No, you are not off base. Services, with few exceptions, are simply the inputs and outputs of processes.

In software engineering we are taught the differences between interface and implementation, white box testing and black box testing. Service vs. process is nothing more than that.

There is utility in getting folks to focus on the inputs & outputs as opposed to the internals. Value is experienced at the interface.

SOA is all about this. And the software engineering concepts of cohesion and coupling (the theoretical basis for distinguishing interface vs. implementation) are applicable to organizational operating models as well. Organizational capabilities that are tightly coupled to the internal procedures of other organizational capabilities are just as difficult to re-engineer as spaghetti code.

But raising it to the level of dogma is not advisable. Services can't exist without processes. And if you want to optimize the service (e.g. by identifiying & elevating constraints), you need to look @ its implementation.

And then there is the fractal problem - what if the process itself transcends any given service, because it is a long lived value stream invoking many services? This is why we have choreographies invoking services, which themselves may be lower level choreographies...

Yin & yang... microcosm & macrocosm...

Charles T. Betz

read the article "Functions and processes in IT management"

In the 2008 publication "IT Service Management - Global best Practices, Volume I" you can find the article that handles this topic in detail. It also provides a solution. It doesn't have to be 'your' solution, but I can promise you one thing: this solution works in practice - which is one thing ITIL never did.
The article describes how you can move away from traditional attempts to implement the ITIL reference model, and work with a universal implementation model instead. It finally puts things like "capacity management" and "security management" in its rightful place, and it solves the mystery of "how many processes are there in ITIL" - which actually is not an interesting question at all.

ITIL is just one of the available reference models, next to ASL ("how to rule the game from the position of an application manager"), BiSL ("what do I run into when trying to manage the customer's information infrastructure" - delivering the same kind of chaos ITIL did for Supply management), or MOF (read the cross-reference between MOF v4 and ITIL v3 and you'll understand the platform-independent value of MOF). Everyone agrees that ITIL cannot be implemented. If everybody would start doing the SAME, we might get somewhere....

The world isn't listening

There are a number of solutions to the weaknesses presented by ITIL. Yours is an excellent one. As an editor of that book I am aware of your article "Functions and Processes in IT Management".

But all these alternative solutions to ITIL suffer from one weakness - they are not ITIL. By about 2013 at the current rate we will have a million ITIL-certified practitioners. We already have over half that. Most sites are now at least aware of ITIL and most of THEM are adopting bits of it. The vast majority of them has no idea there exists an alternative, let alone what they might be. The world isn't listening. And they probably won't listen. They have their answer - time to worry about something else.

There are many frameworks - there is only one meme (so far): ITIL.

Something else will come along. But it won't be a better ITIL - no time for that and it would require critical thought and decision making. It will be something bigger that swallows ITIL, or just maybe renders ITSM irrelevant and forgotten.

Oh sure the alternatives will exist in niches where people do listen. COBIT might even rattle ITIL: if there is a contender I'd put my money on then COBIT is it, for the same reason that ITIL succeeeds: momentum, mass. But I believe ITIL will remain the 600lb gorilla for a few years yet.

Great ITSM thinkers like you, Jan, perform an essential service but replacing ITIL isn't it :) You are shaping the future whilst influencing the present.

@Alex: buy the book. It should be on every ITSM bookshelf.

you shouldn't replace ITIL

I haven't suggested to replace ITIL or any other reference model. These models contain value and should stay where they are. The solution lies in a very different direction.

By the way, we don't just write about it - we also bring this to practice. Once you understand where everybody went wrong for the last two decades, it's rather easy to find the right track - no magic involved, just forget you are an IT expert and start acting like a decently educated manager would. It's all based on a simplified and highly standardized approach that provides success where most other projects simply fail again and again. We're currently labeled 'the consultancy killer', so you'll understand we're not making too many new friends in the field ;-). But the customers, and the 'wiser' consultancy organizations who want to take a position higher in the value chain - they highly appreciate these new developments.

In the Netherlands, companies are now forgetting about ITIL V3 and turning to a much simpler and more effective solution instead. I hear the interest in ITIL V3 is dropping in other countries as well. This is exactly what we predicted early 2007: when companies have no clue how to make a success of V2, how would they ever be able to apply V3? V2 couldn't be implemented, V3 even less. Nevertheless, both versions contain a lot of value in terms of optional guidance. But you need a different solution to bring it to practice.


OK I'll re-read the article :) It is true that this industry changes fads like hairstyles, and interest in ITIL could wane fairly quickly, but I don't see it right now. We are indeed on the downward side of the hype curve but that isn't the same thing as terminal decline, it is just an adjustment on the road to mainstream adoption. And although ITIL has faddish aspects, this wave is a lot longer period than most IT fads. Perhaps the Netherlands acts as a bellwether for us, being as always out in front in this area.

the practice you refer to is ISM?

methods versus reference models

In general, the Dutch are very sober, simple and straightforward people. Don't bring us any hocus-pocus. Cut the crap. Etc.
And yes, I refer to ISM (tm) and also to FSM - a set of two management methods that complement eachother. They both cover one side of the Information Management domain in the SAME model.

I think it's important to understand the difference between a method and a reference model here. Copying from what I wrote in the MOF-ITIL Cross-Reference:

"First of all, the approach is important: the way the framework is perceiving reality, the elements that are taken into perspective, and their coherence. Second, the modeling technique is of interest: the way reality is described in tangible structures (for example, IDEF0 schemes, process flows, practice documentation). Another important consideration is the activation and implementation of the framework: the way the framework is deployed, (for example, adopt or adapt, incremental, phased, step-by-step, big-bang). Finally, the support structure is of interest: the automated instruments available to support the method, such as schemes, tools, documents, and templates."

Looking at this approach, you won't find much support to label ITIL as a 'method'. That's why we created a true method that scores on all of these considerations. It's simple to replicate that approach, so this is available to anyone who wants to step off the ITIL train because the destination no longer suits them. You simply take another train, re-use some of the wagons of the ITIL train as well as from MOF, COBIT, etc., and make sure the rails go in the right direction. No big deal.

a Disney diet

Yes as you know I awarded the Netherlands the Sagan Award this year for services to IT Skepticism.

Unfortunately other cultures raised on a Hollywood intellectual diet believe in magic, the ability to solve problems with a gun or other immediately effective technology, and the post-modernist idea that saying something is true makes it so.

So they want to buy an ITIL and fix the problem. Telling them they need to think about it, combine components from several sources, and craft a solution of their own doesn't go down well, as many consultants are finding around the world.

You are quite right: I just doubt whether the bulk of the IT community - or even the ITSM community - will ever understand that, or want to understand that.

Good thoughts

I couldn't agree more that the failings in IT management i have seen are never fixed by an ITIL implementation, in my opinion if an IT organisation was effectively managed; ITIL would be nothing new... just different words to describe what they were already doing. If an organisation is not being well managed no amount of ITIL adoptrion, implementation, new tools or consultants fees will fix that for very long, and infact it will probably make it worse.

in my humble opinion, ITIL is a good framework of language and basic "processes" to hang your organisation from, it's not fool proof and it won't protect you from yourself.


And thank you for the reading material and recommendations, I find myself putting down so many "ITIL/ITSM" books due to their sycophantic nature.

(hardly a surprise i ended up at this site)



I have looked a the link you mentioned to SAME, I think this is great stuff, simple, and real... do you have any other links to related material, I think you may have in fact written this paper?

plenty more

there's plenty more where this came from. It just hasn't all been published yet, and some of the published material is copyrighted so I can't simply provide it publicly. Most of it is all over the books my team produced with a huge team of experts, in the ITSM Library, a series of books previously published for the itSMF. I'm currently writing 'the ultimate book' on this subject, and a team of authors is writing a series of books on detailed topics, all in the same (SAME) architecture. These titles will be published by Van Haren Publishing, independently from any formal body.

There's one publicly available article I wrote for CEPIS/UPGRADE, titled "This is NOT Governance".
More relevant articles can be found on my company's website, but since that is all in Dutch, apart from one otyher article on the Process Management Matrix (PMM): here is a shortcut to an English translation of that article. It will tell you how to avoid one of the most common pitfalls when introducing process management ("failing to remove the responsibility from the previously responsible line manager, when introducing new process managers").

I'm occasionally bringing this message to the public at conferences. Next session will be at the itSMF Sweden conference in Gothenburg.

pitfalls need to be

Hi Jan, funny you mentioned pitfalls. I've several times warned companies for obvious pitfalls when trying to change/improve things. After these experiences I'm now convinced that it's no use warning them. They just have to fall in like a child that learns to walk ;-)

Also do not forget that we Dutch were one of the first to adopt ITIL. The maturity of a tyipcal Dutch company in terms of ITIL (and the like) is way beyond companies in other countries for instance in France (and for me that's not only due to language issues ;-) )

Syndicate content