There has been a discussion thread on one of the LinkedIn groups recently on how many processes there are in ITIL, with various numbers being bandied about. The answer seems to be of greatest importance in the training field, where apparently some ATOs think it is a critical fact to teach.
Actually, the more one seeks to answer such questions by really reading the ITIL core books, the more one realizes how ITIL is riddled with inconsistencies. In the case of processes, perhaps the biggest issue is that the books contain a very specific definition of a process. I don’t have an issue with this definition – basically, a series of activities that transform inputs into outputs, initiated by a specific trigger, governed by a set of policies and requiring resources to perform the actions.
However I do struggle to find a representation of this in each of the so-called “processes” that are so glibly discussed in literature and training courses. Some are pretty straightforward; the change, event, incident and problem management ones spring readily to mind and simple process flow diagrams for these are included in the material. But others are not so straightforward.
What about Software Asset and Configuration Management? The Service Transition book describes a Configuration Activity Model (actually little changed from the original V1 book), with the key activities being Planning, Identification, Control, Status Accounting and Verification & Audit, and many training providers teach snappy acronyms and mnemonics to help delegates remember them. But is this a process in the same sense as the ones previously mentioned?
There will certainly be some process flows associated with some aspects of this model, e.g. Verification & Audit, where the process will be triggered either periodically or because of a particular reason. But once a Configuration Management System is operational, much of the activity involved with it will actually be actions that are part of other processes, e.g. interrogating and/or updating the CMS during the lifecycle of an incident, problem or change.
There other areas in the books that describe process flows, but don’t appear to label the activity as a process, or describe an activity, e.g. risk management, where there may be well be a process flow.
Training courses place much emphasis on differentiating between processes (change, release, event, capacity, etc) and functions (service desk, applications management); certainly at the foundation level, this appears to be considered vital. The LinkedIn discussion – which is by no means the only one of this nature that I have seen – would seem to reinforce this. In reality, there will be functions (in the ITIL sense) that represent most of the areas that are described as processes. Typically functions represent groups of people with responsibility for a range of activities, some of which may be steps in a process that spans several functions and is owned by a different function.
Indeed, read the following words from the Service Strategy book:
“Functions are often mistaken for processes. For example, there are misconceptions about Capacity Management being a service management process. First, Capacity Management is an organizational capability with specialized processes and work methods. Whether or not it is a function or a process depends entirely on organization design. It is a mistake to assume that Capacity Management can only be a process. It is possible to measure and control capacity and to determine whether it is adequate for a given purpose. Assuming that it is always a process with discrete countable outcomes can be an error.”
I understand that there is an urge to keep the messages simple and straightforward, particularly at the Foundation level where the MCQ style of testing tends towards things being “black or white” rather than in “shades of grey”. But wouldn’t it be wonderful if delegates were actually being taught about Service Management as a subject, with all its complexities and vagaries, rather than as a series of “facts” and definitions, many of which are dubious and not truly helpful in enabling organizations to deliver high quality services.
Even more beneficial would be if all the core books were explicit about the interplay between functions and processes, and that there was a common structure to each book and section that differentiated between real process flows and the myriad of activities, ad hoc or otherwise that surround a particular area. Maybe organizations would find it easier then to concentrate on developing the appropriate solution for their circumstances, rather than desperately trying to “Implement ITIL” and getting bogged down in trivial and irrelevant questions such as “the number of processes in ITIL”.
++++++++++++++++++++++++++++++++++++
Try substituting Service Management for the first word in the following!
Life it is not just a series of calculations and a sum total of statistics, it's about experience, it's about participation, it is something more complex and more interesting than what is obvious. Daniel Libeskind
Any feedback and comments are always welcome!!
---------------------------------------------------------------------------------
30th April 2010
Hi Aidan
I love this post.
I was over 20 years into my IT career when my best friend started to relentlessly badger me to learn about ITIL. I ignored him for a couple of years before finally heeding his advice. I quickly came to appreciate his certainty of its significance. My subsequent devotion to ITIL culminated in my serving as the 2008 President of the SF itSMF Chapter. I still participate on the fringes of the current board as I enter my 33rd year as an IT guy.
I love your post because I have lamented ITIL’s relationship with my beloved discipline of Process Management since the day I became foundation certified. I found it intriguingly ironic to encounter an incredibly process-centric framework that left me with the impression it couldn’t comfortably describe the meaning of process and process management.
Despite my impression I joined the ranks of itSMF USA because nothing this side of COBIT used the “p” word as much as ITIL. I felt my passion for process made it mandatory for me to embrace and participate in its mission.
I delivered a presentation at the itSMF USA Fusion ’07 National Conference, titled: “Ensuring Process Success.” It was, and still is, a what-is and how-to overview of process management – with absolutely no mention of ITIL, or IT for that matter. The objective I most wanted to achieve at the conference was to inspire the audience to go back to their jobs seeking an in-depth understanding of process management. I was certain the insights would enable my compatriots to take their ITIL balls and run with them. Some in the audience loved it and a few disliked it intensely.
In the months following I found it to be folly to create wide-spread interest in the discipline. Throughout my subsequent chapter presidency I failed to foster an appreciation for process mastery.
And so it goes – as you note of the Service Strategy book’s attempt to address mistaken perceptions of process. I don’t agree with their example. I submit that capacity management “can only be a process” when it is in reference to: “an organized group of related activities that together create a result of value to customers.”
The person waiting for the result of my “measuring and controlling capacity” so they can make decisions associated with those results is the customer of the process I followed to do the measuring and controlling. It may not be an ITIL Process, it may not be a significant process, but it is still a process. I cringed when I read that excerpt but it was assuaged by my appreciation of your considerations in regard to their “dubious definitions.”
Properly designed, thoughtfully implemented, passionately managed processes will always be the key to “delivering high quality services.” I will always believe in ITIL’s ability to help organizations meet that goal, but I will never turn to it to understand process.
Steve Romero,
IT Governance Evangelist
------------------------------------------------------------------------------------
25th May 2010
Hi Aidan
I believe that the deep thought group of authors of v3 determined that there are in fact 42 processes in ITIL, but felt that such a simple answer would be unacceptable to those looking for opportunities to discuss, argue, consult and/or teach. Indeed, for those who want to “implement ITIL”, the most important item missing from the v3 material is ‘what is the question?’ – and don’t say ‘it depends’. If ‘what is the question’ could be included in v3 (refreshed? reprinted? tidied-up?) or some later version, I think many of those who bought an ITIL, regardless of the price, and cranked the handle, will feel vindicated. Meanwhile, my suggestion to TSO to include “Don’t panic” on the cover of each book has been ignored – apparently such an addition might create uncertainty about the magic contained in the books which, in turn, may lead to reduced sales.
John Groom
---------------------------------------------------------------------------------
.gif)
