ITSM or ITIL?

What is the difference between ITSM and ITIL? Is there any significant difference? What term should you use? Does it matter?

It matters because you need to know what it is you are talking about; otherwise, you can quickly get confused (I certainly can). Look at it this way: without it being specifically defined, we’ve been doing IT service management for as long as computers have been with us. Then, some 25 years ago, along came the IT Infrastructure Library, a documented framework to help us “do ITSM.” It’s also worth mentioning that there’s more than just ITIL in this ITSM picture. There are also “complementary frameworks” such as Control Objectives for Information and Related Technology (COBIT) or ISO/IEC 20000. I don’t want to scare you, so I’ll leave those for later.

While considering these weighty matters, I’m often asked whether ITIL should be pronounced “eye-till” or “it-ill.” There is no international standard way to pronounce ITIL, so the choice is yours.

Heritage of ITIL

I think heritage is a good word. It’s less threatening than history and implies something valuable. It’s helpful to your understanding of ITSM and ITIL to appreciate your inheritance.

Let’s start by chopping off the letters IT from ITSM and talk about service management. Service management (SM) has been going on for centuries. The medieval blacksmith was providing a service. His customers went to him (not many female blacksmiths then I think) because those customers didn’t have the skills, equipment, or time to make their own iron objects. They needed to achieve something—get their cart fixed perhaps—and they used the blacksmith’s services to do that. A successful medieval blacksmith would have had to make sure he was available when needed, had the right skills and equipment, and charged an acceptable rate for his work. If he was polite and dependable, that would be even better. Aren’t these principles still the same today?

Putting the letters IT back on brings us to the latter half of the 20th century when computers started appearing outside the science of ballistics and the murky world of code breaking; these were the early days of IBM computers and of Lyons’ Electronic Office (LEO).

Those were great times. To do IT we put on white coats and inhabited special air-conditioned rooms where strange machines whirred and clicked while lights blinked and line printers rattled. Computer people created a mystique about their profession, and lesser mortals were made to keep their distance.

That was all very well, but the idea of “service” never really entered people’s heads. Early computerization was mainly about automating previously manual tasks, such as accountancy and stock control, and achieving benefits in huge staff savings and through greater accuracy.

Then came the 1980s, with client-server architecture and PCs. Suddenly people who were not specially trained experts found themselves sitting at workstations interacting directly with the technology. Things were on the move. Mobile phones ceased to be the size and weight of a brick and could fit into people’s pockets. Home computing became unexceptional, and the World Wide Web transformed information management around the globe.

It was in this context that forward-thinking IT managers came together in the late 1980s to share their experiences of this changing world and to discuss the best ways of managing the new and rapidly changing infrastructure. The IT Infrastructure Library was born.

Version 1

Version 1 was the distillation of the wisdom of those hard-bitten, battered, and bruised IT managers. It was published as a series of actual, hard-copy books and covered ten specific processes. It was immediately a success because it provided a commonsense approach based on real-life experience. I well remember attending a presentation on the subject and undergoing a sense of deep revelation when the incident process was described—sad, but true!

Version 2

Valuable experience had been gained with version 1, so, around the year 2000, an update of ITIL was published. The concepts in the original 10 processes had proved their worth and were retained, and the Service Desk was introduced as a separate discipline. These 11 areas were grouped into 2 volumes: Service Support and Service Delivery. Additional volumes such as Planning to Implement Service Management and Applications Management were also published.

Despite its success, version 2 had its deficiencies.

•  It did not really help ITSM people to clearly articulate the great benefits of professional service management toward achieving business success.

•  Its relationships with program and project management were not clear.

•  It appeared to still have its emphasis on live operations.

Version 3

A major rewrite of ITIL led to version 3 being rolled out in 2007. Now there was the concept of the lifecycle. Extra processes were defined. The academics had their input. The result was ITIL very much as it is today. Some additional clarification was introduced in the 2011 version. This 2011 version is the one I’ll be talking about.

You might want to argue with me that all this background is unnecessary and that you could pass the exam without all this heritage stuff. Well, that’s absolutely true, but if you want to understand fully why ITIL is here and what it is for, you really need to know its provenance.

Beyond a Superficial Understanding of ITIL

To understand a subject fully, it’s going to take more than just some background information. I believe that if you have a clear grasp of a subject’s philosophy and principles, you’ll get a deeper understanding, a quicker understanding, and a better chance of success in the relevant exams.

Let’s clear up some common misunderstandings and get some clarity of what ITIL is really about.

Common Misapprehensions and Misconceptions About ITIL

A great number of people (even those who’ve had some ITIL training!) have some odd ideas. Let’s knock such ideas on the head at once. Here’s a list of what ITIL is not, despite common misconceptions to the contrary:

•  It is not a standard. There is no such thing as an ITIL standard. There is, however, a formal, international standard for ITSM. That standard is ISO/IEC 20000. By the way, ISO doesn’t mean International Standards Organization but International Organization for Standardization, and IEC means International Electro-technical Commission, so now you know.

•  It is not a method and not a methodology. Let’s not get caught up in the difference in meaning between method and methodology; suffice to say that ITIL is neither one nor the other.

•  It is not a list of compulsory actions. ITIL is not a cookbook with recipes for you to follow.

•  It is not a product you can implement. You can’t go out and buy ITIL. Of course, you can buy the books. You could even read them (not a bad idea!). You could buy a service management tool of some sort, and that may not be a bad idea either. But implementing the tool isn’t “implementing ITIL,” as you’ll be finding out later.

•  It is not a substitute for leadership. This should be obvious, but it’s worth making it clear.

•  It is not a substitute for management. There is always the risk that some people think you “do ITIL.” No you don’t. You “do” IT service management, and you can do it better by applying the ITIL best-practice framework.

•  It is not a substitute for proper supervision. It would be great if you read the ITIL books, understand them, and define and publish documented services and processes. But you’ll achieve nothing unless you not only have some people in appropriate roles to do the work but also can make sure that they are following those services and processes that you have defined. I’ll be mentioning this topic later in this chapter in the section “Maintaining Control Through Governance.”

•  It is not a magic solution to your service management challenges. I suspect you’ve probably got this point by now.

What ITIL Is

So, I hear you say, if ITIL is not any of those things, what is it? The answers to that question are as follows:

•  It is guidance. It is extremely valuable guidance of proven worth.

•  It is flexible. It is not a rigid set of compulsory actions.

•  It is a comprehensive framework. You can overlay it onto your service management arrangements. Doing that will help you identify what you’re doing well and what you’re not doing well.

•  It is a compendium of best practices. It was taken from a wide range of sources (I’ll be coming back to that later, too).

•  It is vendor-neutral. It is not a proprietary product owned by a Google or the Microsofts of this world. The copyright is owned by HM Queen Elizabeth II (not personally, but as Crown copyright). Everyone is at perfect liberty to adopt the ITIL framework and adapt it for their own use.

•  It is supported by a huge variety of software solutions and tools. I’ll be giving you some guidance on tool selection in Chapter 8.

The maxim you should never forget is “adopt and adapt.”

My Ten Commandments (What Is Compulsory in ITIL)

Earlier I was clearing up some common misapprehensions. While I was doing that, you may have been asking yourself how ITIL could be useful given that it’s not a specific list of detailed actions. That’s a good question. The answer is that while ITIL is not like a “cookbook” giving detailed instructions, it does require you to meet some challenging, compulsory managerial objectives. Please give me your full attention for my Ten Commandments.

I’m now putting on my most impressive patriarch’s voice (Morgan Freeman, beware!) and intoning, thou shalt have . . .

1. Clearly defined, agreed on, and documented roles and responsibilities

2. Clearly defined, agreed on, and documented services

3. Clearly defined, agreed on, and documented processes

4. Clear ownership of services and processes, as well as all other components of the infrastructure

5. Meaningful process and service metrics

6. Measurement of performance at the point of service delivery

7. Regular reviews of the performance of services and processes

8. Publication of reports on performance

9. A service improvement program

10. Clear communication between IT and users to establish and nurture trust between IT and the business

I’d ask you to note particularly that the word documented appears in the first three commandments. In the world of ITIL, we like documentation. Too many organizations have undocumented or poorly documented roles and responsibilities, as well as services and processes, and then they wonder why things aren’t working well.

Moreover, I’d like to believe that having all these ten good things is obviously sensible. Who wouldn’t want clearly defined, agreed on, and documented services? (So why haven’t you got them, then?) However, if all those things are so good, why do so many organizations fail to achieve them? That, of course, is a rhetorical question for which you can think of your own answers. This book will help you on the path to achieving them in your own area of responsibility.

The Three Axioms

Version 2 of ITIL presented three clear and simple objectives of service management. I find that these are three useful axioms to bear in mind when considering what ITIL is about.

•  Integration   To integrate IT and the business that it supports

•  Effectiveness   To drive up the quality of IT services

•  Efficiency   To drive down the cost of IT services

I was sorry that version 3 appears to have jettisoned them because I contend that they are as equally valid now as in the past.

Complementary Frameworks

Earlier I mentioned that there are complementary frameworks and promised to return to them later. I hope you’re glad that I keep my promises!

ITIL is not “precious about itself” in the way that some other frameworks and methods sometimes appear to be. Do Six Sigma black belts actually argue that adopting Six Sigma would remove hunger from the world and help England win the next World Cup? It sometimes feels to me that some of them do! ITIL is at the other end of that spectrum. It is a framework of “easy virtue”; it’s happy to become intimate with any other frameworks and methods where there is synergy.

Here is a selection of such frameworks and methods:

•  Agile

•  Balanced Scorecard

•  Business Information Services Library (BiSL)

•  Capability Maturity Model Integration (CMMI)

•  Control Objectives for IT (COBIT)

•  European Foundation for Quality Management (EFQM)

•  Frameworx

•  Quality Management Systems (ISO 9001)

•  Environmental Management Standards (ISO 14000)

•  Software Process Improvement and Capability Determination

•  ISO/IEC15504 (SPICE)

•  Information Technology—Security (ISO 27000 series)

•  Management of Risk (ISO 31000)

•  Corporate Governance of IT (ISO 38500)

•  Service Management System (ISO 20000)

•  Lean

•  Managing Successful Programmes (MSP)

•  Outsourcing Professional Body of Knowledge (OPBOK)

•  Project Management Body of Knowledge (PMBOK)

•  Project Management (PRINCE2)

•  Defect Reduction and Elimination (Six Sigma)

•  Enterprise Architecture (TOGAF)

“Best” Sounds Good, But What Does It Mean?

Having mentioned best practice a few times, it would be sensible to examine the term a bit more closely.

When ITIL version 3 first appeared, there was an argument that we shouldn’t use the term best practice because that implied it could never be improved. Proponents of that argument preferred the term good practice. I never subscribed to that point of view. I felt that such arguments were unhelpful and that most people knew perfectly well what best practice meant and that we should leave it at that. I’m glad that most of the world now takes the same view!

Unencumbered by these academic tussles, I hope we can agree that best practice means proven activities or processes that have been successfully used by multiple organizations.

The perceptive among you will see that I’ve sneaked in a formal definition here and there are many more definitions to come!

Best practice is derived from a fusion of sources and enablers, as shown in Figure 1-1.

Figure 1-1   Generating best practice

Sources of Best Practice

Figure 1-1 lists five sources:

•  Standards   The highest-quality sources and the most valuable are found in recognized standards, such as ISO/IEC 20000. International standards are published only after a rigorous process of drafting, examination, and peer review. You can’t do much better than an ISO standard as a source of best practice. Other “standards” may be useful, but you’ll need to check their quality carefully.

•  Industry practices   These are another potentially valuable source, but you’ll have to decide whether a particular industry’s practice is relevant to you. If your business is a finance institution, would you find the practices of the steel industry to be entirely appropriate? You should also examine the practices critically, perhaps doing some “compare and contrast” to determine whether what you’re seeing is actually the “best.”

•  Academic research   This can be a good source too; ITIL version 3 contains much useful stuff from the latest business research and management theory. However, you should bear in mind that most people are “doing ITIL” for practical purposes. You should be careful not to get diverted down an academic side road; remember that you may not be engaged in producing a master’s thesis. (However, if you are so engaged, don’t forget to take full account of ITIL.)

•  Training and education   This is what you’re doing now, and it can be a source because good ideas can come from classroom discussion, from course designers, and even from the authors of books!

•  Internal experience   Be careful here. While this is a potentially valuable source, internal experience may be misinformed, subjective, and based on misapprehensions. Check it out carefully. If it’s good stuff, make use of it; if it’s flawed, you’ve got something to put in your continual service improvement program!

Enablers of Best Practice

It’s all very well acquiring a heap of best practice, having it documented, and then having it assessed for quality and usefulness. But actually you’ve got to do something with it; you need to identify your enablers.

•  Employees   Ah, yes. These are the good people who turn up every day and actually do the job. Organizations may have a lot of automation, but somebody has got to run it.

•  Customers   These are the people for whose benefit you do all this ITSM using the ITIL framework. They are the ultimate enabler of best practice.

•  Suppliers   Your third-party contractors will probably have a crucial role as enablers, particularly if you’ve outsourced many of the components of your services.

•  Advisors   If you don’t already have the experience, skills, and training to adopt and adapt ITIL, it may be sensible to seek advice. Perhaps that means informally from user groups or forums, or you may invest in consultancy (those people who borrow your watch to tell you the time and forget to give you your watch back; again, they could also be the authors of books—beware!).

•  Technology   Today the market offers a veritable cornucopia of software solutions and tools to help you. But you need to take care over which ones you select. Will the “solution” that the salesperson is proposing actually be appropriate to your “problem”? Tools can be helpful, but if your services and processes are not clearly defined, agreed on, and documented (where have I heard that before?), a tool is not going to be of much use other than to highlight the poor state of your processes and services. I’ll be covering tool selection in Chapter 8.

Crucial Definitions in ITIL

Before you’re tempted to skip this bit because it looks like it could be boring, let me give you fair warning you that you’ll need to have all these definitions clear in your mind if you’re to understand fully the rest of this book and to pass your exam.

Since ITIL version 1 first appeared, one of its most valuable features has been the clear, unambiguous definitions it provides. Having such clarity means any argument you may have will be conducted on a sound basis (“What do we mean by incident as opposed to problem”?). You want to avoid the situation observed by Rev. Sydney Smith, who was strolling along a narrow street around 1800 with a colleague, when they heard two women leaning out of their opposite windows and screaming insults at each other. “These two ladies will never agree,” Smith said, as the debate raged over his head, “for they are arguing from different premises.” (That’s a story for the intellectual readership!)

Let’s get our premises defined.

Business

I’ve mentioned the word business many times already, and it’s vital to understand because in ITSM and ITIL it means more than just a commercial operation of some sort. Business is where the needs of the ultimate customer are being met (we hope). That ultimate customer could indeed be a commercial customer (someone receiving a social media service, for example), or they could equally be the customer of a government service (paying their taxes online, for example). Business covers both private- and public-sector enterprises.

Ownership

Ownership is crucial. Any application, service, piece of hardware, and so on, that’s not clearly owned by a nominated individual or group is nobody’s child and will be severely neglected, abused, and forgotten. Ownership can be defined as the act, state, or right of possessing something. My definition of an owner in ITIL terms is a nominated individual or group empowered to exercise accountability for a specific configuration item (CI). (I’ll define accountability and CI later—if you can wait that long. Please contain your excitement.)

Service

This is the most crucial of all crucial definitions. Take a deep breath, clear your brain, and read on.

There are numerous definitions of service. The official ITIL version 3 definition is that a service is a means of delivering value to customers by facilitating the outcomes customers want to achieve without the ownership of specific costs and risks.

When I first came across this definition, I confess I wasn’t too impressed; it seemed to be a lot of “management speak.” But I have warmed to it over the years as I have unpicked it to get at the underlying logic.

First, it’s about delivering value, delivering value to customers, and giving customers something that is worthwhile. You do that by “facilitating the outcomes customers want to achieve,” in other words, helping them do something they want.

So far so good, but what’s all this specific costs and risks bit? The crucial point here is in the word specific, which I interpret as meaning detailed. You accept that there has to be some level of cost and a risk when you receive a service, but as the recipient of that service, you don’t want to be concerned about all the specific detail behind it. Exercise 1-1 illustrates this point.

The famous business guru Peter Drucker says, “Quality in a product or service is not what the supplier puts in. It is what the customer gets out and is willing to pay for. A product [or service] is not quality because it is hard to make and costs a lot of money, as manufacturers typically believe. This is incompetence. Customers pay only for what is of use to them and gives them value. Nothing else constitutes quality.”

More Crucial Definitions in ITIL

No, I haven’t finished the list yet; here are some more.

Outcome

In the definition of service the term outcome is used, which is the result of carrying out an activity, following a process, or delivering an IT service. The term is used to refer to intended results, as well as to actual results.

Again, you don’t have to memorize this definition word for word, but make sure you can recognize the correct definition when you see it.

Service Management

Now we’re getting down to it! The definition of service management is as follows: a set of specialized organizational capabilities for providing value to customers in the form of services.

You can follow this rapidly with the following.

IT Service Management (ITSM)

ITIL defines IT service management as the implementation and management of quality IT services that meet the needs of the business. IT service management is performed by IT service providers through an appropriate mix of people, process, and information technology.

You have now reached a milestone in this book. I’ve defined IT service management. Please make sure you have these concepts and definitions firmly embedded in your mind before going further.

Service Providers

The previous definitions mentioned service providers. These are, surprisingly, people or organizations that provide services (“Is that really true?” I hear you ask me. Yes, it is!). Basically, IT service providers provide IT services to internal or external customers.

This couldn’t be much clearer. But note how customers can be internal or external. An internal IT department provides its services to internal customers; they are the business of which it is a part. On the other hand, an outsourced service provider’s customers will be external to it.

In fact, ITIL defines three types of service provider.

•  Type I   An internal service provider that is embedded within the business unit it serves. There may be several Type I service providers in a single, large organization.

•  Type II   An internal service provider whose services are shared among more than one business unit. A Type II service provider is also known as a Shared Service Unit.

•  Type III   Provides services to external customers.

I worked for six years for a company called Tradeteam, the United Kingdom’s largest drinks logistics company. The internal IT department was a Type I service provider for Tradeteam’s various depots and its head office. But Tradeteam was a joint venture between, at the time, Bass Brewers and Exel Logistics. Exel IT provided Tradeteam with its Internet and e-mail services; Exel IT was, thus, a Type II service provider to Tradeteam. Meanwhile, Tradeteam had a number of contractual relationships for services from the likes of BT and Computacenter; BT and Computacenter were, therefore, Type III service providers as far as Tradeteam was concerned.

Stakeholders

This is a book on management, so you may well have been wondering how long it would take before stakeholders got a mention. That time is now. In ITIL there are three generic types of stakeholder.

•  Customers These are the people or organizations that commission and, perhaps, pay for the service being provided. Customers are typically management-level people with whom service providers will have regular, formal review meetings.

•  Users (or end users) These are people who are having their business activities facilitated at that very moment by the IT services. These people will actually have their hands on a keyboard or grasping a radio data terminal that they are using. These could be accounts clerks or storekeepers, for example (or even the chief executive officer when sending a text message).

•  Suppliers This is nice and simple. A supplier is a third-party service provider (a Type III service provider). It is someone with whom you have a contractual relationship.

You mustn’t forget, of course, that everyone working within every type of service provider is also a stakeholder of some sort.

Process

You have now reached another significant moment. This is a definition as important as that of service. Please make absolutely sure you appreciate the difference between service and process. The ITIL defines a process as a set of coordinated activities combining resources and capabilities to produce an outcome that creates value for the customer.

The ingredients of a process can best be illustrated by the generic process model shown in Figure 1-2.

Figure 1-2   Generic process model

In the center of Figure 1-2 is the process itself, comprising a set of coordinated activities as mentioned in the formal definition, along with the procedures that tell the process practitioners what they actually need to do to perform the activity concerned.

When considering process, I find it useful to have in mind an example of a typical process, such as Incident Management. In Incident Management the set of coordinated activities include detection, reporting, logging, categorizing, prioritizing, investigating, diagnosing, fixing, and closing. There will be procedures for each of those activities, perhaps with detailed work instructions on, say, how to log an incident using the Service Desk tool.

You’ll need to specify who does what activity (this is where roles come in, which I’ll talk about later in the chapter) and to decide what you are going to measure so you can monitor the process, assess its efficiency and effectiveness, and make measureable improvements to it.

That’s all good stuff, but you need the wherewithal to make these activities happen. You must have process enablers. These fall under two headings: resources and capabilities. I’ll be discussing those in more detail in Chapter 3.

So far so good. You’ve got your process activities, and you’ve got your enablers. But whether anything actually happens at all, or happens in other than a chaotic way, is another matter. I hope you’ll agree that you need something to control what’s going on.

Let’s have a nominated owner to exercise authority and accountability. Let’s have some process documentation to show everyone who the owner is and to specify what the policy and objectives of the process are. Let’s receive feedback on how the process is performing.

ITIL also helps you to recognize a process when you see one by offering you four characteristics that every process has.

1. It responds to a specific event. Something happened that sets it off; there is a defined trigger.

2. It is measurable. Metrics should include such elements as performance, cost, quality, duration, and productivity.

3. It produces a specific result. The true value of the process is found here, and the result must be identifiable.

4. It delivers its result to a defined customer (or user) in a way that meets their expectations.

In ITIL version 3 you’ll be looking at 27 processes. However, you may be a little reassured to know that only 22 are in the ITIL Foundation exam syllabus.

Function

Just as you’re thinking you’ve got service and process clear in your mind, I now introduce the word function—it’s never-ending, isn’t it? The ITIL defines a function as a unit of organization specialized to perform certain types of work and responsible for specific outcomes.

Functions are the major building blocks of an organization. Functions are where the activities of processes are actually performed. One function can be involved in as many different processes as may be required.

As with process, when considering function, I find it useful to have in mind an example of one, such as the Service Desk. Most people can picture a Service Desk and many will have worked in one and will know that the Service Desk performs a lot of the activities specified in the Incident Management process and the Request Fulfillment process. However, these processes are not the exclusive preserve of the Service Desk; other functions get involved too.

Roles

Within functions there are people who have roles. I guess we’ve all had our own job descriptions/role profiles and so on. The ITIL defines a role as a position, responsibility, or duty within a process or function.

Taking the example of the service desk, typical roles are First Line Analyst, Team Supervisor, and Service Desk Manager. Most don’t find the concept of roles difficult, and I’m sure you won’t either.

This is a good moment to introduce you to four generic roles that are fundamental to ITIL: Service Owner, Process Owner, Process Manager, and Process Practitioner.

Service Owner

In ITSM this is, unsurprisingly, an important role, and one person can own more than one service. Picture yourself as a Service Owner (a senior manager, of course) with the following accountabilities and responsibilities, and you can feel a justified sense of importance!

•  Initiation, transition, and ongoing maintenance of the service

•  Prime customer contact for service-related issues

•  Ensuring service delivery meets customer requirements

•  Identifying service improvements and raising RFCs (these are requests for change; you’ll examine them further in Chapter 5).

•  Liaising with Process Owners throughout the service management lifecycle (this is a crucial relationship; Service Owners look to Process Owners to ensure their services are properly supported)

•  Effective reporting and monitoring

•  Accountable for the delivery of the service

Process Owner

Process Owner is another vital role (I’ll let Service Owners and Process Owners slug it out among themselves to decide which one’s more important). Again, one person can own more than one process. The role covers the following:

•  Initiation, transition, and ongoing maintenance of the process

•  Defining process strategy, policy, and standards

•  Assisting with process design (not necessarily actually designing it; you’ll have experts in process design who do it during the Design lifecycle stage—there’s a surprise!)

•  Ensuring process documentation is available and current

•  Auditing the process for efficiency, effectiveness, and compliance (as a Process Owner this makes sure you don’t get nasty surprises when the formal auditors appear)

•  Communicating information to ensure awareness (it’s no good moaning that people aren’t following the process if they don’t know it exists)

•  Provisioning resources and training (or telling the powers that be that resources and training are essential or process benefits won’t happen)

•  Providing input to service improvement programs

Process Manager

Come again? Isn’t this role the same as Process Owner? Well, in a small organization it may be, but there can be advantages in having separate roles. For example, some organizations make the Service Desk Manager the owner of the Incident Management Process. That may not be such a good idea because functions other than the Service Desk get involved in Incident Management and the Service Desk Manager may not be sufficiently empowered to act as the owner of the whole process. Specialist teams may view the Service Desk Manager as being less important than they are, and they may be reluctant to give incident investigation and diagnosis the priority it demands. However, if someone on the IT executive team is the owner of the process, that is less likely to occur. The Service Desk Manager could then be effective as the Process Manager, reporting to the Process Owner, and would have the clout necessary for the role. As manager of the Incident Process, the Service Desk Manager could then happily do the following:

•  Help to plan and coordinate activities (processes are a set of coordinated activities, aren’t they?)

•  Ensure all activities are carried out as required

•  Appoint people to the required roles

•  Manage resources assigned to the process (it’s the Process Owner’s responsibility to get the resources)

•  Help ensure the smooth running of services (yes, processes underpin services)

•  Monitor and report on process performance

•  Identify improvement opportunities

•  Help prioritize improvements in the CSI register (the CSI register is essentially a huge “to-do” list)

•  Make improvements to the process implementation (in other words, providing guidance and training to practitioners within the process in order to create new capabilities by achieving heightened conformance to the process, including accurate and complete documentation and the effective use of tools)

Process Practitioner

At last you’ve come to those who actually do the work in the process. Their good work covers the following:

•  Carrying out one or more activities of the process

•  Working with other stakeholders to ensure that all contributions to the process are effective

•  Ensuring that inputs, outputs, and interfaces for their activities are correct

•  Creating or updating records to show that activities have been carried out correctly

Getting Organized the ITIL Way

There is no model, ITIL-style organization. ITIL does not say what your organization should look like, but it does provide some useful guidance. Each Chapter 6 in the five main ITIL books is titled Organizing for…, and therein you’ll find a number of roles, each with a detailed list of responsibilities. Now, this doesn’t mean you need to have one person, and one person only, for each role. Roles can be combined within one position. But it can be useful to go through each of the responsibilities listed and ask yourself, “Whose responsibility is that in my organization?” If it’s not clear, get it clarified. If it’s covered by two or more people, you may already be having a turf war or you’re risking one, or each may think the other is doing it, so things are falling through the gap between them. Of course, if it’s not covered, you’ve got a black hole into which things will probably be disappearing.

A good way to get these risks under control is to create a RACI matrix (some pronounce this “rakki,” and others say “ray-see”; I prefer the latter as I’ve always thought of myself as a racy type). RACI stands for Responsible, Accountable, Consulted, and Informed, and you can create RACI matrices at various organizational levels as best suited to your needs. In fact, you could have a whole set of hierarchical RACI matrices. But for these purposes, let’s keep it simple for the time being.

Figure 1-3 gives an example of a simplified RACI matrix. This is for my favorite process, the Incident Management Process.

Figure 1-3   Example RACI matrix

Across the top you see some roles listed and down the left are some activities in the process. In the appropriate cells the letters R, A, C, and I appear either singly or in combination. Cells can be blank if appropriate. So, let’s look at the activity Detect. It is the responsibility of the End User to detect failure and to inform the Service Desk. The Support Manager (whoever that may be in this example) is accountable for this activity taking place properly.

Turning to the next activity, Log, that is the responsibility of the Service Desk Analyst, who should consult the End User when doing so (all pretty reasonable?). The Service Desk Manager is accountable for this activity taking place properly.

The next activity is Categorize, which is a bit more complicated. The Service Desk Analyst retains responsibility for doing this and must continue to consult the End User, but now the Service Desk Manager and the Support Technician need to be told what’s going on.

And so it continues. The most important point to remember (in addition to what the letters RACI mean) is that for any one activity many can have responsibilities, many can be consulted, and many can be informed, but only one person can be accountable. For example, a football team has 11 players, each with their specific responsibilities, but it is the team coach or manager whose head is on the line. If the team doesn’t perform, they’re the one who has to go!

The other point to remember about RACI is that it provides the linkage between the roles, the levels of responsibility, and the authority assigned to each role that is involved in carrying out the activities of a process.

Maintaining Control Through Governance

ITIL is not a substitute for leadership, management, and proper supervision. I hope you remember that from the list of common misapprehensions I gave earlier this chapter. The point is that no matter how splendidly your services and processes have been negotiated, agreed on, and documented, if nobody pays the slightest attention to them, it will have been a waste of time and effort. Equally, in the world of management, we have to deal with human beings with all their quirks and foibles. Do resources tend to go only to whoever shouts the loudest? Do you have a “queen bee” who demands priority over everything and everybody else?

The antidote to this distortion is governance. Good governance is about ensuring fairness and transparency, ensuring that it is the business need that determines who gets what, how much, and when they get it. Governance ensures that we focus on conformance and compliance, especially compliance to legislative requirements (Sarbanes-Oxley, Freedom of Information, Data Protection, and so on) and to business performance imperatives. The aims must be to meet audit requirements and to use your resources to maximize the creation of value to the business.

Risk

The management of risk is mentioned several times throughout ITIL, and risk management is a whole area of study for you to pursue if you want. However, for the immediate purposes, I can keep things simple.

Risk can be defined as “uncertainty of outcome.” Things might turn out better than you expected; equally they could turn out worse. In essence, there are three activities in risk management.

•  Identify   Before you can start any clever risk management stuff, you have to identify as clearly as you can any areas of risk. This is the essential work to do at the outset.

•  Analyze   Now you ask some pertinent questions. What is this risk about? Define it. How vulnerable are you to this defined, perceived risk? What would the impact be if the risk materialized, and how likely are those circumstances to occur?

•  Manage   Once you’ve identified and analyzed a risk, you can then decide what to do about it. There are four basic approaches you can take.

•  Accept   If there is little or nothing you can do about it or if the likelihood of the risk becoming real is remote and the impact minor, you can decide to accept the risk. For example, there is a risk of an asteroid hitting the earth and destroying all life. However, the likelihood is remote and, outside of science-fiction movies, there’s little you can do about it other than accept it. Accept, however, is not a permissible approach just because you can’t be bothered or would prefer to ignore the risk (politicians: take note).

•  Avoid   If you don’t have to take the risk, don’t. Take an alternative course of action. You may decide to stick with a conventional solution rather than go for a cutting-edge high-risk option.

•  Mitigate   You may not be able to eliminate risk entirely, but you may be able to take action to reduce risk to an acceptable level. You do this when you build in resilience by duplicating data circuits, for example. Moreover, you could develop a contingency plan that would help reduce the impact if the risk still came to pass.

•  Transfer   This may be an attractive option. Let’s outsource the data center and make it someone else’s problem. However, you may end up replacing one risk with another. When you outsource your data center, you may be putting it into the hands of people for whom it is their core business, but you will be relinquishing some management control over it. You’ll need to be careful of what is and what is not covered by the contract. Your service provider will know what’s in the contract and what’s not!

Tools

Tools are sometimes touted by smooth-talking sales reps as the answer to everything: “Buy my new shiny gizmo; feel its fabulous functionality!” Also, be careful if your chief executive officer has been let loose alone at an exhibition where the latest toys are on sale!

If you haven’t got the fundamentals right, the best you can hope to get from a tool is the ability to do the wrong things faster; that may not be a huge advantage.

However, having use of an appropriate, integrated ITSM tool will substantially enhance the value of your carefully negotiated, agreed on, and documented services and processes. As a general rule, ITIL sees tools as being extremely useful. Tools help achieve consistency, accuracy, efficiency, and the ability to capture valuable evidence to support service improvement initiatives. In due course you’ll look specifically at how tools can help in every lifecycle stage, but don’t forget: “A fool with a tool is still a fool.”

Chapter Review

You discovered that the IT Infrastructure Library is a well-proven compendium of best practices based on real-world experience backed up by academic research and peer review. You now appreciate that ITIL is neither an international standard nor a strict methodology but instead is a valuable approach to managing IT services. ITIL works well in conjunction with other complementary frameworks such as ISO/IEC 20000, Six Sigma, COBIT, and so on.

Effective service managers use ITIL to guide them in their job. Everything they do is based on the ITIL philosophy of integration with the business, driving up quality and driving down cost while delivering value to customers. Their success is dependent on understanding ITIL fully, adopting the ITIL guidance, and adapting it to suit the needs of the business they are part of.

A full understanding of ITIL is founded on the acceptance of some crucial definitions for the words service, service management, process, function, and role. You must have a clear view of what I mean by words such as business, ownership, service provider, stakeholder, governance, and risk.

Service providers should organize themselves based on the concept of good governance and the services and processes they have designed, using RACI matrices to show roles and responsibilities and their interdependencies.

Service managers should be alert to the need to manage risk and to ensure they make the fullest possible use of service management tools. Ideally all organizations should have use of an up-to-date integrated IT service management tool offering rich functionality and ease of use alongside excellent vendor support and future flexibility.

Quick Review

Here are the key concepts and terms you encountered in this chapter. Read through this list; if anything seems unfamiliar or you can’t readily define it, go back and read the relevant section again.

•  Best practice: sources and enablers

•  ITIL

•  Complementary frameworks

•  Service, process, function, roles

•  RACI

•  Service Owner role

•  Process Owner, Process Manager, Process Practitioner roles

•  Service provider types

•  Customers, users (end users), suppliers

•  Governance

•  Risk

Questions

The following seven questions are typical examples of what you’ll encounter in the ITIL Foundation exam. At this stage questions come from a comparatively limited range of concepts. The questions that come later in this book will be chosen from an increasingly broader source.

There is only one correct answer to each question. You’ll also notice that some questions are simple multiple choice, while others are more complex, offering you four permutations. Enjoy!

1.  What is the purpose of the RACI model?

A.  To define the requirements for a new service

B.  To analyze the impact of a new process

C.  To indicate the main areas of risk

D.  To document the roles and responsibilities of relevant stakeholders in an activity

2.  Which role should ensure that process documentation is kept up-to-date?

A.  The Customer’s Representative

B.  The Service Desk Manager

C.  The Service Owner

D.  The Process Owner

3.  Which of the following are characteristics of every process?

i.  It is measurable.

ii.  It has a defined trigger.

iii.  It delivers a specific result.

iv.  It delivers its result to a specific user/customer.

A.  i and iii only

B.  i and ii only

C.  ii and iii only

D.  All of the above

4.  Which of the following statements is most correct?

A.  The best service should be given to the customer who pays the most money.

B.  Internal customers should receive the best service because they are part of the same business unit as the service provider.

C.  Internal and external customers should receive the level of customer service that has been agreed on.

D.  External customers should receive better customer service because they are always paying for it.

5.  Which of the following are characteristics that contribute to ITIL’s success?

i.  It is nonprescriptive.

ii.  It is best practice.

iii.  It is nonproprietary.

iv.  It is a standard.

A.  iii only

B.  i, ii, and iii only

C.  ii, iii, and iv only

D.  All of the above

6.  Which of the following statements is correct for all processes?

A.  They define functions.

B.  They are performed by an external service provider.

C.  They help customers avoid specific costs and risks.

D.  They deliver specific results to specified stakeholders.

7.  Which of the following could be identified as stakeholders when considering IT service management?

i.  Functions

ii.  Customers

iii.  Service owners

iv.  End users

A.  iii only

B.  i, ii, and iii only

C.  ii, iii, and iv only

D.  All of the above

Answers

1.  D. This is a simple question with an obvious answer. I hope you got it right!

2.  D. The word process appears both in the question and in the correct answer and is one of the listed responsibilities of a Process Owner.

3.  D. These are the four characteristics of a process; it is rare for an exam to omit a question on this topic.

4.  C. You usually can’t go too far wrong in choosing an answer that includes phrases such as “agreed on with the customer.” You may have thought that some other answers had some merit, but the question emphasizes the word most to guide you.

5.  B. Please remember that ITIL is not a standard. If you hear people talking about “ITIL standards,” ask them what they mean; they’re probably talking about aligning their service management arrangements with ITIL best practice (I hope!). The formal, international standard for IT service management is, of course, ISO/IEC 20000.

6.  D. The question again helps you by emphasizing the word all. If you can conceive a credible exception to the statement given in an answer, then all can’t apply, and you can reject that particular answer. Here the options A, B, and C fail the all test.

7.  D. The range of stakeholders in IT service management is wide.