"A Service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks." - ITIL Glossary
Introduction
Let’s start by talking about what Service Management actually is, then we can move on and look at the subject of ITIL ® 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.
ITIL ® is 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 known 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 ITIL ® publications …
ITIL ® Core Guidance - Print Versions
ISBN 9780113310456 Service Strategy (SS) ISBN 9780113310470 Service Design (SD) ISBN 9780113310487 Service Transition (ST) ISBN 9780113310463 Service Operation (SO) ISBN 9780113310494 Continual Service Improvement (CSI) ISBN 9780113310500 ITIL Lifecycle Publication Suite (Complete V3 Set)
You can also get them as eBook versions (the wonders of modern technology eh?) …
ITIL ® Core Guidance - eBook Versions
ISBN 9780113310524 Service Strategy (SS) ISBN 9780113310548 Service Design (SD) ISBN 9780113310555 Service Transition (ST) ISBN 9780113310531 Service Operation (SO) ISBN 9780113310562 Continual Service Improvement (CSI) ISBN 9780113310517 ITIL Lifecycle Publication SuiteTip – You can often get reused 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 about ITIL ®.
ITIL ® is NOT …
- A Methodology
- A Formal Standard
- A Rigid System
Many times, people new to ITIL ® will think that the books contain all the answers to the problems of managing an IT service operation. However, that is not the case: the books were never intended to do that.
They were not meant to be a methodology or a system – 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.
The last thing we should 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 got swallowed up by the OGC.
There was a rewrite which led to Version 2 coming out in the mid 1990s. The Version 2 Library (as it was called) consisted of 9 Books. There were 7 subjects, but a couple of them were divided into parts 1 and 2. The guidance was again rewritten and the resulting Version 3 guidance – now consisting of just 5 publications in its core - was published in the summer of 2007.
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 – the guidance is no longer regarded as a library as such. ITIL ® is now simply regarded by the cognoscenti as documented Best Practice!
ITIL Processes
ITIL Version 2 was regarded by many as a process-based approach to the subject of Service Management. Version 3 gets away from the trap of process silos by making use of a Service Lifecycle approach. When you think of it, there are distinct phases in the life of an IT service. Services must be conceived, designed, transitioned into the live environment and then operated for their useful life; during which time, we seek to continually improve them, until they are eventually retired.
And right there, we have the phases of the Service Lifecycle ...
- Service Strategy - the conception of services
- Service Design - the design of services
- Service Transition - the management of a service change/release project
- Service Operation - the supply and support of IT services
- CSI (Continual Service Improvement) - the improvement of services
The ITIL V3 guidance follows this structure so we have one book on each of the above phases of the Service Lifecycle; and this is really the big change between V2 and V3 - fundamentally, V3 is a change of structure for the guidance itself. That said, it is still possible to look at the information from a process perspective, because there are processes defined within each of the publications.
Here is a complete list of the processes to be found in ITIL V3 ...
Service Strategy - 4 Processes
- Strategy Generation
- Financial Management
- Service Portfolio Management
- Demand Management
Service Design - 7 Processes
- Capacity Management
- Information Security Management
- Availability Management
- Service Catalogue Management
- IT Service Continuity Management (ITSCM)
- Service Level Management
- Supplier Management
Service Transition - 7 Processes
- Transition Planning
- Release and Deployment Management
- Service Evaluation
- Service Validation
- Service Asset and Configuration Management
- Change Management
- Knowledge Management
Service Operation - 5 Processes
- Incident Management
- Problem Management
- Request Fulfillment
- Event Management
- Access Management
Continual Service Improvement - 3 Processes
- The 7 Step Improvement Process
- Service Measurement
- Service Reporting
Note on V2 Processes
In the previous version of ITIL (V2), there were just 10 processes - all of which are represented in V3, though some have been slightly renamed. For example Release Management (V2) becomes Release & Deployment Management (V3) and Configuration Management (V2) becomes Service Asset & Configuration Management (V3). Additionally there are new processes; and some processes which were technically there in V2, but were in peripheral books. The IT Skeptic has a very good diagram that illustrates this transition from V2 to V3.
Strategy Generation Process
The ITIL V3 Strategy Generation Process does not, at first glance, look like a process as such. When the publications were first released, the steps of the process were referred to as the '4 Main Activities' of Service Strategy. However, since the publication of the overview documentation (An Introductory Overview for V3), it has become clear that these 4 Main Activities are indeed the steps of the process.
So here are the steps ...
- Define the Market
- Develop the Offering
- Develop Strategic Assets
- Prepare for Execution
Now Let's go through them.
Firstly, the 'Define the Market' step is all about understanding, or gaining clarity, on the question of: who is the customer?
It might sound a bit unnecessary, but actually, for some operations, they are not sure exactly who their customers are. This naturally brings up the subject of different Types of Service Provider. V3 suggests there are 3 broad types of Service Provider.
Here they are...
- Type I - a single internal customer
- Type II - multiple internal customers
- Type III - external customer(s)
The second step concerns understanding what the customer wants. The creation (development) here is the development of the offering i.e. what will be offered - the idea. It is not the development of the service solution - that is done in Service Design. However, it includes the identification of 'Market Spaces' - or niches - in which to operate and develop service offerings.
The third step is all about tooling-up. In other words acquiring the necessary Resources and Capabilities to put the strategy into effect.
Resources - Stuff you can use (money, people, products)
Capabilities - Stuff you can do (manage, organise, develop)
Finally the 'Prepare for Execution' step concerns thorough self-analysis arounf what the organisation already does well - useful to take account of such things in the development of a strategy - and also, the production of a strategy itself.
A Strategy can, of course, take the form of any of the 4 Ps - or any mixture of the 4 Ps - see my article on Mintzbergs 4Ps for more information.
Financial Management
Good Financial Management allows a service operation to measure, and quantify, both effectiveness and efficiency in financial terms; answering questions such as:
Which are our most profitable services?
Which services should we invest in?
Which services should be retired?
Is our strategy paying off?
The Financial Management for IT Services ITIL process is responsible for three main activities:
- Budgeting
- Accounting
- Charging
Budgeting is, essentially, financial planning; and it has three main areas: operating and capital planning, demand planning and regulatory and environmental planning.
Accounting is a means of achieving operational visibility and demonstrating good stewardship. It is concerned with activities such as service recording, cost types and cost classification.
Charging is, of course, focused on the service catalogue. An optional activity in ITIL, it is the business of recovering costs, making a profit or making a loss (providing a subsidised service).
The process interfaces with many of the other ITIL processes, essentially gathering data from various sources across the whole organisation; and is responsible for disseminating financial information, wherever necessary, to be used as a means of facilitating superior decision-making.
Service Portfolio Management
The Service Portfolio is the tool that is central to the concept of the service lifecycle. The Portfolio contains the following parts:
- Pipeline
- Service Catalogue
- Retired Services
However the Service Portfolio Management process is concerned with the management of the Pipeline. If consists of the following steps:
- Define
- Analyse
- Approve
- Charter
The service portfolio is where services begin their lives - in the concept stage. So, bear in mind that: ideas that begin in the pipeline may never come to fruition and the process is continuous. Information in the portfolio is constantly being refreshed and reevaluated, however, let's go through the steps.
It's all very well having an idea for a new service, but is it a good idea? That's what this first step is all about. Ideas for new services are first properly defined; and a formal business case is produced spelling out the justification for progression.
Financial management provides key inputs to this process allowing the proposed new service to be analysed for its value proposition. The proposed service is categorised with reference to the following questions.
Does this proposed new service allow us to:
- Run the business
- Grow the business
- Transform the business
This thorough analysis allows the proposition to be balanced against all other possible investments and properly prioritised.
The formal approval would naturally take place at the relevant change authority as defined by the organisation. But this is the stage where the decision is made to as to whether or not to take the service forward into the design phase of the lifecycle. Services not approved may remain in the portfolio for further evaluation, refactoring etc.
The charter step is the committing of resources to the project and the communication of the decision. Once the new service reaches the chartered state, it enters the service catalogue. Notice that at this stage, the service has not been designed - that has still to happen. But now the proposal is destined to become a service.
You can see that the service portfolio management process is essentially responsible for the management of the service pipeline. The portfolio itself - as well as the service catalogue - comes under formal change control, so progress from pipeline to catalogue follows the normal considerations of the change management process.
Demand Management
There are really two aspects to Demand Management that should be considered: the first concerns operational support activity; the second relates to strategic intent – hence the inclusion of the process in the Service Strategy publication.
The Demand Management process is primarily concerned with understanding Patterns of Business Activity (PBAs).
IT Services are effectively consumed on demand in the operational environment in supporting business activity. The more business activity there is, the more transactions there will be to process and store. So this process is concerned with the business end of things. Understanding the sources of such demand and also introducing mechanisms to affect it.
The sources of demand can be so affected by making use of Financial and/or Physical constraints e.g. differential charging may be used to affect the demand for services if charging is being done.
There are strong links between this process and the Capacity management process. Demand Management is about understanding where the demand is coming from; Capacity Management is about coping with it.
Strategically, whatever the customer is asking for (demanding) must become an important aspect of future plans for new services, hence there is also an important input from the Demand Management process into the Service Portfolio/Service Catalogue processes.
Let's Talk About Service Design
We have just completed the Service Strategy processes in this series, so let's now turn our attention to the Service Design publication. There are 7 processes in this book. Here they are ...
- Capacity Management
- Information Security Management
- Availability Management
- Service Catalogue Management
- ITSCM
- Service Level Management
- Supplier Management
We will be going through each one of these in turn, however, I wanted to discuss why some of these processes are in the Service Design book in the first place. Processes like Capacity and Availability Management, for example, each have operational responsibilities, so why are they not in the Service Operations book?
The answer to the above question related to the view that in creating value, services must address both the functional aspects (Utility) of the requirement; and also the non-functional aspects (Warranty). And further, if we consider what is meant by warranty, we discover that it consists of a kind of guarantee or promise.
There are four aspects to the warranty promise - these four parts of the promise ensure that the service will:
1. Be there when needed (availabiltiy)
2. In sufficient quantity (capacity)
3. Is continuous enough (ITSCM)
4. Is secure enough (security)
So that is why the decision was made to locate these processes in the Service Design book; rather than elsewhere. In other words, when designing a new or changed service, these things need to be designed-in.
OK - that said - we'll crack on with taking a look at each of these processes in turn ...
Capacity Management
Capacity Management in V3 is strongly linked with Demand Management; as indeed, it was in V2. Demand Management is all about understanding the sources of demand i.e. patterns of business activity (PBA); Capacity Management is about doing something about it – whether that be planning for growth to cope with expected/anticipated rises in demand or attempting control or regulate the causes of that demand.
The process divides into three sub-processes:
- Business Capacity Management
- Service Capacity Management
- Component Capacity Management
Business Capacity Management is concerned with the future of the business. It has access to the business plans; and it is responsible for planning for the various alternative futures the business is contemplating at any time.
Service Capacity Management is the sub-process that ties in with Demand Management; trying to affect demand by making use of physical or financial constraints. An example of a financial constraint being the use of differential charging – if charging for IT services is actually carried out.
Component Capacity Management is the sub-process responsible for the bits and bytes of the infrastructure. It is focussed on issues such as the bandwidth, storage and throughput of systems.
All these sub-processes work together to plan for anticipated future growth and also to get the best out of the current infrastructure. They all get involved in monitoring and tuning activities; and they are all involved in the construction of the capacity plan.
Information Security Management
This is a new process in version 3; and fundamentally, it is a governance process. Governance is about ensuring that the organisation's policies are actually followed. So this process is responsible for ensuring that we do actually have a policy for information security in IT; that it is aligned with the organisation's overall security policy; and that it is widely communicated and followed.
There are a number of sub-processes within Information Security Management. These are: Security Controls, Security Testing, Management of Security Incidents and Security Review.
Security Controls
This sub-process in concerned with the design of Security 'Controls'. Controls are both technical and organisational measures that seek to ensure the confidentiality, integrity and availability of data.
- Confidentiality - only the right people can see it
- Integrity - it's intact or trustworthy
- Availability - there when it's needed
Security Testing
This sub-process ensures that security mechanisms - the tools and processes - are regularly tested so determine their effectiveness in the event that a security attack should occur. It is also responsible for producing management reports to quantify any residual risks.
Management of Security Incidents
This sub-process is responsible for ensuring that security measures are introduced to effectively manage security incidents.
Measures may be:
- Preventive
- Reductive
- Detective
- Repressive
- Reductive
Security Review
This sub-process is responsible for ensuring that the current security measures are appropriate; and also to verify that the necessary maintenance and testing has bee, and is being, properly carried out.
Availability Management
The Availability Management process is concerned with planing to deploy the levels of resilience in the infrastructure that are necessary to ensure the terms of the Service Level Agreement (SLA) will be met. A key output is therefore the Availability Plan.
Identifying single points of failure (SPOF), understanding their significance for the provision of service and then planning to eradicate them where appropriate to the smooth running of services is the essence of Availability Planning. In particular, the Identification of mission critical systems or, as they are known in ITIL, Vital Business Functions (VBF) and ensuring they are protected by deploying fault-tolerant systems is an important part of Availability Planning.
Availability is defined as the percentage of Agreed Service Hours that the service is actually available, so the calculation is simple ...
Actual Service Time x 100 = Availability
------------------------------
Agreed Service Time
e.g. A service that should be available for 40 hours per week, but which was down for 1 hour within the agreed service times would have an availability of ...
39/40 x 100 = 97.5%
Techniques Used by Availability Management
* Fault Tree Analysis (FTA)
* Component Failure Impact Analysis (CFIA)
* Management of Risk (MOR)
* Technical Observation Post (TOP)
* Service Failure Analysis (SFA)
The Availability Plan 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 Availabiltiy Management process; and go to the Change Management process for consideration in the normal way.
Service Catalogue Management
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 plus Service Level Packages that provide additional levels of utility 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 new ITIL role of Product Manager. The availability of different service level packages for the same core service techniically 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 across 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 reponsible for mapping user profiles onto Service Level Packages in the catalogue i.e. making appropriate product recommentations.
ITSCM (IT Service Continuity Management)
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 retored 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 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 strategy that needs to be employed.
There are a number of strategies in common use:
- Immediate Recovery
- Fast Recovery
- Intermediate Recovery
- Gradual Recovery
Each of these strategies concerns recovering IT services with a specific timescale.
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 infrastucture is a second factor to be taken into consideration in the construction of an appropriate strategy for ITSCM.
The business needs to recognise that there is generally a trade-off between investment costs, in terms of service provision, 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 arriving at 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 differnt forms: from simple walk-through reviews to full-blown testing with everyone in the operation involved in simulating a disaster and invoking recovery procedures.
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 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 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
The Service Level Management process works in conjuction 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 bugeting for any necessary investment identified by the Availability Management process.
Once an SLA is in place, this process is concerned with monitoring and measuring service level achievements; and broadcasting them to all relevant parties. Additionally, SLAs are regularly reviwed and updated where and whenever necessary.
Previously, in V2, the activities of this process were a responsibility of the Service Level Management process, but in V3, Supplier Management is a process in it's 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 detail in the Supplier and Contacts Database (SCD) - a data-source component of the Configuration Management System (CMS).
Service Level Management
The Service Level Management process is responsible for negotiating and agreeing Service Level Agreements (SLA) and Operational Level Agreements (OLA) in ITIL V3. The responsibility for negotiating Contracts/Underpinning Contracts, which was part of this process in V2, has now been stripped away; and is now the reponsibility of Supplier Management.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 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 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 conjuction 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 bugeting for any necessary investment identified by the Availability Management process.
Once an SLA is in place, this process is concerned with monitoring and measuring service level achievements; and broadcasting them to all relevant parties. Additionally, SLAs are regularly reviwed and updated where and whenever necessary.
Supplier Management
Supplier Management is responsible for sourcing, vetting, negotiating contracts and monitoring the performance of external partners in Service Management; renewing or terminating contracts as necessary. A contract, in this context, is a legally-binding agreement that underpins the Service Level Agreement (SLA); and is therefore, sometimes, known as an Underpinning Contract (UC).Previously, in V2, the activities of this process were a responsibility of the Service Level Management process, but in V3, Supplier Management is a process in it's 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 detail in the Supplier and Contacts Database (SCD) - a data-source component of the Configuration Management System (CMS).
Let's Talk About Service Transition
Service Transition i.e. the traditional territory of Change Management and Release Management (now Release & Deployment Management) receives a much higher profile in ITIL V3 - and rightly so, in my opinion. After all, in the modern workplace, we typically live with, and therefore must learn to manage, very high volumes of change.NB This Knol is being built up, over the course of time, into a complete free reference source to ITIL V3. It replaces the project originally started at ITIL V3 Talk . This is simply because the Knol format more readily lends itself to this work. The function of the ITIL V3 Talk Blog has therefore changed to provide a more topical and news-worthy discussion of ITIL V3.
Copyright (C) 2008/2009 Will Edwards
Comments
Write New Comment ▼
Write New Comment
Sorry! This knol's owner(s) have blocked you from editing, making suggestions, or commenting here.