ITIL Version 3

On these pages you will find a summary of what the IT Skeptic knows about ITIL Version 3, kept up to date as facts unfold.
Note: the IT Skeptic isn't trying to sell you anything except my own books and the ads on these pages. Advice on anything else is impartial and not aligned with any vendor or organisation.

Some samples:

ITIL V3 2011 All about the new version: what we are not allowed to call ITIL V3.1
V3 certification All about ITIL V3 Certification / qualifications / training
free V3 exams ITIL Version 3 certification: eight sources of free ITIL V3 Foundation practice exams, and some ITIL Version 2 sources too!
V3 process list The IT Skeptic's Unofficial List of ITIL Version 3 Processes, cross referenced to all the sources
V2 to V3 diagram A visualisation of how ITIL Version 3 transforms ITIL version 2
Which V3 books? Which ITIL V3 books to buy and on what media?
V3 book errors 26 errors you need to know about in the ITIL Version 3 books
ITSM library for $211 How to assemble all the ITSM reference library you need for $211
Free V3 books How to refer to the ITIL V3 books online for free
Questions for ITIL vendors There are some obvious criteria for a reasonable person's definition of ITIL compliant. Here are some searching questions to ask your prospective tools vendor, from the IT Skeptic

or see all the page links to the right under "About",

or try these threads:
All about ITIL on this website
All about Version 3 on this website

If you found this post useful, and you are a Facebook user, please Like this blog :

Comments

Is there a definitive number of processes?

It is a pity that the books didn't include a definitive list of processes, apart from all of the core books (other than Service Strategy) having a Processes chapter.

I made it 23 processes, but I omitted the 7-step Improvement Process from the CSI book which I'm happy to include, so I agree: 24 processes.

But, I have some concerns about a few of these.

Firstly,
I think your list has "(Early) Support" in the wrong place as "Evaluation and Early Support".

The correction required, I think, is:
- Transition Planning and (early) Support (the ST book omits the "early")
- Evaluation (ST book section 6.4)

Secondly, Strategy Generation.
It is clearly a process but it does not formerly appear as a process name in any of the books other than on Fig 4.19 in the Service Strategy Book. (I globally searched for "strategy generation" in the advance electronic texts supplied to ATOs). However, The Strategy book (Chap. 4 Strategy) covers this.

Strategy Generation was used on a pre-launch presentation slide by Sharon Taylor, ITIL Chief Architect who authored the Strategy Book, so she should know!

Thirdly, Common Service Operations.
It's covered as Chap 5 of SO but the first paragraph says that Common Service Operation activities are "sometimes described as processes but in reality they are sets of specialised technical activities...".

Personally, I think the activities here: IT Operations, Mainframe Management, Server Management, Network management etc. are Functions. My view is supported by SO Chapter 6 and Fig 6.1 which says they are Service Management Functions. The Chief Architect had a process called Operation Management (note the singular)on her pre-launch slide which was mainly in the SO book. So, I assume this is the Common Service Operations?

Conclusion
----------
So, 24 processes. That makes COBIT's 34 processes now look a realistic number at last!

So why not,since the V2 processes are essentially unchanged in V3, stick with ITIL V2, add in ISO 17799/27001 (InfoSec)and PRINCE2 (ProjMan)and use COBIT instead.

Only 4 of COBIT's 34 processes are not mapped by the above frameworks and most organisations won't wish to implement all of COBIT's 34 processes anyway. COBIT has a solid approach to business alignment with its Business Goals mapping to IT Goals mapping to IT processes.

The cynic in me (I can't say sceptic, can I?), feels that maybe some motivation for V3 wasn't primarily as a "money-spinner" but was to ensure that COBIT didn't win the Framework's War. Time will tell.

Twenty Processes in ITIL V3 - According to ITIL?

After using the very latest in technological advances (reading the ITIL V3 sections that introduce the processes for each book), and avoiding the temptation to create processes from areas of the documentation where they are discussed, but not presented as an ITIL V3 sponsored process, I have found 20 definitive processes in ITIL V3. They are:

- Access Management
- Availability Management
- Capacity Management
- Evaluation
- Event Management
- Financial Management (aka Service Economics)
- Information Security Management
- Knowledge Management
- Problem Management
- Release and Deployment Management
- Request Fulfillment
- Service Asset and Configuration Management
- Service Catalog Management
- Service Continuity Management
- Service Level Management
- Service Portfolio Management
- Service Validation and Testing
- Supplier Management
- Transition Planning and Support

I have discounted the following 'processes' discussed in the Continual Service Improvement book:

- Business Questions for CSI (?)
- Return on Investment for CSI (?)
- Service Measurement (a candidate!)
- The 7-Step Process (more of a simple, well trodden methodology)

There are many missing when compared with the original 40+ offered by the 1980s IBM Information Systems Management Architecture (ISMA), no Business Relationship Management (sorry ISO 20000 fans), and no real emphasis of a number of Service Design sponsored candidates: Requirements Management, Data & Information Management, Application Management, Environmental Management.

Will the real list of ITIL V3 processes please take on step forward - anybody there from the refresh team?

Once we have the definitive list we can start to properly discuss how you "get the fish from the ocean to the table" through the Service Lifecycle......

Twenty Processes in ITIL V3 - According to ITIL??

Ian:

Great effort to start the discussion on what the 'official' 20 v3-processes are.

I have tried to read your list very carefully with great interest. However, for whatever reason, I failed to see "Change Management" and "Incident Management" in the list. I know for sure that these two processes have been identified as the 'core' v3-processes. In addition, how about "Demand Management"? It is not in your list as well.

What troubles me the most is that "Service Stragegy" has also been mentioned or implied as a 'core' v3 process in some discussions and documentations. However, it was not described as such in the book.

Now, we are back to the v3 landscape with more than 20 processes counted. The challenge to many remains as to what are the official 20 v3-processes.

27 processes and [not] counting...

I guess that when the Integrated ITIL Process Models by Jeroen Bronkhorst is published things will become clearer.
Anyway, giving it a try... After all it's an interesting topic (we keep going back to the underlying processes no matter what). Just beware it's lengthy.

On the white paper "ITIL V3: Get ready for the next chapter in service management" (from HP) one can read:
"For example, through the five books, 27 processes are defined"

It's note a quote, but from the context it seems to come from Jeroen. So, 27 is the number of processes counted for the ITIL Process Models.

Asssuming that number, by "reverse engineering" the ITIL v3 core books to see if 27 processes would come up I've got this:

Service Strategy (4)
• Service Strategy (it's called a process in the ITIL v3 Foundation official syllabus; some call it "Strategy Generation")
• Demand Management
• Service Portfolio Management
• Financial Management
Service Design (7)
• Supplier Management
• Service Catalog Management
• Information Security Management
• IT Service Continuity Management
• Capacity Management
• Availability Management
• Service Level Management
Service Strategy (7)
• Knowledge Management
• Evaluation
• Service Validation and Testing
• Transition Planning and Support
• Release and Deployment Management
• Service Asset and Configuration Management
• Change Management
Service Operation (5)
• Request Fulfillment
• Event Management
• Access Management
• Problem Management
• Incident Management
Continual Service Improvement (3)
• The 7-step Process
• Service Reporting
• Service Measurement

This gives a total of 26 processes, with some of them not being consensual due to insufficient explicit process formalisation within the ITIL v3 core books.

I'm guessing here that Business Relationship Management (BRM) is the one missing (again, I'm playing with the 27 processes assumption). There are some hints for this.
It appears defined as a process in the ITIL v3 core books glossaries (oddly enough, except for Service Strategy which defines BRM as... Business Relationship Manager).

BRM is mentioned in all books, although with variations.
Both Service Design and Service Transition refer BRM along with SLM. Service Design even calls BRM a process.
In Continual Service Improvement (page 161) again BRM is cited as a process.
Service Operation (page 183) implicitly states the BRM is a ITIL process:
"While ISO/IEC 20000 initially mapped to the prior Service Support and Service Delivery publications of ITIL, the
standard continues to map well to ITIL today and also covers IT Security, Business Relationship Management and
Supplier Management."

BRM is a ISO/IEC 20000 "Relationship Process" that is certainly not detailed on the ITIL v3 core books as the other 26 (as far as I could find, it only has a glossary definition and some references in the text) that should be included as a process (it's a good idea to have a process responsible for maintaining the relationship with the business...).

Naturally, it's more difficult to count processes with the two books that bring more news to ITIL (Service Strategy and Continual Service Improvement). It's still fresh.

BTW, the ITIL v3 Foundation official syllabus lists 20 processes that must be covered in the training (and it states that there are more. But not which ones. The ones left out are at least the 4 new Service Transition Processes. The others would be 2 new processes I've added above for Continual Service Improvement: Service Reporting and Service Measurement and Service Strategy's BRM):

05-1. Outline the four main activities in the Service Strategy process
• Define the market (SS 4.1)
• Develop the offerings (SS 4.2)
• Develop strategic assets (SS 4.3)
• Prepare for execution (SS 4.4)
05-2. State the objectives, basic concepts and roles for:
• Service Portfolio Management (SPM) (SS 5.3, 5.4, 11.2.1)
• Demand Management (SS 5.5)
• Financial Management (SS 5.1, 5.1.2)
Service Design
05-3. Explain the high level objectives, scope, basic concepts, process activities, key metrics (KPI’s), roles and challenges for:
• Service Level Management (SLM) (SD 4.2, 6.4.6, CSI 3.5, 4.6)
05-4. State the objectives, basic concepts and roles for:
• Service Catalogue Management (SD 4.1.1, 4.1.4, 6.4.5)
• Availability Management (SD 4.4.1, 4.4.4, 6.4.7)
• Information Security Management (ISM) (SD 4.6.1, 4.6.4, 6.4.10)
• Supplier Management (SD 4.7.1, 4.7.4, 6.4.11)
• Capacity Management (SD 4.3.1, 4.3.4, 6.4.9)
• IT Service Continuity Management (SD 4.5.1, 4.5.4, 6.4.8)
Service Transition
05-5. Explain the high level objectives, scope, basic concepts, process activities, key metrics, roles and challenges for:
• Change Management (ST 4.2, 6.3.2.4)
05-6. State the objectives, basic concepts and roles for:
• Service Asset and Configuration Management (SACM) (ST 4.3.1, 4.3.4, 6.3.2.4)
• Release and Deployment Management (ST 4.4.1, 4.4.4, 6.3.2.8, 6.3.2.9, 6.3.2.10)
Service Operation
05-7. Explain the high level objectives, scope, basic concepts, process activities, key metrics, roles and challenges for:
• Incident Management (SO 4.2, 6.6.6)
05-8. State the objectives, basic concepts and roles for:
• Event Management (SO 4.1.1, 4.1.4, 6.5.5)
• Request Fulfilment (SO 4.3.1, 4.3.4, 6.6.7)
• Problem Management (SO 4.4.1, 4.4.4, 6.6.8)
• Access Management (SO 4.5.1, 4.5.4, 6.6.9)
Continual Service Improvement
05-9. Explain the high level objectives, basic concepts, process activities, roles and metrics for:
• The 7 step improvement process (CSI 3.7.3, 4.1.1 6.1.1, 6.1.2, 6.1.3)

"ITIL V3: Get ready for the next chapter in service management"
http://h71028.www7.hp.com/ERC/downloads/4AA1-2729ENW.pdf

ITIL Foundation Certificate (v3) Syllabus
http://www.itsmf.org/files/ITIL_Foundation_Certificate_Syllabus_v[1].3.0.pdf

Be Well.

ITIL "processes" are functions, mostly.

I continue to be confused by ITIL's loose usage of the terms "process" versus "function."

Consider these quotes:

A business process is not just a random collection of activities – it meets certain precise criteria … A business process is a collection of interrelated work tasks, initiated in response to an event, that achieves a specific result for the customer of the process. (Alec Sharp/Patrick McDermott)

Business Process. At its most generic, any set of activities performed by a business that is initiated by an event, transforms information, materials or business commitments, and produces an output. (Paul Harmon)

Can someone explain to me in what sense Capacity Management is a "process"? Or Knowledge Management? What is a "Knowledge"? When am I done "managing" it? What event kicked that process off? Is there a consistent set of repeatable, measurable activities? How many of the ITIL processes listed above are truly event-driven?

The following, to me, are true process examples:

Resolve Incident/Problem
Execute Project
Implement Change
Fulfill Service Request
Complete Capacity Plan

(Note the avoidance of the vague verb "Manage" - when are you ever done "managing" something?)

I think most of the so-called ITIL "processes" look more like this:

A project team attempted to model the workflow for a major area they had improperly described as a single process – Supply Chain Management. …Because their scope actually included some five processes, it was impossible to express in a single diagram. There was no clear beginning point – there were many – and there was no clear ending point – there were many. It was impossible to trace a path (a workflow) through all of the included activities, especially because of timing issues. Some tasks were part of transaction-oriented processes that happened hundreds of times per day, other were part of ad hoc processes that occurred several times a month, and others still were monthly or quarterly….Moral: Too many Processes spoil the broth. (Alec Sharp/Pat McDermott)

These ITIL processes appear far more functional - steady state capabilities, each containing multiple different event streams, often perfomed by organizational units with the same name. Yet ITIL doesn't do well with the function/process distinction, originally by claiming that Help Desk was a "function" (and not recognizing the "Fulfill Service Request Process"), and now adding "Application Management," "Technical Management," and "Operations Management" as additional functions.

One of my criteria for "is something a function or not" is to ask the question, "could it be the name of an organization?" "Technical Management" does not in my view meet this criteria - I have never encountered a group by that name. I have encountered Operations Management groups and (more rarely) Application Management groups (named as such).

If there is an underlying method or ontology behind how ITIL has used the terminology of function versus process, I would love someone to explain it. My theory is that it is a non-rigorous mindset, loosely based on the business process re-engineering movement, in which everyone started to think "process good, function bad."

In my opinion, the BPM professionals get the last word here. Not the ITIL authors. The BPM folks I know who consult on ITIL work often pull their hair out over the terminological confusion. It might have been excusable in in v2; it is less so in v3, especially with the Service Strategy authors citing Rummler/Brache as references... the leading BPM authors of the last 15 years.

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

The crux of the matter

I do think this is a key point. I come from a systems audit background and for years I was pushing for a more process based approach to service management, but I came to believe that the reason many service management transformation projects fail when they came to the old service delivery "processes" was that there was no meaningful way to present, implement or operate them as workflow driven processes. I don't think v3 has got the distinction between function and process right, but I do think it is a move in the right direction. I'm less bothered by the theoretical view than the practical - trying to make something work.

Maybe ITIL V4 will cover this?

Charles: again something with 'hammer' and 'nail' and 'head' comes to mind...
The ITIL V2 was a complete mixup of processes and functions. In fact there were no more than 5 elementary processes or process groups described in ITIL V2 - the rest were functions, using these elementary processes. It was dangerous however, to explain this to an ITIL class because they might fail the test if they understood this...

You can understand how happy I was when I read the ITIL V3 core books and found the following:

"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 is always a process with discrete countable outcomes can be an error."

However - my hopes were killed immediately after. Unfortunately the authors forgot to take the consequence of this glimpse of understanding, and kept on describing many functions as if they were processes.

Of course this entirely depends upon the definition of 'process'. Most of this kind of problems have a semantic background and are caused by differences in definitions between people arguing about this. So let's have a look at what ITIL uses:
"Process: A structured set of Activities designed to accomplish a specific Objective."
This aligns to the generally accepted definitions of 'process'. The structure of a process is in fact a series of activities that are placed in a logical order. This flow is controlled by means of the control activities. These control activities make sure the operational activities are performed in time, in the right order, etc. (eg in the change management process it is always made sure that a test is performed before a release is taken into production and not afterwards). ITIL confirms this approach by adopting standard systems management principles.

So what would the consequence of the V3 glimpse be then?
I'd say: if Capacity Management indeed is a function, then Availability Management is a function, Security Management is a function, Continuity Management is a function, Financial Management is a function, etcetera.
Like any other kind of service organization, an IT service provider has only a very limited set of high frequency basic processes or process groups:
Four processes concern effectiveness:
a. You agree with your customer what you will deliver [contract management].
b. You deliver what you have agreed [operations management].
c. You repair anything that goes wrong [incident management].
d. You change your service if your customer wants another service [change management].
Two processes concern efficiency:
a. You know what you use to deliver your service with [configuration management].
b. You make sure you deliver tomorrow what you have agreed today at optimized conditions [planning & control].

You can now easily understand what these functions in fact do:
• Capacity management is a function that uses a set of basic processes:
− for realisation of the capacity of the agreed services at the agreed rate/demand, this function uses operations management
− for repairing capacity issues it uses incident management
− for changing capacities it uses change management
− for agreeing on capacity aspects it uses contract management
− for proactive actions of capacity issues it uses planning & control
− for the knowledge of which capacity carriers are deployed in which parts of the enterprise infrastructure it uses configuration management

And also
• Availability management is a function that uses a set of basic processes:
− for realisation of the availability of the agreed services at the agreed rate/demand, this function uses operations management
− for repairing availability issues it uses incident management
− for changing availability it uses change management
− for agreeing on availability aspects it uses contract management
− for proactive actions of availability issues it uses planning & control
− for the knowledge of which availability measures are deployed in which parts of the enterprise infrastructure it uses configuration management

We could go on:
• Security management is a function that uses a set of basic processes:.... etcetera.
Network management, data management, workload management, print management, knowledge management, etc. will now all be recognized as variations to the themes above.

Note: I quoted from the updated publication "IT Service Management - An Introduction", which is planned for launch at the itSMF USA conference, September 17.

As said before, it often is also possible to define functions as processes. But that would require descriptions in terms of logical sequences of activities, inputs and outputs, feedback mechanisms, etcetera, according to basic systems management theory (adopted in ITIL). The fact is that the functions listed above are not normally described in those terms, and that thus the function interpretation is most realistic.
Maybe ITIL V4 will cover this?
Best regards,
Jan

Empathy

hi Jan,

I had the same exact encounter with the "ray of hope" language, and then having my hopes dashed.

Your framework is intriguing and reflects a nicely rigorous point of view. I tend however to amalgamate demand and fulfillment processes into an overall value chain, e.g. contract + change + (operations including incident) = primary IT value chain, with the "efficiency" processes being the control/support processes. Didn't see risk management in your framework.

Do you see service request fulfillment as being purely about operations management?

Will you be in Charlotte?

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

risk is there

Charles,
the framework is published in the new ITSM title, and it does cover 'risk management'. But there are many names for the beast, so the book shows another one ('planning & control' - what's in a name). The mission of the process is the similar to risk though: "make sure, proactively, that you will be able to provide tomorrow the services that you agreed today, whatever will happen to your internal and external environment".
The 'framework' (too much honor for the simple process model) is rigorous; but it's also so simple that everyone will be able to explain it to their neighbour, five minutes after it has been explained to them. And it solves the entire process/function issue.

Service request fulfilment is just one interpretation of the generic operations management process. ITIL V3 shows a glimpse of understanding on the operations management process. Hopefully that will also be covered to its full potential in ITIL V4! I can recommend a very enlightning booklet on this topic: "Operations management - a new process". It's the only book I've ever seen or worked on, that provides a full description to a staged implementation of operations management as a process in ITSM - although IPW and ISM build on that process, it has only been described once (to my knowledge).

I'm sorry but my budget won't allow me a trip to Charlotte and I haven't found a sponsor yet.
And I have a nice one for you too: explain me the difference between Problem Management and Risk Management....
rgds
Jan

Risk is broad and shallow, Problem is narrow and deep

How's this?

Risk is broad and shallow, Problem is narrow and deep. Risk is about managing any threat external or internal, including problems; Problem is about fixing any fault in the service delivery mechanisms, usually internal. Risk encompasses security threats, Problem doesn't. Problem is expected to eliminate, Risk need only identify (responsibility for fixing may reside elsewhere).

Like it, and...

I think the thrust of Jan's question has to do with the proactive side of Problem. Risk is by definition an un-realized potential. Problem, in response to an Incident (e.g. root cause resolution) is unrelated to Risk. Problem in the proactive sense might be a specific response to a Risk. I would state idealized business rules this way:

1. A Problem may be either Incident-Based or Proactively Identified.
2. An Incident-Based Problem should be related to the originating Incident.
3. A Risk consists of Probability, Impact, and one or more Mitigation Strategies.
4. A Risk Mitigation Strategy may be related to (one or more) Proactively Identified Problems.

By relating Risk Mitigations to Proactively Identified Problems, we then leverage the Problem lifecycle and data structures, including the ability to bring in functional and hierachical escalation and understand the Problem/Risk activities with respect to their Configuration Items.

I could draw a data model and a process flow but it's dinner time.

Do I have a system that automates all this? No. But it's consistent with where I may be in 2 years.

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

Roles and Competencies

Charles, Jan

Good dialog. I am at an airport so will have to make time next week to add to your insights. Just a quick one before I board - the SMBOK uses the terms knowledge domains to represent roles, and knowledge areas to represent competencies or skills involved within a service provider organization. I have for too long faulted ITIL for its loose lips regarding the use of process and function. V3 rightfully describes the latter as an organizational unit and then liberally misuses the word process. My count of 'processes' in V3 would be more accurate and nearer 27 if I viewed them as competencies and not syllabus topics.

academic truth is not always practical

Charles,
as I said, this most likely will be matter of semantics. IF we want to find a solution for this, we should need to clarify the definitions and views we use.
I don't say that you can't come up with a set of definitions that are different, that's not the issue and that's not even difficult. So the difference will be true - but NOT practical.
I have decided to help my customers in another way; I have one overarching domain where all proactive management is concentrated. It covers risk and problem and can be applied to capacity, availability, security, continuity, and all other service quality parameters. This results in a lot of *functions* - just as many as the organizations and can handle.

I have not seen any of my customers master more than 5 processes, so I'm NOT going to bother them with structures that are built on academic truth but are very unpractical. It's great to KNOW what is behind the structures, but it's not necessary to share that with everyone. The knowledge provides you with great consulting strength, because you can always explain why you say something, and if they understand, you can explain it a layer deeper. But in the end, the average employee will not want to be bothered with a level of academic truth that has no meaning in his day-to-day practice.

So: we'll have to decide our view before we go on: do we discuss this as academics or as practitioners.
Jan

"Pracademic"

I won't be slotted into either category; I made a decision a long time ago not to pursue an academic career, but rather to work in the real world, keeping my eyes open and my brain active and my IEEE and ACM memberships current...

Over-generalization can be a problem. I think there's a case to be made that over-abstracting (which is what you may be at risk of doing by trying to generalize risk and problem) is a classic "ivory tower" mistake. For example, I have written elsewhere about the problems that stem from the overly-generalized ITIL concept of Change Management. On the other hand, if it works for you with your clients, more power to you.

One problem I have with combining the two is 100% practical: problem management as I have encountered it is generally confined to IT, while risk management is a higher level concern, crossing all aspects of the corporation, and rolling up to Chief Risk Officers. Many Risks are non-IT (e.g. the aggregated, quantified risk of a loan portfolio). I have worked with various kinds of risk management professionals and if I were to propose that somehow the Problem process was part of their world, I might be perceived as impractical.

And, Problems that stem from Incidents are not Risks. They have already been realized.

So, in the end, I would not consolidate the two terms; I would leave them distinct, but provide for some means for them to be related. I will be curious to see how this works out for you.

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

take a pracademic scope

I've been an academic researcher for a decade before I switched to IT management, maybe that still haunts me ;-)
I've read your blog on the CHM issue and posted a comment. It's not such a big problem. What people tend to forget all the time is that each system should be defined (and scoped) before analysing it. Once this system scope is defined, it's no problem to apply the reference model that ITIL is. if bob and gary (in your blog) would have used the same scope, they would have had no problem understanding eachother.

The crucial thing to do is to create an IMPLEMENTATION model and not use the REFERENCE model for the implementation. ITIL is a typical reference model, in all three versions. Btw - it always sayd so: "adopt and adapt", so if you take it for the bible you've only got yourself to blame.
ITIL is not only just a reference model, it is also a limited reference model since it is scoped to a specific domain: the information technology domain. That doesn't make it less valuable - on the contrary, once you understand this, you'll find it much easier to apply the elements of ITIL.
This ITIL scope, the information technology domain, is quite different from the information management domain. Read chapter 5 in the Introduction book and you'll see how that works. I'll post a white paper on the 3x3 matrix shortly, to introduce the ideas behind this.
On the problemXrisk issue; can you explain the difference between a problem and a risk if you use both WITHIN the same scope, i.e. the information technology domain?
rgds
Jan

Reference models & problem/risk

Hi Jan,

I come from a conceptual modeling background where language semantics are critically important; building in the frame of reference - the scope - is a big part of what we do there, in part through being very choosy about the language we use. It's why data modelers get a bad name, because we really do have long conversations about what the meaning of "is," is.

Rather than requiring people to consciously scope a frame of reference before they apply a framework, I would rather that we do all we can to more carefully scope the terms we use in these frameworks, so that words like "change," "service," and "configuration item" aren't perpetually causing confusion. This way, the framework's scope is intrinsic and correct application more likely.

For example, if ITIL v2 had simply distinguished between Change Management and Project Portfolio Management (aka Demand Management), there would have been less confusion in this regard, and no need for people to worry about scoping it.

The simplest, most abstract reference model in the world is an entity called "Thing" with a many to many relationship with itself. Anyone can use this reference model, but they need to be rather careful in "scoping it to a particular domain"... :-)

The interaction on my blog is not a theoretical scenario. I don't know who is or was "to blame"; neither the ITIL consultant, nor those who hired them, were at all precise about the frame of reference, quite the opposite. ITIL advocates in some cases have presented it more as a totalizing discourse, one that seeks to subsume a broader and broader scope in its purview (the opposite of careful domain scoping), and I have had concerns about this.

I am very curious to see your distinction between "information technology" and "information management." Does "information systems" fit into this scheme? Does ITIL have guidance on "information management" versus "information technology?"

Re: risk/problem within the scope of IT - is it not true that a risk by definition is potential, not actual? If I review the definitions for risk, they are all characterized by the use of terms such as "chance," "hazard," "potential," "possibility," etc. If it is realized, it is no longer a risk - it is an issue, occurrence, failure, case, exploit, breach, incident, problem, etc. And if a problem is the realization of a risk, it cannot also be a risk itself - because it is no longer potential, it is actual.

Cheers,

Charlie

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

synonyms until proven different

Semantics is crucial, even for others then data modelers ;-) Just think of the dramatic effect we have suffered from the bad definitions of incident, problem and service request in the ITIL books.
At this moment, we simply can't easily align all definitions because we all come from different positions and have different views, and consequently different frames of reference. Just think of the problems you yourself have when discussing CMDB issues with an ITSM expert that was trained in ITIL.

I will satisfy your curiosity soon I hope. I'm currently finishing a piece of work I've been working on since 1996: the 'ultimate' definitions scheme for IT management. This includes a vision layer with an end-to-end perspective that covers the domains of business management, information management and technology management, and a set of 2000+ definitions built on top of that. These definitions are derived from 100+ frameworks and standards, and have been developed as a consistent set. I have applied several very strict paradigms throughout this definitions list, resulting in a very logical structure. Terms like "information systems" are included of course, and you'll see a very clear and simple definition that builds on other definitions.

ITIL does not provide guidance on the "information management" domain - ITIL is about IT and the management of IT services. Thus, ITIL covers only the Technology domain. Once this domain is mastered, management attention will shift towards the environment of that domain, covering more ground. And that is exactly what has happened in the Netherlands. I've been publishing the work of thought leaders in that new domain since 1997, and it currently is THE hype in NL. As a consequence, the interest in ITIL V3 is relatively low: management is now taking an approach with a much wider scope than ITIL V3 is covering.

"a risk by definition is potential, not actual" => that also applies to a problem....
A problem *potentially* causes effects in terms of incidents but it may take a while before the very first incident happens - it may even never happen. It's quite easy to write a text on the effects of problems, using the terms "chance", "hazard", "potential", "possibility", etcetera. So - until you come up with a definition that is fundamentally different - risk and problem can be defined as synonyms. And as long as they are synonyms, the rest of your reasoning fails to apply. Please try again ;-)
jan

overlapping but not synonyms

"Just think of the problems you yourself have when discussing CMDB issues with an ITSM expert that was trained in ITIL."

Yes, just as a trained biologist would have problems with people who have been taught to believe in unicorns. ;-) I agree with Skeptic that the CMDB as defined by ITIL v2 was a mythical beast, a poorly considered attempt to define a tangible "system" that has caused much confusion. ITIL v3 is somewhat better.

I am not sure that ITIL v3 has absented itself from the "information management" domain but would have to see your framework. Is enterprise architecture part of your information management domain?

Also, in your master framework/glossary, are you using any conceptual modeling/ontology techniques to declare subtypes, relationships, etc?

Re: problem, we still have a failure to communicate.

A Problem may be a

- Potential Problem, or
- Actual Problem

(Think of them as subtypes. Still thinking about whether the subtypes are disjoint.)

A Potential Problem is a Risk - agreed. You can write your definition that way. But an Actual Problem cannot also be a Risk. It has crossed the line into actuality, and yet is still a Problem.

If I were creating an ontology, I would say that "Risk" and "Actual Problem" are disjoint, while "Risk" and "Potential Problem" may be a union - or at least have a large intersection. But since an "Actual Problem" is a full fledged subtype of Problem, you cannot say that Risk and Problem are a union.

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

Never seen a unicorn? Look harder...

If you really believe, you will find ;-)

The problems with the CMDB from V2 are mainly coming from people who take the books for true, instead of using them as a reference set. I've been responsible for configuration management teams for at least 6 years in practice, and know for sure that the ideas can be applied with great effect. It's what people do with it where it goes wrong.

ITIL has never touched the Information Management domain, apart from a small piece of release management in V2. But that was more of an accident than a deliberate action, I guess.

Enterprise architecture relates by definition to the enterprise, i.e. business, information and technology, so why would it be confined to any of these subdomains?

"A problem may be a potential problem".... OK - it's a Sunday afternoon, but still: you must be kidding. That would be a circular definition.
An what would "a potential problem" be then? Brrrrrr.

I define a problem as a "[ITIL term] Condition with an unknown underlying cause that may give rise to one or more incidents." Whether it has or has not caused any incidents in practice is a non-issue. And as soon as I know the cause of the condition, I call the problem a Known Error; the definition is slightly changed then: remove the word 'unknown' and you have it. I will then consider taking it away. 'Problem' is a term that received its current meaning in ITIL, quite different from what the Americans used to call a 'problem' before: their 'problem' was the ITIL 'incident'... A problem ticket was in fact an incident record... 'Risk' is not a term that is core to ITIL.
Now what about this term Risk? Is a risk a problem, or only a known error? Does a risk refer to a known cause (with a potential effect) or to an unknown cause?
And is it useful to solve this? Isn't 'risk' coming from an entirely different reference model? And may it - in the end - be a synonym to an ITIL Known Error? Or to an ITIL Problem?

Example: when I see a network engineer design a network and he projects the main line AND the back-up line in the same gutter, I recognise a chance that a building constructor comes along with a dragline and cuts both lines with one ditch. This constructor may NEVER come to that, but still....
So that would be a Risk... or a Problem, or a Known Error?
There is a chance of a bad effect (like with a risk). And there is a severity to the effect (like with a risk). But I know the cause if an incident would arise from it (i.e. the constructor does come along). You see: it's no use trying to define these as separate issues, because the reference views are different.

And I have another question for you: if a real effect comes from a risk in practice, is the risk then no longer a risk?

I guess it's all a matter of definitions. It always is.
jan

Really quite clear

Hi Jan,

I didn't say configuration management was mythical; it has a long and distinguished history, starting with (IIRC) blueprint management for complex industrial systems... it is the monolithic CMDB, attempting both enterprise and element configuration management (with service dependency monitoring thrown in for good measure) in one unitary system, that is (and will remain) non-existent.

The problem with your statement is that people in general are fairly concrete in outlook, so the errors resulting from taking ITIL v2 "for true" should not have been a surprise to anyone. It seems you are perilously close to saying, "ITIL is great, as long as no-one takes it seriously."

I would be very curious to hear more about how you have succeeded with configuration management. Has it been more in terms of managing critical parameters & controlling drift? Or has it been in terms of maintaining an enterprise inventory of configuration items with their dependencies, and leveraging this data to drive the enterprise change and incident/problem processes?

Re: problem & risk. I have my v2 CDs here at home, and v3 is at the office, so here goes in terms of v2. Hopefully these core semantics did not change that much with v3, which I am still reading.

First the v2 definitions we all are familiar with:

Incident: “any event which is not part of the standard operation of a service and which causes, or may cause, an interruption to, or a reduction in, the quality of that service.” Therefore, an Incident is an Event. It has transpired. It is not potential, it is actual.

Problem: "Unknown underlying cause of one or more Incidents." It is critical to note that the definition does not say, "zero or more." In the main definition, problems are functionally dependent on Incidents. You can not have a Problem without one or more Incidents, according to the definition.

But wait! - we have (in section 6.8) the contradictory concept of "Proactive Problem Management." If a Problem can be proactively identified, it must be that we can associate it with zero or more Incidents! So, there is a cardinality contradiction in the ITIL spec, germane to our discussion. (Not a surprise to this data analyst...)

Now when I have a cardinality contradiction that means that there are actually two entities in play; our original definition of Problem, and our new concept of Proactively Identified (i.e. Potential) Problem. It's a fairly common data modeling move to see them as both subtypes of the same supertype, which gives rise to this hierarchy:

A. Problem
--1. Actually Identified Problem, unknown cause of one or more actual Incidents
--2. Potential Problem, may not have caused any Incidents yet

Now Risk is universally defined in terms of potential. It may make reference to past occurences, but whether or not a Risk has actually transpired is not essential to its definition - we anticipate Risks all the time that have never (yet) occurred. This means that Risk has a strong affinity with Potential Problem. Is Risk an essential aspect of an Actually Identified Problem? Not necessarily. If we had never identified it as a Risk, had never quantified Impact * Likelihood, and there is no particular reason to do so even after it has transpired - then, in my mind, it is in no way a Risk, and you cannot equate.

Known Error I think is a red herring in this debate.

The crux of the matter is your question, "if a real effect comes from a risk in practice, is the risk then no longer a risk?" My answer is possibly - and this possibility is what prevents you from equating Risk with Problem. In some cases, the risk is no longer potential; it is now an event, problem, incident, charge-off, or what have you. Risk Management no longer applies, unless the Risk may continue to generate like Incidents.

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

Risk = Problem

Charles,
definitions have never been the strongest part of ITIL. In all three versions you will be able to find plenty of inconsistencies in the set.
On problem & risk:

If I live in England I am at risk of having my house flooded in periods of heavy rain. The fact that this Risk indeed happened to a large number of houses hasn't changed that risk. Some houses have escaped this RISK until now, but they are at risk of being hit this very autumn when the rains come again. Risk may be equal to Known Error here: you know what causes the flood. It's not even a Problem....
Risk actually means 'threat' in this case. Risk can also mean 'the chance of something to happen'. And you can even use both meanings in one sentence (see above; hint: look for the capital R).

In ITIL terms this situation contains both 'Problem types'.

If I see the main line and the back-up line in the same gutter and the contractor hasn't been around, then there is the risk that he ever will be. This is a 'potential problem' in your words, and I would also call that a Risk or a Known Error: I have seen the potential cause of something happening.

Even the V2 definition of 'incident' covers the risk aspect: ".... which causes, or may cause, an interruption....".

I would suggest that the most practical definition of 'problem' would include the '0' option: "A problem is a situation with an unknown cause that has lead, or may lead, to one or more incidents".
As soon as the cause is known, you'll have the Known Error and you can take some action.
Jan

Depends on the example

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

too nice to quit

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

Theoretically, yes, but...

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

risk/problem

That's a way to put it, but I prefer to disagree. "Broad", "shallow", "narrow", and "deep" are quantitative measures and they don't influence the qualitative definition in its basic character.
Just try to bring me two definitions that fundamentally differ ;-)
Jan

The Value Equation....?

Jan, Charles - I am a bit ditzy here after a long week but must say - IT is a service provider. We provide information system services. Those services help their users/buyers achive thei "desired results" for what we hope is an acceptable or affordable cost. The comparison between results achieved and cost of achievement is the universal basis for value assessment and at the core of the SMBOK speak.

This weeks workshops involving a number of experienced CIOs confirms the simple equation: value = results/cost.

IT is in the "information business" as expressed by Edward Van Schaik ex IBM and author of much that is now ITIL...the "GRANDFATHER OF ITSM".... We need to return in our discussions to that theme - how does what we do positively affect the 'value equation'? Am I making any sense....

Charles - what is your cell for next week - I will be on 858-688-0404

Re: Risk Management vs Problem management

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

the nail it has been smote square on the head

Indeed the nail it has been smote square on the head. Brilliant post Charles. We've discussed this before but you have indeed encapsulated the whole issue with this post.

Substance abuse

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.

COBIT will have its day

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.

COBIT Review Process

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

Another version of the list...

Rumagoso,

I've compiled a list of them as well and am writing a few bits on this. You can find it here:
http://www.symantec.com/enterprise/security_response/weblog/2007/09/the_...

Next weeks installment will have a mapping of the process areas to where some of the content can be found in the various books.

I'll give this a detailed look over, once I hit the post button. Will be interesting to compare and contrast.

Enjoy!
kengon

Another take on the infamous 27 processes

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

BRM

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

Not the only one...

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

It's 24 processes for me!

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?

process & function

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?

BPM best practices

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

Why leave out Data & Information management?

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

And other "activities"

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

I completed the HDI

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

Help desks, Service desks, definitions and so forth

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.

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

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?

Super Users

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

ITIL v3 - SLM compared to CSI

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.

Syndicate content