by William A Edwards MBCS
Statement of Rights
This book is provided for your personal use. You may change this book or distribute it without written permission.
Copyright © William A Edwards 2014/15
ITIL® is a Registered Trademark of AXELOS Ltd
The De-Facto Standard
Functions and Processes
Version 2 in Some Detail
The Service Lifecycle
Continual Service Improvement (CSI)
The ITIL Processes
Strategy Management for IT Services
Financial Management for IT Services
Service Portfolio Management
Business Relationship Management
Information Security Management
Service Catalogue Management
IT Service Continuity Management (ITSCM)
Service Level Management
Release & Deployment Management
Service Validation & Testing
Service Asset & Configuration Management
7-Step Improvement Process
Implementing IT Service Management
About the Author
When I first encountered ITIL®, I had already been working within the IT industry for many years. I was Technical Manager at Apricot Computers in the UK. I am a graduate of the University of Birmingham (in the UK) and a lifetime member of the British Computing Society. I mention these facts because, despite my background, my professional qualifications and my extensive practical experience within the computing industry, I struggled with ITIL® at the beginning.
It is not that any of this stuff is difficult – it really is not – however, the source material, as you will know if you have looked at it, is certainly not too accessible to beginners. That’s because it is not meant to be introductory material. It is, of course, reference material. In addition, the source books are written by people who understand the discipline very well and are fluent in the management-speak of their peers. There is nothing wrong with any of that, except that beginners often do not possess the necessary specialist vocabulary to be able to understand it.
At the time, I turned to Amazon to look for a good introductory text on the subject and, although I bought all of the source material – quite an investment as you may know – and a number of additional books on the subject, I was eventually forced to conclude that there simply were no good quality introductory texts available at the time.
So I leaned about Service Management the hard way; by working hard, studying the books and passing the exams. I became qualified as a Service Manager – what was often referred to as the ‘Red Badge’ qualification back in the early days of ITIL® – and then went on to pass all of the present exams in the new qualification program. Yes, every single exam, not just those you need to pass to achieve the new ITIL Expert qualification which, of course, I do also hold.
For the past 13 years, I have been consulting, teaching and helping people to implement Service Management based on ITIL® best practice guidance and this book, the result of years of study, reflection and application of the principles, represents my contribution to the online knowledgebase. If you are new to the subject of ITIL® and Service Management and you want to learn what it is all about, then this book was written for you.
Let’s start by talking about what Service Management actually is, and then we can move on and look at the subject of IT Service Management.
Service Management was started outside of the IT arena by organisations like banks and airlines that wanted to improve their customer experience. Basically, they were looking for ways to provide better quality services and they wanted to operate more efficiently. The result was the birth of Service Management as a discipline.
The ITIL® books attempt to document the application of Service Management principles to the IT world. It is a UK government initiative and it seeks to draw from various good practices commonly operating in the real world and distil what is referred to as Best Practice from those real-world methods.
This Best Practice guidance is documented in a series of publications produced by the Office of Government Commerce – the OGC.
Here is a list of the Official ITIL® publications:
ITIL® Core Guidance – Print Versions
ISBN 9780113313044 Service Strategy (SS)
ISBN 9780113313051 Service Design (SD)
ISBN 9780113313068 Service Transition (ST)
ISBN 9780113313075 Service Operation (SO)
ISBN 9780113313082 Continual Service Improvement (CSI)
You can also get them as eBook versions (the wonders of modern technology eh?) …
ITIL® Core Guidance – eBook Versions
ISBN 9780113313105 Service Strategy (SS)
ISBN 9780113313112 Service Design (SD)
ISBN 9780113313129 Service Transition (ST)
ISBN 9780113313136 Service Operation (SO)
ISBN 9780113313143 Continual Service Improvement (CSI)
Tip – You can often get reused print versions on eBay at a fraction of the price of the new books!
Let’s now take a quick look at some very common misconceptions.
ITIL® is NOT …
- A Methodology
- A Formal Standard
- A Rigid System
People new to Service Management will often think that the ITIL® books might contain all the answers to the problems of managing an IT service operation. However, that is simply not the case and the books were never intended to be that.
They were not meant to be a methodology or a system or a formal standard – they are simply meant to provide GUIDANCE. That means that all the answers are definitely not in there. Nevertheless, the guidance is pretty comprehensive as we shall see and, whereas ITIL® is not a formal standard, it has come to be considered as the worldwide de-facto standard for IT Service Management.
The last thing we should briefly discuss, before getting into the nitty-gritty, is a little about the history of ITIL®. It began in the 1980s and the original books were published by the CCTA – Central Computing and Telecommunications Agency. The CCTA no longer exists as such. It was ‘swallowed up’ by the OGC (Office of Government Commerce).
There was a rewrite (mid 1990s – 2004) which led to Version 2 being released. The Version 2 Library (as it became popularly known) consisted of 9 Books. There were 7 subjects, but a couple of them were divided into parts 1 and 2. Later, the guidance was again rewritten and the resulting Version 3 guidance – consisting of just 5 publications in its core – was published in the summer of 2007.
In 2011, the Version 3 guidance was further revised. The changes were all minor. A couple of ‘new’ processes were added. I say ‘new’ because they were not named as processes previously, but they were already present in the V3 books. Other than that and a quick once over to correct mistakes, the most changed book was Service Strategy.
None of the concepts changed at all, but many people had struggled with the V3 Service Strategy volume. It needed an update and I am glad to see that it has now been completed. This new version of the guidance is now officially known as ITIL® 2011.
By the way the acronym originally stood for …
- I … Information
- T … Technology
- I … Infrastructure
- L … Library
However, these days, it is regarded as unimportant what the letters stood for as the guidance is no longer regarded as a library. ITIL® is now simply considered by the cognoscenti as documented Best Practice for IT Service Management.
It was Version 2 of ITIL® that really took off!
Many public and private sector organisations that adopted IT Service Management made use of the V2 guidance. Other frameworks for Service Management, such as MOF (Microsoft Operations Framework) and the open source COBIT (Control Objectives for Information and Related Technology) basically lost the race.
This does not mean that MOF and COBIT are not useful and relevant; they certainly are and indeed ITIL® itself acknowledges their strengths. COBIT is stronger in audit and governance, for example. But, just as the VHS standard for video recorders prevailed rather than the technically superior Beetamax, so ITIL® eventually was hailed as the de-facto standard for IT Service Management.
Hey wait a minute – isn’t this book about ITIL® 2011?
Yes: this book is about ITIL® 2011. But do you know something? All of the Version 2 processes continue to live in Version 3 and beyond, and Version 2 will be much easier for you to get your head around. So that makes it a very good place to start.
Version 2 was, very much, a process-based approach to the subject of IT Service Management, so before we can understand it, we need to understand what a process actually is, how it differs from a function and what are its characteristics.
OK, so here we go …
Here is the definition of a process taken from the official glossary:
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.
Does that kind of language leave you a bit cold?
Yes – well that’s why you bought this book isn’t it – so we could get away from that stuff and find out what it actually means. Here’s my definition: if you were baking a cake, the process would be the recipe.
Now that’s much better isn’t it!
A recipe is not just a list of ingredients, but a whole series of tasks that need to be completed in order to turn the ingredients (inputs) into deliverables like cake (outputs); and that’s what a process does. Processes have input(s) and output(s); they have a specific goal; and they have roles and responsibilities assigned to the individual tasks that transform those inputs into the outputs.
Now let’s take a specific example: Incident Management – that’s a process and it involves people who work on the Service Desk. By the way, the Service Desk is defined as a function in ITIL®. A function (we’ll be discussing a number of them later on) consists of the people who actually carry out processes.
So here we have a good working example of the relationship between functions and processes: the Service Desk is involved in the Incident Management . A good way to think of it is that processes are what is being done and functions are the people who are doing it.
In ITIL® we have a Service Desk rather than a Help Desk: after all, we are Service Providers, the discipline is known as Service Management, so we have a Service Desk. Now let’s just think about what happens when someone calls the Service Desk.
- We would start off by logging the call
- We would categorise and prioritise the call
- We would try to resolve the issue
- If unable to resolve, we would escalate
- The relevant specialist would resolve the issue
- We would keep track of things
- Eventually, the call would be closed
Later, we’ll discuss each of those steps in more detail. But, for now, just recognise that a set of sequential activities are initiated when someone calls the Service desk and this is an excellent example of a process. The above list of activities are, essentially, the steps of the Incident Management process and, that process is performed by the Service Desk function.
There are other functions typically involved in the Incident Management process – that’s what is meant by the phrase functional escalation – but more about them later. For now, we are concerned with simply understanding the difference between a process and a function.
- Process: what is being done
- Function: who is doing it
There – that wasn’t too bad was it?
The Incident Management process is one of 26 processes defined in the current version i.e. ITIL® 2011.
In the Version 2 foundation course, you would have studied only 10 processes – 5 processes were defined in the old Blue Book (Service Support) and a further 5 were defined in the old Red Book (Service Delivery). All 10 of the old V2 processes are present (with some slight renaming) in the present version.
This section is important to your understanding of ITIL® 2011 – I want you to understand that. Of course, there are differences between V2 and subsequent versions but (apart from process names) in this section, I have avoided using V2 terms where they were not carried forward to subsequent versions. This was a deliberate decision to eliminate any possible confusion.
Because Version 2 contained less processes, I firmly believe that a new student stands a far better chance of understanding how they fit together and gaining that holistic understanding of IT Service Management is very important. But there is another excellent reason for starting with Version 2 – in the real world, that is still what many organisations effectively have in place.
Once we have looked at Version 2, we will go on to consider how the structure of the guidance changed with the introduction of subsequent versions.
So, let’s make a start …
Here is a list of the 10 processes that made up Version 2:
- Incident Management
- Problem Management
- Change Management
- Release Management
- Configuration Management
- Service Level Management
- Financial Management
- Capacity Management
- Availability Management
- IT Service Continuity Management (ITSCM)
Now then, what were all those processes about? Well let’s start off with the old Red Book (Service Delivery) processes and take a look at each one in turn.
The Service Level Management process seeks to document the requirements of the business – they are known as SLRs (Service Level Requirements).
In general, the business is not expected to understand the technical aspects of IT, so the requirements may not be well thought out or may even be downright unreasonable, however, this process (SLM) will engage in a negotiation to achieve an agreement with which everybody is happy. During those negotiations, we will reach a point where the business believes the proposed service levels will meet the business requirement and the IT staff believe the levels of service specified in the agreement can be met, working within the allocated budget.
The process of arriving at that agreement can be a lengthy one. It is often iterative, in that, once the business fully appreciates the financial implications of the initially presented requirements (SLRs), it may change those requirements. This is not weakness; it is just the reality of how negotiation works.
Eventually, an agreement is reached where the business will agree to what is to be subsequently provided, in terms of:
- Storage/throughput – known as Capacity in ITIL®
- Resilience – this is known as Availability in ITIL®
- Continuity – known as ITSCM in ITIL®
- Security – known as Security in ITIL®
That agreement is technically known as a Service Level Agreement (SLA).
Tip – Continuity is often referred to as DR (Disaster Recovery) in many organizations – the ITIL® term is IT Service Continuity Management (ITSCM).
Of course, these days, with technology being what it is, it is technically feasible to provide very high levels of capacity (storage and throughput) and availability (resilience) – it just costs money! The big question is: are they (the customers) prepared to pay for what they want?
Well that’s why we have a negotiation!
Imagine you were dealing with a company that wanted to keep their IT systems going for most of the time. 24 × 7 has become a bit of a buzz-phrase, but it is technically, not really possible. However, it is possible to keep IT systems running even when technical, component failure occurs by utilizing fault-tolerant systems.
There are many technologies that permit us to increase uptime by using the principle of redundancy. This is a simple idea – you have 2 or 3 of certain components in the infrastructure and then when something fails you arrange things to automatically fail-over to the standby unit. Thus you get increased resilience by utilizing the principle of redundancy.
Here are some technologies on the open market that utilize the principle of redundancy:
- RAID (Redundant Array of Independent Disks)
All of the above technologies operate on the basis of automatic failover.
Now the Availability Management process seeks to ensure that the appropriate technologies are deployed to achieve the resilience necessary to meet the levels of service defined in the Service level Agreement (SLA) and to do that it produces a plan – the Availability Plan is a key output of the Availability Management process.
The process both produces and executes the plan and, of course, the execution is done by raising RFCs (Requests for Change) at the appropriate times in order to get resilient systems deployed in a timely manner.
The Capacity Management process is responsible for ensuring that the necessary raw processing power – storage facilities, bandwidth etc – are all in place to meet the growing needs of the business. This process is very forward-looking i.e. it is not just concerned with now, but with the future of the business. It actually models the growth of the business to predict how it will grow over time and also attempts to predict the effect of that business growth on the IT infrastructure and the services it supports.
The process actually breaks into three sub-processes (as if we didn’t have enough processes to consider already!) but more about them later.
The main output of the process is the Capacity Plan which is a plan to introduce the necessary capacity – bigger disks, fatter pipes and faster processors – in a timely manner so that the business is never impacted by the lack of such things. Just like the Availability Management process, this process also produces and executes a plan and, again, the execution is done by raising RFCs.
Tip – Capacity Management is a balancing act: balancing the supply of capacity (storage, bandwidth etc) against demand (the consumption of it) and doing so in a cost-effective manner.
What would happen to the fictitious company we were considering if they were to completely lose all IT facilities; if the building were to burn down, or was flooded or some other major disaster occurred that resulted in the complete loss of all IT facilities? Most companies would eventually go bust without IT. Perhaps some might survive by reverting to manual, paper-based systems, but I think you would agree that these days, with such heavy dependency on IT, most companies would not survive if their key IT systems were not restored within a critical period of time.
If you were to think about this question a little more, you would recognize that some companies would go bust almost immediately. Large financial institutions, for example, would probably not survive for very long without IT. On the other hand, some operations might be able to manage for weeks or possibly even months without IT – sure, there would be a lot of inconvenience, but they would survive.
These questions are right at the heart of the concern of the ITSCM process. It is, naturally, for the business to decide what it wants to happen should such a scenario occur. But it is this process that will come up with the plan (the ITSCM Plan – the major output of the process) to achieve what the business wants and to regularly test that plan to ensure that it will run properly should it ever become necessary.
Now, as you know, all of the above (availability, capacity and continuity) costs money! So this process (Financial Management) is responsible for ensuring that the plans produced are properly costed and a budget is secured to implement them. And you know the problems don’t you? There never seems to be enough money in the pot. So that’s why we have considered these 5 processes together, because they work together – not in isolation – to ensure that the needs of the business are satisfied.
Whenever other processes require financial expertise, it is provided by this process. But the scope of Financial Management relates to three main areas of activity.
Here they are …
- Budgeting – Securing the necessary funding
- Accounting – Showing where the cash actually went
- Charging – Getting our money back!
Tip – Charging is optional if the organisation is non-profit. But if it is introduced, it can be utilized as a mechanism for shaping user behaviour and can therefore be a very useful tool for managing customer demand.
In addition to the three main activities listed above, this process is involved in many other fiscally-related activities.
Processes like Availability, Capacity and ITSCM each have a responsibility to be cost-effective. Let’s face it; you can spend a lot of money in these areas. In particular, an incorrectly-sized ITSCM plan could cost the organization substantially. So we can think of the responsibility of these processes as being, to produce an integrated set of plans to meet the needs of the business (or the organisation) in a cost-effective way.
Service Level Management (SLM) is the process responsible for negotiating all of these concerns with the business, or organization, and arriving at an agreement to which all parties subscribe. It is, of course, easier said than done. But it is crucial to the success of IT Service Management because whatever is agreed in the Service Level Agreement (SLA) is what the business is actually going to receive.
Higher levels of service invariably mean a higher cost of service provision. The whole thing is up for negotiation before the plans have been finalised, but once the SLA is agreed, the plans – including the financial plan i.e. the budget – can be implemented to provide the business the levels of service that are right, given all eventualities.
Let us now move on to discuss 5 more processes – the processes in the old Blue Book (Service Support). These processes are responsible for working together to provide support for what has been documented and agreed in the SLA.
The Incident Management process is carried out by the staff on the Service Desk. The Service Desk staff may or may not, additionally, perform other ITIL® processes, but they will definitely be involved in the Incident Management process.
The goal of this process is to restore normal service operation as quickly as possible. Normal service operation being: whatever is defined in the SLA. To help achieve this, the process has access to a key repository – a knowledgebase – which stores details of past incidents and has documented workarounds (temporary measures) that can be invoked at first point of contact to reduce the impact of incidents. A workaround is simply a quick-fix or method of avoiding effect of the incident to enable the user to continue working.
The incident may be resolved at first point of contact; however, it may be necessary to involve technical staff working in other functions – often referred to as second-line, third-line support etc. In these cases, the Incident Management process will retain the ownership of the incident, whilst passing the detail to the necessary support staff to deal with the situation. This activity is known as functional escalation in ITIL®.
The incident is monitored and tracked by Service Desk staff and eventually it is closed – usually with confirmation from the user that the incident has been resolved.
The Problem Management process is concerned with identifying the underlying causes of incidents. Supposing we have something in the infrastructure that keeps failing repeatedly. There must be some reason that it keeps failing – and that reason is the problem.
A number of years ago, there was a situation in which DC10 airplanes were involved in a series of crashes. When investigated, it was found that the design of the cargo hatch door had caused the disasters. In other words, the cargo hatch door design was the problem.
Thinking in terms of cause and effect: incidents are an effect; problems are a cause. Some organisations call this aspect of Problem Management (the identification of underlying causes) Root-Cause Analysis.
In a nutshell, this process investigates incident data, looking for underlying causes and then it produces either, or both, of two outputs:
- A short-term fix, known as a Workaround
- A permanent fix initiated via RFC (Request for Change)
Workarounds are added to the KEDB (Known Error Database) for future reference. This is very useful to Service Desk staff who, as part of the Incident Management process, will search the database for these temporary fixes as incidents are raised. In this way, the impact of incidents that cannot be resolved immediately can often be reduced. This is also a good illustration of how ITIL® processes work together to support each other.
Whenever we make a change to the live infrastructure, there is always a corresponding risk to be understood and managed. Change Management is about understanding that risk, assessing it and considering whether or not to proceed with operational change. It is further concerned with the overseeing the successful management of such changes into the live environment.
All changes need to be managed i.e. assessed, authorised, planned, implemented and validated. But the key to getting this discipline operating effectively is to get the right kind of assessments and authorisations in place. That is why there are actually, three types of change recognized by ITIL® and they are each handled slightly differently.
- Standard Change – pre-authorised by the process
- Normal Change – goes before the CAB
- Emergency Change – goes before the ECAB
The CAB (Change Advisory Board) is a group of people who meet regularly to discuss proposed changes and to advise on whether or not they should be implemented. Clearly, if your organisation did this every time an RFC was raised, the process would become onerous. That’s why we have an ECAB (Emergency CAB) which can be convened very quickly, and it is also why we would almost certainly choose to pre-authorise certain types of change; typically those where the risks are well known and well understood.
A release is not a single change, but a collection of changes introduced into the live environment simultaneously and the Release Management (Release and Deployment Management in ITIL® 2011) process works with the Change Management process to ensure the successful introduction (Rollout) of releases into the live environment.
The process considers all aspects of the release including technical and non-technical aspects, including such things as managing user expectations. When dealing with complex changes, a project management approach is definitely preferred, and that’s what the Release Management process brings to the party.
An aim of the process is to do fewer, better-managed releases, and this is achieved by packaging releases wherever possible. Release Packages consist of Release Units and there will typically be more than one Release Unit in a package. Defined in ITIL® as the ‘part of the infrastructure normally changed together’, a Release Unit is itself a little bundle of changes.
Just to make sure you get the idea of the Release Unit, consider this: imagine you are driving along in your car and your type pops. You have a broken component in the infrastructure (tyre) but you don’t actually change the tyre, you change the whole wheel. So you see, the wheel is effectively a Release Unit – the components normally changed together.
Tip – An IT example of a Release Unit is a Microsoft Service Pack – the components (in this case a bundle of software changes) normally changed together.
An important responsibility of Release Management is to ensure that planning and testing, prior to the introduction of a release, is properly completed to ensure the successful transition of releases into the live environment.
The Configuration Management (Service Asset and Configuration Management in ITIL® 2011) process is concerned with the population and maintenance of the Configuration Management Database (CMDB); a key repository utilized by all IT Service Management processes. It is the place where asset information is stored and also (the thing that differentiates it from an asset database) the relationships between assets. The CMDB thus holds a logical model of the infrastructure.
The introduction of such a database can represent quite a challenge for many organizations, both in terms of effort and cost, but the payoff for creating one is immense. All sorts of useful queries can be answered from the information it holds. For example, we could, very quickly and easily, establish the exact impact of the failure of a particular item (Configuration Item) of hardware in terms of the software applications and users that would be affected. Just think how useful that kind of information would be when assessing the impact of a proposed change.
Tip – A Configuration Item, usually abbreviated C.I. is an item held in the CMDB. It can be anything (hardware, software, documents etc) that the organisation wants to manage under change control.
The 5 Service Support processes listed above are instrumental in maintaining the status-quo for the services provided to the organisation. Incident and Problem Management work together to reduce the impact of incidents and to keep things operational.
Change, Release and Configuration Management work together to manage and record changes – large and small – in a controlled manner, ensuring that information in the relevant database is kept up-to-date and can be relied upon by the other service management processes.
The successful resolution of an incident will often involve many or all of the support processes listed: for example, Incident Management will do the initial diagnosis; Problem Management may produce a temporary fix (Workaround); Change Management will get the necessary components swapped; and Configuration Management will record the Change in the CMDB.
Generally speaking, Release Management would not normally be involved in an incident resolution, but it could be: for example, if we have a virus loose on the network and needed to make an Emergency Change, then Release Management would be involved because software installation is a part of the scope of that process.
The important thing to understand is that these processes operate in parallel and they feed each other. The outputs of one process may become the inputs of another. For example, when Incident Management or Change Management needs to get something swapped, it raises an RFC (Request for Change) which then goes to the Change Management process.
The above processes make extensive use of the information recorded in databases such as the CMDB and KEDB (Known-Error Database) and they are also responsible for keeping them up-to-date. Configuration Management maintains the CMDB and Problem Management maintains the KEDB.
Tip – The CMDB and KEDB are physical databases that – together with other repositories – make-up the Configuration Management System (CMS) in ITIL® 2011.
Remember that all of the above V2 information applies to V3 and beyond – it was not made obsolete with the introduction of subsequent versions. The terms Service Delivery and Service Support are obsolete (i.e. they are V2 terms) but the processes described within those V2 books still exist, though some of them have been slightly renamed.
Here are the Version 2 processes carried forward and slightly renamed to their ITIL®2011 names:
- Incident Management
- Problem Management
- Change Management
- Release & Deployment Management
- Service Asset & Configuration Management
- Service Level Management
- Financial Management for IT Services
- Capacity Management
- Availability Management
- IT Service Continuity Management (ITSCM)
As you can see, apart from a few of the V2 processes – Release Management, Configuration Management and Financial Management – being renamed slightly, they all continue to exist, and function in much the same way, in Version 3 and now in ITIL® 2011.
Release Management becomes Release & Deployment Management. This renaming implies that the process is responsible for deploying new services, as well as performing releases for existing services. Asset Management has always been a sub-set of the Configuration Management discipline and we can see this is now reflected in the new name for the process. Financial Management now becomes Financial Management for IT Services – a nod toward the new service-based accounting guidance to be found in the ITIL® 2011.
We need to go through each of the 26 processes in detail, but before we do that, let’s discuss the major difference between Version 2 and subsequent versions of ITIL® – the concept of the Service Lifecycle.
Tip – The Service Lifecycle is now the of the new guidance i.e. how the 26 processes are organised.
The Service Lifecycle is the big change between Version 2 and subsequent versions of ITIL® and – fundamentally – it is a change of structure for the guidance itself.
Services are conceived, designed, transitioned into the live environment and then operated for their useful lives during which time, they are continually improved. That is the reality of life for an IT service. Every service goes through those 5 phases of development and progression and that’s how the new version of ITIL® version is structured – that’s why the new books bear those titles.
To make sure we understand what the service lifecycle is, let’s consider a little analogy: imagine you won a lot of money – so much that you would never need to work again in your entire life. Where would you go? What would you do? Where would you live? Those kinds of questions relate to strategy.
Now, staying with our illustration, suppose you decide to live in Australia, would you buy a house or have one built to order? Let’s say you decide to have it built, what would you do next? Probably, you would get an architect to draw up the necessary plans – that’s design. Once your plans are ready, you would get a builder to construct the house for you – that’s transition. Then you would finally get to live in it – that’s operation.
Now, if you are married, it is pretty much guaranteed that after you move in, your wife (or you yourself, if you are female) will want to add a conservatory – this is not being sexist; it is just reality. As Billy Conolly once said after he and Pamela had moved into their dream house, “women see something that we men don’t – they see potential!” Anyway, adding the conservatory, converting the loft, changing the kitchen etc – that’s CSI (Continual Service Improvement).
The titles of the books in the guidance are a reflection of the phases of the Service Lifecycle.
- Service Strategy
- Service Design
- Service Transition
- Service Operation
- Continual Service Improvement (CSI)
So this is how the 26 processes are now organised into the 5 ITIL® publications …
The following 5 processes are discussed in the Service Strategy book:
- Strategy Management for IT Services
- Financial Management for IT Services
- Service Portfolio Management
- Demand Management
- Business Relationship Management
The following 8 processes are dealt with in the Service Design book:
- Design Coordination
- Capacity Management
- IT Service Continuity Management (ITSCM)
- Availability Management
- Service Catalogue Management
- Information Security management
- Service Level Management
- Supplier Management
The following 7 processes are covered in the Service Transition book:
- Transition Planning
- Release & Deployment Management
- Change Evaluation
- Service Validation & Testing
- Service Asset & Configuration Management
- Change Management
- Knowledge Management
The following 5 processes are defined in the Service Operations book:
- Problem Management
- Incident management
- Request Fulfilment
- Event Management
- Access Management
The following process is in the Continual Service Improvement (CSI) book:
- 7-Step Improvement Process
Now, before we go through each of the 26 processes and 4 functions, let’s briefly discuss each of those books at a top level so we can get a feel for what they are about.
For many people, this book is the most difficult to understand. That’s because it is written for those people who are right at the top of the organization who are expected to have some familiarity with general business principles and the understanding of what strategic thinking is about and this is often unfamiliar territory for many IT people.
Now that doesn’t mean we can’t understand it. Let’s face it, if you can understand TCP/IP, then you can cope with just about anything!
So, first off, the book is very cerebral. In order words, it is a lot about thinking. The book itself actually says it will help an organization to be able to ‘think and act’ in the right way. The essence of the material concerns finding answers to questions like these:
- What services should we offer?
- To whom should we offer them?
- How can we differentiate our service offerings?
- How do we create value for our customers?
- How do we define quality?
- How do we effectively allocate resources?
- How do we resolve conflicting demands?
Strategy – see?
Now then, although the book is concerned with those things, it does not endeavour to provide the answers to those questions. The intention is to provide the guidance that would allow an organization to find the answers to those questions, for itself.
To achieve this, it is suggested that there are four main activities that should be considered as part of an organisation’s strategic thinking.
- Define the Market
- Develop the Offering
- Develop Strategic Assets
- Prepare for Execution
It is worth bearing in mind that the ITIL® books are written with the intention of being useful to organisations of different sizes and shapes. There are three specific service provides types that the guidance addresses. They are easy to remember; they are called Type 1, Type 2 and Type 2.
- Type 1 – Has a single, internal customer
- Type 2 – Has multiple internal customers
- Type 3 – Has external customers
If you think this strategy stuff is not a part of IT, then perhaps you are not alone. Many people think that strategy belongs outside of the scope of IT. But it really depends on the nature of your organization. For a Type 3 provider this strategy stuff definitely is IT because, for such providers, IT is the Business.
For a Type 2 provider, IT operates in an internal market. Organisations, naturally, always have a choice when it comes to where to source the IT services it requires. So, here, the recognition of the existence of competitive forces, coupled with a strategic approach to service provision can help to provide us with a competitive edge.
For a Type 3 provider, the strategy guidance enables us to identify market opportunities and correctly position ourselves so that we win new business and retain and even delight existing customers. We do this by providing services that truly do deliver real value to our customers and for which they are more than prepared to pay.
OK – now – Service Design: what would you expect this book to be about? Designing services – right?
And so it is. But, it is not only concerned with designing services. It is also concerned with the design of other things too. Specifically, it is concerned with the design of the following:
- Design of Services
- Design of Architectures
- Design of Processes
- Design of Measurement Methods
- Design of Tools
Tip: The above list occurs repeatedly throughout the Service Design publication. It is known as the 5 Aspects of Service Design.
New and existing services come within the scope of this phase of the lifecycle.
The key output of Service Design is a Service Design Package (SDP) which contains a complete description of the service to be built and released. This is an important package of documents that contains everything necessary to take the service from design and through the remaining phases of the lifecycle.
The main components of the Service Design Package are shown below:
- Documented Business Requirements
- The Business Case
- The Service Design
- The Specifications
- An Organisational Readiness Assessment
- A Service Lifecycle Plan
Underneath our services are the architectures that support it and these include the architectures of Services, Applications and Infrastructures.
The services in our catalogue will conform to an architectural blueprint. For example, some of our services may be reliant upon the existence of other enabling services; and some services may utilise other enhancing services to add functionality.
In addition to the architecture of services, applications have architectures. For example, an accounting service might consist of the following elements:
- Sales Ledger
- Purchase Ledger
- Nominal Ledger
Finally, infrastructures have architectures consisting of the various hardware elements such as:
- Network Infrastructure
- Hardware Components
Infrastructure includes both a) what is necessary to support the service, and, b) what is needed to manage the service including monitoring and reporting.
Many people make the mistake (when new to ITIL®) that the books will contain the exact processes they need to implement in their own organisation. In other words, they expect to open the books, find the process steps and then just implement them. This could not be further away from what the guidance recommends.
Although you will find processes described in the books and you will find flowcharts in there too, the ITIL® recommendation is that you should actually design your own processes. That means that the process diagrams are there simply as a reference – they are meant to provide … guidance.
Tip – Many of the better IT Service Management tools – the software you actually use to perform IT Service Management – have the capability for process design built-in.
In designing processes, you need to think about the following characteristics that all processes share. They all have the following in common:
- KPIs (Key Performance Indicators)
- Roles & Responsibilities
- Process Owner/Manager Role
And in addition, there are 4 Key Characteristics of all processes:
- They Produce Specific Results
- They are Measurable
- They Deliver Value to Customers/Stakeholders
- They Respond to a Trigger Event
A useful model when designing processes is the RACI model (pronounced racey). It is an example of an authority matrix:
- R … Responsible
- A … Accountable
- C … Consulted
- I … Informed
The RACI model is a useful tool for mapping the activities of a process onto individual roles. For each of the activities of a process, we need to consider who should be responsible i.e. who gets the job done; who should be accountable i.e. who ensures the job gets done; who should be consulted and who should be informed i.e. which steps require information to be fed into and out of the process.
Note that you might have several, or even many, people responsible for an activity, but only one person would be for each activity. If you think about it, were you to make more than one person as accountable for something, in practice, you would actually have nobody accountable!
The idea of continually measuring the results we are producing is a central part of the ITIL® philosophy and, in particular, an integral part of Continual Service Improvement (CSI) which seeks to, constantly, demonstrate objective, measurable improvements.
It is, therefore, important to decide exactly what needs to be measured and how those measurements should be collected and that’s what is meant by the design of measurements.
There are very many things you could measure within the following categories:
- Component Measurements
- Process Measurements
- Service Measurements
The above represents different categories of metric that are useful to different audiences.
The reliability of components in the infrastructure can be measured to produce metrics such as:
- MTBF – Mean Time Between Failures
- MTRS – Mean Time to Restore Service
- MTBSI – Mean Time Between System Incidents
Tip – The MTTR (Mean Time to Repair) metric referred to in V2 is actually a part of the new MTRS metric. But MTRS is a much more useful measurement for many businesses.
The effectiveness and efficiency of processes can be measured. Effectiveness relates to the goal(s) of the process; efficiency is concerned with doing things in the best possible way. But the main metric for processes is the Key Performance Indicator (KPI).
A KPI is something for which you can calculate a numerical value that provides an indication of the effectiveness of the process. If we consider the Incident Management process for example, measurements such as those below can provide a useful indicator of effectiveness:
- % of Calls Correctly Classified
- % of Calls Resolved at First Point of Contact
- % of SLA Breaches
By the way, KPIs can be qualitative (a specific category such as red, amber, green) or quantitative (a specific number such as a percentage). Remember though that, even for quantitative KPIs, you still need to measure in order to be able to put things into those categories.
ITIL® does not tell you what your KPIs should be; it simply provides suggestions. You decide the KPIs for your own processes yourself.
If you consider the separate configuration items (hardware, software and anything else) that make up an individual service, you will understand why a failure of any one of them might impact the overall service. This is why it is useful to calculate and report the overall, end-to-end reliability and availability of each service.
One of the central themes of ITIL® is to ensure that we report to each audience in the appropriate way. Service measurements that aggregate measurements from individual configuration items to provide an overall view of the health of a service are particularly useful when reporting to the business.
There are a couple of obvious choices to be considered when it comes to the design and/or selection of tools:
- Proprietary Solution
- Best of Breed
A proprietary solution provides a ‘one-stop-shop’ – an integrated approach to the whole of IT Service Management, however, it may or may not be a good fit for your requirements. On the other hand, a best-of-breed approach – mixing and matching different software – may present interesting integration challenges.
The guidance suggests that you should decide upon your own criteria for software selection - including both mandatory and nice-to-have requirements – and then evaluate and rank candidate software, looking for at least an 80% fit to your requirements.
Tip – Tools are also known as Products in ITIL® – they are one of the 4 Ps in Service Design (People, Processes, Products and Partners).
When introducing a new service (or a significant change to an existing service), it is the responsibility of Service Design to include in the Service Design Package (SDP) everything necessary to get the service through transition and into the live environment. So that means there might well be aspects of the design, or redesign, of processes, tools, measurements and architectures included in addition to the actual design of the service.
In ITIL® 2011, the Service Management discipline is a dynamic model, recognizing that managing the complex infrastructures of today necessarily means not just coping with change, but coping with the management of very high levels of change.
Whenever we make a change to the live environment, there is always a corresponding risk involved. Seeking to understand these risks and manage them effectively in the deployment of change is what the Service Transition book is all about.
This phase of the lifecycle receives the Service Design Packages (SDP) from Service Design and it executes a transition project that terminates with the graceful handover, typically after a bedding-in period (known as Early Life Support) of a live service to Service Operations.
The transition processes work together to accomplish the successful handover and the important thing is that the transitioned service is virtually guaranteed to work first time and to create a minimum of disturbance and/or disruption to normal business. This guarantee can be made because the processes in this phase of the lifecycle will ensure the new (or changed) service will be first built in a test environment where extensive testing, including testing of the remediation plan will be undertaken. The remediation plan (often called a backout plan by many organisations) is a plan for how to recover, in the very unlikely event that things do not go to plan.
Tip – The goal is to introduce the service with ‘least disruption for the business’ and that means even if it is more work for IT. This is a central principle in ITIL® i.e. that we need to think of the needs of the business (or organisation) first.
There are many references to the creation of value throughout ITIL® – Service Operation is where the value is seen.
There are several competing influences that Service Operations seeks to balance.
- Internal v External Focus
- Proactive v Reactive
- Stability v Responsiveness
- Cost v Quality
An organization that has a view that “the customer is always right” has an external focus; whereas an operation that takes the view that “you can have any colour you want, as long as it’s black” has an internal focus.
The idea of fixing things before they are broken (being proactive) sounds good on the face of it, but we don’t want to become the source of unnecessary churn.
Similarly, we want to be handle requests for change in an effective and efficient manner, but we don’t want to create an unstable environment in the process.
Finally, we need to be able to balance the desire to provide a quality service against the cost of providing it – a typical project management concern.
We have already met the Service Desk function, but there are actually four functions defined in the Service Operations book:
- Service Desk
- Technical Management
- Application Management
- Operations Management
A function is the people and tools that are used to execute one or more processes. As we discussed, the Service Desk provides us with a good illustration: the Service Desk function performs the Incident Management process.
These other three functions are responsible for carrying out the other ITIL® processes. Don’t get confused about functions: although they are discussed mainly in the Service Operations book, they actually apply to the whole lifecycle. In other words, the people in these functions perform processes in the other lifecycle phases too.
Here are the other three functions:
Technical Management is the function responsible for the infrastructure. It provides knowledge, guidance and the actual resources for the maintenance of the infrastructure. The people in this function are our subject matter experts in the area of infrastructure.
Application Management is the function responsible for application software. It provides knowledge, guidance and the actual resources for the maintenance of applications. It is also the interface to the software development environment. Again, these people are subject matter experts, but in the area of software.
Operations Management is the function responsible for general ‘housekeeping’ activities such as print jobs, backup etc. It is also responsible for both Facilities Management i.e. the management of the physical environment; and Operations Control i.e. monitoring. People in this function generally have a wide range of technical skills including both hardware and software.
The idea of continually improving what we are doing in Service Management has always been a part of the ITIL® philosophy. In version 2, it was a specific responsibility of the Service Level Management process. Now, it is the subject of an entire book within the guidance.
The thinking is based on the ideas of William Edwards Deming, who was a leading management thinker around the time of the end of WWII. An American, his ideas were rejected at the time in the USA and embraced by the Japanese. Many analysts have credited the post-war economic revival of Japan as, at least in part, being connected with the adoption of his ideas.
Amongst other things, Deming is famous for the Deming Cycle, or Circle. These days the thinking of Deming, which was truly revolutionary (no pun intended) has been adopted by most progressive organizations in the west. Amongst other things, he believed that the people actually doing the work (whatever that was) were best-placed to make suggestions about process improvement, not the people at the top of the organizational structure.
It now seems quite an obvious truth. But at the time, it was a revolutionary idea.
The basic idea is that you first plan what you are going to do, and then you do it, whilst collecting performance data at the same time. You analyse your results (check) and finally, you make some changes (improvements) based on that analysis. Once you have made an improvement, you take actions to consolidate your position before thinking about going round the cycle again.
There are many things to which you can apply this improvement philosophy including processes, services, systems, tools, technology and so on. Thus, Continual Service Improvement (CSI) is said to operate across the lifecycle contributing to the delivery of ever-increasing levels of value to the business.
It might not be entirely evident at first, but the Deming Cycle is deeply embedded into much of the ITIL® philosophy and the more you look for it, the more you can find it. Most ITIL® processes involve planning, doing and checking. The notion of initiating improvements based on measurements, then, effectively completes the cycle and that is the subject of this book in the guidance.
Essentially, the overall approach to CSI involves answering these questions:
- What’s the Vision? – Set by Strategy
- Where are we now? – A Baseline Assessment
- Where do we want to be? – A Target
- How do we get there? – A Plan
- Have we arrived? – A Measurement
- How to maintain Momentum? – Next Improvement
The above model is not an ITIL® process; it is actually described as an approach – The CSI Approach.
You can use that same basic approach for improving Services, Processes and whole Lifecycle Phases. Even, to go a step further, for the improvement of the Service Management discipline as a whole.
At this point, we should have a pretty good overview of IT Service Management discipline based on the ITIL® guidance. We have encountered processes and functions and we have discussed enough processes to have developed a reasonable grasp of what is being done.
The official stance is that no process is more important than any other and there is certainly an argument for that view. However, my own opinion is that if you can first grasp the foregoing, you have the essence – the heart – of what ITIL® is all about.
However, the next step is to look at all 26 processes in turn, put some more flesh on the bones, so to speak, and add in all of the bells and whistles. So this section looks at each of the ITIL® processes in turn following the structure of the lifecycle.
So, here we go …
Here are the steps of the process:
- Define the Market
- Develop the Offerings
- Develop Strategic Assets
- Prepare for Execution
This is concerned with understanding who the customer actually is. This may seem ridiculous, but a thorough understanding of the customer and the market in which the customer exists is an absolutely essential part of crafting a service strategy.
Naturally, there are different types of organization and different types of customer. You remember that ITIL® defines three different types of service provider, operating within different markets.
- Type 1 … Single Internal Customer
- Type 2 … Multiple Internal Customers
- Type 3 … External Customers
A Type 1 service provider is an organization that services a single internal customer – in other words, the Business, or the Organisation itself, is the customer. For many such operations, the concept of the Business (or Organisation) being a customer is an alien thought however, the notion of the customer is pivotal to the whole idea of being a service provider. Service providers have customers – whether or not they actually pay any money for the services they receive. That idea is central to Service Management.
Type 2 service providers also service an internal market, but they operate as an autonomous entity providing services to various Business Units. Generally, Type 2 providers do recognize they are operating within some kind of market. However, competition does not really exist in the true sense of the external market. Though, perhaps some would argue that the constant threat that the organisation may choose to outsource the provision of some services does act to provide some kind of commercial driver.
Type 3 service providers offer their services to customers on the open market. They charge for the services they offer and are in the business of service provision in order to make a profit.
Charging may also be implemented by Types 1 and 2 providers even though, in those cases, the customer is internal. The decision of whether or not to do this is a policy decision. But, should the organization’s policy permit the charging of internal customers, the mechanism can prove useful as a means of shaping user behaviour.
This activity is concerned with understanding what the customer wants and needs. Customers don’t buy products or services – they buy solutions. So exactly what solutions will we, as a service provider, be offering? That question is the essence of this activity.
The guidance suggests that an organization should be concerned with aligning its portfolio of services with Market Spaces – these are simply opportunities that exist to develop service offerings for the target market. Naturally, in order to do that, we first need to spend some time actually identifying those opportunities (Market Spaces).
The guidance suggests starting off by coming up with an ‘Outcome-Based’ definition of the services to be offered. In other words, what exactly would be the specific benefits of each of the services that could be offered? Once we have a whole set of these ‘Outcome-Based’ definitions, the opportunity (Market Space) will become apparent.
The Service Portfolio – a new concept brought in at Version 3 – is a key information system that is essential to this process. As we shall see, the portfolio is quite central to the whole idea of the service lifecycle.
The identification of market spaces is an activity that is crucial to subsequent decisions related to where and how to commit resources. Resources are a limited commodity, so good decisions on where to invest them is a vitally important aspect of strategy. Information in the portfolio therefore begins with the identification of Market Spaces.
Strategic Assets provide the raw material for creating a service. As service providers we combine them to create services that deliver value to customers. There are two types of service assets – resources and capabilities.
Resources are as tangible assets. They are things the organisation can to achieve its goals, such as hardware, people, money etc. Capabilities are intangible assets. They are the various things the organization can actually such as management, organization, skills, knowledge etc. Collectively, resources and capabilities are referred to as service assets.
As we are continually challenged to deliver higher levels of service, we respond by developing the ability to meet those challenges and this necessarily involves the development or acquisition of further resources and capabilities.
The strategy guidance also discusses the discipline of IT Service Management itself and the case for viewing it as a strategic asset of the organization. If we can get better at the business of IT Service Management, it argues, then IT Service Management itself will become a strategic asset of the organization.
Tip – Be aware that the guidance refers to IT Service Management as a whole in several places. Above is an example of this i.e. the idea of IT Service Management becoming a Strategic Asset.
In Preparing for Execution, we are concerned with the crafting of strategic intent; there are two parts to it – Strategic Assessment and Strategy Generation.
Strategic Assessment – concerns thorough self-reflection. In other words, what is it that we, as a service provider, already do well? Understanding what we already do well is likely to reveal a core of differentiation – the understanding of what makes our services do well.
Strategy Generation – in order to generate a strategy, Mintzberg’s 4 Ps provide a useful reference point. His 4 Ps are: perspective, position, plan and patterns.
- Perspective – the operation needs a vision
- Position – that basis on which we will compete
- Plan – including Critical Success Factors (CSF)
- Patterns – develop consistency in actions taken
Tip – Be aware that there are another set of 4 Ps in the Service Design book (People, Processes, Products & Partners). Make sure you don’t get them confused.
Finally, out of all of this reflection – strategy involves thinking as well as acting – comes the strategy itself i.e. the basic stance of the organization for the services it will offer. Will we be the cheapest in the market; will we become the quality offering; will be become the most trusted source for our services? These questions relate to positioning and, along with our perspective (vision) they affect our plan.
The best way to think of what the process does is that it provides the necessary financial advice, guidance and rigor where it is needed by other parts of Service Management. For example, supposing that the Problem Management process needs to make a Business Case to justify some additional spending. The Problem Manager, who might not be well-versed in financial matters, may need some assistance with that – well this process would be provider of that help.
There are three main activities in Financial Management:
Budgeting is the business of predicting the costs that will be incurred for the fiscal year ahead or, in other words, it is financial planning. It is the business of putting a price on the integrated set of plans (Capacity, Availability etc produced by Service Design) that will be necessary to support the business for the year ahead.
Accounting is showing where the money has been spent – this is described as providing operational visibility. Accounting should be introduced after Budgeting and before Charging. It is easy to understand why: once we know how much a particular department is costing, it is a useful prerequisite to preparing and issuing the bill.
Charging is an optional area in ITIL®. There are pros and cons to be considered for Type 1 and Type 2 providers. However, if the organization does decide to charge the Business for the provision of IT Services, the guidance on how to do it effectively is provided.
- Zero Balance – Cost Recovery
- Cost Plus – Making a Profit
- Cost Minus – Making a Loss (Subsidised Service)
- Going Rate – Internal Comparison
- Market Rate – External Comparison
- Fixed Rate – Arbitrary
The optional activity – charging – depends on what kind of organization you actually have and whether or not it is appropriate. However, even in some operations where the business (customer) is internal, charging for the provision of IT services can be of great benefit. At least it serves as a constant reminder to non-IT staff that technology costs the operation money.
As discussed, there are definite pros and cons to introducing charging. ITIL® essentially stays out of the argument. Basically, you decide what is right for your organization and ITIL® gives you the tools to implement charging if it is appropriate for your operation.
Here are the charging policies you might consider …
- No Changing – it’s still a policy decision
- Cost Minus – making a loss
- Zero Balance – recovering costs
- Cost Plus – making a profit
- Market Rate – an external price comparison
- Going Rate – an internal price comparison
- Fixed Rate – an arbitrary charge
Most of these policies make sense from their names. Making a loss sounds a bit silly, but that is the essence of what is entailed in providing a subsidized service. The Going Rate is a term to describe an internal comparison i.e. what others are charging internally. It might also be based on opportunity-cost i.e. what you could charge someone else for the resources you have committed.
The Service Portfolio is a central concept in ITIL® 2011. It represents the commitment of the organization to market spaces (opportunities).
The steps of the process are as follows:
This is where a Service begins its life as an idea. It is where the idea is evaluated to determine whether or not it is a good idea i.e. the Business Case is prepared, and it is where the idea is eventually approved or rejected. The process takes the concept from a service definition to the actual chartering (allocation) of resources.
In analyzing the proposition for a new service, the process would consider the following questions.
Does the proposed new service help us to:
- Run the Business
- Grow the Business
- Transform the Business
The preparation of a Business Case provides the necessary justification – often financial – for taking the idea forward. A Net Present Value (NPV) calculation is often useful for determining the expected Return on Investment (ROI) in the preparation of a Business Case. Remember that Financial Management for IT Services process can provide assistance with this type of calculation.
Once the service reaches the chartered status (i.e. resources are committed) the service leaves the Service Pipeline and enters the Service Catalogue. The catalogue is the customer-visible portion of the Service Portfolio. At this stage, the service is still to be designed and built; however, the decision has now been taken to commit to the delivery of the service.
The process itself is cyclic in nature – continually seeking to validate the accuracy of the information contained within the Service Portfolio and periodically refresh the business cases.
Demand Management is closely related to Capacity Management. However, Demand Management is more forward-looking seeking to operate on the causes of demand i.e. the customer. Capacity Management is specifically responsible for ensuring we have sufficient capacity (bandwidth, storage, throughput etc) in the infrastructure.
The Demand Management process is concerned with understanding and influencing the customer demand for the services that the business offers. Now, of course, there are subtle differences when it comes to the different supplier types.
For Type 1 and 2 suppliers, this means understanding the demand for whatever it is that the business produces. For example a toy manufacturer produces toys and Demand Management would be attempting to understand the factors operating within the external market that create demand for those products – that’s why this process is in the Service Strategy book.
Every Christmas, for example, the demand for toys increases – that is known as a Pattern of Business Activity (PBA). This process seeks to understand those PBAs and regulate or influence them. If demand for our products drops, then the introduction of special offers, for example, can help to stimulate consumption; if demand is greater than the ability of the business to respond, then an increase in price can help to both curtail demand and optimise profit.
For Type 3 suppliers – where IT is the business – the customer demand for the products the business produces is the same thing as the demand for IT services since IT services, in that situation, are the product. However, the same considerations apply and it remains vitally important to properly match supply against demand.
The outputs of this process include policies that define working practices including constraints that are designed to influence or regulate consumption of the product:
- Financial Constraints – e.g. Differential Charging
- Physical Constraints – e.g. Flexible Working Hours
Financial constraints might include, for example, differential charging – charging more for our services at peak times and less at off-peak times – as a means of shaping user behaviour. Physical constraints might include, for example, the adoption of flexible working hours as a means of displacing demand over time. Such policies would then be carried out by other processes e.g. Financial Management.
In addition, this process is concerned with stimulating demand for the consumption of our services.
Services are composed of various elements and by adding on additional functionality (also called Utility) and/or Warranty – a service guarantee – the service provider can create differentiated offerings. This is important because, if we are to get people to buy our services, rather than those offered by the competition, we need to give them a very good reason to do so.
For example, an email service might consist of the following elements:
- Email Service
- Superior Spam Filtering
- 15 Gb of Free Storage
The combination of these elements becomes our differentiated email service offering.
By the way, if you have a gmail account, you will recognise that although Google don’t actually sell their email service, they actually did include the above elements in the package and that is probably why you have the account.
As service providers, we want to be successful and that, of course, means we want people to buy our services. To achieve that objective, we really need to understand why people buy them and/or why they don’t buy them. We may think we understand, but that is not quite the same thing.
In order to be successful as a service provider, we need to truly understand our customers. When we can get our minds deep into the businesses of our key customers and understand them so well that we could probably go and work there, then we develop a unique perspective on our customer’s needs that is priceless.
This perspective enables us to develop services that truly do serve the needs of our customers in a way that not only differentiates us from the competition, but that really creates value for our customers. When we can do that, there really is every reason that those customers should buy from us. The role of Business Relationship Manager is tasked with developing that perspective for our key accounts – some organisations call this role the Account Manager. But don’t get confused: although we do want to sell services, this role is much more than a sales role.
The Business Relationship Manager represents our organisation to our customers and also does the reverse i.e. it represents our customer’s interests internally. This role would work closely with the owner of the Service Catalogue (Product Manager) to get ideas for new services properly considered via the Service Portfolio Management process.
Tip – The Product Manager is the owner of the Service Catalogue or a sub-set of the catalogue known as a Line of Service. Large organisations would have more than one Product Manager. Don’t get this role confused with the owner of the Service Catalogue Management process.
In much the same way that there is an overarching spine process (Transition Planning & Support) that glues together the other process activities within Service Transition, so we have an equivalent process here in Service Design. This process functions much like the Project Office in PRINCE2 (Project Management guidance).
For each new service design, the process performs the following activities:
- Planning & Coordination
- Review & Handover
Planning and coordination involves coordinating the design activities carried out by all the other design processes. When all design activities are complete, this process (Design Coordination) is responsible for conducting a final review of the design, specifications and plans. It then assembles the SDP (Service Design Package) and formally hands it over to Service Transition.
In addition to the above, the process is also concerned with setting design policy, managing design risks, planning the best use of resources and capabilities across multiple projects and improving the effectiveness and efficiency of Service Design as a whole.
Often described as a ‘balancing act’, Capacity Management is responsible for ensuring that sufficient capacity – bandwidth, storage and throughput – is available to support the current and future needs of the organization.
The process seeks to balance supply against demand – working with the Demand Management process – and also seeks to balance cost against capacity. In other words, the process recognizes that you can always purchase more capacity (storage, bandwidth etc) but it might not always be wise to do so.
For example, it doesn’t matter how big the user’s mailboxes are, they will always fill them up. That’s a fact; and it is an application of Parkinson’s Law to the IT world. So providing bigger mailboxes is definitely not the answer to that particular capacity issue. Instead, we need to be more concerned with affecting user-behaviour – that’s what is meant by Demand Management.
The process beaks-down into three sub-processes:
- Business Capacity Management
- Service Capacity Management
- Component Capacity Management
This sub-process is concerned with the future of the business. It is responsible for modelling business growth and ensuring that provision for that growth is properly planned. It has access to important business data including the Business Plan and it is required to ensure that sufficient capacity always exists to cope with the various alternative futures the business may be contemplating at any particular time.
This sub-process is closely related to the subject of Demand Management. Demand Management is all about trying to understand varying customer demand for services and ensuring that adequate capacity (storage/throughput) exists to handle it. Sometimes this is achieved by simply shaping (regulating) user behaviour. A simple example of this would be the introduction of flexible working hours to naturally spread demand over a longer period. Service Capacity Management is concerned with the end-to-end provision of capacity for the services offered to the business.
This sub-process is concerned with the bits and bytes of the infrastructure. It is concerned with monitoring file-systems as they grow; it is concerned with monitoring bandwidth; it is concerned with monitoring processors (CPUs). It looks for capacity bottlenecks and ensures that solutions are introduced.
All three sub-processes are involved in the following activities to a great or lesser extent:
Tuning involves monitoring the infrastructure, analyzing the gathered data, tuning variables in the infrastructure and implementing various control policies.
There are very many variables in the infrastructure that could be tuned to optimize the provision of capacity. For example, log file sizes might be reduced; TCP/IP Windows might be adjusted and so on.
There are several different types of modelling activities the process would be involved in including analytical modelling (based on mathematical principles like queuing theory). Here, the optimum required capacity to cope with the current demand for services could be identified and perhaps even brought on-stream seamlessly and automatically for example, by utilising technologies such as VMware.
This activity attempts to predict the effect of the introduction of a new application into the existing infrastructure.
The process makes use of the CMIS to record information from the three sub-processes and to model the growth of the business over time.
Tip – Don’t get confused between the CMIS and the CMS; they are separate information systems that both live inside the SKMS (Service Knowledge Management System).
The capacity plan is a key output of the process which considers the possible alternative futures for the business and makes capacity recommendations for each.
Generally, this is an annual activity tied up with the production of the annual budget by Financial Management; however, the capacity plan may be revised should it be required to plan for the support of new services to be introduced into the live environment.
It is the people at the top of the organization – normally, the directors – that are ultimately responsible for the organisation’s data. This process is concerned with fulfilling certain of the important legal obligations of the organisation in relation to the collection, storage and distribution of its data.
The Information Security Management process is concerned with the confidentiality, integrity, availability and authenticity of data.
- Confidentiality – only the required people can see it
- Integrity – the trustworthy-ness of the data
- Availability – there when it’s needed
- Authenticity – external data transactions can be trusted
As such, the process has close links with Availability Management (concerned with availability issues) and Access Management (concerned with confidentiality issues).
It is specifically responsible for devising the Information Security Policy (ISP) which should be an integral part of the overall Security Policy of the organization. Communication of the policy is an important responsibility of the process. Let’s face it, one of the most common reasons that people fail to follow organisational policy is that they don’t know what it is.
The process is also concerned with identifying and assessing risks relating to data security and imposing security controls to mitigate against such risks. The process uses the CRAMM (CCTA Risk Analysis and Management Method) technique to evaluate and manage risks.
The process uses the Security Management Information System (SMIS) to keep a record of policies, reports, controls and risks.
Tip – The Information Security Management process is one of several ITIL® processes involved in Risk Management; it is worth noting that both ITSCM and Availability Management are also involved.
Availability Management is concerned with resilience – ensuring that we have sufficient resilience (fault-tolerance) in the infrastructure to cope with component failure in such a manner (by masking the effect) that the SLA (Service Level Agreement) remains unaffected.
Availability is defined as the percentage of Agreed Service Time that a Service is actually available. The calculation is pretty straightforward:
Agreed Service Time
So notice that 100% availability is not the same thing as 24 x 7. In fact 24 x 7 might be a nice buzz-phrase, but technically, it is not really achievable in practice. The best many operations hope to achieve is 99.999% availability – often referred to as the five nines of availability.
You could spend a lot of money making use of the principle of redundancy to increase resilience by eradicating single points of failure (SPOF), for example by using technologies such as RAID, clustering, mirroring, duplexing etc. So be aware that the process is not trying to increase resilience to the levels possible, but it is very specifically concerned with providing the level of resilience that is needed to meet the requirements specified in the SLA – and to do so in a cost-effective manner.
Here are some techniques used by Availability Management:
- CFIA – Component Failure Impact Analysis
- FTA – Fault Tree Analysis
- SFA – Service Failure Analysis
- TOP – Technical Observation Post
CFIA is a method of assessing the impact of component failures i.e. answering the question: which services would be affected if a specific component in the infrastructure were to fail? The analysis provides the answer to this question for each component in the infrastructure. The usefulness of the technique is that it can help to identify critical components that may need additional resilience to be added.
FTA is an analysis technique that uses logic gates to represent the infrastructure. It allows the application of logic to be applied to quickly assess the knock-on consequences of the failure of a component of the infrastructure.
SFA involves getting a team of technical experts together following a service outage in order to take on-board any lessons that have been learned during the failure and the process of restoring normal service operation.
TOP also involves getting a group of technical experts together to make recommendations, but this is done during the event rather than afterward.
There are a number of standard metrics used by the process:
- MTBF – Mean Time Between Failures
- MTRS – Mean Time to Restore Service
- MTBSI – Mean Time Between Service Incidents
The Availability Plan is the main output of the process. It will be updated regularly – at least annually, in line with budgets, but perhaps more regularly as appropriate for the organisation. Any proposed new services or changes to existing services may impact the Availability Plan, so representation of this process on the CAB is desirable.
The actual changes required to implement the plan will also be subject to change control in the normal way i.e. Requests for Change (RFC) will be raised by Availability Management process, and go to the Change Management process for consideration in the normal way.
This process is simple and straight-forward – it concerns the production and maintenance of the service catalogue; the service catalogue being the customer-visible portion of the service portfolio. It may offer several different views of the same information, typically a business view (Business Service Catalogue) and a technical view (Technical Service Catalogue). Ensuring that an accurate service catalogue is produced and maintained has many benefits to other areas of ITIL®.
The service catalogue contains complete details of all the services in the live environment and those being prepared to run i.e. in the design phase. New services enter the catalogue when resources have been committed to the project i.e. when the service has reached the [_chartered _]state – see the Service Portfolio Management Process (above).
Services consist of a Core Service (CSP) plus Service Level Packages (SLP) that provide additional levels of utility (functionality) and/or warranty (gold, silver, bronze etc). These additional levels of warranty/utility are purchase options; and the idea is to manage the service ‘as a product’ hence the ITIL® role of Product Manager. The availability of different service level packages for the same core service technically makes the offering a Line of Service (LOS).
Product Managers are the experts on Lines on Service and are responsible for the following:
- Developing and managing services through the lifecycle
- Managing services as a product over their entire lifecycle
- Subject matter experts on Lines of Service (LOS) and the Service Catalogue
- Coordination and focus around the Service Catalogue, of which they maintain ownership
Product Managers work closely with Business Relationship Managers (BRM) who represent the customer – in what many organisations call an Account Manager capacity; and we can think of the Service Catalogue as providing substance for discussions with prospects around the product offerings in the catalogue. Business Relationship Managers are responsible for mapping user profiles onto Service Level Packages in the catalogue i.e. making appropriate product recommendations.
The ITSCM process needs to be seen as part of an organisation’s wider Business Continuity Management (BCM) process. In other words, ITSCM is the IT part within BCM. It is concerned with ensuring that the key IT systems either remain operational, or are restored to normal operation within agreed business timescales, in the event of a major disaster such as fire, flood, terrorism etc.
In order to achieve the goal of immunity or restoration, the mission-critical services and systems need to be first identified - in ITIL®, these key services are known as Vital Business Functions (VBF) – and the overall approach needs to be agreed with the business. In order to do this, a Business Impact Analysis (BIA) would be carried out seeking to address the question of what would happen to the business in the event of a catastrophic loss of IT services. This analysis provides important input into the decision concerning the recovery strategy that needs to be employed.
There are a number of strategies in common use. Each of these strategies concerns recovering IT services with a specific timescale.
Getting the ITSCM Plan ‘right-sized’ for the operation is a vitally important aspect of the exercise. These days, with technology so advanced, it is possible to provide the business with a whole host of options for recovery. These include …
- Immediate Recovery (Hot Standby) – instant or almost instant recovery
- Fast Recovery (also Hot Standby) – recovery in less than 24 hours
- Intermediate Recovery (Warm Standby) – recovery within 24 – 72 hours
- Gradual Recovery (Cold Standby) – recovery in greater than 72 hours
The options above are popular and pragmatic and most organisations have a plan that would fit into one of the options because they are doable. There are other (less popular) options though, including :
- Do Nothing – a plan for the business to go bust!
- Reciprocal Arrangements – with another company/operation i.e. you can use our IT if we can use yours.
- Manual Backup – revert to paper systems (yuk!)
There are many options to choose between for providing technology and architectures that are capable of being recovered very quickly – in fact, possibly even instantly – so such considerations should ideally be built-in to the design of the infrastructure from the outset. However, the cost of provision of a highly resilient infrastructure is a second factor to be taken into consideration in the construction of an appropriate strategy for ITSCM because, of course, our budget is not unlimited,
The business needs to recognise that there is a trade-off between investment costs and achievable recovery times. Understanding this trade-off and communicating it together with a proper assessment of business impacts allows the business to choose a recovery strategy that is right-sized for the organisation.
This process is responsible for recommending that strategy and then planning accordingly. The ITSCM plan is a key output of the process, and regular review and testing of the plan are key activities. Testing can take different forms, from simple walk-through reviews to full-blown testing with everyone in the operation involved in simulating a disaster and invoking recovery procedures.
Good times to test the plan include: immediately after the initial formulation; regularly (at least annually); and following any major change.
The Service Level Management process is responsible for negotiating and agreeing Service Level Agreements (SLA) and Operational Level Agreements (OLA). The responsibility for negotiating Contracts/Underpinning Contracts, which was part of this process in V2, has now been stripped away; and is now the responsibility of the Supplier Management process.
A Service Level Agreement is a written agreement between the Customer and Service Provider that documents service level targets. An Operational Level Agreement is an agreement between internal technical teams, and it underpins the SLA. A Contract or Underpinning Contract (UC) is a legally-binding agreement with an external organisation that also underpins the SLA.
The process begins with documenting Service Level Requirements (SLR) – these represent the warranty (guarantee) aspects of the service. After the necessary negotiations, the process will arrive at an understanding with the business, or organisation, that will form a draft agreement and will become the basis of the SLA itself.
Three Types of SLA
- Customer Based – focused around the needs of one particular customer
– Service Based – focused on an individual service
– Multi-Level – a more complex structure with different levels for different services and/or customer groups
The Service Level Management process works in conjunction with other processes to arrive at an appropriate agreement. In addition to the Supplier Management process, which is responsible for negotiating the necessary contracts with external operations that underpin the SLA, the Availability Management process is responsible for the necessary planning to achieve the agreed levels of service, and the Financial Management process is responsible for budgeting for any necessary investment identified by the Availability Management process.
Once an SLA is in place, this process (SLM) is concerned with monitoring and measuring service level achievements, and broadcasting them to all relevant parties. Additionally, SLAs are regularly reviewed with the customer and updated where and whenever necessary.
Supplier Management is responsible for sourcing, vetting, negotiating contracts and monitoring the performance of external partners in Service Management, and renewing or terminating contracts as necessary. A contract is a legally-binding agreement and we will have them in place with external organisations we are working with. Some contracts are said to underpin the Service Level Agreement (SLA) and such a contract is therefore known as an Underpinning Contract (UC).
Previously, in V2, the activities of this process (Supplier Management) were a responsibility of the Service Level Management process, but from V3 on, Supplier Management is a process in its own right. A good decision, because the skills necessary for contract negotiations with external organisations are quite different to those required for the internal negotiations with which SLM is most concerned.
The process maintains all the necessary contract detail in the Supplier and Contacts Management Information System (SCMIS) – a component of the SKMS.
When performing a service transition such as the introduction of a new service into the live environment, we are really involved in running a transition project and we therefore need a process to be responsible for the top-level planning of the project. In a nut-shell, that is what this process does. It ensures there is a coordinated approach to service transitions and it effectively operates in much the same way as the Project Office within the PRINCE2 guidance.
Tip – PRINCE2 (Projects in Controlled Environments) is a source of Best Practice for Project Management and contains relevant additional guidance for Service Transition.
As a top-level process, it is accountable for the overall transition goals including delivering the service within agreed costs and timescales – a typical project management message that you may recognise i.e. to ensure the project comes in on time and within budget and also ensures the service does what it should do (quality).
Specific responsibilities of the process include:
- Planning and Coordination of All Transitions
- Establishing Services within agreed Parameters (Time, Quality and Cost)
- Identifying and Managing Risks
In particular, coordination involves making best use of resources and capabilities, balancing them across the various transition projects that may be in progress at any particular time, and also working with project managers responsible for business change to integrate service transitions within the overall business change process.
The main thing to remember about this process is that, in addition to actually introducing releases, it is also responsible for ensuring that the necessary testing that precedes a release is properly completed. Now don’t get confused, there is a separate Service Testing and Validation process that typically performs the testing, but Release & Deployment Management it gets done.
The reason for this distinction is obvious when you consider the stated purpose of the process i.e. to deploy releases whilst ‘protecting the integrity of the existing services’. This basically means that we do not engage in deployments unless we have a very high degree of confidence that the transition will be successful first time. And when you think about that, it is obvious why testing is necessary and therefore why this process is accountable. Quite simply, it is the only way we can possibly have that level of confidence.
- Major Release – new hardware and/or software with significantly increased functionality
- Minor Release – minor updates
- Emergency Release – quick fix for bugs and/or known errors
It is important that the organisation’s release policy spells out the correct balance between cost, stability and agility. For some services, stability may need to be maximised even if that means more testing and therefore more costs are incurred. For other services, it may be more important to deliver functionality very quickly (i.e. being agile) even if that means stability might be jeopardised – it is all a matter of policy.
- Push or Pull
- Big Bang or Phased
- Automated or Manual
When considering release options, the process will consider a ‘push’ versus a ‘pull’ approach i.e. whether to ‘push’ out the release to users or to install on demand. It will consider a ‘big-bang’ versus a ‘phased’ approach i.e. whether to do it all in one go or to use several separate release phases. Finally, it will consider whether to use an ‘automated’ or a ‘manual’ method of handling the release.
If you think about the progress of a change or release from the initial request through to the actual deployment, it is clear that there are various distinct stages that may each be required to be evaluated and approved; for example, build, test and deployment.
Even within the deployment stage alone, where the deployment option chosen is a phased approach, there may be a need to approve the progress of the deployment from phase 1 to phase 2 and so on. Supposing that, despite our extensive testing, the phase 1 deployment has not gone quite so well as we expected, should we go on to phase 2 or should we roll back? There could, of course, be a case for either decision. But the point is that an evaluation would be necessary in order to make the right decision – and that’s what this process does.
Each phase of a release typically involves a little cycle consisting of baseline, deploy and evaluate activities. Release and Deployment Management does the deployment and this process (Change Evaluation) does the evaluation i.e. it provides a Change Report so the Change Management process is equipped to authorise or reject the progress of the release.
Note: For completeness, in a phased release, it is the Service Asset and Configuration Management process (discussed later) that performs the baselining activity.
There are all kinds of tests that might be carried out in support of a service transition including (but not limited to):
- Functional Testing … Does it work properly?
- Operation Testing … Will it work in the live environment?
- Performance Testing … Is it fast enough?
- Integration Testing … Does it work with other systems/services?
Quite simply, this is the process that performs the testing. It is a lifecycle wide process and can therefore be used at any time to validate the ‘fitness for purpose’ (utility) and/or ‘fitness for use’ (warranty) of any service. However, the process is used extensively by the Release and Deployment Management process in the support of a release.
We said that testing was very important when performing any kind of significant change and that Release and Deployment Management was accountable for the testing – and this is true – but this process (Service Validation & Testing) actually maintains the test environment (including test data, test scripts and test models) and actually performs the necessary testing, providing reports that are utilised by the Release and Deployment Management process.
This process is responsible for the initial population and subsequent maintenance of the CMDB – you CAN have more than one (for example, a testing CMDB and a live CMDB) if it is appropriate to your organisation. Either way, the CMDB live inside the SKMS (Service Knowledge Management System).
Here are the process steps:
- Status Reporting
The introduction of this process and the corresponding database does need to be thought through very carefully before actually starting, and typically, the Planning stage of the process might take approximately 3-6 months – perhaps a little less these days, now that we have such excellent tools available for auto-discovery and recording of complex infrastructures.
Identification is the business of deciding exactly which items in the infrastructure will come under Configuration Control i.e. which items will become Configuration Items (CIs) – and then labelling them.
Control involves the population and maintenance of the CMDB itself. The step is called ‘control’ because it is synonymous with Change Control i.e. nothing will get changed in the live environment without a record of the change being made – hence changes are controlled.
Status Reporting (also known as Status Accounting) permits a complete and accurate record – a cradle to grave history – to be generated for any item (CI) under configuration control, so we can see exactly where any CI is within its lifecycle, and we can also see any planned updates.
Finally, Verification involves the regular auditing of the live environment to ensure that it matches the logical model held within the database.
Change is initiated by the raising of an RFC (request for Change) and, in principle, anyone in the organization can raise one – this includes users. The process evaluates RFCs, considering whether or not to approve them for implementation.
As we previously discussed, all changes need to be managed i.e. assessed, authorised, planned, implemented and validated. But, in order to strike the correct balance between maintaining control of change whilst remaining flexible and agile so that we don’t unnecessarily obstruct change, there are actually, three types of change recognized by ITIL® and they are each handled slightly differently.
- Standard Change – pre-authorised by the process
- Normal Change – goes before the CAB
- Emergency Change – goes before the ECAB
Standard Change does not need approval – it is simply performed and recorded in the CMDB. This allows for changes to be pre-approved where the risks are well understood; for example, a request for a new printer or a replacement monitor. Such changes would typically not need to be discussed at the CAB. Having said that, the decision about how to define the changes that actually follow which of the three routes mentioned above is a policy decision and it may vary from organisation to organisation.
Normal changes are discussed by the Change Advisory Board (CAB) which will make the recommendation. Strictly, the approval of change is done by the Change Authority (in practice, this is often the Change Manager). The Change Manager role is an important role and, in many organizations, the role will have overall accountability for all aspects of change. In addition, part of the responsibility of the Change Manager role is to ‘chair’ the CAB.
Tip – In ITIL® all processes have owners. The Change Manager is the owner of the Change Management process and this role has overall accountability for the process.
The ECAB (Emergency CAB) is effectively a subset of the CAB and it meets to discuss emergency changes. Again the Change Manager will effectively ‘chair’ the meeting however, this meeting might be quite informal – in practice, it is often a telephone conference conversation.
Knowledge Management is ‘getting the right information to the right people at the right time’ so they can make the right decision. That statement is very easy to remember and it is also a very useful definition.
In ITIL® we have an SKMS (Service Knowledge Management System) that contains information systems such as the AMIS (Availability Management Information System), CMIS (Capacity Management Information System and SMIS (Security Management Information System) and there are others too.
These information systems contain databases that are populated by various ITIL® processes. Getting the right information to the right people at the right time involves allowing them access (with suitable controls) to the information contained in the SKMS.
The SKMS contains Management Information Systems (MIS) including:
- CMS (Configuration Management System)
- AMIS (Availability MIS)
- CMIS (Capacity MIS)
- SMIS (Security MIS)
- SCMIS (Supplier & Contract MIS)
- Service Portfolio
Then, the Management Information Systems contain databases, for example, the CMS contains:
- Incident Database
- Problem Database
From the above, you can see that there are 3 distinct levels in the SKMS: the level of the database container, the level of the information system container and the very top-level of the knowledge container, the SKMS itself. So, we can see that the structure of the SKMS conforms to a conceptual model that you may have previously encountered in some other context i.e. the D-I-K-W Model.
- D … Data
- I … Information
- K … Knowledge
- W … Wisdom
The difference between data and information is context i.e. information is data set into context. Similarly, the difference between information and knowledge is further context. To use an analogy: data is like the words in a message, information is like a sentence and knowledge is the meaning of the whole communication.
- 60 … This is an example of data
- [_ Filesystem 60% Full _] … This is information
- We will run out of space in 30 days … Knowledge
Modern toolsets allow us to get the information (held within the various information systems inside the SKMS) into context so we can understand the meaning of the data we have been gathering.
The SKMS does not contain wisdom – that is the human judgement applied to the knowledge. What would it be wise to do if our filesystem was going to fill up in 30 days? Add a disk and grow the filesystem before it happens – that’s wisdom.
Of course, the SKMS needs to be built and maintained and that is part of the job of this process i.e. to ensure that this is done, bearing in mind that many ITIL® processes actually populate and maintain the individual component databases and information systems.
Using suitable tools to browse, query and search the SKMS, the data held within the various databases is set into context so that it becomes meaningful information. This information can be presented in useful and understandable format, such as graphs, bar charts and so on, and by analysing that information, wise decisions can be made.
We briefly discussed this process as an example at the beginning when we were drawing the distinction between processes and functions. Now, here are the actual steps of the process, as defined in the guidance:
- Functional Escalation
Logging – involves recording the incident in a database
Categorisation – hardware or software; which application etc
Prioritisation – involves setting an initial priority
Analysis – is an initial attempt at resolution
Functional Escalation – getting the call to the right specialist
Monitoring/Tracking – keeping an eye on incident progress
Closing – requires confirmation from the user
During the categorisation activity, the Service Desk analyst is attempting to identify which specific items in the infrastructure are actually affected. This requires a certain amount of skill in decoding what is being said by the user and then matching the information against records in our CMDB. You will remember that the CMDB is one of many databases that comprise the CMS (Configuration Management System).
The priority of an incident is set according to two factors: impact and urgency:
- Impact … the effect on the business/operation
- Urgency … how quickly it needs to be resolved
It is possible for an incident to be high-impact (e.g. lots of users affected) but low urgency (i.e. plenty of time available to fix), just as the reverse situation – low-impact, high-urgency – is also possible.
When people call the service desk, which is defined as the ‘single point of contact for all users of IT services’ they do so for all kinds of reasons.
- They need help with software
- They forgot their password
- Something is broken
- They need a new laptop
- They want to make a complaint
The best way to think of these types of demands is that they are either incidents or they are not. If the call is not an incident, then nothing is wrong with our services and therefore, nothing needs to be diagnosed or fixed. That type of call i.e. where nothing is wrong, is not an incident; it is a service request.
With service requests all we have to do is log them, track them and, subject to appropriate authorisations being in place, escalate them to the appropriate group to fulfil the request and that’s exactly what this process does.
So where does a password reset fit: is it an incident or a service request? You could actually argue the toss either way and there are certainly many organisations that deal with them as incidents. There is nothing wrong with that if that is your organisation’s policy.
Either way, the call gets logged and dealt with within agreed timescales, so it should not concern the user – either way – as to how the call is categorised. But personally, I would classify them as service requests simply for management information purposes. That way, our incident stats are much more meaningful and useful to roles that make use of the data including the Service Level Manager, the Incident Manager and the Problem Manager.
The Problem Management process is specifically responsible for adding data to the Known Error Database (KEDB) – a database to be found in the CMS. In particular, it is responsible for producing and documenting workarounds. This is a key output of the process
A second key output of this process is the production of Requests for Change (RFCs) to get permanent fixes initiated in the infrastructure.
- Production of Workarounds
- Production of RFCs
Analysis techniques used by this process include Kepner Tregoe (a problem-solving methodology ) and the use of Ishikawa Diagrams (a brainstorming technique).
Problem Management is involved in Trend Analysis – a method of identifying the existence of underlying problems. If a particular user is continually experiencing the Blue-Screen-of-Death syndrome or a particular router is continually getting into an error condition, then these are examples of trends.
The existence of a trend almost certainly implies an underlying problem and this process would be responsible for finding that cause and doing something about it i.e. producing a workaround or an RFC (or both).
The process is both reactive and proactive. Reactive Problem Management investigates underlying causes after an incident or incidents have occurred; Proactive Problem Management attempts to uncover problems that have not yet caused incidents. When a car manufacturer recalls a particular model to get a component of the steering or the brakes changed, that is an example of proactive Problem management in the real world.
Note: For much more on the subject of Problem Management, please see my book [+ Problem Management for Newbies+] which is now available on Kindle.
Imagine for a moment that you are driving along in your car and the oil light or the petrol light illuminates on the dash. Everything seems fine, the car has not stopped and indeed, performance has not been affected at all. But if you don’t pull in at the next service station and do something about that warning, you are going to finish up with a service interruption.
The petrol light is not notifying you of an incident; it is notifying you that something ‘significant’ has changed state and it is a very good example of what we mean by an event. An event is defined as: a ‘change of state that has significance’ for a CI or a service. There are very many pieces of hardware, software and firmware that are capable of generating event messages, often in SNMP (Simple Network Management Protocol) format, that can notify us of ‘significant’ changes of state that have not yet caused incidents.
Often, this process is fully automated. Using programmable tools, we set our own rules (known as correlation rules) to specify what we want to happen when an event is detected. Of course, the relevant action will depend upon the level of significance of the event itself. Some events have a very low level of significance, for example, a user has logged on; other events, like a warning that a filesystem is nearly full (that’s a bit like running out of petrol) have a much higher level of significance.
So the job of this process is to detect these events, make sense of them and then trigger the appropriate control action – whatever that happens to be.
In the case of the user logging in, the appropriate action might simply be to log the event. But with the filesystem warning, the appropriate action could be to raise an incident so as to get a human involved. With modern technology, we might go a lot further with our automated responses. Staying with the same example, we might also have a prepared disk standing by and a script that could be invoked to add it to the filesystem.
It can be a challenge to get the right tools and to program them correctly. In particular, getting the level of filtering right (some events are of such a low level of significance that they may be usefully ignored) is very important. But of course, the more you get into Event Management, the more proactive you are being.
Access Management concerns the physical granting (and revoking) of rights and privileges so that people can gain access to the software, systems and services they need to carry out the responsibilities of their roles.
The process does not decide who can have access to what; that is a policy decision made by another process i.e. the Information Security Management process. However, this process (Access Management) may be thought of as the execution arm of security.
Ideally, we would integrate the process with the organisation’s HR Function because, hopefully, they will know when we have new starters joining the company and also what their roles will be. When we are informed of that kind of information, in advance, we are able to create the various accounts and logins, and grant the necessary access rights that will be needed by those people.
Similarly, when people get promoted, demoted, or perhaps they leave the organisation, for one reason or another or, possibly, have died, access rights may need to be granted or revoked and HR is ideally placed to provide us with the necessary notifications. The same is true for contractors who work for the organisation for certain periods of time: they may need access to our systems just for those periods.
Of course, if for some reason, after starting work for us, a person does not have access to the necessary systems, they would call the Service Desk. The Service Desk would be expected to log the matter as a Service Request and escalate it to the appropriate group for fulfilment (this would involve someone in either the IT Operations Management or the Applications Management functions depending on the organisations policy).
However, before escalation, the Service Desk would check the identity of the individual and also check whether the
person’s role is allowed access to the requested systems. Both of these checking steps are a part of the process, along with the actual granting of rights.
Earlier, we discussed the Deming Cycle (Plan, Do, Check, Act) – this could really be thought of as the philosophy that underpins the discipline of Continual Service Improvement (CSI) – and the 7 Step Improvement Process is really ITIL’s ® version of it.
Here are the steps:
- What is the Vision?
- Define what will be Measured
- Gather the Data
- Process the Data
- Analyze the Information
- Present and use the Information
- Implement the Improvement
The key to understanding this process is to recognise that the activities are carried out by other parts of ITIL®.
The vision is, of course, set by Service Strategy and the ‘defining what should be measured’ step is carried out as part of the design of a new service i.e. at the design stage, we don’t just design the service, we also design the measurement methods too; it is one of the 5 aspects of Service Design – remember?
Similarly, ‘gathering the data’ is done by the many processes that perform various activities and populate our databases with performance data. For example, the Incident Management process populates the Incident Database. This (together with data from many other processes) is what is being gathered as we go about our normal Business-as-Usual (BAU) operations.
When we have an SKMS in place, we have the necessary tools to crunch all of the data held in those databases and process it into information that we can present and analyse and, in that analysis, we are looking for improvement opportunities.
During analysis, we would be asking question such as these:
- Do we see any clear trends?
- Are they positive or negative?
- Are they good or bad?
- Are we operating as planned?
- Are we meeting our targets?
- Are any improvements required?
Once improvement opportunities are recognised, they get logged in the CSI Register which is also held within the SKMS. The CSI Manager, who has a budget to work within, will then select the best opportunities from the register and raise the necessary RFCs to get them implemented.
It can be a bit overwhelming to read through 26 process descriptions and get your head around them and 4 functions too. The experience is something akin to trying to learn how a car works by studying all of the component parts and that’s why, in this book, we looked at an overview of IT Service Management first, using Version 2 of ITIL® as grist for the mill, so to speak.
We have encountered the 4 Ps once or twice already. You may recall that there are actually two sets of 4 Ps in ITIL® – one set in Service Strategy (Perspective, Position, Plan and Patterns); the other in Service Design (People, Processes, Products and Partners). Well, the latter is a very good way of thinking about what IT Service Management is, at the top level.
IT Service Management is: People working with Partners using Processes embedded into Products (our integrated toolset). The people are divided into functions (we discussed 4 functions); partners are external organisations that play a part in the delivery of our services; products, in this context, are the tools (software) we are using to perform the processes we discussed.
In practice, the adoption of IT Service Management in any particular organisation means cherry-picking from the guidance. You don’t have to adopt all of the processes and you don’t have to copy the exact steps of any of the processes either. The overall message is that you should ‘adapt and adopt’ the guidance to the specific needs of your organisation.
In practice, your adaptation of these principles will be mixed in with practices derived from a variety of sources including your own experience and learning as well as guidance from other sources of Best Practice such as PRINCE2 (Project Management) Six Sigma (Process Improvement) COBIT (IT Service Management) and so on – there are many relevant additional frameworks you might profitably utilise.
When it comes to introducing IT Service Management into your organisation, you might decide to appoint a project manager and treat the whole thing as a project – that’s certainly a good approach. However, you might instead like to think about using the CSI Approach that we encountered in the Continual Service Improvement book i.e. instead of running a project, use the ITIL® guidance as your vision and work toward it by initiating little cycles of improvement.
Here is the CSI Approach again:
- What’s the Vision? … ITIL® Can Provide it!
- Where are we now? … A Baseline Assessment
- Where do we want to be? … A Target
- How do we get there? … A Plan
- Have we arrived? … A Measurement
- How to maintain Momentum? … Next Improvement
There is no right way to do this, except what is right for your organisation. But one way is to think in terms of processes. Start by baselining: which of the processes we have discussed do you actually have in place and how mature are those processes? There are process maturity frameworks that can help you decide, including the one in the appendix of the ITIL® Service Design book.
Then set yourself a measureable target; perhaps this might be to introduce a new process or to improve one of your existing processes – for example, are you doing Problem Management or Change Management as well as you might?
Use the guidance to help you with the design or redesign of the process you intend to introduce, or improve, and then produce a plan for its introduction. Make sure you involve the people who will be affected by the changes in the discussions up-front and genuinely take their ideas into account. Don’t make the mistake of thinking the books must be right; they are a good source of guidance but, as we have discussed, they are not the only source.
Get your plan together and implement it whilst measuring your actual results. Tweak it if you need to (remember Plan-Do-Check-Act) – for that matter, keep tweaking it if you need to, until you get that one process to the level of maturity you require. Then stop, consolidate, drive the improvements into the organisation’s working methods. And – when you are ready and not before – select another process and repeat the improvement cycle.
Always keep the vision in mind and remember to do what is right for your organisation. Don’t be rigid in your interpretation of what the books say. Use ITIL® as the guidance it was intended to be – adapt and adopt the principles and processes to the needs of your organisation and you are sure to enjoy great success.
In compiling the glossary, a number of difficult decisions were made regarding which definitions to include and exclude. This scoping activity needed to be done because the official ITIL® site manages a huge glossary of terms. It is believed that the following list of terms, whilst not exhaustive, should be very useful to the reader.
(ITIL Service Design) The structure of a system or IT service, including the relationships of components to each other and to the environment they are in.
(ITIL Service Strategy) Any resource or capability. The assets of a service provider include anything that could contribute to the delivery of a service.
(ITIL Service Design) Ability of an IT service or other configuration item to perform its agreed function when required.
(ITIL Continual Service Improvement) (ITIL Service Transition) A snapshot that is used as a reference point.
Proven activities or processes that have been successfully used by multiple organizations. ITIL® is an example of best practice.
(ITIL Service Strategy) Justification for a significant item of expenditure. The business case includes information about costs, benefits, options, issues, risks and possible problems.
A process that is owned and carried out by the business. A business process contributes to the delivery of a product or service to a business customer.
(ITIL Service Strategy) A segment of the business that has its own plans, metrics, income and costs. Each business unit owns assets and uses these to create value for customers in the form of goods and services.
(ITIL Service Strategy) The ability of an organization, person, process, application, IT service or other configuration item to carry out an activity. Capabilities are intangible assets of an organization.
(ITIL Service Transition) The addition, modification or removal of anything that could have an effect on IT services. The scope should include changes to all architectures, processes, tools, metrics and documentation, as well as changes to IT services and other configuration items.
Change Advisory Board (CAB)
(ITIL Service Transition) A group of people that support the assessment, prioritization, authorization and scheduling of changes.
(ITIL Service Strategy) (ITIL Service Transition) A document that includes a high level description of a potential service introduction or significant change, along with a corresponding business case and an expected implementation schedule.
(ITIL Service Transition) A document that lists all authorized changes and their planned implementation dates, as well as the estimated dates of longer-term changes.
(ITIL Service Transition) A regular, agreed time when changes or releases may be implemented with minimal impact on services. Change windows are usually documented in service level agreements.
(ITIL Service Strategy) A document that contains details of a new service, a significant change or other significant project. Charters are typically authorized by service portfolio management or by a project management office.
Configuration Item (CI)
(ITIL Service Transition) Any component or other service asset that needs to be managed in order to deliver an IT service. Information about each configuration item is recorded in a configuration record within the configuration management system (CMS) and is maintained throughout its lifecycle by service asset and
Configuration Management System (CMS)
(ITIL Service Transition) A set of tools, data and information that is used to support service asset and configuration management. The CMS is part of an overall service knowledge management system and includes tools for collecting, storing, managing, updating, analysing and presenting data about all configuration items and their relationships.
Critical Success Factor (CSF)
Something that must happen if an IT service, process, plan, project or other activity is to succeed. Key performance indicators are used to measure the achievement of each critical success factor.
(ITIL Continual Service Improvement) A database or structured document used to record and manage improvement opportunities throughout their lifecycle.
Definitive Media Library (DML)
(ITIL Service Transition) One or more locations in which the definitive and authorized versions of all software configuration items are securely stored. The definitive media library may also contain associated configuration items such as licences and documentation.
Emergency Change Advisory Board (ECAB)
(ITIL Service Transition) A subgroup of the change advisory board that makes decisions about emergency changes. Membership may be decided at the time a meeting is called, and depends on the nature of the emergency change.
(ITIL Service Operation) A change of state that has significance for the management of an IT service or other configuration item. The term is also used to mean an alert or notification created by any IT service, configuration item or monitoring tool. Events typically require IT operations personnel to take actions, and often lead to incidents being logged.
A team or group of people and the tools or other resources they use to carry out one or more processes or activities – for example, the service desk.
Ensures that policies and strategy are actually implemented, and that required processes are correctly followed. Governance includes defining roles and responsibilities, measuring and reporting, and taking
actions to resolve any issues identified.
(ITIL Service Operation) (ITIL Service Transition) A measure of the effect of an incident, problem or change on business processes. Impact is often based on how service levels will be affected. Impact and urgency are used to assign priority.
(ITIL Service Operation) An unplanned interruption to an IT service or reduction in the quality of an IT service. Failure of a configuration item that has not yet affected service is also an incident – for example, failure of one disk from a mirror set.
A service provided by an IT service provider. An IT service is made up of a combination of information technology, people and processes. A customer-facing IT service directly supports the business processes of one or more customers and its service level targets should be defined in a service level agreement.
IT Service Management (ITSM)
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.
IT Service Provider
(ITIL Service Strategy) A service provider that provides IT services to internal or external customers.
IT Steering Group (ISG)
(ITIL Service Design) (ITIL Service Strategy) A formal group that is responsible for ensuring that business and IT service provider strategies and plans are closely aligned. An IT steering group includes senior representatives from the business and the IT service provider.
Key Performance Indicator (KPI)
(ITIL Continual Service Improvement) (ITIL Service Design) A metric that is used to help manage an IT service, process, plan, project or other activity. Key performance indicators are used to measure the achievement of critical success factors.
(ITIL Service Operation) A problem that has a documented root cause and a workaround. Known errors are created and managed throughout their lifecycle by problem management. Known errors may also be identified by development or suppliers.
Known Error Database (KEDB)
(ITIL Service Operation) A database containing all known error records. This database is created by problem management and used by incident and problem management. The known error database may be part of the configuration management system, or may be stored elsewhere in the service knowledge management system.
(ITIL Service Operation) The highest category of impact for an incident. A major incident results in significant disruption to the business.
(ITIL Continual Service Improvement) Something that is measured and reported to help manage a process, IT service or activity.
(ITIL Service Operation) Repeated observation of a configuration item, IT service or process to detect events and to ensure that the current status is known.
Operational Level Agreement (OLA)
(ITIL Continual Service Improvement) (ITIL Service Design) An agreement between an IT service provider and another part of the same organization. It supports the IT service provider’s delivery of IT services to customers and defines the goods or services to be provided and the responsibilities of both parties.
(ITIL Service Strategy) Using an external service provider to manage IT services.
(ITIL Service Operation) A cause of one or more incidents. The cause is not usually known at the time a problem record is created, and the problem management process is responsible for further investigation.
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. It 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.
(ITIL Service Transition) One or more changes to an IT service that are built, tested and deployed together. A single release may include changes to hardware, software, documentation, processes and other components.
(ITIL Service Transition) A set of configuration items that will be built, tested and deployed together as a single release. Each release package will usually include one or more release units.
(ITIL Service Transition) Components of an IT service that are normally released together. A release unit typically includes sufficient components to perform a useful function.
(ITIL Continual Service Improvement) (ITIL Service Design) A measure of how long an IT service or other configuration item can perform its agreed function without interruption. Usually measured as MTBF or MTBSI. The term can also be used to state how likely it is that a process, function etc. will deliver its required outputs.
(ITIL Service Transition) Actions taken to recover after a failed change or release. Remediation may include back-out, invocation of service continuity plans, or other actions designed to enable the business process to continue.
Request for Change (RFC)
(ITIL Service Transition) A formal proposal for a change to be made. It includes details of the proposed change, and may be recorded on paper or electronically. The term is often misused to mean a change record, or the change itself.
(ITIL Service Strategy) A generic term that includes IT infrastructure, people, money or anything else that might help to deliver an IT service. Resources are considered to be assets of an organization.
A possible event that could cause harm or loss, or affect the ability to achieve objectives
A set of responsibilities, activities and authorities assigned to a person or team. A role is defined in a process or function. One person or team may have multiple roles – for example, the roles of configuration
manager and change manager may be carried out by a single person.
A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. The term ‘service’ is sometimes used as a synonym for core service, IT service or service package.
Service Acceptance Criteria (SAC)
(ITIL Service Transition) A set of criteria used to ensure that an IT service meets its functionality and quality requirements and that the IT service provider is ready to operate the new IT service when it has been deployed.
(ITIL Service Design) (ITIL Service Strategy) A database or structured document with information about all live IT services, including those available for deployment. The service catalogue is part of the service.
Service Design Package (SDP)
(ITIL Service Design) Document(s) defining all aspects of an IT service and its requirements through each stage of its lifecycle. A service design package is produced for each new IT service, major change or IT service retirement.
Service Improvement Plan (SIP)
(ITIL Continual Service Improvement) A formal plan to implement improvements to a process or IT service.
Service Knowledge Management System (SKMS)
(ITIL Service Transition) A set of tools and databases that is used to manage knowledge, information and data.
Service Level Agreement (SLA)
(ITIL Continual Service Improvement) (ITIL Service Design) An agreement between an IT service provider and a customer. A service level agreement describes the IT service, documents service level targets, and specifies the responsibilities of the IT service provider and the customer. A single agreement may cover multiple IT services or multiple customers.
An approach to IT service management that emphasizes the importance of coordination and control across the various functions, processes and systems necessary to manage the full lifecycle of IT services. The service lifecycle approach considers the strategy, design, transition, operation and continual improvement of IT services.
A set of specialized organizational capabilities for providing value to customers in the form of services.
(ITIL Service Strategy) The complete set of services that is managed by a service provider. The service portfolio is used to manage the entire lifecycle of all services, and includes three categories: service pipeline (proposed or in development), service catalogue (live or available for deployment), and retired services.
(ITIL Service Strategy) An organization supplying services to one or more internal customers or external customers. Service provider is often used as an abbreviation for IT service provider.
(ITIL Service Operation) A formal request from a user for something to be provided – for example, a request for information or advice; to reset a password; or to install a workstation for a new user. Service requests are managed by the request fulfilment process, usually in conjunction with the service desk. Service requests may be linked to a request for change as part of fulfilling the request.
(ITIL Continual Service Improvement) (ITIL Service Design) The ability of a third-party supplier to meet the terms of its contract. This contract will include agreed levels of reliability, maintainability and availability for a configuration item.
A person who has an interest in an organization, project, IT service etc. Stakeholders may be interested in the activities, targets, resources or deliverables. Stakeholders may include customers, partners, employees, shareholders, owners etc.
Statement of Requirements (SOR)
(ITIL Service Design) A document containing all requirements for a product purchase, or a new or changed IT service.
(ITIL Service Design) (ITIL Service Strategy) A third party responsible for supplying goods or services that are required to deliver IT services. Examples of suppliers include commodity hardware and software vendors, network and telecom providers, and outsourcing organizations.
(ITIL Service Design) An IT service that is not directly used by the business, but is required by the IT service provider to deliver customer-facing services (for example, a directory service or a backup service).
(ITIL Service Transition) A controlled environment used to test configuration items, releases, IT services, processes etc.
Underpinning Contract (UC)
(ITIL Service Design) A contract between an IT service provider and a third party. The third party provides goods or services that support delivery of an IT service to a customer. The underpinning contract defines targets and responsibilities that are required to meet agreed service level targets in one or more service level agreements.
(ITIL Service Design) (ITIL Service Transition) A measure of how long it will be until an incident, problem or change has a significant impact on the business. For example, a high-impact incident may have low urgency if the impact will not affect the business until the end of the financial year. Impact and urgency are used to assign priority.
(ITIL Service Strategy) The functionality offered by a product or service to meet a particular need. Utility can
be summarized as ‘what the service does’, and can be used to determine whether a service is able to meet its required outcomes, or is ‘fit for purpose’. The business value of an IT service is created by the combination of utility and warranty.
Value on Investment (VOI)
(ITIL Continual Service Improvement) A measurement of the expected benefit of an investment. Value on investment considers both financial and intangible benefits.
Vital Business Function (VBF)
(ITIL Service Design) Part of a business process that is critical to the success of the business. Vital business functions are an important consideration of business continuity management, IT service continuity management and availability management.
(ITIL Service Strategy) Assurance that a product or service will meet agreed requirements. This may be a formal agreement such as a service level agreement or contract, or it may be a marketing message or brand image. Warranty refers to the ability of a service to be available when needed, to provide the required capacity, and to provide the required reliability in terms of continuity and security.
(ITIL Service Operation) Reducing or eliminating the impact of an incident or problem for which a full resolution is not yet available – for example, by restarting a failed configuration item. Workarounds for problems are documented in known error records. Workarounds for incidents that do not have associated problem records are documented in the incident record.
Glossary definitions copyright © AXELOS Limited 2012. All rights reserved. Material is reproduced with the permission of AXELOS.
William A Edwards is a graduate of the University of Birmingham, England. He began his career in IT in 1973 and was Technical Manager of Apricot International during its heyday.
He holds the ITIL® Expert certification and is a lifetime member of the British Computing Society. These days, he writes books, blogs about his passions and still runs the occasional ITIL® training workshop.
Introduction to IT Service Management based on ITIL® The ITIL framework from the OGC is the de facto standard for IT Service Management. However, the source material, as you will know if you have looked at it, is certainly not too accessible to beginners. That's because it is not meant to be introductory material. It is, of course, reference material. In addition, the source books are written by people who understand the discipline very well and are fluent in the management-speak of their peers. There is nothing wrong with any of that, except that beginners often do not possess the necessary specialist vocabulary to be able to understand it. And that's why this guide was written; to provide a clear and concise, yet comprehensive introduction to ITIL and to help you develop a thorough understanding of IT Service Management. • Quality Overview of the IT Service Management Discipline • Includes All 26 ITIL Processes • Full Service Lifecycle Description • Helpful Illustrations and Tips • How to Implement IT Service Management • Excellent Exam Prep for the ITIL Foundation Exam Introduction to ITIL and Service Management A top quality introduction to the ITIL framework and the IT Service Management discipline, this book includes descriptions of all 26 ITIL processes and a full service lifecycle description. In addition, there are helpful illustrations and tips to assist the reader with the understanding of important concepts. ITIL Foundation Examination Preparation Covering ITIL versions V2, V3 and the latest rewrite of V3 (i.e. ITIL 2011) this guide is fully up-to-date and is excellent exam prep material for anyone looking to study for the ITIL® Foundation certificate in IT Service Management. About the Author The author is a graduate of the University of Birmingham, England. He was Technical Manager of Apricot International during its heyday and has been involved with IT Service Management in training and consultancy for the past 14 years. He holds the ITIL Expert certification is a lifetime member of the British Computing Society.