ITIL Foundation

User Guide


Printed and Published by:

Key Skills George House Princes Court Beam Heath Way Nantwich Cheshire CW5 6GD

The company has endeavoured to make sure that the information contained within this User Guide is correct at the time of its release. The information given here must not be taken as forming part of or establishing any contractual or other commitment by Key Skills and no warranty or representation concerning the information is given. All rights reserved. This publication, in part or whole, may not be reproduced, stored in a retrieval system, or transmitted in any form or by any means – electronic, electrostatic, magnetic disc or tape, optical disk, photocopying, recording or otherwise without the express written permission of the publishers, Key Skills. © Key Skills 2000



Page Foreword Section 1 Hardware/Software Pre-requisites Section 2 Installation Procedure Section 3 6 5 4

Operating the software
Sign-on procedure The user interface Section 4 - Course Notes Topic 1 – Overview of IT Service Management and ITIL Lesson 1a - Introduction Topic 2 – Supporting the User of IT Services Lesson 2a – Service Desk Lesson 2b – Incident Management Lesson 2c – Problem Management Topic 3 – Control Processes Lesson 3a – Configuration Management Lesson 3b – Change Management Lesson 3c – Release Management Topic 4 – Service Delivery Building Blocks Lesson 4a – Availability Management Lesson 4b – Capacity Management Topic 5 – Getting the Right Service Quality at the Right Price Lesson 5a – Service Level Management Lesson 5b – Financial Management for IT Services Topic 6 – Protecting Business and IT Services Lesson 6a – Continuity Management Topic 1- Exam Technique Lesson 7a – Passing the ITIL Foundation Exam Acronyms Glossary of Terms

7 7

9 13 20 24 30 37 46 51 59 65 72 77 82 84 90


4 . Training someone to simply operate a computerised project planning tool does not make them a project manager – any more than teaching them to use a calculator would make them an accountant! Key Skills in Project Management (Fundamentals) is the first step in bridging this skills gap. and yet they have never received formal training in the basic techniques which can make the difference between a successful project and an expensive failure. Professional project managers will find this course lays a solid foundation on which the other modules in the Key Skills PM Portfolio will build to provide a career-enhancing programme of learning and development. either directly or in a supporting role. For many people it is all the training they will need to enable them to operate more effectively in a project environment and to make more effective use of their planning software. the introduction of computer-based project management tools can lead to disappointing results. For exactly the same reason. Many people are involved in project work.Foreword Projects are essentially about change – and because managing change is an increasingly significant fact of business life – project management is an essential key skill in today’s working environment.

5 .Section 1: Hardware/Software Pre-requisites For optimum performance. you should operate this multimedia course on a computer with the following minimum specification: Pentium P100 Processor 16 mb RAM 8x CD-ROM drive Sound-card & speakers SVGA Monitor (NB The course uses 800x600 resolution) Mouse/Pointing device A 32-bit Windows® operating system is also needed.

There are a number of ways in which installation and operation can be effected and you should contact Key Skills Technical Support Section for advice. this multi-media training course can be installed and operated over a local area network or a corporate Intranet. 6 . please call us on 01270 611600.EXE.1 From CD-ROM (Single User) Place the CD in your CD drive and run START. Any problems. Please follow the accompanying registration instructions carefully 2.2 Network Instructions Subject to bandwidth and licensing terms. The first time you run the course you will be required to register it with Key Skills. START.Section 2: Installation Procedure 2.EXE will run the course directly from your CD-ROM drive and no runtime files will be copied to your hard disk drive.

If you click on the lesson title text then you will be taken to the start of the corresponding lesson. for example: Go to Bookmarks Start at First Page Each of these lesson panes is divided into two distinct areas.Section 3: Operating the Software 3. 3. 7 . If you are new to the course you must enter your name/identification and then confirm this to the system. Note: The bookmarking system is switched off as soon as you move around the course using either the Index or the Contents buttons at the bottom of each page. Once you have passed the title screen and copyright notices you will be asked to identify yourself to the system. By clicking in the bookmark area you will be taken to your last point of study within the corresponding lesson. otherwise your bookmarks within the course will be invalid. with music and introductory title screen. The left side of the pane is the bookmark area and a pink bar will appear in this area to show whether you have part or fully completed the corresponding lesson.2 The User Interface Once sign on is completed you will be presented with the main menu which looks like this: Each topic is represented by one of the “panes” on the menu screen. double click on the course icon and the program will commence.1 Sign-On Procedure To start the course. If you have used the course previously be sure to use the same name.

or parts of a lesson. the main user controls are located at the bottom of the screen. and their functions are as shown below: Newcomers to the course will gain most benefit from starting at the beginning of the first lesson and working their way through.Throughout the course. to the end. The Contents and Index facilities are particularly useful for browsing in this way. sequentially. at any time. However. 8 . the package is also a valuable source of reference and it is possible to re-visit specific lessons.

such as ISO9000. the ICT infrastructure. In addition to the two main manuals we will also refer to a guidance overview booklet known as ‘little ITIL’. For the purposes of this course we are interested in what’s known as ‘Core ITIL’ This core consists of two major volumes. This overview booklet is published by the IT Service Management Forum or ITSMF. Individuals currently working organisation’s IT department • Those wishing to develop skills in IT Service Management Organisations and their employees who have implemented or intend to implement an IT Service Management structure. allowing it to sit comfortably along side a recognised quality system. Further updates to the manuals were published late in 2002. Service Support. there is a strong link between ITIL and recognised quality systems. amongst other things. In both cases. recent technological developments. ITIL provides a best practice framework focusing on the provision of high quality services. consultancy and management tools. and it places particular importance on customersupplier relationships. ITIL and ISO9000 Today’s businesses need to concentrate on providing a ‘Quality Service’ and to adopt a more customer focussed approach. People who include: • will benefit from this course in an Lesson 1a Introduction The ITIL Library consists of seven volumes. This course has been designed to provide you with sufficient knowledge to pass the ISEB and EXIN Foundation level exams. with many organisations offering related products including training. This ‘overview’ will provide you with enough knowledge to sit the Foundation Certificate in Service Management. ‘Service Support’ and ‘Service Delivery’.Introduction Welcome to this computer based training course in IT Service Management. It was conceived by the UK government who approached various organisations and subject matter experts to write all of the books in the library. They are: ‘Planning to Implement Service Management’ – used by Project managers who are implementing ITIL. For example. Examine Service Management and the Organisation. In this introductory lesson we will: Discover what ITIL is. Many companies require their suppliers to become registered to ISO 9001 and because of 9 . The central core of the library consists of Service Delivery. and at its centre . There are two further ancillary volumes. and it was originally published in the late 1980’s. It consists of a library of reference books outlining good practice guidelines for IT Service Management. and ‘Security Management’ – which offers additional information on infrastructure. This course forms an ‘introductory overview’ to the content of both books. and you will find that much of the material is also covered in the ‘little ITIL’ book. ITIL’s non prescriptive nature allows the tailoring of ‘Service Management’ implementation. and how we define a service in IT terms. which provide additional guidance. Since its inception ITIL has expanded from a library of books into a whole industry.Application Management. Business Perspective and Infrastructure Management. an independent user organisation dedicated to IT Service Management. Finally we will examine the functions that make up the core ITIL processes. • • • • • So what is ITIL? ITIL is an acronym for Information Technology Infrastructure Library. Applications Management holds this central position as it’s the only volume in the library which deals with both Development and Service Delivery issues.Section 4: Course Notes Lesson 1a . or OGC. The ITIL library is published by the Office of Government Commerce. On an operational level ‘Service Support’ processes address any changes or failings outlined in these agreements. and in 2001 revised versions of the ITIL manuals were published to include. areas within ‘Service Delivery’ address customer agreements and monitors targets within these agreements. such as the internet and e-commerce. and how ITIL fits in to a quality environment.

Each new application might be made up of a number of projects. it is important to understand the relationship between Service Management Guidance the IT business as a whole. you will be working alongside technical specialists helping to maintain the ICT infrastructure. change and so on. Working practices and general procedures.Lesson 1a Introduction this. Registered companies have had reductions in Customer complaints. Peopleware. and it can vary depending on organisational structure and policy. This transition point is also known as the implementation point. The management of Hardware and Software is dealt with in a separate ITIL guidance volume called ‘ICT Infrastructure Management’. then its implementation should be as transparent as possible. Inclusion of data here is a contentious one. In addition. a company's compliance with ISO 9001 ensures that it has a sound Quality Assurance system. It considers applications as ‘strategic resources’ that need to be managed throughout their life. database management systems. its documents and procedures. known as a programme. an organisation develops new applications. Although this process isn’t examined in detail in this course. significant reductions in operating costs and increased demand for their products and services. understanding the implications that decisions made at one stage has on later stages. Our focus in this course is the management of ‘Peopleware’. For example a development team might retain project responsibility until the end of a warranty period. development tools and general applications and computer data itself. documentation of both products and services. To deliver effective services to business. And finally. As IT management staff. Service Management and the Organisation In any organisation. all three infrastructure components should be managed and controlled efficiently. dramatic The ICT Infrastructure If service provision to business is to be effective. As well as maintaining and servicing these ongoing business functions. Hardware. details of training products. as it’s suggested by some people that a fourth infrastructure category should exist. and this is known as Application Management. ITIL defines a major process to handle the complex relationships which affect projects. managing IT services is a fundamental part of day to day operations. handling data as a separate corporate resource. The ICT infrastructure is divided into 3 areas. or a group of projects. workstations etc. 10 . IT Service Management staff must take a customer focused view and concentrate on providing high quality services that are available when users want them. It should be assumed that end-users have no Information & Communications Technology knowledge. The relationship between these different projects needs to be understood and documented in order to monitor progress. considering issues from feasibility through productive life and final retirement of the application. to service management staff. at the end of which they hand over the completed project. and are easily maintainable. including mainframe computers. and associated ownership. and how it relates to Service Support and Service Delivery. Software and Peopleware. A transition point is defined as the point at which responsibility for the project passes from the development team to the team responsible for end user delivery and support. this includes skills sets. network equipment. registered companies find that their market opportunities have increased. Software consists of network and mainframe operating systems. and ensuring that delivered services are cost effective. Application Management considers the whole ‘cradle to grave’ lifecycle of an application. As these projects develop they approach a transition point. Hardware consists of all the ICT and environmental infrastructure. that respond quickly to demand.

its documentation. Ten of the eleven disciplines support the Process Management discipline. many organisations do follow this model. payroll and order processing. hardware and so on. Every organisation will have this function in place. its support. and these could include a wide area network or a UNIX server. So. The remaining six disciplines make up the Service Support function. software. and pro-active long-term planning of services. For example we might have in place an Incident Management process. hardware. In practice. A key phrase in the definition of IT services is ‘end to end’. Five of these delivery. or when checking into a hotel. However. Placing an order for goods or services for example.Lesson 1a Introduction What does ITIL regard as a Service We all encounter business services in our everyday lives. the application software. Change and Release Management to ‘share’ staff. Service Desk is seen as a function. The IT service consists of a set of related functions provided by IT systems in support of the business. However. and is seen by the customer as a coherent and self-contained entity. operating a Service Desk. but ITIL guidance allows you to form your own structures. The core ITIL processes are made up of eleven disciplines. and to be managed by one individual. but may not have an Incident Manager. that provides a capability to satisfy a stated management need or objective. with exception of one. employing service desk staff and managed by a service desk manager. and that’s the Service Desk function. facilities and people. we are being offered a business service. The remaining 10 disciplines all relate to processes. such as management processes. These are: • Service Desk • Incident Management • Problem Management • Change Management • Release Management • Configuration Management All six disciplines relate to the day-to-day maintenance of a quality service. 11 . Our Incident Management function might be managed by a member of the Technical Support or Service Desk team. or a customer database forming part of a service support IT system. disciplines relate to service These are: • Service Level Management • IT Financial Management • Availability Management • Capacity Management • IT Service Continuity Management Day to day Service Delivery functions might consist of technical support. The ITSMF’s ‘little ITIL’ book defines Service as: ‘An integrated composite that consists of a number of components. there are other less obvious IT services. This shared management is known as the CCRM or Configuration. Obvious examples of IT services might include e-mail. In most cases businesses are underpinned by IT services. for example a Problem Management team need not be separate from a Capacity Management Team and so on. ITIL does not mandate the creation of specific functional areas. that is for Configuration. ITIL does suggest one good practice. Change and Release Management function. its networks. Broadly speaking ‘end to end’ means that we deal with all aspects of the service.

and are the subject of the ISEB and EXIN examinations. We looked at the relationship between service management and the business organisation. Interaction between other functional departments might be less frequent. We looked at the ICT infrastructure and its three constituent components.Lesson 1a Introduction Although we have represented each function here as a separate entity a great deal of interactivity exists between each of them. and the interactivity which exists between them within IT Service Management. its make-up. Summary In this introductory lesson we have: Briefly examined the history of the ITIL library. Information on available capacity at a remote site or location would be provided by Capacity Management. Service Level Management deals with the provision of high quality services. Hardware. In this scenario. and how ITIL defines Application Management as a major process designed to handle these complex relationship. its documents and procedures as a primary focus of this course. For example. Software and Peopleware. Capacity Management and IT Service Continuity Management might work together to develop a cost effective and workable strategy to handle a major disaster. such as a flood. and how Service Delivery and Service Support sit at its core. such as ISO9000. 12 . For example. We highlighted Peopleware. The pre-determined level of support required for on-going business function would be managed by IT Service Continuity Management. In fact there is a great deal of relationship management within IT Service Management. We have discussed how ITIL’s flexibility allows easy integration into a recognised quality system. provided at the right cost levels. leading to certificates in Foundation IT Service Management. Consequently it interacts frequently with IT Financial Management. Each function communicates with others in the group. We defined ‘What a service is’ in IT terms. These 11 disciplines and the relationship between them form the basis of this course. and examined some less obvious examples of ‘IT services’ And finally we looked at the eleven disciplines which form the core ITIL processes.

is “Service Desk”. they can contact someone who will provide a solution or an answer. complaint or question. Name at least six technological aids that can be employed to improve the efficiency of a service desk. what ITIL is referring to in this context is an IT Service Desk – but the principle can.provided. For the purposes of this course will be making the assumption that the term Service Desk refers to an IT and Communications Technology -or ICT . tracking. Obviously. requests for change. The Service Desk is meant to be the focal point for the reporting of incidents. in addition to an IT Service Desk there may be a Service Desk where customers for the company’s products can call to get support. so that when a problem or a query comes up. namely: • Service Desk • Incident Management • and Problem Management. We will be looking in more detail at both Incident Management and Problem Management in the remaining two lessons of this topic. When a Customer or User has a problem. Another Service Desk may exist so that employees can get answers to queries relating to company policies. time is of the essence and what the users want is either a rapid resolution or a work-around to their problem that will enable them to carry on with their work with a minimum of interruption. which is described in Chapter 4 of the Service Support book of the IT Infrastructure Library. Such a facility is known by various names in different organisations – some common ones being Help Desk. Describe the importance of the Service Desk as a single point of contact for IT users. Nothing is more frustrating than calling an organisation and getting passed around until you find the right person to speak to . personnel issues and so on. So. 13 . More importantly they want a result their problem solved. ITIL Best Practice demands a single point of contact for users in their communication with the IT service provider.Lesson 2a Service Desk Lesson 2a Service Desk In this lesson we will be examining the IT Service Desk. Explain what is meant by “escalation” in a service desk context and identify two different types of escalation procedure. the end-user and the IT provider alike.Service Desk. ITIL has three closely related chapters. The name used by ITIL – and hence during this course . The integration between IT and communications technology is so close these days that it makes sense to handle them via the same Service Desk. of course. they want answers quickly. • • • • Introduction One of the most important considerations when delivering IT Services is to ensure the provision of proper support for the users. On the other hand it also provides a channel for the IT provider to communicate information to users. monitoring and resolution of events that are a threat to “normal service”. Identify three of the main approaches to structuring a service desk. The Incident Management process enables the recording. Problem Management addresses the underlying reasons for such incidents and seeks to implement permanent resolutions in order to prevent a recurrence. Call Centre or Customer Hotline. In order to support users in this way. Often. For the rest of this lesson we will be examining the Service Desk function. that they are not out at lunch or on holiday or it's just after five o'clock. and often is applied to many areas of a company’s business. or any queries that a user may have about the service. When you have completed this lesson you will be able to: • List the main reasons why the establishment of a service desk can have major benefits for the organisation.

any time that they are unable to operate at full efficiency as a result of a problem with the IT Services that they use will be both disruptive and costly. does draw a distinction between the two terms. The principle of a “single point of contact” that we have already mentioned is considered an essential element of ITIL Best Practice. So it is important to understand why such a facility might be needed and the benefits that it should provide. A machine operator for example. any changes that may be needed and possibly the payment arrangements. ITIL. the particular services. and by making it obvious to all how support can be achieved very quickly via a centralised Service Desk. Identifying the most commonly occurring problems and feeding this information back quickly to the IT Service Management structure is a critical aspect of the Service Desk. IT does not exist just to provide ICT components or technology just for the sheer joy of playing with new equipment. the Service Desk is the thermometer by which we can monitor the health of the IT services that are being provided. leaving skilled network technicians or database experts. another major benefit that a Service Desk brings is its contribution to the principle of continuous improvement of the services offered by IT. to whom they can turn when things go wrong. So. The Service Desk will keep records of types of enquiry. The alternative to a Service Desk is for each group of users to have their own “super-user”. Another guiding principle of ITIL is that IT should maintain a focus on the support of business goals. A Customer is the person who negotiates for the provision of the product or service. This factor becomes even more crucial in an ebusiness context where the lack of service will directly impact on end-customers and certainly lead to loss of business. ITIL strongly suggests that IT costs can be reduced by not requiring high levels of IT skills within the business community. So customer satisfaction and retention can also be listed as an important benefit. what the specification should be. Finally. The users of our IT services and their managers are customers in every sense of the word. An efficient Service Desk can help to reduce the overall cost of ownership of the IT department. and it can do this in a number of ways.Lesson 2a Service Desk Why Have A Service Desk? The establishment and operation of an effective Service Desk is a relatively expensive proposition. Additionally. of the facilities that they are already using. in a business sense. however. A well-staffed and efficient Service Desk is a critical element in proving to the business that IT is listening and responding to their needs. or aspects of a service. Points of Contact There is often some confusion about the terms “user” and “customer” – so far in this course we have used the words interchangeably and for many people they mean pretty much the same thing. An effective Service Desk will significantly reduce the likelihood of such problems. that seem to cause most problems and so on. In this way. for example. 14 . Making better use of skilled and expensive IT staff can also reduce costs. A further consequence of this will be that the IT users will in turn be able offer a better level of service to the external customers of the business. Like all customers they would quickly become frustrated and unhappy if they were unable to find somebody who could help them when they had problems with the systems on which they depend. Straightforward issues can be resolved immediately by the Service Desk. to concentrate only on the complex problems or concentrate on improving the quality of the infrastructure. the issues that are taken to mean the person who actually uses the product or service under discussion. the service desk can also operate as a “shop window” – adding value to the business by making users aware of facilities that they may not know exist – or how to make better use. It is there to help the organisation achieve its business objectives. A User – or End-User . It will usually be the case that the users or customers are performing a valuable function for the organisation.

the Service Desk should have the following ingredients: • Well trained staff with good interpersonal skills. chances of a problem being resolved directly and immediately at the desk. Reactively being in response to issues.Lesson 2a Service Desk It may well be that the User and the Customer are the same person. User and Service Level Management relationships and that the Service Desk has a responsibility to act on behalf of the User within the IT infrastructure. for operational systems. problems and queries raised by the users and ‘proactively’ being where the Service Desk goes out to make users aware of issues that might affect them. So. Here. the idea of the Service Desk as a single point of contact is an important one in ITIL. Enough technical competence to address users’ problems directly or to interface with technical experts if necessary. and users being the operators. So. Keeping an eye on any Service Level Agreements that may specify maximum acceptable response times for resolving user issues. Customers normally being managers. for example. such as automatic call distribution equipment and knowledgebased systems that assist in identifying solutions to problems. or if they had a query on their pension arrangements. they will be different groups of people. Appropriate technology. response times and so on. Such an incident would be given a much lower priority than had the figures been reversed. These definitions are relevant here because whilst the Service Desk is the main point of contact between the User and the IT service provider. Well organised systems and processes for recording and tracking incidents and matching against previous incidents and solutions. that a user calls in complaining of a 2 second response time – when in fact the Service Level Agreement specifies that 95% of responses should be within 4 seconds. • • • As the user’s friend. the first duty of the Service Desk is act as the IT users “friend” within the IT department. the general point is that Service Level Agreements provide the link between the Customer. we’ll assume a Service Desk is the single point of contact for just Information and Communications Technology issues. But in many cases. So staff within such an organisation could call the Service Desk if the lift broke down. for the Service Desk to publish regular electronic newsletters to the user community informing them of new facilities. It may well be for. as the single contact point. The importance of this to the Service Desk is that they must be aware of what Service Level Agreements are in place and how these match up with the question. This particularly relates to the role of the Service Desk in: • Monitoring progress on incidents and queries Reporting this progress back to the user. • • • 15 . the Service Desk has the responsibility of communicating with the user. Some organisations will take this principle to its ultimate conclusion and have a single Service Desk as the point of contact for everything to do with the ability of the business to continue to function properly. both Reactively and Proactively. changes to services and so on. It is not uncommon. In both cases the key point of reference is the IT Service itself – as defined in the Service Level Agreements – which will contain statements about hours of availability. or a light bulb in their area failed. This kind of Service Desk has the disadvantage of demanding a very wide range of skills to be available – which normally implies a referral system being used – which in turn reduces the In order to operate effectively as a single point of contact and the users friend. time to resolve issues. example. the Service Level Management process is main point of contact between the paying customer and the provider. Chasing any experts that have been assigned responsibility for resolving an issue. complaints and issues that may be being raised by users. Service Desk as a Single Point of Contact As we have already seen.

otherwise longdistance telephone calls could easily drive up the cost of providing the service to unacceptable levels. For examples. The opposite extreme of the local service desk is the central service desk. The Virtual Service Desk is based on the concept that physical location is not relevant and that whilst the Service Desk may be perceived as a centralised point. particularly telephony re-routing equipment. Configuration Management records will need to be readily accessible so that. As far as the local users are concerned they are contacting a local service desk – but in reality their calls may be automatically routed to the most appropriate desk. Also. Service Desk Structure A debate that always occurs early on in the implementation of a service desk is how the desk should be structured. the Service Desk must have all the necessary linkages with other ITIL disciplines. The logical extension of the virtual service desk is what is sometimes called the “follow the sun” option. There are a number of strategies that will usually be considered. it may actually consist of several local service desks. There will need to be liaison with Service Level Management so that potential breaches of Service Level Agreements can be recognised.Lesson 2a Service Desk In addition. which is local knowledge. lessons learned in one area may not be passed on to the others. staffing or whatever criteria apply. these days. 16 . where all incidents and queries are reported to and handled by a single centralised structure. the Availability Management process will be keen to look at Service Desk records of incidents for conducting their own analyses and as part of their role in improving service availability. This is widely used by multi-national companies – or even. The aim is to provide as close to 24 hour coverage as possible for users in each hemisphere with the European service desk coming on line just as the Australian one is closing down for the night – and vice versa. Conversely. by local companies who want to take advantage of cheaper labour rates in other parts of the world. the issue of language alone may give favour to local service desks. operating between the hours of 6am to 6pm local time and a second desk in London operating the same hours local time there. Centralisation has the benefit of providing consolidation of management information and improves utilisation of resources – and therefore can reduce operation costs. Particularly in an international context. So a typical “follow the sun” strategy might consist of a service desk in Australia. So people in Europe requiring support during the night will have their calls automatically rerouted to Australia. There are a couple of obvious disadvantages to this approach. Another major issue with this centralised approach is the cost of communications. In these situations. The big advantage of this approach. from a geographical perspective. for example. time of day. however. a caller’s IT equipment can be easily identified. Such problems can be minimised the use of centralised logging of incidents and results and by establishing a central configuration management database that is accessible by all the local service desks. Here for example. based on the proximity. there must be continuous communication with the Problem Management process – particularly when a major problem has cropped up. each distinct site or region of the organisation has it’s own service desk – and hence can provide local expertise to solve local problems. This option is obviously much more demanding on the use of technology. in that a perceived loss of local knowledge may tempt local sites to set up their own super-users or unofficial help desks. There are dangers. will obviously become more important the more geographically and functionally dispersed the organisation’s sites become. careful planning will be needed. in order to ensure that the whole process appears transparent to the end user. such as duplication of resources and the maintenance of organisation-wide standards and consistency.

Lesson 2a Service Desk This is in fact a major advantage of this approach in that the local desk will tend to be handling local calls during the period of peak demand – so that overnight re-routing. and hence long-distance traffic. The role of the service desk is simply to act on these reports and to ensure that they are handled in the same way as user-reported incidents as far as recording and classification are concerned. For example. Escalation Escalation Management is an important part of running an effective service desk. Communicating with the Service Desk There are many mechanisms by which problems and incidents can be communicated to the service desk. Functional and 17 . e-mail. be careful with telephone calls. some of these inputs allow potential for some form of automated response. for example. It can all too easily be used as an excuse for the service desk not playing its role in monitoring and processing incidents on behalf of the user as the user’s friend. the loss of a particular communications link in a network would usually be reported via network monitoring software. Be careful with this one though. Clearly. can continue to support a user with a query that may have been raised with the Australian Desk a few hours earlier. “follow the sun” may well be more than two service desks. the different inputs that will be encountered must be anticipated and catered for. Although there are some complexities with this approach. it clearly has many advantages and it is becoming a very common arrangement for multi-national organisations offering 24 hour /7day a week coverage – particularly those in the e-commerce field. time differences and coverage required. Escalation is the process of moving an incident or query to the point where it is most ably resolved. If something comes in via e-mail then at least an acknowledgement of receipt can generated automatically. It may even be possible to introduce a degree of self-service where users register and track their own incidents without the need for interpersonal communication with service desk staff. Such incidents are often referred to as Operational Events. Lost calls of this kind are often referred to as “fugitives”. Finally. browser-based web-forms and so on. There’s a problem out there that cannot be investigated because it hasn’t been recorded – and although the user could have been more persistent. So. if the initial recipient of the call is not able to deal with the incident or query – who should it be passed to so that resolution can be achieved as quickly as possible? ITIL distinguishes between Hierarchical escalation. Machine generated communications could come from some form of system monitoring tool. These can be categorised into two sorts . Human users can communicate using a whole range of options such as telephone. the service desk needs the automatically generated notifications about operational events so that they can inform users about a possible degradation in performance caused by the fault or actions necessary to repair it. fax. which in turn will be used as a key measure of service desk performance. voice mail. To make this work effectively it is imperative that information about incidents is replicated or shared between the different sites so that the European Desk. Hence the information that would have been gained about a particular incident or query will be lost. should be relatively minimal – but it’s there if needed. Also. Of course. depending on the location or users. the fault is with the service desk staff and or their technology for not making it easier for them to report the incident. So when a service desk is established. If they are not handled properly it is possible that the user will hang up in frustration and not re-dial. All that would be recorded is that a call had been dropped.human generated and machine generated.

Factors that are normally considered are the increased costs of employing more highly skilled staff against the improved service to the endusers that will almost certainly result. There is a school of thought that says a good target is to have about 70% of all issues resolved at the service desk. the conceivable issues at the first point of call. Service Desk Capability Related to the escalation procedures is the general debate about how skilled and capable of resolving issues the service desk staff should be. These will include: • A customer-focussed attitude – where helping the customer is far more important and satisfying than playing with the latest technology. The percentage of calls that get passed upwards will be determined by the skill levels and training of the service desk staff. skill level is adopted. As we have said. if not all. More serious issues may then go to the problem manager. Regardless of the technical skills that are put in place on the Service Desk. Immediately following the introduction of a new service. in a generic rather than just ICT service desk. without further referral. there are no hard and fast rules. change schedules and of of to so Service Level Agreements must also be accessible so that work can be prioritised depending on the SLA clauses. the use scripts will increase the rate at first call.either because they are very serious or need higher level authority to sanction the resources needed to provide a solution. In between these would be what is often called the skilled or semi-skilled service desk – and this is considered by many to be the optimal solution. The first level of hierarchical escalation would normally be to the service desk manager. with a remit to call together the necessary specialists to resolve the incident as quickly as possible. Whatever diagnostic resolution knowledge on. merely logging and routing calls – and at the other would be an expert desk capable of handing most. which would clearly be unacceptable. So functional escalation is the handing over of responsibility to a functionally more competent area. calls that cannot be directly handled by the service desk will be directed to experts in the relevant functional area. rather than the exception. Once things have bedded down it may be possible to relocate them to more productive areas. Hierarchical escalation is where problems are passed up the management chain . in order to tackle a particular issue. This can be particularly challenging when dealing with customers who are slow to catch on or who become frustrated. who is usually the own of the incident management process. • • 18 . Very explicit parameters need to be established to govern hierarchical escalation. all operators must have certain basic attributes to make them suitable for the job. it may be desirable to have some experts available on the service desk to handle the initial rush of calls about the new system. A methodical approach to questioning and the recording of facts – and the ability to maintain that approach when under severe pressure or when handling a difficult customer. Also this may be a dynamic situation with the optimum skill level changing over time. An articulate nature – in particular the ability to translate technical information into something that is meaningful to the business user. irate or even abusive. But this will vary considerably depending on the service being offered and the maturity level of that service. So at the one end of the scale we may have an unskilled service desk.Lesson 2a Service Desk Here for an example. for example. Achieving this optimal balance is an interesting and difficult task. otherwise it is very easy for it to become the norm. ITIL does not make any recommendations in this respect because there is no absolute answer – every case must be considered on its merits. as will access databases.

telephony and software. problems or anything that would help to provide a better answer. An example of this would be the identification of an incoming caller based on their telephone number and the linkage of this with configuration management. Conference call facilities can be useful in allowing a second-line expert for example to be included in the conversation with the end-user. This would allow all the details of the user. Computer-Telephony Integration can achieve major gains in efficiency.Lesson 2a Service Desk A good business perspective and understanding of what are the business critical services. Examples of telephony technology might be Automatic Call Distribution systems. And finally Automatic Tracking and Alert tools could be used to monitor the status of an incident as it progresses through the various stages towards a resolution. and possibly service history. Finally we have seen some of the new technology that can be employed to improve the efficiency of operation of the service desk. learn from them and identify patterns over time and are able to suggest probable causes and solutions. As with all business investments . This is particularly true in the case of the virtual service desk.multi-lingual capability is becoming an increasingly important attribute for some service desk staff. 19 . which ensure that a bank of service desk operators are used in an optimal order and that work is smoothed out as evenly as possible. • • Benefits & Problems The benefits of and potential difficulties with Service Desk are listed on Page 14 of the little ITIL book and in Section 4. This business culture is often helped by recruiting service desk staff from within the business itself.the costs of introducing all of this kind of technology must be carefully weighed against the benefits that they bring in terms of service improvements and operational efficiency. as discussed earlier. Service Desk Technology For the service desk to work effectively. Summary In this lesson we have been looking at the reasons for and functions of an ICT Service Desk. some investment in modern technology will be needed. We have examined different strategies for structuring and resourcing a service desk and we have seen the skills and attributes that service desk staff must have if they are to operate effectively. Automatic Referral or Escalation tools would divert an issue to a pre-determined list of second-line support staff after a certain period of time. And finally .1. We have seen how the Service Desk’s role is to act as a single point of contact and the users friend in IT.8 of the Service Support Manual. their facilities and equipment. or in multi-national organisations. Useful software technology would be Intelligent Knowledge-based systems that record incidents. to be brought to the operators screen before the call is even answered. Database access would provide fast identification of known errors. Relevant technology can be categorised into two types.

are often regarded as part of normal operations. many organisations include Requests for Change within the scope of incident Management. because the processes are essentially similar. or a reduction in quality of. the Service Desk often plays a key role in Incident Management. but again with no central recording or control. Automatically registered events. It is considered good practice to record all enquiries as incidents because they are often evidence of poor quality training and/or inadequate documentation. incidents were handled by a fragmented set of processes where users faced with a problem would contact IT staff direct and any resolutions would not be documented. Alternatively. • When you have completed this lesson you will be able to: Define the term Incident Management according ITIL Best Practice. would like to have the system down for longer so that they can conduct analyses and identify strategies for designing out any problems that may exist. which is described in Chapter 5 of the Service Support book of the IT Infrastructure Library. Incident Management – Introduction ITIL defines an incident as “Any event which is not part of the standard operation of a service and which causes. Problem Management is more about identifying the underlying cause of faults and finding ways of engineering out these faults in the longer term. Understand the difference between Incident Management and Problem Management. They are still included in the definition of Incidents though – albeit that the service to end-users may never be affected. an interruption to. that service”. such as the failure of a disk drive or a network connection. However. Identify the key stages in an Incident’s Lifecycle. Incident Management is more aimed at a “quick fix” or a workaround rather than a longer term structural resolution to any fault. One of the main goals of Incident Management is to restore normal service as quickly as possible. Historically. This has to be balanced against the efficient us of resources – and the prioritisation of different incidents that can occur simultaneously. This approach led to poor use of expensive resources – the IT experts – to a failure to learn lessons from previous incidents. with a minimum of disruption to the business. ITIL Best Practice processes aim to resolve both of these issues. It may be that following the initial logging. system monitoring tools may have alerted technical specialists who would rectify the problem. A request for a new product or service is usually regarded as a Request for Change rather than an Incident. on the other hand.Lesson 2b Incident Management Lesson 2b Incident Management Objectives In this lesson we will be examining Incident Management. It is important to distinguish between Incident Management and Problem Management – which is the subject of the next lesson. recording and monitoring their progress and retaining ownership on behalf of the user as long as the incident is still “open”. This can of course lead to some conflict between the two disciplines when Incident Management staff are driven get a system back up and running quickly. • • • • The Scope of Incident Management As we mentioned in the previous lesson. The priority for Incident Management is recovery of service as quickly and painlessly as possible. or may cause. 20 . a distinction is made between simple queries and an incident that relates to a failure or degradation of a system. Assess the priority of Incidents can be prioritised based on a number of factors. Their colleagues in Problem Management.

It is quite likely. Recovery itself may entail the business in further actions. Initial Support may involve the application of a work-around. The example classifications given in ITIL are Hardware. the problem may have been resolved by replacing the disk drive. one of the vital jobs at this point of the life-cycle is to identify the correct second-line support group to whom the incident should be functionally escalated. Incidents can also be classified into different types for use in subsequent analysis. Incident Lifecycle It’s very important to understand the process that an incident goes through from its initial detection right through to its point of closure. Resolution and Recovery may involve raising a Request for Change and getting that change implemented. and then assigning a priority to the incident. which they don’t use until the final resolution of the underlying problem. some sort of temporary solution that we know about from the existing problem or incident database. such as re-entering or verifying data. If this total process is taking too long then hierarchical escalation procedures may end up being used. a work- 21 . in that several attempts may be required in order to find the best resources to tackle the problem. Also included in this part of the process will be the matching of the details against previously reported incidents to check for known errors.Lesson 2b Incident Management around may come from the expertise of the Service Desk staff – in which case it should be recorded for future use. for example that an initial report of a printer problem was classified as a hardware fault – but subsequent analysis determined that the fault was actually with the software. Software and Service Requests – but what is sensible here will obviously depend on circumstances. This would be true where a work-around is available. For example. In the event that the incident cannot be immediately resolved at the Service Desk. It is important that such corrections are made to the incident classifications so that an accurate record is maintained. We will be returning to the subject of priority in a few minutes. Alternatively. This activity may be iterative. It is vital that every incident is logged with a unique ID reference – even if we know that the problem has already been reported and a fix is being produced. for example. if a disk has crashed. Incident Closure should involve some confirmation by the originating user and. But the service has not been recovered until the data is brought up to date from the backup or archive copies. based on an official request for change. where appropriate a revised classification. It is possible for an incident to be closed whilst the underlying problem is still under investigation. as we discussed in the previous lesson. Investigation and Diagnosis may result in a direct resolution or the incident being routed to the identified second line support. Apart from the basic details about the incident. This shuttling backwards and forwards of an incident between different support groups is one of the major issues for Incident Management. Some organisations have an extra category which is “Incident Closed and Underlying Cause Resolved”. the log will normally include details of how the incident was reported and the services and Configuration Items that are affected. The first step is the detection and recording of the incident.

If a “known error” is generated then in most cases this will lead to a Request for Change – in order for the underlying fault to be corrected. Remember that everything should be logged as an incident – even if it is a Service Request ie. monitoring. it will eventually have to be brought back into the incident lifecycle at incident closure. any problems and their links to incidents. Unless. problems. Pragmatically.Lesson 2b Incident Management Whilst all this is going on there are the issues of ownership. It involves generating reports. resource availability will also have a bearing. there are good reasons why we should just live with the problem for now because the cost of a shortterm fix is not justified. In understanding the full lifecycle of an incident it is important to know what further records and processes may be generated as a result of an incident. ITIL standard practice guidance says that all these activities remain with the Service Desk and the use of to help with automatic status tracking is very important in the incident lifecycle. about any “known errors” and their links to problems.. requests for change. So if nobody with the right 22 . the Configuration Management Database should be being updated with information about the incident. Additionally. The absence of a Configuration Management Database will make it very difficult to harmonise separate incident recording. In other cases. A good example of this might be ahead of a major infrastructure change. keeping users informed and managing escalations. Once a Request for Change has been through the Change Management process as defined by ITIL. Whilst all this is going on. where making significant changes now would not be worthwhile. Some problems will justify the generation of a “known error”. either by the Service Desk or direct to the incident management process by automated support tools. not just a work-around. such as incidents. However. in order to achieve the close down of that request procedure. So an integrated Configuration Management Database not only contains configuration item information but also related support records. then this will lead to the release of a structural solution to the problem. and release records. such as a password reset for example. We will be looking in more detail at the Configuration Management process in Lesson 3. This will be a permanent fix to the underlying fault. since it determines what effort is going to be put into its resolution. Assessing Priorities Assessing the priority of an incident is a very important process that needs to be carried out early in the incident’s lifecycle. known errors. All of these are proactive activities carried out by the incident management staff – which is usually the Service Desk. If the Classification and Initial Support process determines that the incident is in fact a Service Request then the Service Request procedure will be invoked. this being an admission or statement that we are aware of the problem and we have a resolution to it. it may well be that a workaround is an adequate solution – at both the incident and problem levels. other things can also come into play. as we have just said. or if the Service Desk or second or third-line support cannot ascertain the underlying cause. Because the request was raised as an incident. When an infrastructure fault is first reported it is recorded as an incident. acting on the users behalf. Incidents can spawn problems if they are recurring incidents. Priority is determined mainly by the impact and urgency of the incident or enquiry. and change recording systems. problem recording. Finally. a request for a standard operational item. and about requests for change and their links to known errors. tracking and communication to be maintained. there will be constant updating of the status of the incident as it moves through the various points of it’s life-cycle. however.

in this definition. a fault with a payroll system that occurs on the 2nd of the month may well be considered less urgent than the same fault occurring on the 20th. For something to be high priority both the impact and urgency must be high. So a high urgency does not always mean a high priority if the impact is considered to be relatively low. So it is important to work very closely with the business in order to understand the factors that are considered high or low impact. and SLA threat – Problem Management staff must be informed so that they can provide extra support to the Service Desk team. Note that when a major incident occurs – in other words one with a high impact. The Service Level Agreement for the service states that only four incidents per month are permissible. We have seen how Incident Management is Defined. Where there are a number of medium priority incidents to resolve then clearly the ones that have suitable resources immediately available will be tackled first. is the measure of the effect of the incident on the business. which is the subject of the next lesson. Lets say that Incident A occurs and that this is the fourth incident relating to a particular service in the current month. For example. These two factors together dominate the ITIL model for determining priority. Although if both the impact and urgency are high then it is likely resources will just have to be made available from whatever sources. In these circumstances – all other things being equal – it would be reasonable to give Incident a higher priority. Service Level Agreements can also influence priority. The resources available are also likely to affect the priority given to an incident.4 of the Service Support Manual. In both cases. the scope of Incident Management and the differences between Incident Management and Problem Management. On the other hand Incident B occurs on a different service and this is the second incident to have occurred so far during the month. Benefits & Problems of Incident Management The benefits of and potential difficulties with Incident Management are listed on Page 18 of the little ITIL book and in Section 5. We have also examined the different factors that must be considered in determining the priority of different incidents. This could be measured in terms of numbers of users affected or financial loss for example. Another factor affecting priority may be the existence of a specific statement in a Service Level Agreement that is threatened by the incident. Impact .Lesson 2b Incident Management skills to solve the fault is immediately available it may have to be put down the list a little. urgency 23 . which may be competing for limited resources. Urgency concerns the time scale in which the incident needs to be resolved. As we have already mentioned. We have followed the main stages through which an Incident passes during it’s lifecycle and looked at the records that must be kept and the need for an integrated Configuration Management Database. Summary In this lesson we have been examining Chapter 5 of the Service Support Manual – Incident Management.

List the benefits gained from this process As the term suggests a proactive response is an ongoing and methodical process. where they support the incident management process and the service desk. and a satisfactory resolution found to that problem. we aim to use skilled. ITIL defines a problem as ‘the unknown underlying cause of one or more incidents. This prioritisation is sometimes referred to as ‘prioritising in pain factor order’. and the related problem. Proactive response adopts a forward-looking approach. The pain factor relates to the number of people affected by incidents. and IT provision. Identify Problem Management’s reactive and proactive activities. The ‘reactive’ requirement of problem management is to resolve Problems quickly. As is common to other ITIL processes. but also has a proactive element. if IT users were encountering lots of problems caused by poor quality software delivered and supported by a third party • • • The final component in the ITIL infrastructure library guidance for supporting the user of IT services is Problem Management.Lesson 2c Problem Management Lesson 2c Problem Management Objectives In this lesson we will be examining Problem Management. Remember that we said that Problem Management processes are normally carried out by technical staff. As is common to other ITIL processes. and with other internal and external suppliers. technical specialists in the most effective way possible. Problem Management responds to incidents in a reactive way. We will define the difference between problems and known errors a little later in this lesson. Once a problem has been identified. and more of their time on resolving underlying causes of those incidents through problem management processes. It should identify the underlying problems. effectively and permanently. and the seriousness of the impact on the business. it should be a permanent solution that will resolve the problem and the related incidents. When you have completed this lesson you will be able to: • Define the term Problem Management according to ITIL best practice. which is described in Chapter 6 of the Service Support book of the IT Infrastructure Library. Whether problem management acts reactively or proactively. and to proactively prevent the occurrence of incidents. and with a combination of Service Desk. Recognise the standard set of activities for problem control and error control. allowing them to concentrate on major incidents. Broadly speaking. 24 . The intention is to minimise occurrences of incidents by identifying and resolving problems and known errors. it is important that resources to deal with them are prioritised on a ‘business needs’ basis. and that is to minimise the adverse effect on the business of incidents and problems caused by errors in the infrastructure. the communication of management information between IT Service Management roles is very important. Incident Management and Problem Management. then the change will normally be implemented through change management procedures. Any workaround should allow the smooth continuation of business. Problem Management exists to ensure that a process is in place which identifies once and for all the root causes of problems. and distributed to other IT Service Management roles. they may even get involved in making decisions about purchasing. Problem Management processes are usually carried out by teams of technically focused specialists who work closely with Service Desk and Incident Management staff. thereby attempting to minimise underlying problems and their causes. and find an immediate workaround. It also helps minimise the effects as well as preventing potential problems occurring in the future. When a resolution is implemented via the change management process. This information is used both internally. problems and errors.’ It goes on to define the goal of Problem Management. For example. Trying to prevent issues occurring by providing intelligent analysis of problem trends and statistics. such as Availability Management. within the problem management team itself. which are causing related incidents.

Ultimately. Normally a service and its configuration items are introduced to the live environment with some Known Errors. Finally conducting Major Problem Reviews. A problem only exists from the point of identification to the point when we have found the reason for the problem occuring. Error Control focuses on resolving Known Errors under the control of the Change Management Process. Error Control has become a common process in both the applications development. or in evaluation or analysis of the software or supplied service. So let’s look at some problem management definitions in more detail. We defined how Problem Control focuses on transforming Problems into Known Errors. In some instances they could also revoke the contract. targeting support action. to monitor them. One of the most effective Problem Management techniques is to match against a number of multiple related incidents. This Configuration item information can prove useful when attempting to identify the underlying cause of incidents. identify and prevent the problem reoccurring in the future. and Providing Management Information from Problem Data includes techniques such as trend analysis. It is the responsibility of the Problem Management process to review. can provide vital information on expected levels of availability. so that when related incidents are reported in the live environment they can easily be identified. by redirecting the efforts of an organisation from reacting to large numbers of incidents to preventing future Incidents. and as a consequence. A Problem Record is then raised. These Multiple related incidents are of particular concern to Service Managers. and realising that they have a common underlying cause. enhancement and maintenance environment and the live environment. and the duration of these breaks will be no greater than two minutes. This process redefines a Problem as a Known Error. It does this by identifying the root cause of the problem and providing a temporary workaround where possible.Lesson 2c Problem Management supplier. The provision of management information from problem data to Availability Management for example. and to eliminate them when feasible and financially justifiable. Once this point is reached the Problem becomes a ‘Known Error’. an SLA might specify that in any rolling month there will be no more than two breaks in service provision. They could use this to help the suppliers make improvements. then information gained from Problem Management would be very useful to the Contract Management team. information from these reviews can identify weaknesses in problem management and incident management processes. or existing Known Error records. Proactive Prevention of Problems. influence statements made about availability in Service Level Agreements. you provide a better overall service to you customers and make better use of the IT support organisation resources. These are • Problem Control • Error Control • Assistance with handling major incidents • Proactive prevention of problems • Providing management information from problem data • Conducting major problem reviews Problem Control focuses on transforming Problems into Known Errors. The objective of Error Control is to be aware of errors. which is ‘The unknown underlying cause of one or more incidents’. as they can threaten reliability clauses within Service Level Agreements or Contracts. Hence Problem Management helps by providing a very important role in the ITIL Service Management structure. So any train of events casing us to approach these parameters is a major concern. For example. Firstly. These reviews take place after a problem causing major incident or multiple related incidents have been successfully resolved. the definition of a problem. and communicating this information to relevant management areas. by providing early Identification of problems. 25 . New Problem identification occurs when we are unable to find a match amongst the definitions of existing problems. These review procedures form part of a ‘Service Improvement Programme’ a key task for any ITIL conformant organisation which aims to improve value and quality. It is important that these are recorded in a ‘Known Error Database. and providing support to the organisation. So how do we define the responsibilities of staff working in Problem Management? These responsibilities can be broken down into a number of focused areas. Typically 80% of incidents are caused by 20% of the IT infrastructure components. Additionally.

We will discuss this classification process in more detail later in the course. Problem Management is unlikely to implement the resolution of an error. which allow those working in Problem Management to use a structured approach to problem diagnosis. and at this point it will be linked to requests for change. ITIL recommends. Ultimately the outcome from this process should be a Known Error. and require a good technical knowledge. Classification Problem Classification is often an extension of the incident classification. such as the incidents that caused it. which leads to further investigation and so on. These two stages are complex. It may also be a reoccurring incident. It’s likely that the incident will pass through the change process. These are: • Identification • Recording • Classification • Investigation • Diagnosis • Review & Closure Each reported incident passes through this process set. The appropriate people involved in the 26 . and is used mainly to determine an appropriate allocation of resources. a problem might be identified in the Local Area Network.Lesson 2c Problem Management The Problem Control process set consists of a standard set of control activities. there are occasions when Change Management may devolve authority to the Problem Management team. However. Both are important mechanisms. any resolution is likely to require some level of agreed change. Review and Closure On resolution of every major Problem. so let’s take a few moments to define each of these in more detail. amongst others. and a link is generated to any associated records. although there is no statement on how to do so. and also to any Known Errors to which it might relate. Initial investigation results in initial diagnosis. Importantly. ITIL’s good practice guidance suggests that. for particular types of problems. Problem Management must still raise the necessary change records in order to do this. Although Error Control remains part of the Problem Management Process Set. and to be able to track back. a record is created with a unique identifier. In general it is important to record everything. where a trend has been identified and a problem identified as a result. Or it might come about as a result of Problem Management’s proactive work. supported by problem solving and diagnostic skills. Investigation and Diagnosis These two stages are defined separately because they form an iterative process. within the configuration management database. This leads to the creation of a team of problem solvers mainly drawn from network specialists. Once a Known Error has been identified then it is handed to Error Control. Recording Once a problem has been identified. hence the responsibility for the resolution will transfer to Change Management. Known Error records are kept. Problem Management should complete a major problem review. An incident might be completely new and have no matching characteristics with records in either existing Problem or Known Error databases. These are Kepner and Tregoe analysis and Ishikawa fishbone diagrams. two techniques to help this process. regardless of the type of fault. For example. which has already been identified. Throughout this process records will also be linked to related configuration items. Identification Problems can be generated from many sources.

Often this work is carried out in conjunction with Availability Management staff. For example. what at first appeared to be a problem with a network might actually be the result of a database problem. by checking knowledge bases for records of problems. hardware and software configuration. release procedures and so on. This analysis might indicate that a particular network route is more heavily used than expected. The examination of over complex relationships. This process is known as ‘classification’. However. A proactive activity involves the analysis of past incidents. or at least reduce. For incidents. can identify any vulnerable points that are a potential threat to business. the Problem closure is the last of the Problem Control Activities and is often carried out automatically when a resolution to a Known Error is implemented. it is usual to retain both the initial and final classifications. which has a similar server. for example testing procedures. or merely a small inconvenience. might reoccur at another site. If we are experiencing a large number of incidents related to several different areas of the business then priority must be assigned appropriately. However we should point out that an interim closure status can exist.Lesson 2c Problem Management resolution should be called to the review to determine. Service Desk staff will be able to link Problem Classification When a Problem is identified. and the IT infrastructure as a whole. this impact. when a Known Error has been identified and a solution put in place. This can be particularly important when problem resolution is ‘time constrained’ by a Service Level Agreement. Known Error or Problem records. ‘Closed pending PIR allows us to confirm the effectiveness of the solution prior to final closure. and as a consequence is a potential future risk. and our own internal staff. problem or change will have both an impact on the business services and urgency. or single points of failure. analysis might identify that a preexisting problem at one site. and involves careful analysis of paths through the component infrastructure that make up the various services. a status of ‘Closed pending Post Implementation Review’ could be assigned to it in either the Incident. The problem is then reclassified. For example. providing access to ‘knowledge bases’. Internal staff can be encouraged to take part in system reviews during development. and the progress of those technical support staff that are called in when problem diagnosis. life threatening. Known Errors. the amount of effort required to detect and recover the failing Configuration Item has to be determined. For more serious Problems or Known Errors. Problem classification is also used to prioritise the sequence in which problems are addressed. One of the main reasons for problem classification is to ensure that any group of specialists that we bring together to solve a problem is the most appropriate. ensuring a higher level of maintainability is designed into the system. For example. For example. investigation and resolution is necessary. Another element of proactive problem management involves working with third party suppliers. If a problem is generated by the local area network. Finally. a customer using on-line banking to read their balance may involve hundreds of different paths. changes etc. It is also important to be aware of the impact of the Problem on existing service levels. And finally. Every incident. A problem’s classification may well change as a consequence of the diagnosis activity. 27 . • • • • What was done right What was done wrong? What could be done better next time? And finally how can we prevent Problem from happening again Impact describes how vulnerable the business might be. This first classification of a problem is described as the ‘initial classification’. so that resource allocation to problem areas can be improved. Sources of Problem and Error Identification We discussed earlier in this lesson how problem management works reactively to identify problems. Also involved is the broader analysis of the IT infrastructure itself. then it’s important that we assemble LAN and desktop specialists. remember an important part of Problem Management is to continually monitor its own progress. this may involve nothing more than a telephone call to the user to ensure that they are now content. For example. to ensure all procedures are adequate. Urgency illustrates the time that is available to avert. a formal review may be required.

then the Service Desk can execute this. The first example is defined as a routine incident. A situation might arise. a product is released which contains Known Errors. To identify incidents. This proactive activity includes analysing and maintaining the Known Error Knowledge base. raising a request for change to achieve this. where due to time or cost constraints. 28 . Update the category data in the incident. if this is valid. it is vitally important that the preexisting Known Errors are recorded in a Known Errors Knowledge or Database. In this case the incident then follows a similar route to our Known Error example. and exits the model at the routine procedures level. Closure only occurs when the relevant change has led to the business finding a satisfactory resolution to the underlying errors. often with the support of change management. And finally Error Closure. It’s worth noting that Problem Management is responsible for recording errors discovered in both the live and development environments. Error assessment involves deciding on how to resolve the error and. and to assign actions to them. one which isn’t recognised at the Service Desk. The incident process moves on to: Increase by one the incident count on the known error record. Let’s look at some example incidents and follow their path through the model. resulting in a better understanding of the underlying problems and Known Errors in the Organisation.Lesson 2c Problem Management recently occurring incidents to Known Errors and Problems in these bases. and the end-user. and if the workaround exists the user is informed immediately. but recognised in the Known error database as a database related error. information management moves it through an Incident matching process model. Here Problem Management works closely with Change Management and Release management process teams. this could involve reclassification of the incident. The next process is to extract any permanent resolution or circumvention knowledge from the known error database. problems and related incidents. in order to provide support to the Service Desk. An incident might have been initially identified as a network error. and identifying underlying trends in Known Errors. in other words. Error Control consists of four defined processes and these are: • • • • Error Identification and Recording Error Assessment Recording Error Resolution Error Closure Error identification and recording only comes about when a root cause and. Initially we will attempt to match it against our Known Error database. as it’s a preexisting Problem it does have a match in the problem database. Recording Error Resolutions in documents that the problem has ‘actually’ been resolved. then the incident moves to ‘inform user of workaround’ status. Error Control also has a proactive element. If a permanent resolution exists. The second example is defined as a non-routine incident. Assisting Incident Management is a fundamental responsibility of Problem Management. However. For the Service Desk to match incidents in the faulty software to Known Errors. If a match is found. All four of these processes are classified as reactive. The third incident example has no match in the Known Error database. a temporary workaround has been found. if possible.

It’s also focusing on the key problems. leaving implementation of proactive manage-ment areas until later. and Problem and Error identification processes. Benefits & Problems The benefits of and potential difficulties with Problem Management are listed on Page 22 of the little ITIL book and in Section 6. To achieve tangible benefits in an ITIL compliant organisation Problem Management cannot operate in isolation. 29 . This incident is identified as being caused by a new problem. and useable knowledge bases exist. We finished by defining the four Error control processes. and the reasons in favour of implementing Problem Management. then it’s best to focus on the reactive elements of problem and error control. the fourth example has no matches in either the Known Error or Problem databases.4 of the Service Support Manual. Summary In this lesson we have been examining Chapter 6 of the Service Support Manual – Problem Management We have examined in detail the standard set of control activities. and some possible drawbacks. which are causing the greatest ‘pain’ to the business. the Incident Management. of Problem Management implementation. To work effectively. The incident is then forwarded for further support to the problem management team. Remember Pareto? 20% of Problems may cause 80% of service degradation.Lesson 2c Problem Management Finally. If ITIL implementation resources are scarce. and a new record is raised in the Problem database. We’ve looked at three interrelated areas. and to outline the benefits. and the Problem Classification. Ideally once service monitoring activities are in place. Problem Management and Service Desk functions. it must coexist with a structured incident management process.

Problem Management. then we can’t know what any ‘fallback site’ should contain. Information provided by Configuration Management is very useful to other processes. how much it cost and what depreciation model we are applying. For example. and the type of information and records it contains Describe the five Configuration Management sub-process. To know the total cost of the IT infrastructure. their ICT components and any related support records. configuration information about a fault in one type of workstation could help Problem Management rectify future problems before they occur. four major To account for all IT assets and configurations within the organisation and its services. recording details about services. effective Capacity Management planning and Availability Management planning can only take place if they fully aware of all ICT components and their relationship to each other. how can we build something without knowing what we are building on. Planning. where it was sourced from. The objective of these Processes is to. • Ensure that the organisation has accurate records of its ICT assets Changes to the IT services are executed quickly and with the minimum of business risk To ensure an integrated set of data exists. • • • Configuration Management sits at the centre of the three ITIL Control Processes. In this lesson we will. It is critical for Configuration Management to support IT Service Continuity Management. knowing what assets we have and their current status is fundamental to business stability. • Examine the relationship between Configuration Management and the Service Delivery and Service Support functions Define a Configuration Item in ITIL terms Look at the Configuration Management Database. Status Accounting and Verification. But without a thorough understanding of what a ‘live site’ contains. who is responsible for maintaining it. Knowing what we have. Identification. In any organisation. To provide a sound basis for Incident Management. This can be very useful for cost accounting of IT services. Control. To provide accurate information on configurations and their documentation to support all other service management processes. Configuration Management. ITIL guidance considers this process as the foundation on which a stable organisation is built.Lesson 3a Configuration Management Lesson 3A Configuration Management Objectives In this lesson we will be examining the first of the three ITIL control Processes. providing records that relate exactly to the real physical situation. and what dependencies exist between different assets. and what we have to build with. which is described in Chapter 7 of the Service Support book of the IT Infrastructure Library. In the same way. After all. Verify Configuration records against the infrastructure and correct any exceptions. Configuration Management provides organisational confidence. This is how ITIL defines the Configuration Management goals. Change Management and Release Management. So lets start by looking at how Configuration Management relates to Service Delivery and Service Support as a whole. • • 30 .

However existing systems are unlikely to cover the ‘relationships’ or linkages between these assets. A release record will contain information about a number of related CI’s. So how does Configuration Management store. problems and known errors. A service might be made up of several CI’s. rather than IT assets. These items together can provide a service. 31 . manage and update this information. Software. including information related to IT service staff and their skills. and it defines IT assets and services as Configuration Items. ITIL guidance suggests trying to link these databases. communications equipment and networks. For example a service for the personnel dept might consist of hardware. • In ITIL terms Configuration Management can be defined as Asset Management plus relationships. workstations. including procedures. ITIL suggests that we should be able to draw a map of how a service is assembled from its constituent components. Incidents. so that we can link a record to any related configuration items. software and related documentation. Peopleware. This graphical representation can help us understand the impact of any changes we make to a CI on the service as a whole. We have established that Configuration Management underpins all the Delivery and Support Processes. ITIL guidance is explicit on this point and states that ’without effective configuration management we are not likely to effectively implement the other ITIL processes. We’ve also established that it monitors the interrelationships or linkages between CI’s. contracts and so on. This linkage is very important. Information relating to Software. where it was purchased. Because configuration management’s remit is wider than pure asset management. making changes to one. The second level holds records related to IT services. This information is used for tracking the progress of change and release records. • • • • • • • And finally. we may hold requests for change. It’s also a service to which guarantees are applied. In the change and release section of the CMDB. including servers.Lesson 3a Configuration Management ITIL places Service Level Management at the very top of our objectives because it represents service delivery’s ‘shop window’ to customers and users alike. By definition this statements broadens the scope of Configuration Management. Service level management is supported by several Support and Delivery processes. including operating systems. so ITIL clearly focuses on Assets and their relationships. and related documentation. in the form of Service Level Agreements. can have a knock-on effect to several others. where they know the cost of equipment. all of which are individual configuration items. and its current status. Most organisations have some sort of asset management system in place. and the relationship between Configuration Items. The CMDB is also the ideal place to hold incident records. problem records and known error records if they are held on separate systems. application or script software. we tend to refer to the information that Configuration Management maintains as Configuration Items or CI’s. Changes and releases Records at the highest level contain information about the organisations hardware. and the service itself can also be defined as a configuration item. Details about Peopleware. information related to documentation. or any custom designed software. By doing so. future searches on a particular CI will return information relating to outstanding incident. change records and so on. This whole support structure is underpinned by the configuration management process. which amongst other things.’ A typical CMDB should contain information on: • Hardware. This system may only cover hardware and bought-in software. problem or known error records. enable Service Level Management to negotiate and comply with SLA’s. Services. and this will lead us to a failure to deliver a quality service. It does this by entering all this information into a Configuration Management database or CMDB.

software and documentation. The first of the Configuration Management subprocesses is planning. These are: • Planning • Identification • Control • Status Accounting • Verification Planning is carried out at the beginning of any process to establish a configuration management plan. ITIL suggests that Configuration Management is made up of five sub-processes. which should comply with a predefined configuration policy. Let’s look at each of these processes in a little more detail. the configuration management team would be expected to hold information about licences. a unique identifier. as a CI in the CMDB. asset management systems wouldn’t contain the linkages to incident. Perhaps more importantly. Also worth noting here is the management of software licences. servers. Configuration Management has linkages to two other information repositories. 32 . software. or is to be. guidelines and responsibilities The relationships with other ITIL processes The relationship with other parties carrying out Configuration Management And finally tools and other resource requirements • • • We start by defining a strategy. and replica configuration models in the IT infrastructure. and the repercussions of illegal software use can be severe. peopleware and so on.Lesson 3a Configuration Management which make up a new release. policy. Again records relating to the contents of both the DSL and DHS are held in the Configuration Management Database. procedures. so it’s considered good practice for configuration management and release management to work jointly on this process. under the control of Configuration Management and therefore subject to formal Change Control’. For example. but for its ‘live systems’ only. However. A CMDB can offer great benefits to an organisation. and ‘ITIL’ defines a Configuration Item as ‘any component of an IT Infrastructure. as with the DHS and DSL the physical licences might be held in a separate repository. For example the DHS might contain a fully configured standard server and workstation. However. or known errors. including a documentary item such as a Service Level Agreement or Request for Change. However the benefits might not be immediately obvious to senior management. or to change and release management records. and the Definitive Hardware Store or DHS. an organisation might want to establish a Configuration Management system. This has become a major issue for many organisations. and what it covers. and these are: • • Strategy. We briefly defined earlier in this lesson what constitutes a CI. which categorises the item into hardware. and will describe how to achieve a change defined in the change records. The DHS houses spare parts for critical equipment. will sub-define lower level configuration item records. Other common CI attributes might include a manufacturers or developers id. and should be revisited regularly. problem. Control. The processes of Identification. purchase date etc. distinguishing between hardware. ITIL suggests five key points which should be addressed in planning. In a fully ITIL implemented organisation. it will require a unique form of identification. For example hardware type might be made up of workstations. The DSL is the safe storage area for trusted software. and critically wouldn’t document the relationships between CI’s and asset records that a CMDB would. and is managed by the Release Management process. who might suggest that a simple asset management system would be sufficient. and in some circumstances. These are the Definitive Software Library or DSL. Also an ID type. scope and objectives Processes. In addition to the CMDB. asset management only addresses higher value issues in the infrastructure and doesn’t examine it to the same level of detail. its location. Status Accounting and Verification are on going. CI’s will vary in type. network equipment and so on. which is. Whatever the CI type. Firstly. what they contain.

CI information about the failed component could be held in the CI for the workstation. or to purchase an off-theshelf product. We will discuss this in more detail later in this lesson. balance information availability and the level of independent control. Remember the objectives should be ‘SMART’ objectives. if configuration management is implemented ahead of other processes. greater levels of CI detail exist in some areas than others. within any organisation. And finally responsibility has to be allocated. Accurate definition of the scope is important in order to understand the amount of work involved. Once the strategy.Lesson 3a Configuration Management Another policy may define that all new boughtin or internally developed systems or services are to be brought under Configuration Management control at the point of hand over. the policy might be to replace the whole workstation rather than the failed component. Achievable. This logic must also apply to software. CPU and other component parts. external software vendors. or a module or sub module of that program. A configuration item record may well contain information about candidate configurations items below it in its hierarchy. or a wider configuration. then it is important to define how these other processes will have to change to accommodate the new configuration management process. For example. The key target is minimum records’. configuration management is being introduced into the organisation after other ITIL processes. future inter-process relationships will need to be considered. Suppliers. in other words Simple. policy. After all. against the resources and effort needed to support the CMDB at that level. Having dealt with strategy. When defining a configuration item we need to establish what level of detail is appropriate. The greater the level of control required over an area or service. Careful consideration needs to be given to CMDB implementation. However. procedures. but not the communication network. Measurable. whether to design and build a CMDB from scratch. change and release management group is necessary. The second of the five Configuration Management processes is identification. Be careful in choosing the most appropriate level. the objectives can be outlined. So. Alternatively. and developers might have their own CMDB with which we want to exchange information. Generally speaking. The final point on planning is the use of tools. ‘maximum control with It’s also worth noting that. select a configuration item level which is most beneficial to the configuration management process. in this example scenario. The organisation might already have in place processes to control assets. the level of configuration hierarchy could be restricted by the support tools available. workstations and data centres. Also consider that a candidate CI might have linkages to other CI’s other than its immediate parent. Realistic and Timely. and then further down into its motherboard. processes and changes have to be carried out. and other resource requirements. and a timeframe in which to achieve them. So work should be allocating to staff in either a configuration management group. and the resources required. in the event of a workstation failure. policy and scope are defined. Although these may not be formally identified as a Configuration Management process. but this could be adapted and improved upon. The primary focus of the identification process is the establishment of the ‘Configuration Item Level. If. defining a CI as a program as a whole. with the benefit of automatic CI recording to the CMDB via these tools. The scope might encompass desktop services. the greater the number of configuration management record detail. For example. or it could be further categorised into its component parts. Vitally it should be possible to link the CMDB to system and network management tools. and make each of these a CI. Planning procedures should be created and maintained along with other related guidelines. but existing live systems will not be within scope. In these circumstances the CI 33 . Relationships with other parties who carry out Configuration management also requires particular attention. or change management processes. scope and objectives. a complete workstation might be considered as a configuration item. For example breaking down a workstation into its monitor and screen. our next action is to examine the processes. may be impossible if the depth of our CMDB system hierarchy is specified to two levels only. these plans. guidelines and responsibilities.

Version Identification needs to address the full lifecycle of the Configuration Item. or might be printed labels which we apply to identify the relevant CI’s. At the same time version numbers are assigned. For instance. If for example the development department assign their own version numbers. When identifying and refining CI types. or changes brought about by incidents. During the baselining process. items in development and awaiting release are also included. so. This is known as ‘baselining’. It’s very common to take baselines of standard workstation configurations to provide a ‘rollback’ position if recent changes prove unsatisfactory. but have subtle differences. are exactly the same. which.Lesson 3a Configuration Management information would show its linkage to its parent. including documentation. except for having monitors of different sizes. This slight difference in specification wouldn’t justify the specification of a new CI type. two workstations exist. we might come across candidate CI’s which are generally very similar. These are: Register. we should include the relevant related items. It can provide a specification from which copies can be built. In defining the inter-relationships between CI’s. These numbers should be monitored carefully. The most frequently used in ITIL good practice are Composition. CI’s are registered as they fall into the remit of IT service management. A workstation being the parent. or the linkage from one category to the other. Defining scope identifies which items of hardware. At any point. and also a ‘used by’ relationship to other CI’s. Part of this process involves identifying the number of ‘configuration types’. then it’s important that this information is transferred to the CMDB at the point of handover. problems or known errors. Connection and Usage. To help us accommodate these anomalies we can specify these as a ‘CI variant’. software. Baselines should be established at formally agreed points of time. than to have to restructure the database at a later date. and can provide valuable review information after the implementation of a request for change. it’s far easier to have empty elements in the database. If we receive new equipment from an external supplier. This can be a very useful process. There are many reasons for updating a configuration items status. the monitor. and their linkages with other CI’s. before making significant change to the infrastructure. These might exist in electronic format. Documenting these linkages in the CMDB can have a huge impact on database size. we should establish that information received from the supplier is accurate. It’s good practice to establish in advance the required levels of CI’s in the database. Each new CI added might identify three or four linkages. there are a number of typical ‘types’ which can be used. ‘Connection’ describes the relationship between hardware items. The control of configuration items consists of three sub processes. items should be labelled. to reflect the position at a particular time. An additional function of the control process is to protect the integrity of configurations. in addition to those items already in the live environment. procedures. For example. Successfully building and maintaining a CMDB depends on accurately identifying and labelling its configuration structures and CI versions and types. With most CMDB tools. ‘Usage’ describes the interdependency between application usage of a common software module. Update and Archive. In many organisations this activity has a direct link with procurement. It would not be helpful to lose this level of detail by incorporating details into the parent CI. During development we might want to capture information about CI’s and their relationships. All these 34 . even if we don’t initially populate the database to this level. Finally having identified and documented information about CI items. For example. and what benefits their identification will bring. the current configuration consists of the most recent baseline plus any approved changes that have been implemented. ‘Composition’ is the simple parent child relationship. peopleware and so on. This is termed as defining its scope. The relationship between a LAN and a server for example. at the point of handover. keyboard or system box being the child. The third Configuration Management activity is Control. A change of ownership. A change of financial asset value. as baselining can provide a rollback point if things go wrong. a change in the CI’s status from testing to ‘live’. peopleware and documentation are to be included.

Interestingly many manufacturers are building automated management functions into their PC’s. It can also help us establish ‘baselines’. and to document changes in a CI’s status. the protection procedures should be in place for the definitive software library and definitive hardware store. What has happened to it up to this point? Its present status. Status accounting can also be used to monitor organisational procedures. ITIL recommends the use. following a major failure in the IT infrastructure. protection against unauthorised change or corruption. 35 . that a request for change on a configuration item was properly authorised. and installed software. and procedures are maintained so that the CMDB and the information it contains are secure. and not necessarily the destruction of the record. and we will be examining this in more detail in the release management lesson. And we would usually carry out an audit before the live implementation of a new Configuration Management database. • • Carrying out a manual verification and audit can be a time consuming and expensive procedure. sometimes known as ‘COTS’ packages. These audits involve checking the physical whereabouts of equipment. • The fourth Configuration Management activity is Status Accounting. ITIL defines status accounting as. During calls from users.’ Status accounting allows us to reveal a CI’s past status. we can then retreat to this ‘baselined’ point. it’s worth noting that in many large organisations. To establish that our records are accurate. Protection against viruses. for instance. If we encounter problems at a later date. of automated verification tools. In addition to the regular ‘spot checks’. Protecting the integrity of the configurations includes security against theft. Guarding against any environmental damage. The definition of what constitutes a redundant CI. is to establish that the information in the CMDB exactly matches the real life environment. decommissioning and timing details. or before the preparation of a baseline. Configuration control scope must extend to ‘bought in’ CI’s. These tools are able to roam networks and servers. and the secure storage of these back-ups. and configuration management process is most likely to be revealed by this ‘spot check’ approach. The primary function of Verification. service desk staff can ascertain what hardware and software are being used. After a disaster. would usually be specified in a predefined policy document. By declaring a status of ‘trusted’ we save all the configuration items and relationships as a baseline. and making back-up copies of the CMDB information. The fifth and final configuration management activity is Verification. for example the change from ‘live’ status to ‘withdrawn’. (what state is the CI in now?). This verification and audit procedure should be carried out regularly but randomly. By definition this will involve software licence issues. It’s also worth remembering that some verification can be carried out by the service desk staff. such as commercial ‘of the shelf’ software. where possible. or verification and audit as it is sometimes known. Deliberate avoidance of the change. and its future status.Lesson 3a Configuration Management updates have to happen under the authority of the configuration management process. ‘The reporting of all current and historical data concerned with each CI throughout its lifecycle. The protection process safeguards against illegal changes to CI’s. and whether this matches current configuration item records. Archiving decommissioned CI’s takes place when a component is no longer in use. Archiving involves the removal of CI’s from the CMDB and archiving onto secure storage. A single unauthorised change might be concealing many others. reporting on installed hardware and software. (What plans there are for this CI in the future?) This accounting procedure enables changes to CI’s and their records to be tracked. verification and audit would usually be carried out at the following times: • Before a new release. Following detection of unauthorised changes to the infrastructure. responsibility for the verification and audit process would rest with a Configuration Librarian. with the result that the CMDB would not reflect the real life situation. Configuration management offers little benefit if the information that it provides is out of date or inaccurate. Enforcing access control procedures. Importantly. Finally.

Identification. Control. implemented. 36 . Status Accounting and Verification. both supporting. The Known Error process will have links in the database to problem records. and the type of information and records it should contain. but this authority can be delegated in the case of incident and problem records. when an incident occurs we will record it in the CMDB. configuration management can be defined as asset management plus relationships. When the incident moves into the Problem process. Benefits & Problems The benefits of and potential difficulties with Configuration Management are listed on Page 26 of the little ITIL book and in Section 7. often acting on behalf of the change and release management processes. When executing a Request for Change the Configuration Items. and we looked at how these assets are defined as configuration Items or CI’s. We went on to examine the configuration management database or CMDB. We also looked at how the CMDB links to the Definitive Software Library and the Definitive Hardware Store. and configuration management as a whole. In this integrated environment we can see the fundamental role of the configuration management database and configuration management as a whole. which in turn are linked back to the ‘underlying cause’ configuration items. support this. We have seen how configuration management forms the foundation on which service delivery and service support functions are built. The CMDB is used to read and write information by each of the service support process throughout the incidents lifecycle. and their status changed as it moves through the tested. and how all of these processes support service level management. build stage of the change process. Summary In this lesson we have been looking at the configuration management process. And finally we looked at the potential benefits and pitfalls when implementing configuration management.Lesson 3a Configuration Management As we discussed earlier in this lesson. and their interrelationships.4 of the Service Support Manual. will be examined in order to asses the impact of the change. Change records will be stored. and depending on these processes. and it’s important to realise how the CMDB. and we went on to look at the relationship between Service Support and Service Delivery and the CMDB. Planning. When an incident is identified it passes through these processes. we will be recording the problem information in the CMDB. The ultimate update authority always lies with the configuration management process. and also looking at the CMDB for related incidents. Configuration management also remains responsible for updating the CMDB during the change and release processes. its structure. At the same time we could examine the CI’s which might be causing the incident. In ITIL terms. We discussed in detail the five Configuration management sub-processes. For example. configuration management is closely linked with the overall Service Support and Service Delivery process.

or changes which are the result of strategic decisions. On the other hand. ITIL guidance addresses the potential impact of proposed changes by suggesting the use of fixed change slots in what’s termed a ‘forward schedule of change’ As a result users are informed about up coming changes. and produces a backout plan. configuration and release management processes to be staffed and managed as a single team. Availability Management will be concerned about any impact the change has on service availability. ‘Change is the process of moving from one defined state to another’. The first of these is the ability to handle changes promptly and efficiently. So lets look at some of these relationships in more detail. Capacity Management will assess the impact on the business performance of any proposed change. including those in development areas. but to an appropriate level of detail. Change Management should handle them in a streamlined and pre-planned manner. Examine the relationships between Change Management and other ITIL processes. It’s supported in this role by Capacity. As a further safety net. and the goal of Change Management. and the Change Advisory Board Emergency Committee. giving the organisation a point to which they can retreat if a change proves unsatisfactory. 37 . Change Management must balance the need for change against the risks on the IT infrastructure of implementing it. • Define what change is in ITIL terms. Capacity. Change Management Relationships For change management to be effective it must work very closely with several other IT service management disciplines. Change Management has overall responsibility for assessing the potential impact of any changes on the ICT infrastructure. Capacity and Availability Management should be involved as early as possible in the change process in order to judge the impact of the proposed changes. These processes are. Historically. In this lesson we will. Where more significant and complex changes arise. they should be dealt with efficiently. Release. making changes to the IT infrastructure has resulted in a loss of business. Change Management is responsible for implementing changes in the organisation with the minimum of disruption. Define a Request For Change or RFC. and Availability Management. Availability and Configuration Management. Examine the Change Management process in detail. which is described in Chapter 8 of the Service Support book of the IT Infrastructure Library. When a need for simple and routine change occurs. It has many definitions. and lost production time. or it can be expanded to cover all changes. and when it will take place. and examine some of its potential sources Look at the role of the Change Advisory Board. So what is Change Management? Well let’s start by more accurately defining the term change. what the change entails. And finally. in order to minimise the impact of any related Incidents upon service’. but possibly the simplest one is the most apt. There are a number of key points here which highlight why the change management process is critical to a well run IT services organisation.Lesson 3b Change Management Lesson 3b Change Management Objectives In this lesson we will be examining the second of the ITIL control processes. ITIL defines the goal of change management in the following way. change management carries out impact analysis on proposed changes. ‘To ensure that standardised methods and procedures are used for efficient and prompt handling of all changes. Change Management can either be restricted to changes to the ICT infrastructure and the current ICT services offered in the live environment. We mentioned earlier in the course that its quite common for change. • • • • The second control process within ITIL guidance is Change Management. Change Management.

and be passed on to the Change Management Process. One of the main responsibilities of the Change Management Process is to establish a ‘Change Advisory Board’ or CAB. and it might not be outside our current Service Level Agreements. The exact content will vary depending on the origins of the RFC. Remember however. The impact is manageable. which generates a RFC after investigation of multiple incidents has lead to a known error and a proposed ‘structural’ resolution. Availability and Configuration management. In many cases this authorisation is with the help of other experts who form a body known as the Change Advisory Board. there is an ongoing update of information within the Configuration Management database. a request for change will contain such information as the sponsor. to meet customers requests.Lesson 3b Change Management Any change to the infrastructure involving software. Change Management is able to ‘Asses the overall impact’ of the change. At this point Change Management ‘authorises the change’. and business benefits are worthwhile. For example. As we said earlier. We may have a ‘New or changed business requirement for an IT service’. hardware. Or from Problem Management. The CAB will also advise on the grouping of changes into ‘releases’ to minimise disruption to the organisation and maximise benefits. where financially viable. hardware. 38 . and in the light of the business need make recommendations as to whether they should be accepted and implemented. part of Change Management’s responsibility is the analysis of any proposed change. Once assessed we should be able to state. or a new CI is created if we replace one piece of software with another and so on. As a consequence Change Management must work closely with Configuration Management. the reason for change and initial costing information. The most common and well documented are those that form part of the incident resolution lifecycle. it falls to Release Management to manage the actual physical implementation. recognition by the server. how they make up one or more services. an initial list of configuration items affected. or even to operational staff. addition to the network. To do this effectively it must understand what CI’s will be affected by the change. where the change is a simple one. The trigger for the Change Management process is the receipt of a Request For Change or RFC. that overall responsibility for any change remains in the hands of change management. intellectual property rights. and in some cases. will result in changes to Configuration Items. Implementation of new or changed legislation might bring about an RFC. their installation. A major change in business requirements may generate a significant Request for Change. be it effecting software. documentation or related infrastructure components. This may not have been reported via incident or problem management. Change Management can be devolved In these cases it is common for the Change management process to be devolved to Problem Management. However. The role of Service Management is to ensure full impact analysis against effects on existing services. the requested date for implementation. Such a request may have already passed through a conventional investment appraisal process. it’s important. often identified by the service level review process. Typically. By exchanging information with Capacity. your organisation has recently purchased new workstations. It also ensures that any RFC’s which don’t merit detailed consideration by the CAB are recorded. An RFC might arise because of customer or user dissatisfaction with a current service. and enters the ITIL Service Management process for a second review. Throughout the change management process. For example. Another source of RFC’s is the need for the introduction of new or upgraded CI’s. services and so on. For example. the cost of change is reasonable. who in turn generate an RFC. and on the infrastructure as a whole. security and so on. and if linked. The role of the CAB is to consider RFC’s. And finally when a change is ready for release to the wider user community. or rejected. Again this will generate a Request for Change. a CI status can now be moved to ‘under change’. the way in which constituent CI’s are linked. ITIL defines a number of sources from which an RFC can be received. services affected. where a user identifies an incident and reports it to the service desk staff. Particular examples include legislative changes relating to privacy. So Configuration Management identifies CI’s which are likely to be affected. on behalf of Change Management. providing the help and user documentation. will all generate RFC’s.

If the change is accepted it moves to the next process. These change types are usually considered low risk. and senior IT representative. they are ‘urgent change’ or ‘standard change’. or are repeats of earlier requests. and logs as soon as possible. users. Making changes to the IT infrastructure without making changes to any fall back sites can be very dangerous. financial. Significant and Major. There are two possible states from this assessment. and of course IT service Management staff. At any CAB meeting there may be a different combination of staff attending. although in some organisations it is defined as an approval board. however the core members of the CAB should be the chairperson. or as a direct result of incidents or problems. who will typically chair the meeting. after filtering it’s common for RFC’s to change status and be redefined as change records. remembering that RFC’s can come from many sources. However. developers. for example. When making decisions about a proposed change. An example of this might be a hard disk replacement or upgrade on a user workstation. It can then be dealt with via a pre-existing set of processes and authorisations. Change categorisation involves an initial assessment of the actions and resources required to make the change. a senior business representative. Whether changes are standard or urgent. seven days a week. consultants. One other area for consideration when deciding whether or not to implement a change is its likely impact on IT continuity plans. other service management staff. In such organisations it is usual to have a Change Advisory Board Emergency Committee in place. Ultimately the CAB is responsible. and makes changes traceable. customer. the principles for processing them remain the same. for ensuring that the change management and configuration management process work together to update relevant records. This involves assessing Changes for impact on the business and urgency. and don’t require consideration by the CAB. 39 . comprehensive testing of changes isn’t always possible. The CABEC are usually called in at short notice to analyse the impact of a RFC. and we will spend the next few minutes looking at this process in some detail. Often due to time and business pressures. technical and risk implications.Lesson 3b Change Management Typically a CAB is made up of a Change Manager. Minor. A ‘standard’ categorisation is assigned when a frequently occurring change is identified. At this point RFC’s are filtered. A word of caution here about CABEC activities. In general a CAB is regarded as an advisory body. other experts. the change is considered non urgent. Plus representatives of the customer. The CAB Emergency Committee In many large organisations IT provision is now 24 hours a day. However. and ITSM representatives. The committee would usually consist of the Change Manager. In this example. There are four possible outcomes from this process. have been incorrectly requested. are requests for service modification rather than changes. Change Procedures We established earlier in this lesson that the trigger for the Change Management Process is the receipt of a request for change. These are: Standard. and so passes onto the ‘Categorisation’ process. and we will be looking at this process later in this lesson. through the emergency committee. As a consequence this provides a definitive mechanism for change approval. ITIL defines a comprehensive change management process. To address these RFC’s. Nor are configuration items updated with status or change information. outside contractors. and the Change Manager allocates a priority to the change. It should also consider the repercussions of not implementing the change at all. urgent changes pass through a ‘streamlined’ version of the change management process. It’s usual for RFC’s to be logged in the CMDB ahead of this filtering process. It’s role is considered as advisory because the ultimate responsibility for change lies with the change management process and hence the change management staff. including the business. and authorise any correcting work. with the Change Manager rejecting those which. So lets start with an incoming Request for change. who acts as Chairperson. user. The initial recipient of the RFC is the Change Manager. In such environments the need for a RFC could occur at any time. the CAB should consider the business.

Lesson 3b Change Management 40 .

Remember. software. documentation and so on. so that if an error occurs during implementation. A change record will typically contain details of the back out plan. If however. The CAB will also perform detailed impact analysis. and outweigh any potential benefits the change might bring. then the Change Builder instigates the back out plans. Eventually implementation dates and a schedule are decided upon. and can also identify vulnerable areas in the IT infrastructure. to company Board or other senior management members. The review process can provide valuable information about our change management process. Change Builders are not normally permanent members of a Change Management Team. problem or known error records. accepted. possibly with a request to modify the scope of the change. The CAB activities of estimating and scheduling may well be iterative. in build. Change records are usually linked to impacted infrastructure configuration item records. If the Change is tested successfully it moves onto the Change Manager. which is passed to the relevant service management staff. If at this point a failure occurs. Note that a failure during the change building process will almost certainly result in the change returning to the CAB. After investigation. the first action is for the Change Manager to circulate RFC’s to either the CAB. for example the Capacity Manager. and put forward schedules for change based on priority and resource availability. significant and major will be defined by individual organisations. and this often requires input from ITSM specialists. If at the point of live implementation the change fails. As we saw earlier in this lesson. Note that throughout the cycle of building and testing. A successful review will trigger the ‘closed’ status. It’s important that all changes have a back out plan. or the RFC is rejected. not all RFC’s considered by the CAB will be accepted. who will report their actions to the CAB after completion of the change. who coordinates the implementation of the change. and the request for change or change record will be updated in the CMDB. The Change Builder may actually consist of several groups of internal or external staff. under test and so on.Lesson 3b Change Management The definition of minor. and the process continues until an approved change status is reached. so that we can carry out traceability tests. operating systems. At this point the failed change will re-enter the process at the CAB level. who are involved in hardware. 41 . Remember that the Change Manager has overall responsibility for the change. If the change is defined as either significant or major. A ‘minor change’ categorisation would usually be authorised by the Change Manager. then the CAB will have a significant role. Once the change is complete it moves to an Independent tester. the CAB’s role is to give advice. The change has now reached the Change Building sub process. provide estimates on required resources and timescales. As a consequence. and also to any related incident. where the change is tested and quality checks are carried out. CAB recommendations and scheduled implementation dates. the change can be reversed and the service restored. It’s important to accurately manage the change record system within the CMDB. this information is contained in a ‘forward schedule for change’. the Configuration Manager updates the Change Management Database. and the IT service management personnel’s current feelings about risk. the change is implemented successfully. the change record is frequently changed. This in turn would result in new requests for change entering the process. but are drawn from areas of technical expertise. In both cases. the change is returned to the Change Builder. Typical statuses include. when it was built. At the point of approval. and will be dependent on the current status of the IT infrastructure. it’s important that the Change Manager reviews the change. then this will be formally documented in a ‘Projected Service Availability Report’. but that Release Management normally has control at a detailed physical implementation level. the potential risk or financial implications might be considered too high. The aim here is to reduce the number of RFC’s forwarded to the CAB by filtering out any low risk changes. Note the CAB itself might be involved in the review process. A failure at the review stage would identify shortcomings in the implemented change. in which case it might re-enter the process at the beginning. If changes are likely to cause disruption to the business. and during implementation the Configuration Management process is updating the status of change records. and to the business as a whole. or in the case of a major change.

which has been given an Urgent priority by the Change Manager. We will spend the next few minutes looking at how Change Management deals with a RFC.Lesson 3b Change Management In the previous few pages we have seen how the Change Management process deals with a standard change. 42 .

Lesson 3b Change Management
The first action is for the Change Manager to call either a CAB meeting, or in an emergency situation, the CABEC. The aim of this meeting is to quickly evaluate the request for change, by assessing its impact, the resources required and its urgency. The meeting should establish whether it’s urgent status is justified. If the outcome suggests that the RFC status isn’t urgent, then it will be rejected, and will be dealt with as a standard RFC. If, on the other hand, the RFC status is confirmed as urgent, then it passes on to the next process and in to the hands of the Change Building Team. The Change Building Team then build the change and where technically possible, prepares a back out plan. When the change is complete, as much testing as possible should be carried out. Completely untested Changes should not be implemented if at all avoidable. In this case, the Change Manager then coordinates the implementation of the change into the live environment. If the implemented change fails, the Change Manager implements the back out plan. If the change is successful, then the Change Manager firstly ensures that records are brought up to date, carries out testing in the live environment, and at a later date, reviews the change. If after the review, the change is considered successful, then it is closed, and the Configuration Manager closes the RFC and updates the CMDB. Lets take a few steps back, and look again at the process, assuming this time we have time to test the change. This time our built change passes from the Change Builder to the Independent Tester who carries out testing as quickly as possible. If tests are successful, then the change is forwarded to the Change Manager for coordination of implementation. If the change fails during testing, then it returns to the Change Builder process. The Change Management process deals with Requests For Change from many areas of the organisation, and with different levels of authorisation. Where RFC’s are frequent and repetitive, they can be dealt with via preexisting and authorised processes. These processes are known as a ‘standard model for change’. Standard models needn’t be solutions to simple changes, often complex operations can have standard models. In general once a RFC is regularly repeated, we can create a standard model for that change. We saw earlier in this lesson how the Change Manager examines RFC’s and categorises them as either, standard, using a standard change model, minor, significant or major. To assign one of these categories, the Change Manager examines the RFC, and considers the following: Impact The impact the request for change will have on the business, considering such factors as the number of users affected. Novelty Is the change familiar? Has it occurred before? Together, Impact and Novelty can provide us with some idea about the level of risk involved with the RFC. A RFC with high impact and high novelty is certainly a higher risk. Devolved Authorisation Has the responsibility for change been devolved from the CAB to the Change Manager? Or further devolved to say the Service Desk. Standard Model Can the request for change be dealt with via a standard model, with a pre-established implementation process? So lets add some content to our table, We’ll start with column 1. This RFC is regarded as low impact to the business, and is a well known change, so the novelty is also low. Authorisation has been devolved to the change manager, and a standard model exists. This is a high frequency RFC. Column 2 is slightly different, again the RFC is regarded as low impact, but it hasn’t been done before, so its novelty is high, and as a consequence, no standard model exists. Again authorisation is devolved, and it’s categorised as a minor RFC. This type of RFC could act as a trigger to build a new standard model. In our third example, the results are slightly different. Our RFC has a high degree of novelty, and no standard model exists. It will be forwarded to the CAB, so authorisation isn’t devolved to the change manager. This RFC falls into the significant category. The RFC in our fourth example has a standard model, however, business impact is considered high, so devolution to the Change Manager won’t take place, and it must be examined by the CAB before the standard model processes are implemented. Hence this is regarded as a significant RFC.


Lesson 3b Change Management
As both the impact and novelty are high, the RFC in our fifth example must also be considered by the CAB. This is also a ‘significant’ RFC. In example six, we are considering a change which has very high business impact. For example, changing from an ISDN based telephony system to ADSL. Changes of this magnitude would normally be authorised at a higher level than the CAB. It is categorised as a major RFC. Finally, lets examine a couple of examples, which in general should be avoided. Firstly, a Change which is regarded as high impact, but which has devolved authority, this is likely to be considered very risky. Secondly, a change which has no standard model but is low novelty, should, by definition, have a standard model in place, and shouldn’t be re-submitted to the CAB. Over time, we should expect the number of standard models, and the changes passing through them to increase. This should result in a reduction in the number of changes forwarded to the CAB, and reduce the number of ad-hoc change requests devolved to the Change Management Process. The number of changes implemented during the measured period Number of changes backed out by reason code Number of Staff Training records up to date Cost per change verses estimated cost Number of urgent changes

• • •

By auditing the change management process we can check for compliance to procedures. In general a change management audit should investigate: All new software releases Checking that they have been through a proper authorisation process Incident Records Usually selected at random, through the change process and tracked

Minutes of CAB meetings Not only to check that CAB meetings have taken place, but also to see if identified action points have been followed through Forward schedule for change To see if it has been accurately defined, and importantly, that its been published to the user community, and is being adhered to. And finally, that Change review records are in place for all changes. Efficient Change management requires an ability to change things in an orderly way, without making errors and making wrong decisions. Effective change management is indispensable to the satisfactory provision of services, and requires an ability to absorb a high level of change.

Metrics & Audit for Change Management Process
We’ve seen in this lesson how Change Management improves the way in which an organisation implements changes. To clearly identify these improvements, Change Management measures process performance, and this is carried out in accordance with our own standards. Measuring performance usually takes place over time to show, for example, that the number of urgent changes is reducing. So that the results can be clearly understood at all levels in the organisation, this data is usually represented in graphical form. Regular summaries of the change process should be provided to service, customer and user management. Different management levels are likely to require different levels of information, ranging from the Service Manager, who may require a detailed weekly report, to senior management committees who only require a quarterly management summary. Typical metrics for measuring management process are: the change

Benefits & Problems
The benefits of and potential difficulties with Change Management are listed on Page 33 of the little ITIL book and in Section 8.4 of the Service Support Manual.

In this lesson we have been looking at Change Management, the second ITIL control process. We began the lesson by defining what change is, and the goal of Change Management, in ITIL terms.


Lesson 3b Change Management
We looked closely at the relationships between Change Management and other ITIL processes, particularly Release, Capacity, Availability and Configuration Management. We established that the trigger for the Change Management process is the receipt of a Request For Change, and we looked in detail at some of the sources of these requests. We examined the role of the Change Advisory Board or CAB, its make up, and the role it takes in the Change Management process. We went on to look at the role of the Change Advisory Board Emergency Committee. We studied in some detail the Change Management process for both a normal and standard and urgent RFC, and defined the standard, minor, significant and major RFC categories. Finally we discussed the use of metrics and auditing, in order to evaluate the change process, and highlighted the benefits, and potential pitfalls, of the Change Management process.


It focuses on protecting the live environment and its services through the use of formal procedures and checks. This process requires technical competence and its sub-processes are often performed by technical staff under the overall authority of the Change Manager.Lesson 3c Release Management Lesson 3C Release Management Objectives In this final lesson on the ITIL control processes we will be looking at Release Management. authorised and tested versions are installed in to the ‘live’ infrastructure. and its relationship with other IT and Service Management processes Describe what is meant by a Definitive Software Library (DSL). some of which may have already been issued as emergency fixes. ITIL defines the goal of this process is. use whatever means best suits the business. hardware and documentation required. To ensure successful distribution. This is especially important for “due diligence and governance”. A major upgrade or release usually supersedes all preceding minor upgrades. are considered together. This all sounds very simple. In general. by email. software needs to be kept securely • • • Introduction The third and final ITIL control process is Release Management.’ Release Management implements new software or hardware releases into the operational environment using the controlling processes of Configuration Management and Change Management. a release policy and a release metric Releases are often divided into: Major Software Releases and Hardware Upgrades These would usually contain large amounts of new functionality. ‘To take an holistic view of a change to an IT Service and ensure all aspects of a Release’. When you have completed this lesson you will be able to: • Describe why Release Management is needed List the major benefits. both technical and non technical. releases of emergency fixes. however the process becomes much more complex when hundreds of servers need to be upgraded simultaneously throughout a large geographic and cultural area. costs and possible problems of this process Understand how the Release Management process functions. Emergency software and hardware fixes. ‘Roll out’ includes distributing all the configuration items to wherever they are used. a Definitive Hardware Store (DHS). it is likely that you will need to provide scripts to help install the release. Release Managements holistic approach to IT service change ensures that the business as a whole and any relevant technical areas are ready to accept. A release is defined in ITIL as a collection of authorised changes to an IT service. normally containing the corrections to a small number of known problems. This could be done in a number of ways. and the related changes it has undergone. some of which may make intervening fixes to Problems redundant. Minor Software Releases and Hardware upgrades Usually containing small enhancements and fixes. And finally. either via the internet. or by simply posting CD’s. As part of the Roll Out activities. which is described in Chapter 9 of the Service Support book of the IT Infrastructure Library. as well as passwords to activate the release when needed. a Relapse Schedule. It is the responsibility of the Release Management process to plan and oversee the ‘roll out’ of these changes. clear and repeatable processes as well as technical and business skills will be required. Additionally Release Management ensures that we can trace where a particular version comes from. implement and use that release. To make this possible. So why do we need Release Management? Well in simple terms it’s the control process which ensures that all aspects of a release are handled properly. 46 . Release Management is also tasked with ensuring that only the correct. A minor upgrade or release usually supersedes all preceding emergency fixes. including the software.

Note that ITIL refers to specific steps called ‘Roll Out Management’ and this may take place after independent testing to manage in more detail the actual implementation stages that follow. For example. operational acceptance tests and so on. its own area of preproduction. Also worth noting is that any back out plans which have been prepared should also be tested. Information is held here on Release Records. The Release Management process encompasses three defined areas of the organisation. build it or rebuild it in the live environment. There may be three separate stages. Throughout this process it is very important to update the CMDB. Release Management also agrees the exact contents of any release and a detailed roll out plan with Change Management. during and after the move to the ‘live’ environment. which contains both the Definitive Hardware Store. and the Definitive Software Library or DSL. distribution. The development area. and finally the production area. firstly to distribute software. secondly. Roll out management usually comes into play when we’re dealing with very large and complex implementations or ‘roll outs’. potential rebuild and implementation.Lesson 3c Release Management before. and that any status changes to these records is documented. Although we show the DHS & DSL within the Pre-production area. The migration from one are to the next. before we attempt implementation. 47 . It may well be that significant customer acceptance testing has already been carried out. Within the actual production environment we will have to deal with. Each of these three stages should be verified as accurate. tests and other appropriate quality checks. or live environment. However operational acceptance tests are very important – they ensure that anything that goes wrong in the live environment is supportable maintainable and robust. Release management has full responsibility for the pre-production environment. preproduction and live environment. of software and hardware releases. and finally implementation. it’s just as important to control a hardware change and release. it is important that it remains detached from the development. or DHS. Independent testing might include customers acceptance testing. as it is to manage the software equivalent. we should be absolutely certain that a rebuild process has been achieved correctly. Remember. Part of Change Management’s role is to decide on the particular contents of the release and it is very important that the release management team are fully aware of the decisions that have been made by other organisational elements. is only permitted subject to satisfactory results from reviews.

The same organisation may decide that a more appropriate Release unit for PC software should be a suite level. or module level. The definitive Hardware Store should be protected in a similar way. An additional minor release which involves changes to some of its applications 48 . employing adequate security and access controls. or a combination of the two. Information related to the contents of the DSL and the DHS is held in the Configuration Management Database. tested. Commonly the DSL consists of separate disk volumes or servers containing software for individual environments. application suite. Release types are defined in to 3 categories. and are usually scheduled over longer periods of time. if the release unit is at program level. full release. distributed and released together.0. A ‘Package Release’ might consist of groups of delta or full releases. distribute and install. and so on. CD’s and so on. Different release units will exist in different parts of the infrastructure. Delta releases are most appropriate for fixes and urgent or emergency changes. and the Definitive Hardware Store. Software assets are particularly vulnerable to unintended loss or corruption. The general aim is to decide the most appropriate Release-unit level for each software item or type of software. Release Management has responsibility for two critical repositories. For example. Release management moves on to address the question of release type. For example a new Payroll System might be assigned a release Id of V:1. these are. such as fire or flood should also be in place. often at another location. then the whole program would have to be rebuilt. which might include many applications. Remember. and responsibility for keeping these records up to date belongs to Configuration Management. and as such form the most frequent form of release. would have to be rebuilt. The contents of the DHS should be updated as quickly as possible to reflect the live environment. These are the Definitive Software Library or DSL. by cloning these older versions. and to provide longer periods of stability ‘Package Releases’ can be used. Consequently this is a less expensive option. which might be stored in a separate cabinet. Appropriate protection against other threats. A full release is where all components of the release unit are built. and should have specific protection against physical removal. Backup copies of critical elements of the DSL would usually be kept. One of the key activities of Release Management is deciding on the correct ‘release type’. Storing older versions of hardware can be useful if the organisation encounters significant problems with new configurations and software. such as diskettes. However they do give confidence that all the elements of a service work together successfully. for example software which has been developed from valid earlier versions via correct Change Management Processes. Consequently full releases are expensive to build. then it’s possible to revert back. Once the ‘release unit’ is defined. Delta release and package release. They are most appropriate for major changes. This can be set at System. Firstly it defines the ‘release unit’. and as such a change to a CI which forms part of that system will result in a full release for the whole of that system. responsibility for maintaining the contents of the DSL and the DHS is shared between Release Management and Configuration Management. program. by running regular virus checks on any item entering the library. which is defined as ‘that set of Configuration Items within the infrastructure which is normally released together’. or DHS. To reduce the frequency of Delta and Full releases.Lesson 3c Release Management Definitive Software Library and the Definitive Hardware Store. Additionally the DSL could contain other software media. Delta releases involves distributing only the components that have changed since the last release. For example an organisation may decide that a normal release unit for its order processing service should always be at system level. If it’s at suite level then the whole suite. so it’s important to take very good care of the DSL. It’s normal to use a numbering structure. Defining Release Type involves deciding on a form of Release Identification. Finally protecting the DSL against virus infection. which applies to two or three levels. The DSL contains only trusted versions of software. The DSL may consist of one disk containing all bought in and created software held in a single format. For example.

Ensuring these obligations are met is the joint responsibility of Release and Configuration Management. which they believe. The policy content is usually determined by the Release Manager. including those at the highest level.4 of the Service Support Manual. and information on Release frequency. To facilitate this. together with Release Management decides on the type or rollout approach. In a Pilot approach a single site receives all functionality ahead of other sites.1. Benefits & Problems The benefits of and potential difficulties with Release Management are listed on Page 39 of the little ITIL book and in Section 9. A Release Policy might also contain • Guidance on the level in the IT infrastructure to be controlled Details on release identification and numbering conventions A definition on major and minor releases. achieving a simultaneous upgrade can be problematic. with more coming later. • • • We mentioned earlier in the lesson that Release Management is responsible for the detailed planning of releases. 49 . A Big Bang approach involves all sites receiving all functionality simultaneously. Remember there is no absolute limit to the levels used. Compliance with software licence agreements has become critical to businesses. and that the licence agreement has been checked. plus a policy on issuing emergency fixes. that it has been virus checked.1. in conjunction with the Change Manager and the CAB. However. it is important to check what has been purchased has arrived.1. when moving software to the DSL. the Release Plan is extended to Rollout planning. and adds details of the exact installation process developed and the agreed implementation plan. phased or pilot approach. and impounding any equipment. contains unlicensed copies of their software. Note however that combinations are possible. In a phased approach all sites could receive some functionality at the same time.Lesson 3c Release Management would generate a release Id of V:1. and produces a back-out plan Where a release is going to be particularly complex it may require a specific planning phase. An emergency fix to a small element of a module within that system might have a release Id of V:1. This expands the Release plan produced thus far. for example a ‘phased pilot’ approach. Amongst other things. release planning involves: • • • Gaining agreement on Release Content Producing a high level release schedule Planning resource requirements Release planning is responsible for verifying all of the hardware and software in use is as standard. This might be a ‘big bang’. Remember penalties for breaching the laws on software theft are applicable to any responsible officer of the company. In addition the Release Planner develops a Release Quality Plan. Definitions of release Type and Release units should be documented in a Release Policy. This policy should also clarify roles and responsibilities. There are many legal precedents for holders of software intellectual property rights arriving unannounced at premises. and has been derived from the necessary definitive software library and definitive hardware store. The benefit of this approach is that it offers consistency of use across the organisation. Expected deliveries for each type of release Roll out planning involves: • • • Producing a detailed timetable of events Listing all the CI’s to be installed and decommissioned Producing Release notes and communications to End Users Planning Communication • Roll out planning. to ensure all aspects of the release are quality managed. For example.

We examined the Release Management process. and how. Minor and emergency releases. 50 . the Definitive Software Library and Definitive Hardware Store as well as the Configuration Management Database. We started the lesson by defining ITIL’s Release Managements goals. and discussed Release Managements holistic approach to IT service change. we have been examining Release Management. release units and release identification. We looked in some detail at release types. as part of this approach it produces detailed release or rollout plans. and why Release Management is necessary. and the linkages to its critical repositories. We saw how a release can be divided into Major.Lesson 3c Release Management Summary In this third and final lesson on the ITIL control processes. and we concluded the lesson by identifying some of the benefits. an potential problems with the Release Management process.

For most commercial and organisational systems there is a limit to the benefit in extra Availability Management Relationships and Definitions We will now explore the relationships that exist between Availability and the various elements of the support organisation. The generic definition of availability is: “The ability of an IT service or component to perform its required function at a stated instant or over a stated period of time. IT Services and their customers. They may say we expect no more than three breaks of service totalling one hour over a monthly period. Availability Management supports Service Level Management by actively managing the availability of services. or they may say we expect no more than one hour’s lost service over a four weekly period. problem and change management procedures. Availability is now regarded as one of the most important issues for IT service management because of the growing dependence of businesses on their IT services. the availability of a service is influenced by the complexity of that service and the systems that it is based on. In general. and is not directly concerned about the availability of any components that may be vital in making up that service. These statements might say that we expect 99% availability from a service measured over a one month period. customer dissatisfaction and extra costs in having to pay staff overtime for the work they couldn’t do when the system was unavailable. availability that the business can afford by using more and more advanced techniques and equipment. You will appreciate the main responsibilities of the Availability Management process and be able to recognise several techniques which are of use in this area. personnel records and so on. The Service Delivery states that: The goal of the Availability Management process is to optimise the capability of the IT Infrastructure.2. The current best practice view is to make this statement as business focused as possible and to think in terms of unavailability rather than availability. such as Service Level Agreements. The business can have almost any availability it likes provided it is prepared to pay for it. A customer will negotiate a Service Level Agreement with IT Services. It is important for all staff involved to understand that if a business service is unavailable because of an IT problem there will be a loss of business productivity. Introduction Despite the fact that the IT Infrastructure is becoming ever more reliable – and hence Availability levels are generally better than they have ever been – Availability Management is non-the-less a critical support process for Service Level Management. This may also lead to a loss of revenue. Business of course is interested in the availability of its services. You will be able to recognise the main elements of the Availability lifecycle and understand the terms MTBF.and also by our incident. and within the SLA there will be statements about service availability.” (SD Manual 8. which is described in Chapter 8 of the Service Delivery book. The critical words here are ‘cost effective’. One only has to look at the expenditure on safety critical systems and on general aeronautical systems to understand this. The definition of availability and the way we phrase that will be subject to local discussions. such as e-mail.3) 51 . MTTR and MTBSI.Lesson 4a Availability Management Lesson 4a Availability Management Objectives The topic for this lesson is Availability Management. Once you have completed this lesson you will be able to define Availability Management and describe how it relates to other ITSM components. by both corrective and preventive maintenance procedures . services and supporting organisation to deliver a Cost effective and sustained level of Availability that enables the business to satisfy its business objectives. For example it assists the Service Level Manager in negotiating and monitoring service levels. by the reliability of the items in the infrastructure.

In the case of the internal support. Availability Lifecycle It is useful to think of Availability as having a lifecycle. You can review a definition of each of the terms “availability”. Again. then we’ll expect to find statements in the OLA on availability. So imagine that we have a timeline with time running from left to right. This will be recorded in ITIL as an Incident. service level management processes require underpinning support. customers negotiate the SLA availability clauses with the IT service through service level management processes and then.Lesson 4a Availability Management Related terms. Be very careful here as the R in this acronym can have a number of alternate meanings. in ITIL. Availability is often expressed as a percentage the percentage of the agreed service hours for which the component or service is available and that is often as a measure of how good or bad the availability is. There will then be a period of time that it takes to repair the faulty component – this is usually referred to as the Mean Time To Recover or MTTR. Maintainability and Serviceability. that the failure is a crashed hard disk. maintainability. So. Be aware though. reliability of their managed components and services. is reserved for use where support is provided by external parties and will incorporate statements about availability. “maintainability” and “serviceability” by clicking on each of the buttons here. reliability and maintainability when applied to components supported by external suppliers. that it may be useful to understand these other measures as they are often captured by service management organisations to check on various aspects of the availability management process. as we will be seeing in later lessons. Reliability. There will be a period of time that it takes to “Respond” to the incident. one through operational level agreements with internal suppliers. hardware support and so on. We have defined it as “Recover” – but it is also commonly taken to mean “Respond”. lets say that a failure occurs at time X1. measuring the way the third party suppliers are achieving availability would be of value to the organisation and should be part of the role of availability management. Then there will be a further period during which the disk is being repaired or more likely replaced. The period of time between the fault being recovered and the next failure is known as the Mean Time Between Failure or MTBF. it will then take some time to “Restore” the data to the point where normally business can be resumed. the other through underpinning contracts with external providers. which are also defined is the same section of the Service Delivery manual are. The word Serviceability. to get an engineer on site. When we are talking about underpinning contracts the word ‘serviceability’ is often used as a contractual term and that is seen as covering availability. “Repair” or “Restore”. Now for a particular component. “reliability”. In this course we will be using the term “Recover” to encompass all of this – and the Mean Time To Recover is the average length of time that all of this takes to achieve. To say that we require 99% availability of the service over a given period is a fairly common way of defining what is needed by the business. such as application support. Hence it is easy to see that the sum of the MTTR and MTBF will give what is called the Mean Time Between System Incidents or MTBSI. Typically. for example. Once normal service has been recovered there will then be a hopefully long period of time before the component fails again at time X2. Imagine. reliability and maintainability of the components that this group is responsible for. There are broadly two types of underpinning support. 52 . In Service Level Agreements and in clauses with suppliers through underpinning contracts.

On the other hand. ITIL refers to such business-critical functions as Vital Business Functions or VBFs The concept of Vital Business Functions is widely used in IT Service Continuity Management and Availability Management within ITIL and is a way of highlighting the services to which the business must have almost 100% availability. MTTR and MTBSI We can now consider the relationships that exist between each of these three parameters and the terms Availability. typically we can see that if we want to achieve higher availability. if we want to increase the overall availability either of a service or of an assembly of components. then either increasing the Mean Time Between Failure or reducing the Mean Time To Repair – or a combination of the two can achieve this. as we discussed earlier. for example. for example. So. All of these measures. will be more important to the business than others. Such costs may be incurred through revenue loss. say. So. Therefore it may be necessary to aim for higher availability of the first part of the service than the second part. If components don’t fail very often then the services on which are based on them will be reliable services. Trends are very important in the whole of service management. from details of component availability right through 53 . Service improvement programmes. can be applied at both the component and overall service level. with the number decreasing from 10 to 5. then this can be done either by increasing the reliability of each component or the resilience of the assembly or by improving the maintainability and the procedural aspects.Lesson 4a Availability Management MTBF. which are often expressed in the same way. set out to move things forward. As you might expect – a high Mean Time Between Failure is very desirable and directly equates to a high Availability. not only by technical means but by having good support procedures within the IT service management team so that there are no delays between an incident being detected and repair work starting. Because it covers such a wide range. for example. There will be a limit as to how much we can spend to achieve high reliability and high resilience and there will be a limit to how much we can spend to achieve instantaneous reporting and repair. Typically. a low Mean Time To Recover is good news. “Service was available for more than 98% of the agreed service hours during the last month” may be very useful when we’re reporting against service levels in Service Level Agreements.7. If an e-mail service is dependent on two servers and each has a MTBF of 5000 hours. or parts of services. As we said at the start of this lesson. we might want to say that we’ve moved forward in terms of the number of breaches of Availability Agreements from last year to this.7 of the Service Delivery Manual uses what it calls an IT Availability Metrics Model (ITAMM) as a framework for deciding on the sort of reporting that needs to be done. Other functions such as automatic updating of stock levels is important but not as vital as servicing the immediate customers. since this implies a high Maintainability. Reliability and Maintainability that we have already discussed. or overtime payments and so on. This can be achieved. Cost of Unavailability is a more effective way of reporting than percentage availability because it relates the true cost of the loss of service to the business directly. and that relies on having some baseline against which to measure. the critical requirement is that we are able to take payments. So high MTBSI is obviously a good thing. MTBF. It is important to report on trends and to agree on the measurement period. in an EPOS service. Understanding each Vital Business Function allows the Cost of Unavailability of a service to be measured and reported. The Business View of Availability All businesses rely on their IT services – but some services. the business can have almost whatever availability it wants – provided that it is prepared to pay for it. It is obvious from the diagram that a high Mean Time Between Service Incidents implies high Reliability. For example. MTTR and MTBSI. Section 8. what will be the MTBF of the e-mail service ? Increasing the MTBSI and MTBF figures and reducing the MTTR will all cost money.

They are often much more comfortable with discussing business lost. The final point refers to the need for the Availability Management process to be continually looking for improvements on a proactive basis. than they are in percentages and fractions. Predicting and Designing for expected levels of availability and security. new technological options and knowledge of the way the business is developing. The third point. MTBSIs and so on. The Availability Plan should be a long-term plan for the proactive improvement of IT service availability within the imposed cost constraints. it would reasonable to think in terms of one year at a time with a review at least every three months. analysis and maintenance of availability data. objectives and deliverables and should look at all the issues of people. Responsibilities of Availability Management Page 64 of the Little ITIL Book gives a useful listing of the responsibilities of the Availability Management process. tools and techniques as well as looking at the technology. It is beyond the scope of a Foundation course to understand much more about the ITAMM. business downtime caused by loss of IT services. It is an ITIL recommendation that Availability Management staff should be involved when the business case is being created for a new or extended service and that they remain involved all the way through the analysis and design process. The second point is about determining availability requirements in business terms. for the benefit of the service level manager. In many ways the Availability Plan is analogous to the Capacity Plan and should take account of current levels of availability against the service level requirements. management staff having some familiarity with system development processes. The aim being to ensure that the needs of availability management. just the fact that it exists and is a basis for important reporting is what we need to know. both internal and external. Item six is arguably one of the most important areas and defines the role of the availability manager. it is our responsibility to help the service level manager to turn these figures back into meaningful business terms for the customer. if we are producing technical information about availability. implies that availability management staff are involved in the systems development process right from the very beginning.Lesson 4a Availability Management to services. As with many other of the ITIL processes this proactive work is critical but may be the last part of the process to be implemented. concerning the optimisation of availability is self evident and much of this lesson concerns that particular point. This implies availability 54 . including maintainability and reliability. A good plan should have goals. The fifth item on the list of responsibilities is all about the collection. This is all about monitoring service availability against the Service Level Agreements. Hence we must be able to gather these requirements in the relevant terms and translate them into meaningful technical terms for discussion with suppliers of underpinning services. This may be either as a separate entity or by adding extra information to Configuration Management database. It is very important that we are able to work with the service level manager and the customer so that their requirements for availability can be expressed in terms with which they feel comfortable. There is no absolute guideline on how far ahead the plan should look. Conversely. trends in terms of availability. are built in along with security elements. Monitoring the various availability parameters can generate a large amount of data and because of this it is not unusual to find an Availability Management Database being created. it is a basis for all reporting both internal and external. MTBFs. processes. but following the capacity management analogy. but to be constantly reviewing current status and looking for cost effective ways of improving availability. The first of these. The performance of internal and external suppliers against the serviceability requirements in any underpinning contracts and targets defined in the Operational Level Agreements and must also be monitored as part of this process. In other words. not waiting for targets to be threatened before taking action.

The Availability Management Process Section 8. • • This may lead to some conflict and possible trade-offs. This will enable us to look for sensible places where we might decide to replace equipment by higher quality equipment with a higher reliability. This is why security is such an important part of IT service management. or SPOF in ITIL terms. These are intended to help the development teams decide on how to achieve high availability. Configuration data will be very important since that will show the relationships between configuration items and the chain of configuration items that makes up a typical service. an Availability Plan for the proactive improvement of the IT Infrastructure. reliability and maintainability for the IT Infrastructure components that underpin the IT Services. Details of the Availability techniques that will be deployed to provide additional Infrastructure resilience to prevent or minimise the impact of component failure to the IT Service Agreed targets of Availability. maintain Integrity. Part of the proactive work will be to investigate incidents and problems and to see which of those are caused by unavailable equipment and what the impact of these incidents or problems was on availability measures. Incident and Problem data will also need to be examined. for other areas where we might decide to mitigate against a possible single point of failure. Now let’s look at the key outputs from the process. Or. Some of these will be for existing services while others will be for services that are in conception.3 of the Service Delivery manual describes the Availability Management process in some detail. User and IT support organisation perspectives The monitoring requirements for IT components to ensure that deviations in Availability. Make sure that the assets are trustworthy. then we’ll be constantly looking at records of service level achievement or service level breaches or potential breaches. so that the Vital Business Functions and the consequences of loss of availability are fully understood. This can often be done by looking at how many SLAs have been breached because of availability issues and looking at how many components have got measurement in place. maintain Availability. by looking for alternative routing in a network or perhaps duplicating of discs or processors. This will help in determining priorities when setting up the Availability Management processes for the first time. make sure that assets are available to authorised people when they need them. That is. reliability and maintainability to reflect the business. The basic logic behind managing these assets is: • Make sure that access is denied to unauthorised people. reliability and maintainability requirements from the business. Reporting of Availability. Remembering that one of the jobs of availability management is to ensure we achieve service • • • • • Security It can be argued that the most valuable assets of IT services are the data and the ability to process that data. reliability and maintainability are detected and reported And finally. Part of the service level negotiation process will be to determine the availability. and that is to monitor the effectiveness and efficiency of the availability management processes. The inputs to the process include: The Availability Requirements of the business. high availability is not 55 . maintain Confidentiality. And. Or. which are critical. A business impact assessment.Lesson 4a Availability Management There is an additional responsibility on the process owner. which are: • Availability and Recovery Design criteria for each new or enhanced IT Service. For example. levels in the area of availability. In other words.

divided by the agreed service time – all times 100 to obtain a percentage value. the availability of a service or of an individual component or of a grouping of components is given by the agreed service time minus the downtime. if a system is meant to be available for 40 hrs in a week and there are 10 users of the system. Great care must be taken over the definition of what agreed service time is. End User Down Time is found by multiplying the Down Time by the total number of users affected.Lesson 4a Availability Management necessarily good if confidentiality or integrity. For example. This is all about agreement and trust between customer and supplier and whichever figures are chosen should be those most meaningful to the business. an availability of 99% for a service to be achieved on each and every day is much more demanding than the same percentage averaged over a year long reporting period. It is very important to understand and be consistent in the use of reporting periods. depending on business circumstances. is very often expressed as a decimal value – always less than one . which will need to be reduced to an absolute minimum. availability aspects are the responsibility of availability management while the confidentiality and integrity issues are shared responsibilities with security management. a weighted calculation can sometimes be more meaningful. it may well be that the whole responsibility for CIA is devolved to the availability management team. which would be only 90%. then End User Down Time would be equal to four hours downtime x 1. In order to take account of the fact that one user losing access to the system is significantly less serious than 100 users all losing access. Within an organisation. Techniques for Availability Management One of the most basic techniques used in Availability Management is the calculation of availability in terms of a percentage. The way this is calculated is to replace the variables AST and DT with End User Processing Time and End-User Down Time. In order to achieve 99% on a daily basis. So for example we could say that there were four hours of downtime out of 400 potential service hours in the last week. It is very important that such responsibilities are clarified. giving a value of 4. End User Processing Time is defined as the Agreed Service Time multiplied by the total number of users (Nt). Therefore the overall availability would be 400. The pattern of downtime may also be critical and will need to be understood. If just one of the users is affected for four hours but the other 9 users are not affected at all over that period of measurement. In 24/7 systems however. The basic calculation is straightforward. Note that component availability. So. For example. minus 4 divided by 400 all times 100 – giving a weighted availability of 99 percent. Absolute figures of up-time and down-time over an agreed period might be more appropriate and may be more acceptable for the business. it compromises Contrast this with the value given by the more simple basic calculation. the figures often do include and are meant to include any time for maintenance. Its important to note that whichever way of calculating availability is chosen has to be agreed with the users before it can be used as the mechanism that we measure and report on. EUPT will be 400. the allowable downtime on any one day would have to be reduced down to just a few minutes. 56 . Percentage availability may not always be the most useful measure from a business point of view.rather than as a percentage. where the requirement is for very high availability. does it include downtime for maintenance? Is that already factored in? In most cases we would not want to be penalised for agreed downtime for maintenance or upgrades. 10 losses Within ITIL. For example. and that may be a more useful measure than turning that into a percentage value. It is possible to achieve a 99% availability whilst losing service for perhaps two whole days in the year.

– will necessarily increase costs. The reporting requirement to cover such differences will need to be closely examined and agreed with the business. each of which is capable of delivering 90% availability – the End-to-End availability of the assembly will be 0. As a first pass analysis of dependency and understanding of where single points of failure could be critical. how those VBFs are dependent on the components. (NOT from their sales literature). Once an initial base of figures has been established then monitoring of availability over a period of time using monitoring tools and records from the service desk of incidents can allow an iterative improvement in the component availability figures. the lower will be the End-to-End availability figure. we can see that item 3 is essential to all 4 services. Looking another way. 57 . Again it is easy to see that. The formulae for calculating End-to-End availability for items arranged in series is fairly simple.Lesson 4a Availability Management of service each of 10 minutes duration may be more damaging than a single loss of service of 100 minutes for the same period of time. but the general principle is one of significant improvement to assembly availability achieved in this way. CFIA is very useful. here we can see that service ‘B’ is dependent on all four of the CIs 1 to 4 being available. this could be derived from a combination of manufacturers’ engineering specifications. The first of these techniques that we will look at is Component Failure Impact Analysis (CFIA). in a matrix against the Calculating the Availability of Multiple CI’s A very common requirement is to be able to understand and calculate how the availability of an assembly of configuration items is governed by the individual component availability. For example.9 times 0. whilst service ‘D’ only requires items 3 and 4. The overall availability AT is equal to the product of the availability of each of the individual components.9 – or 81%. unlike components arranged in series. at a more detailed level. Finally. there are a range of techniques designed to aid understanding of why availability problems are occurring in particular parts of the infrastructure and to find corrective ways of working. the main areas of interest will nearly always be based around services and not around components. So for the same two components now arranged in parallel – the resulting End-to-End availability will be 99%. then it becomes critical to understand. However. none of them can function without it. So if we have two components. There may also be some technical limitations in terms of how easy it is to switch from one component to another when one fails. In other words. Assuming they are hardware components. Calculating End-to-End availability for items arranged in parallel is a little more complicated – as shown. significantly less than each of the components making up the assembly. Using a combination of those three sources will tend to give realistic values for the availability of individual components. or duplexing. An assembly is a grouping of more than one configuration item. the more CIs that are put in parallel then the higher will be the overall availability – but such duplication of components. other similar installations and your own experience gained during testing or development. One difficulty in both cases is finding good values for A1 and A2. internal reporting for service improvement purposes and for supplier management mechanisms will often require reporting at the component level. It is important to realise that the CFIA matrix can be used by either reading down the columns or across the rows to give us different information. This is represented normally showing configuration items services supported. It is easy to see from this formula that the more items that are put in series. In reporting and discussing availability with end users and customers. If ‘B’ is a service which has vital business functions within it.

Risk analysis can be done in a variety of ways. the Availability Management process will support and work closely with proactive problem management. for example. It is really a post-mortem about some of the more major incidents that have occurred in the infrastructure and trying to find some common underlying theme or cause for the availability losses. We’ll talk a bit more about CRAMM in the IT Service Continuity Management lesson.O. which identifies the chain of events leading to service failure. You will be able to recognise the main elements of the Availability lifecycle and understand the terms MTBF. 58 . The way that’s favoured in ITIL because it originally comes from the same development source. They are also convenience.P. either component 3 or component 4 need to be there but not necessarily both. If.which is often home grown or company-specific and which is beyond the scope of this course. It is part of a family of techniques generally referred to as Failure Mode & Effect Analysis or FMEA and this is covered in more detail in the lesson on Problem Management. It is worth noting that in addition to the techniques that we have discussed in this section. The CCTA – or Central Computer and Telecommunications Agency was the original name for the OGC or Office of Government Commerce. Setting up a Technical Observation Post or T.O.O. Another useful technique is called ‘Fault Tree Analysis’ or FTA.P. It requires significant inter-disciplinary work between different teams to make this work and tends to be managed as a small project with a particular budget and reporting period. There are a couple of techniques that can help us here and they are called. SOA involves a detailed analysis of service interruptions. CI3 is a very good candidate for attention. MTTR and MTBSI. Benefits and Problems of Availability Management The benefits of and potential difficulties with Availability Management are list on Page 68 of the little ITIL book and in Section 8. It requires an inter-disciplinary team and an acceptance from the business that the only way of finding and resolving the issue is by allowing some availability losses to occur. such as replacement with a more reliable item or duplication by the addition of a parallel assembly as a replacement for the single component CI3. we know that on a monthly basis are availability problems while assembling data for end-of-month financial work. This is particularly useful in cases where it proves difficult in test conditions to simulate the fault that is causing the loss of availability. System Outage Analysis. then a Technical Observation Post might be set up to look at this particular process. This may require some extension to the notation . summarised here for your Summary In this lesson we have been examining the Availability Management process Once you have completed this lesson you will be able to define Availability Management and describe how it relates to other ITSM components. You will appreciate the main responsibilities of the Availability Management process and be able to recognise several techniques which are of use in this area. would be watching the process go wrong in order to more accurately understand what’s happening. More sophisticated information can be put in the CFIA such as information that for service ‘B’ to run.5 of the Service Delivery Manual. One of the key requirements of availability management is to be able to achieve an understanding of why a particular lack of availability is occurring and what to do about it. and Technical Observation Posts or T. In effect the T. This is a diagrammatic technique drawn initially from the world of engineering.P. The name was changed in 2001. is an expensive process because it involves bringing together a team of people to look at a service at a vulnerable period of its life. is known as CRAMM.Lesson 4a Availability Management So in the example shown. So many of the same techniques used in Problem Management may also help with identifying the underlying reasons for lost availability. CTTA Risk Analysis and Measurement Method.3. SOA.

Interestingly. which offer an insight into the demands placed on this process. In a large organisation there may be many people working in a Capacity management team under the leadership of a specialist. However. the one of supply and demand. which states that data expands to fit the space available for storage. The day-to- In theory. enough but not to much At the right cost And critically. except where a shortage of people leads to other capacity problems. Ultimately. then they should be invisible to the business. the organisations operation (the current service delivery). • Define Capacity Management. balanced against the costs that the organisation can afford to pay. a decision has to be made over whether the cost of capacity provision provides enough business benefit. There a two ‘laws’ associated with Capacity Management. providing the right level of capacity at the right time. In smaller organisations it might be the role of a single individual who is supported by technical specialists from Networking. There is continual pressure from the business and customers to increase capacity. Capacity Management will have a significant input on purchasing decisions. Capacity Management ensures that IT processing and storage capacity provision match the evolving demands of the business in a cost effective and timely manner. but in doing so there a costs incurred to the business. This highlights a second ‘capacity’ problem. at the right time • • • What is Capacity Management? In order that Service Level Agreements are met. For 59 . Those shown in the question represent just a few of the IT components. and ensure that all current and future capacity and performance aspects of the business requirements are provided cost effectively. The organisation must provide enough capacity to meet justified business demands. ad hoc and regular activities Describe the contents of the Capacity Database and the Capacity Plan day activities include dealing with technical specialists and service level managers. Capacity Management must justify the cost of any capacity increases. Capacity Management . However. and its three sub-processes of Business. and monitoring and tuning activities. people are not usually thought of in capacity terms. Broadly speaking the objective is to provide the: • • • Right Capacity. it is critical that sufficient capacity is available at all times to meet the agreed business requirements. and to most aspects of Service Level Management. Capacity Planning. desktop and so on. In any organisation. As greater capacity becomes available users will make use of it. which could impact on business.’ The Capacity Management process incorporates Performance Management. ITIL defines Capacity Management’s goal as: ‘To understand the future business requirements (the required service delivery). The first is ‘Moore’s Law’. there can be a huge number of capacity elements to be managed. if Capacity Management processes are running well. It’s not usual for the Capacity Manager to communicate with customers. which is covered in Chapter 6 of the Service Delivery book in the IT infrastructure library.a balancing act The Capacity Management Process can be regarded as something of a balancing act. which suggests that ‘processing capacity doubles every 12 to 18 months. Service and Resource Capacity Management Identify Capacity Management’s ongoing. or to be responsible for procurement of new equipment.Lesson 4b Capacity Management Lesson 4B Capacity Management Objectives In this lesson we will be examining Capacity Management. which Capacity Management must address. The second is a variation on ‘Parkinsons Law’. Of all the ITIL processes this can be regarded as one of the most proactive. Once you have completed this lesson you will be able to. the IT infrastructure (the means of service delivery). The Capacity Manager role requires excellent technical and business capabilities.

Service Capacity Management (SCM) is concerned with the services currently in place to support the business. where the monitoring data is analysed to try and identify problems. or below the targets in an SLA. Service Capacity Management (SCM) and Resource Capacity Management (RCM). Resource Capacity Management concentrates on the underpinning technology resources that ‘enable’ business services. and reporting these findings back to the business. and then onto tuning. so that they can be integrated into future plans. and should be able to gather medium term plans and predictions about growth or shrinkage. and are carried out in Resource Capacity Management and Service Capacity Management. It tries to ensure SLAs aren’t breached because of capacity problems. through analysis of data gathered through these activities. Or internal monitoring tools might indicate that we are operating close to capacity. In any organisation the capacity of certain components is being reduced whilst the capacity of others is being increased. Failures might already be occurring. or Configuration items. to show. Capacity Management Structure Capacity Management consists of three interrelated sub processes. that transaction responses are slowing down. monitoring will also produce trend reports on a daily. Thresholds and baselines are set from the analysis of previously recorded data. The monitoring activity should include the monitoring of thresholds. The capacity requirements on the mainframe will be falling while the capacity requirements on the servers will be increasing rapidly. then tuning will be unnecessary. which is intended to forecast the future requirements for resource to support IT Services that underpin the business activities. each working at different levels in the organisational structure. Once a tuning decision has been made it is implemented through the change management process. If these thresholds are exceeded. For example. Capacity Management is also involved in the reduction of capacity or as it is sometimes known. 60 . Conversely. weekly or monthly basis. BCM requires an insight into the business as a whole. upgrading the infrastructure to increase capacity. For example. and the technical parameters of the system are fine tuned to improve efficiency. As we mentioned earlier in this lesson. They are not normally used in Business Capacity Management. Business Capacity Management (BCM) focuses on the future services required by the business and tries to predict future capacity. These activities include: monitoring. The three sub-processes are. An example of this might be where a mainframe-based environment is gradually being replaced by a distributed service. are not over used. except during business reporting. alarms should be raised and exception reports produced. tuning and implementation. Buying in extra capacity at short notice leaves little negotiating power with external suppliers. and what type of problems they are. for example. The Capacity Management process has a number of ongoing. If capacity upgrades are too late then the infrastructure could fail. To work effectively. This sub process is also responsible for monitoring future development and capacity of technical components. through incidents and complaints reported to the service desk. If no problems are identified in analysis. and tries to improve scarce resource utilisation through the use of Demand Management. is likely to be very expensive. Finally the activity returns to monitoring. where the problems are addressed. Tuning is an expensive activity. a threshold might specify that the usage on any individual CPU does not exceed 80% for a sustained period of one hour. This process is responsible for the production of a Capacity Plan. as it involves high level of skill. providing capacity to the business at the right time is critical. In addition to exception reports. Analysis then leads onto reporting. Monitoring leads on to the analysis activity. analysis. they are the ‘yardstick’ by which Capacity Management can measure utilisation of IT infrastructure configuration items. iterative activities. and baselines or profiles of the normal operating levels. and the iteration begins again. and as such. It also ensures that these resources. ‘managing shrinkage’.Lesson 4b Capacity Management example. if we don’t have enough service desk staff to fulfill commitments made in Service Level Agreements. All thresholds should be set below the level at which a resource is overutilised. Note that tuning is an optional activity. Finally. Trend reports are intended to help predict future threshold breaches. Business Capacity Management (BCM). to then find it’s under used could in itself lead to financial problems.

However. or by sharing capacity. and Regular. This activity can be carried out as a short-term requirement because there is insufficient current Capacity to support the work being run. Demand Management must be carried out sensitively. Capacity Management’s Another on-going Capacity Management activity is Demand Management. Analysis. It is essential that customers are kept informed of all the actions being taken. the day-to-day activities. particularly if they are sourced from outside the business. used in Business reporting activity. using skilled resources will incur costs. all of the other on-going and ad hoc Capacity Management activities provide information to the CDB. Ad hoc. Service Capacity Management is responsible for ensuring the performance of all services detailed in SLRs and SLA targets are monitored. Financial constraints might involve the use of differential charging. Long-term Demand Management might be used when an expensive upgrade to the IT infrastructure can’t be cost justified. or. business. As you can see in the diagram. as a deliberate policy of IT management. an example of this might involve charging customers a premium to use network bandwidth during peak hours of demand. Only when we are confident that the change will be a benefit to the business. Amongst the ongoing iterative activities. Remember this group of activities are mainly carried out at the Service and Resource subprocess level. service. Short-term demand management might be needed if there is a partial failure of a critical resource in the IT Infrastructure. financial and utilisation data. Importantly. which we looked at earlier in the lesson. a network router for example.Lesson 4b Capacity Management Tuning can improve service delivery without incurring costs associated with equipment purchase. The CDB provides valuable information on who has used which resource and when. measured. are those of Monitoring. in a multi-server environment. recorded. and these are: Ongoing. particularly IT Services Financial Management. Also note that these activities are 61 . Tuning at service level can ensure that services don’t clash at times of peak demand. its planning and timely implementation. by using mechanisms such as physical and financial constraints. This data can be extremely useful for other ITIL processes. Data in the CDB is stored and used by all the sub-processes of Capacity Management. without causing damage to the business. The CDB is the cornerstone of a successful Capacity Management process. which are carried out at fixed intervals. Tune and Implement. or the reputation of the IT organisation. carried out as a result of a particular need. tuning should be carried out initially in a test environment. analysed and reported. Activities in Capacity Management – What does the Capacity Manager do? In the next few pages we will look at all of the capacity management activities in more detail. should it be implemented through the conventional change management processes. technical. to limit the required IT capacity in the long-term. customers. The Capacity Management activities can be sub divided in to three groups based on their frequency. because it is the repository that holds a number of different types of data including. Any excess demand can be controlled by Demand Management. across several servers. Service provision might have to be modified until a replacement or fix is found. The aim in this case. and how they relate to each of the Capacity Management sub-processes of Business Capacity Management. Remember Business Capacity Management is concerned with future business requirements for IT services. Resource Capacity Management monitors and measures the individual components in the IT infrastructure. Another ‘on-going’ Capacity Management activity is providing data to the Capacity Management Database or CDB. The main objective of Demand Management is to influence the demand for computing resource and the use of that resource. an activity that we will look at later in this lesson. is to influence patterns of use. Physical constraints might involve restricting the number of concurrent users to a specific resource. Service Capacity Management and Resource Capacity Management.

building software and simulating significant workloads. We can ask the ‘what if?’ questions about planned changes to the IT infrastructure. It is initiated at the beginning of a new application. is also covered by in the ‘Best Practice’ guidance. however. and the impact of that usage on the IT infrastructure. Lets look briefly at each of these modelling types. In order to do this we establish a ‘baseline’ model. and to ensure that it meets its required service levels. This provides Capacity Management with important data on future resource requirements. Because Benchmarking involves the purchase of equipment. or when there is likely to be a major change to an existing one. Although Analytical modelling requires less time and effort that other modelling types. and therefore costly. Typically a model is built using a software package. this is the most expensive modelling option. How we make programming. database design and architecture design more resource efficient. This type of modelling can be very accurate in predicting the effect of changes. Once a baseline is created. The primary objective of Application sizing is to estimate the resource requirements to support a modified or new application. in other words what actually happens millisecond by millisecond. It attempts to predict the future from our knowledge of the past. the model can be regarded as accurate. However. as a transaction passes from local pc through the local area network. 62 . ant tries to understand the way in which current service and resources are used. it does give the most accurate predictive figures.Lesson 4b Capacity Management However the CDB is unlikely to be a single database. Simulation Modelling can be cost justified in organisations with very large systems. Modelling tries to predict the behaviour of components and services under a given volume of work. whilst benchmarking being the most complex and expensive. and if virtual response times are sufficiently close to those recorded in the ‘real life’ IT infrastructure. which is used in all Capacity sub-processes. Another ad hoc Capacity Management activity is Application Sizing. as it can involve numbers of staff in producing physical event simulations. where the cost and associated business implications are critical. ‘queuing theory’ is used to calculate response times. If the baseline model is accurate then the results of the predicted changes should be accurate. and this can be integrated in to the Capacity Plan. predictive modelling can be done. Information Ad hoc activities Modelling is an example of an ad hoc activity. to server and so on. We will look at the make up of the CDB later in this lesson. extrapolating the graph data forward into the future. as well as providing valuable information for purchasing and the development team. This activity is performed together with colleagues in system and service development. but it is time consuming. Application sizing is complete when the completed application is accepted into the operational environment. Application sizing has a finite lifespan. particularly at peak times. typically the end results are less accurate. The major modelling types used by Capacity Management are: • • • • Trend Analysis Analytical Modelling Discrete Simulation Benchmarking These modelling techniques vary in complexity and consequently cost. The baseline model reflects accurately the performance that is being achieved. as a way of predicting future trends. Finally. a ‘regular’ Capacity Management activity is the production of a Capacity Plan. The Trend Analysis technique looks at various data over a period of time and attempts to draw a smooth curve through these figures. and extrapolating these results. to ensure that we are fully aware if the likely impact of services being development. and probably exists in several physical locations. with Trend Analysis at the top being the simplest and cheapest. to see how it would perform under the ‘real’ workload. which is typically created annually. designed or purchased. which can recreate a virtual version of a computer system. Simulation modelling involves the modelling of discreet events. Analytical Modelling uses mathematics to represent computer system behaviour. Finally Benchmarking involves physically building a replica of part of the IT infrastructure and measuring such things as its response to a reduced workload. before they are implemented. When the software is executed.

Current information from monitoring tools related to systems. than a ‘virtual’ CDB can easily be created. to Contents of the Capacity Management Database and the Capacity Plan Although the Capacity Management Database is represented in the ITIL guidance as a single entity. problems or issues with current services and current levels of utilization • A Resource Summary – which will show what has happened to particular components over the last year and since the last Capacity Plan • • • • 63 . Service and Resource Capacity Management. Input from the business. It is considered important to keep utilisation below certain industry standard levels for a component type. Ad hoc and exception reports. SCM and RCM will be suggesting ‘proactive changes’ and ‘Service Improvements’. including any issues raised. we will spend the next few minutes looking at the major inputs and outputs to the process. Service Management will provide information about SLAs and a full definition of the quality processes in place. improve levels of capacity. Assumptions . if one exists. and how these relate to the subprocesses of Business. Baselines and thresholds information. Other important inputs to BCM include the Business Plans. the service levels and SLAs. partial CMD functionality. If this information is accessible by other software. and any strategic plans together with IS and ICT plans. along with proposed future services and related SLRs. Outputs from the sub-processes include a Capacity Database. therefore. The Capacity Plan The Capacity Plan is a major output of the Capacity Management process. Monitoring information related to component utilisation. The important inputs to the Service Capacity Management sub processes are. networks and services. the IT Financial Management team will provide fiscal data. which we looked at earlier in this lesson. Trend. there is an argument for making the CMD part of a ‘Super’ integrated CMDB. it is unlikely to exist in this form in many organisations. including.Lesson 4b Capacity Management gained from the activities of monitoring. The main reason for this is that much of the data held in a CDB is common to that in a fully integrated Configuration Management Database. and any SLA breaches. Inputs and Outputs of the Capacity Management Process To fully appreciate the scope of Capacity Management. Incidents and Problems related to capacity. And finally. We will be looking at the Capacity Plan in more detail later in this lesson. Financial Plans and Budgets are a major input to all 3 sub-processes. Data about manufactures specifications for existing and new technology. or reduce costs – preferably both! Carrying out ‘Effectiveness Reviews’ and creating ‘Audit Reports’ form a basis for checking that business benefits are being achieved. will be provided by the technical teams. It has a standard structure and includes. The service review results. Finally BCM requires the Capacity Plan as an input. as Capacity Management activity will turn initial SLRs into achievable and cost effective service level quality clauses. A Management Summary Business Scenarios A Summary of Existing Services. demand management. modelling and application sizing will contribute to the production of a Capacity Plan. Additional financial information will be provided from the CMDB. RCM’s key inputs include incidents or problems related to a particular component. includes the ‘business strategy’ and the business plan. Inputs to the BCM sub-process include. the external suppliers of new technology. and the process users are following the ‘rules’. Remember the data contributors to the CDB are the key to its success. Other outputs include recommendations for SLAs and SLRs. in its role as a ‘super’ asset register. Software tools used by Capacity Management tools may have designed in to them. existing service levels and current SLAs.about levels of growth. Charging and costing recommendations are also produced. Capacity reports will be produced by all three sub-processes.

associated with the Capacity Management process on page 51 of the ITSMF’s little ITIL book. and we have looked in detail at the three Capacity Management sub-processes of Business. and it should be produced in a timescale which allows the recommendations to be considered as part of the budget planning lifecycle. We have defined the goal of Capacity Management in ITIL terms. One final note. This provides a longer-term proactive view. However making the process work successfully depends on several critical factors. Summary In this lesson we have been looking at the ITIL process of Capacity Management. for example Problem and Change Management Effective financial management Links to Service Level Management . Managing the capacity of large distributed networks is becoming increasingly complex. Critical Success factors in Capacity Management. • A Cost Model will illustrate some costed recommendations • Recommendations for the business – Capacity Management usually provides a number of alternatives for the business. 64 . Modelling and Application Sizing. • • Accurate business forecasts An understanding of current and future technologies A cost effective Capacity Management process Working closely with other effective Service Management ensure that any business commitments are realistic And finally. Tuning and Implementation. We highlighted the major inputs and outputs of the Capacity Management process.Lesson 4b Capacity Management • The Capacity Plan will also contain suggestions for cost effective service improvements.4 of the Service Delivery Manual. and the financial commitment from business to IT continues to increase. ensures that the entire organisations capacity requirements are catered for. because new business is won or lost. These include. of Monitoring. in line with any revised business plan. Remember that the Capacity Plan should be updated regulary. Service and Resource Capacity Management. • • • • • There is a further list of potential benefits and problems. We went on to examine the iterative Capacity Management activities. Benefits & Problems The benefits of and potential difficulties with Capacity Management are listed on Page 57 of the little ITIL book and in Section 6. the ability to plan and implement the appropriate IT capacity to match business needs. We concluded the lesson by defining the critical factors for successful Capacity Management implementation. Analysis. A corporate Capacity Management process. or unexpected changes in the IT infrastructure. and defined the contents of the Capacity Database and the Capacity Plan. and the ad hoc and regular activities of Demand Management.

It is also there to ensure service achievements are monitored and reviewed on a regular basis. which are managed through the Service Level Management Process. Service Level Management is a driver for CSIP or SIP – or Continuous Service Improvement Programmes. Alternative Approaches to Service Provision There are a number of ways that IT services can be provided – each having their merits and draw-backs. provide specific targets against which the performance of the IT provider can be judged. Such arrangements are common where an ‘off-the-shelf’ package solution is being provided by the supplier. Often. Or alternatively. When you have completed this lesson you will be able to: • Define Service Level Management according to ITIL best practice. Hence they feel an increased need to formalise the contractual basis on which IT services are provided. Why do we need SLM? Customers have become more aware of their dependency on IT for successful business operation. and this is where Service Level Management can help. it is a risky strategy and one that generally leads to poor support for the users and poor value for money for the corporate customer. An example of this might be to take advantage of dramatically reduced networking costs to provide better response times than the customer originally specified. Services provided on the basis of a contract these two parties. without necessarily being driven by customer demand. In this situation. response times and so on. and recognise the main sections of a Service Level Agreement.Lesson 5a Service Level Management Lesson 5A Service Level Management Objectives In this lesson we will be examining Service Level Management. OLA’s and UPC’s. are agreed and documented in a way that the business understands. in a rapidly changing technical environment. Such programmes are aimed at achieving costeffective improvements to the services offered by the IT service provider. • List the benefits gained from the Service Level Management process. monitoring. reporting and reviewing IT service achievements and through instigating actions to eradicate unacceptable levels of service. The next approach is often said to involve an “intelligent customer” role. Service Level Agreements. the internal IT department adds little or no value. That is. 65 . • Identify the core Service Level Management sub-processes and activities • Understand the relationships between SLA’s. just the and the will be between Whilst this has the benefit of simplicity. through a constant cycle of agreeing. In the simplest scenario there is external provider of the IT service customer organisation.” Service Level Management exists to ensure that service targets. It’s the responsibility of Service Level Management to be aware of service improvement opportunities. before the customers themselves begin to ask about them. such as availability or services. and the service is underpinned by an ‘Underpinning Contract’ with the suppliers. That customer has a Service Level Agreement with the Service Level Management process. somebody who negotiates on behalf of the customer with suppliers for service delivery. which is covered in Chapter 4 of the Service Delivery book in the IT infrastructure library. is considered by many to be the heart of ITIL-driven service management. by providing the same response times but at a much lower cost. ITIL defines its goal as: “To maintain and gradually improve business aligned IT service quality. What is Service Level Management? Service Level Management. The Service Level Management Process is Service Level responsible for ensuring Agreements and underlying Operational Level Agreements or underpinning contracts are met.

There are a number of ways in which this problem can be overcome – perhaps the most common one being the mapping of services onto customer groups. Multi-Level SLAs A third approach to structuring SLAs. and no external contracts are therefore required. escalation 66 . Also. Corporate is the highest level and contains any common features that are true of all services across all customer groups. Here for example Customer Group 3 receives three services. since they may have to cater for the fact that not all groups covered by a service have exactly to same requirements. it is necessary for the Service Level Management team to establish ‘Operational Level Agreements’ with their own internal IT departments. Despite this problem. quite common for a total service to be provided on the basis of a combination of two or more of these strategies. who in turn may have an ‘Underpinning Contract’ with the external suppliers of the various components. For example. An SLA is created for each customer group. describing all of the services that each customer group will receive. although it is much less common. detailing how they would receive Services A. This might cover things like service desk hours. however they would have just one SLA. it becomes relatively straightforward to introduce variances on standard services between the different customer groups. This allows us to have just one SLA per service . One is that the number of SLAs can be dramatically reduced – in our previous example with 10 customer groups and 50 services. is to have a Multi-level or hierarchical structure. admittedly quite a complex one. So the Customer has a Service Level Agreement with Service Level Management and they have an OLA with the internal IT department – and that’s it. ITIL suggests three levels. this is the most common approach that you’re likely to encounter. the whole process can be purely internal. There are a couple of advantages to this 50 in our previous example. If there are geographical differences between the groups as well. Customer and Service. Fortunately most businesses don’t have 1000 customers who are entirely independent of each other and so there is usually commonality of service requirements amongst groups of customers.Lesson 5a Service Level Management Probably the most common arrangement is where the customer has a ‘Service Level Agreement’ with the Service Level Management team. As an example. we would end up with only 10 SLAs. say Service A. So by producing SLAs at the Customer Group level the number required could be reduced to 500 – more manageable but still excessive. It is. And in a similar way. lets suggest 10 major groups of customers. Customer Based Approach An alternative approach is to turn the previous model on its head and map Customer Groups onto Services. will be provided in a generalised format to Customer Groups 2 and 4. Note that for any one service there may be several Operational Level Agreements and several Underpinning Contracts. The drawback of this approach is that it tends to make each SLA more complicated. Finally. namely: Corporate. The disadvantage is that the SLAs can be long and complex and contain a great deal of duplication from one to the other. B & C. In order for that service to be provided.000 Service Level Agreements. This last arrangement is fairly unusual because most systems will depend on some external supply. each of which has a common set of service requirements. if we had 1000 customers and 50 services we could theoretically produce 50. Service Based Approach So a particular service. The SLA Structure One of the early decisions that has to be made is the structure of the SLA procedure – which is a major determinant of how many SLAs will end up being produced. Service D will be provided to Customer Groups 1 and 2. on the other hand. This would clearly be impractical. then this will also add to the complexity.

So in our previous example there would be 10 SLAs at this level. For example. Planning. An SLA which is used internally between departments has no legal weight. the software development team might have an underpinning contract in place with their development software vendor. committing to a 4 hour fix time in an OLA would be useless if our underpinning contract only commits our supplier to a 6 hour fix time! The next level down is the Customer level. but each would be relatively short. It’s important that all targets contained within both SLA’s. at Corporate level the document would be authorised at the highest management level liasing with IT. Finance. Well in simple terms OLAs are agreements that define the internal IT arrangements that support SLAs. and so on. The most common use of an OLA is to define the relationship between Service Desk and internal support groups. responsibilities. For Example. and OLAs that relay on these external suppliers are ‘underpinned’ by the appropriate level of maintenance and support contracts. Each of the SLAs produced at this level is a description of the services for a particular group of customers. It’s important when using the hierarchical structure. to 9am until 9pm. It only contains information which differs from the corporate of customer level clauses. HR and so on. but different from the generic services that appeared in the higher Corporate level. OLAs are required to ensure that the SLA targets agreed between customer and IT provider can be delivered in practice. In order to guarantee these service levels. we decided to change the standard hours of the service desk from 9am until 7pm. Consequently we would have a larger number of SLAs. which make its intention unclear. it’s critical that any commitments made in an OLA are directly supported by the underpinning contract. ensuring that problems can be resolved well within this 2 hour time frame. amongst other things. This OLA offers. Here we have a document representing each service used by that customer. contact points. Importantly. For example. So we have established what constitutes an SLA. 67 . At this level SLAs would contain everything that was common for that particular group of customers. They describe each of the separate components of the overall service delivered to the customer. OLAs are also known as back-to-back agreements. A word of warning here. Individual Service Level Agreements would be authorised at the next management level down in each of these departments.Lesson 5a Service Level Management procedures. So what exactly is an OLA or Operational Level Agreement. particularly when establishing SLAs directly with external suppliers. and as such shouldn’t be an imposition on either the business or IT. Customer level documents might be authorised by Department Heads. then that change would only appear in the corporate level SLA. Finally. So what exactly is an SLA? Well in structure SLA’s are rather like contracts. Service Level sits at the bottom of the structure. and relevant to that particular customer group. If for example. often with one OLA for each support group and a contract for each supplier. and leaves the Business feeling uncomfortable authorising the agreement. it’s simply a document that has a contractual structure to it. roles and The purpose of an SLA is to document an agreement. it must always be written in unambiguous business language. In such cases an SLA would be included in the contract as a schedule.’ Underpinning contracts are put in place with external suppliers or vendors. that the correct level of authority is assigned to each level. a guaranteed response time to serious problems. However they can be included in a legal contract. an internal software development team might have in place an OLA between themselves and Service Level Management. and this is an ‘underpinning contract. The general principal is that SLA’s are authorised by paying customers on behalf of users in their part of the organisation. but they are not in themselves legal documents. This in itself makes change management easier. A further additional contract exists to ensure that SLAs are supported. and shouldn’t contain any technical references. of no more than 2 hours.

and generating ‘buy in’ to the services. and prioritised the work. and which customers or users are using them. and which ones our customer or users would like? Well. This activity involves prioritising the modification of pre existing SLAs. and related costs. this activity documents all currently available services. listing existing services when Service Level Management is initially established. it’s more important to understand the scope of the catalogue. But how do we establish which services are available for inclusion in these agreements and contracts. Ask yourself – are there any new services being developed or purchased from a software provider that might provide a better starting point? Assuming. and also any major problems with services. agreed the SLA structure. It isn’t possible to document every possible SLA clause in the catalogue. It’s not uncommon for organisations to arrange training programmes for senior customers. It’s important to remember that these documents. we can move onto the second stage of ‘Initial per-service’. Organisations now make this available on their intranet as a form of advertising. the customer develops a Service Level Requirement document. assuming that a Service Level Management team is in place. The first point is to establish Service Level Requirements or SLRs. They are often created as an internal document. and these are ‘A Service Catalogue’. and each organisation will document it in their own way. The second related sub-process is planning the SLA structure and establishing which SLAs we need to create. As we mentioned on the previous page. When doing so. Commonly. and its related sub processes where we address customer specific issues. and what customers are prepared to pay. and ‘Service Level Requirements or SLR’s. and whether it’s a service which needs to continue.’ A Service Catalogue contains a list of all services used by each customer group. In order to establish their exact requirements. Once we are happy with both our OLAs and UPCs we can create a draft SLA. providing a shop window. the Service Desk might use it to help them identify those customers entitled to a higher level of service. Remember this is not a wish list. in a more ‘glossy’ format. It can also be used externally as a marketing tool. In the next few pages we will look in some detail at the Service Level Management subprocesses. and see how they fit together to form a complete Service Level Management process. and the wider business as a whole. there are two other important documents in Service Level Management. it might be published to potential customers. in order to re work them into standard formats. we’ve built the Service Catalogue. A service Catalogue could be used internally by the service provider. and any suggested changes to them. the customer should be realistic about potential levels of service. This might involve discussions about upgrading current statements on service level and provision. At a later stage. Find out what users would really like from that service. and sensible advice should be offered from the Service Level Management team. The first activity at this stage. how they should be specified and what is a realistic request in service level terms. showing all the services on offer to the business. The intention is to put actual metrics against various service 68 . It also records whether they are formally documented in any SLA’s.Lesson 5a Service Level Management In the last few pages we have been looking at those agreements and contracts. to help them understand what SLRs are. The second sub-process uses those SLRs to review the underpinning contracts and OLAs already in place with internal and external service providers. There is no specific format for SLR’s. which form an important part of Service level Management. and the services within it. which can help us with this decision. Service Catalogues exist in a number of forms. We should try to establish SLRs by checking requirement documents that exist for new services in development. along with SLA’s. is to build the initial Service Catalogue. These sub-processes can be grouped into 4 stages: • • • • Initial Generic Initial Per Service On-going Per Service On-going Generic So lets look at these 4 stages individually. OLAs and UPCs are all subject to the ITIL Change Management Process. The first stage is Initial Generic. for example.

however SLM takes responsibility to ensure that the necessary monitors are in place. A further activity is to review the Service Level Management process itself. third party suppliers. Internal reporting involves monitoring service quality in SLAs and related OLAs and UPCs. Review and modification takes place at regular intervals via service review meetings. For example service desk staff. It should also explain how we intend to prevent things from getting worse. we can also set KPI’s or Key Performance Indicators for what is considered a successful service. 69 . and it should simply point out when. including fix times for problems. including breaks in service. Remember you can’t control things that you can’t monitor. The third stage in the SLM process. to individual SLAs. debate any problems or issues. It might require several iterations of the process before agreement can be reached. Reporting can be subdivided in to either external or internal reporting. Remember the Service Catalogue falls under the Change Management control process. This proactive SLM activity involves talking with colleagues in Availability and Capacity Management. that any suggested changes to SLA’s should be authorised by the Change Management Process. reporting and review and modify. When the draft SLA is available. This involves informing all parties constrained by the SLA. and possible future SLA breaches. Monitors can provide useful reporting information to IT and the business. and discuss any changes to the SLA. and state whether we have met the SLA or not. the cost of providing certain levels of service becomes apparent to customers fairly quickly. and explanations of how we are going to prevent the failure occurring again. which relate to SLA’s and Service Level Management as a whole. Monitoring involves using the technical tools available to those working in Service Management. Usually. Once the agreement is formally signed. transaction response times and so on. includes the on-going per service activities of monitoring. time to repair. users and so on. These reports should be written in simple business language. SLM isn’t responsible for the technical implementation of monitors. and improving availability to the business. It involves sub processes. Availability and Problem Management. The objective of these meetings is to produce short reports on the way the SLA is working. Remember however. but most likely monthly. such as response times for enquiries at the Service Desk. These meetings are held at regular intervals. which might be needed. These processes include maintaining the Service Catalogue and updating it with new services. External reporting should be written in a simple and clear way. These statements should be supported by ITSM colleagues. Capacity. that it is in place. This detailed monitoring of service quality. to monitor the users important SLA clauses.Lesson 5a Service Level Management quality clauses. response time to users and so on. An exception report is a typical example of external reporting. and IT Infrastructure Management. to identify ways of improving response times. and also to identify future trends. Monitoring OLAs and UPCs will help us understand why SLA breaches are occurring. The final activity is to consider a Service Improvement Programme or SIP. where and why SLA breaches or near breaches occurred. By establishing Critical Success Factors (CSTs) we can measure performance. This is a process of negotiation. weekly isn’t uncommon. The fourth and final Service Level Management process stage is defined as ongoing generic. They will be interested in all activity which affects all service clauses. Reporting on Service Level Achievements We briefly mentioned the activity of reporting earlier in this lesson. amongst others. then that change is reflected in the catalogue. and we will be looking at reporting in more detail later in the lesson. agreement should be sort from customers and users that it represents an adequate specification of service. Service Level Management should look at all provided services and their associated quality requirements to see how we can improve service levels without significant increases in cost to the business. This activity uses SLA contents as a trigger for service improvement. so when an SLA is changed. resulting in more realistic negotiations. and might involve talking to external and internal suppliers about the cost of improving service quality parameters to the customer. the SLA must be implemented. is normally set up by the Capacity and Availability Management processes. descriptions of where we failed. such as Service Desk. Some organisations have automated document links from the Service Catalogue.

for example. we can convince them that we are achieving Service level targets. against which. It is the role of IT Service Continuity Management to create cost effective plans to deal with potential disasters. because each service isn’t treated in isolation. Both devices offer simple to understand graphical representations of service level parameters. A Service Level Management Agreement Monitoring Chart. Green charts. Changes in one SLA can impact on others. Typically these meetings involve customers rather than users and consequently shouldn’t be used as a substitute for user questionnaires and so on. trend graphs can display graphically that over a three month rolling period. 70 . the commencement date and its duration. and for less breaks in service.Lesson 5a Service Level Management down into several response types. its scope. It should be written in clear and concise business terms. by both parties. and the whole Service Level Management team work together to ensure quality of ALL services. the intended customer group. Agreed Service Levels. a request via mouse click on a PC for example. It’s common to state in SLA’s at what level. Customer statements might include defining the maximum number of Users at any one time. This is often broken Reviews In order to establish customer’s perceptions of its service. The third section in our SLA deals with the additional statements. Mechanisms for change should also be outlined in this section. and general extra statements. for example changing one SLA to allow more users on a network might have an adverse effect on other customers using the same network. that changes to SLA clauses should be handled via the Change Management process. Remember however. Amber. and how quickly service will be available after a disaster. Ahead of these meetings Service Level Management staff should review customer related incident records from the service desk. normal hours of service. SLA’s frequently contain clauses covering transaction response times. its contents can be broken down into three sections. and it’s important to remember that an SLA is an agreement between the business and IT with responsibilities on BOTH sides. and are likely to continue to do so. customers will want us to report. detailing the maximum time allowable in responding to an incident report. This can be a lengthy section of the SLA. such as fire and flood. Businesses are very interested in consistency of service as well as quality. detailing the number of transactions the service is expected to support in a defined period. In displaying these trends to customers. ‘Agreed Service Levels’ will define a number of measurable clauses. that the trend is for greater throughput of activity. Another important monitoring tool are trend graphs. If a request is received to amend an SLA clause it is important that the proposed change undergoes a thorough impact analysis. Typical SLA contents So what does a typical Service Level Agreement consist of? Well. is a popular mechanism for external reporting. broadly speaking. There may be as many as 20 different measurable clauses in an SLA. Statements on provision of service in case of a disaster are also important. and it should be authorised at an appropriate level. The SLA introduction describes the service. For example. or an incident response. Service Level Management should carry out regular service review meetings. An introduction. or a commitment to provide data to the IT supplier in the event of weekend working for example. and show where breaches or potential breaches have occurred. This is where a Service Level Management process benefits the organisation. availability and reliability of the service. Also included are statements of User and Customer responsibilities. Clauses related to ‘throughput’ are also common. or SLAM chart. such as service charges and how they are structured. as are RAG. or Red. including system responses.

71 . customer focused and technically aware • Good under pressure. and vice versa. Some typical example KPI’s might include Customer Perception ratings. and how many are held at the right time. A key activity in the review process is to review KPIs. This can be a stressful role. and the monitor.1 of the Service Delivery Manual. We examined the Service Level Management sub-processes in detail. remember however. the IT provider. • In summary we could define the characteristics of a Service Level Manager as being: • A good negotiator. and discussed how. We listed the key characteristics of the Service Level Manager role. Summary In this lesson we have been looking at Service Level Management. review and modify activities. We went on to look at the structure of Service Level Agreements.2. although many organisations hold them more frequently. planning an SLA structure. or process owner. and their relationships with Operational Level Agreements and Underpinning Contracts. they are not the place where changes are authorised. both written and oral • Business orientated. we can better satisfy customer’s requirements. Benefits & Problems The benefits of and potential difficulties with Service Level Management are listed on Page 45 of the little ITIL book and in Section 4. This isn’t meant to imply that this should be a single post. unless that’s appropriate to your organisation. how it’s often driven by a Service Improvement Programme. and went on to look at the structure of Service Level Agreements and the different way in which we can tailor service provision to customer needs. The Service Level Manager must be at an appropriate level to be able to negotiate with Customers on behalf of the organisation. This requires adequate seniority within the organisation and/or clearly visible management support. interpreting technical language from the IT groups in to understandable business language. ITIL suggests that these reviews are held on an annual basis. and to initiate and follow through actions required to improve or maintain agreed service levels. It’s important that the role acts as a conduit between IT specialists and the customer. including. Review meetings can lead to suggestions for change. The role of the Service Level Manager The SLM Process must be 'owned' in order to be effective and achieve successfully the benefits of implementation. The Service Level Management process can carry out its own internal review. We have seen how ITIL defines the goal of Service Level Management. This review should be carried out by the head of the Service Level Management team. firm but fair • A good communicator. and external suppliers. by producing a Service Catalogue and a Service Level Requirement document. We examined the relationships between the customer. report. and highlighted some of the potential benefits and possible problems associated with implementing a Service Level Management process.Lesson 5a Service Level Management so that they are able to answer any questions about these incidents. as it interfaces between two very strong minded communities. and why it’s regarded as essential to the ITIL structure as a whole. the number of service reviews held.

That is providing maximum business value for the minimum financial outlay. where we look at the cost of both developing something and then supporting it over its lifetime. and adhere to policies that are set by the higher-level financial management authorities within the organisation. For this reason the topic of Financial Management is often regarded as a “cross-over” area for IT staff. through any supply contracts we may have. For example if users insisted on a 99. 72 . there are some special considerations in the management of IT services’ finances and that is where the ITIL guidance helps. Financial forecasting is also a critical element of the decision making process and can help avoid cots over-runs. sometimes called Total Cost of Ownership (TCO). We also can contain costs through demand management. where costs are compared with similar organisations. For example. Optimising Service Value is all about helping the business balance the quality of the services it receives against the cost of providing that service quality. because it requires some knowledge of accounting processes. It is often important to demonstrate achievement. ‘Differential Charging’ may – subject to agreement with the business . Containing Costs This includes those costs incurred internally and used to persuade people to use resources at different times. Why Financial Management? The major reason for having financial management for the IT services area is to ensure the provision of value-for-money (VFM) IT services. Having said that. • You will be able to identify 6 types of cost that are commonly encountered and then classify these into one of six accounting cost categories. • You will be able to explain the main reasons why financial management is necessary and you will be able to recognise the three main elements that define the scope of financial management. • Finally. but it is very difficult to make a success of the process without the full commitment of the management from the corporate accounting functions. or resource shortages. IT financial management can help service level management by producing an accurate cost/benefit analysis of providing that level of availability as opposed to a reduced level. It is very important that we know about ALL our costs and are able to manage them.99% availability of a particular service during early SLA negotiations. Such information can be important when the IT function has to defend itself against claims that it is spending more money than it should be for the level of service being provided. Through this mechanism we take into account total lifecycle costs. perhaps though some form of ‘benchmarking’. In the vast majority of situations the Financial Management of IT Services will have to operate within boundaries. Introduction The goal of Financial management for IT services is to provide cost effective stewardship of the IT assets and the financial resources used in providing IT services. If as an IT organisation we don’t understand the costs of support. ITSM decision making will include evaluating suggested changes and formulating business cases This work might include calculating return on investment and is done by the IT Services Financial Management team on behalf of the IT service management group.Lesson 5b Financial Management for IT Services Lesson 5b Financial Management for IT Services When you have completed this lesson you will have a broad appreciation of Financial Management in an IT services context. we won’t be able to make correct project decisions about balancing rapid development against high cost of support. you will be able to describe seven different charging policies that can be applied to IT services. The mechanisms by which we achieve value for money services are: By facilitating decision making For example.

• Monitoring and controlling IT spend against that budget over the given period. each of which has a number of subprocesses. The ITIL guidance is that we should implement. almost certainly. but is unlikely to be acceptable to the business. Accounting without budgetary control makes little sense and in general charging without accounting is not a good option. the budgeting and accounting processes identify all the costs incurred by the IT service management. changes must also bear some relationship to the costs. between IT and the business. then we are attempting to do is recover money from the customers of the services. charges must be documented in the SLA for each service that is charged for. How close that relationship is. 73 . Once they’ve been agreed between the customers and the service level management team. Accounting and Charging. The suggested high level cost types that ITIL recommends are: Hardware. Charging. is usually a matter of debate in organisations. such as computers. at the very least.Lesson 5b Financial Management for IT Services Finally. Also. for example. which would include operating system software and applications. budgeting and accounting. and. we have a vehicle for performing cost benefit analysis and return on investment calculations. or for the creation new services. in terms of business support. The exact models for this will be dependent on standards for accounting within the organisation. The Scope of Financial Management for IT Services IT financial management for services is normally considered as having three main areas. Accounting and Charging which will often develop as an organisation’s financial policies become more mature and increase in both scope and complexity. This would tell us how much IT is costing. Those areas are Budgeting. Types of Cost It is very useful when creating a budget to understand all of the resources that we have by breaking them down into various cost types. as we have said is optional as far as ITIL is concerned. The ability to recoup this money only becomes possible once we move into charging processes. Once accounting is in place. As well as being equitable. Knowing in detail where the money and the resources it buys are being used only becomes possible once we introduce the accounting processes. IT financial management will expect such calculations to be done whenever there are proposals for significant changes. There is a hierarchical dependency between Budgeting. Any decision to recover IT costs. and enable us to understand where that money is going to. If we decide to use charging for IT services. We should do this. The starting point might be to introduce budgeting on a one year ahead basis. • Accounting on the other hand is the set of processes that allows the IT service provider to demonstrate where. These charges must be demonstrated to be equitable. but shed no light on how that figure is arrived at. at this stage. It is theoretically possible to charge without understanding who is using what resource. either totally or partially. the more complex the charging process will be and the more the overhead in gathering the necessary data. The Recovery of Costs from the users of the resources is also an important element in the Value for Money equation. The closer we want the charges to relate to the cost to the IT organisation of service provision. Software. the money from that budget has gone. before we attempt charging. • Seeking to secure that money from the business. data storage devices and so on. within IT. Budgeting is concerned with: • Predicting the money needed to deliver the IT service. networking equipment. Together. is a high level business decision usually taken at Board level and is not considered mandatory within ITIL. we have done nothing to recoup the costs from the business.

process that accountants call Conversely. So if £10000. then IT would expect a cross-charge for that persons time to come from the Finance Department. This is the depreciation. External Service. can be thought of as day-to-day running costs. machine rooms. offices. if we are asked to buy a package and a server for the use of Human Resources only. So capital costs relate to outright purchases of fixed assets and may apply to accommodation. computers. Capitalisation and depreciation policies are very much a concern for the central accounting functions and are in many respects governed by laws to prevent fraud and tax evasion. is spent on an item of equipment which is expected to last for three years. But in each of the next three years £3333 will be taken out of the operational expenditure and the assets will be decreased by that amount. Cost Classification Once the cost elements have been identified and their types understood. we take the cost of the service desk in total and distribute it across all of the customer groups. For example. A useful aide-memoir for these cost types is the acronym HAS PET – as you can see. for example. taxes. once it is completed that application becomes an asset of the company with a value of £100. so that they too can be written off over a number of years. A good example of this is software development. storage space and so on. such as development work. until at the end of three years the asset value Direct and Indirect Costs Costs can further be classified into direct and indirect costs. the assets of the company will be immediately increased by £10. 74 . which is used to account for the cross-charges that can take place between different parts of the business. on the other hand. benefits and other costs of employment. As a minimum. some companies try to roll up some operational costs and classify those as capital. stands at zero and the full £10.000 has been recovered from operational costs. Operational costs include salaries.Lesson 5b Financial Management for IT Services People. rental of equipment or buildings. Accommodation. For example. for example.000 – and the depreciate that asset over the years of its life. Capital expenditure is assumed to increase the total value of the company. ITIL recommends that costs need to be classified as either Capital or Operational costs. utilities. they will need to be classified for accounting and financial purposes. A company may decide that is it has spent £100. and workstations. An example of this might be the cost of the service desk where. ISPs. rather than attempt to work out which group was behind every call and how much time that took. disaster recovery facilities and the like. based on their usage of other resources. They are costs that are shared amongst groups. because IT lacked the resource to do this. Indirect costs cannot be allocated simply to one customer or group.000 on salaries to develop a software application then. if it was necessary for an Excel expert in Finance to give two days training to someone in Human Resources. And unabsorbed costs. expenses. ITIL suggests that we take advice from the main accounting section on the use of depreciation. then we could regard these package and server costs as being a direct cost that can be ‘charged back’ to the HR function. Direct costs refer to a cost that is directly attributable to a customer or a group of customers. while Operational expenditure does not. and licenses for software. Once money is spent on these it is no longer available to the company as an asset. salaries. covering items which might be outsourced. say. Operational costs. where it is too difficult to determine who is using how much of the resource and so the cost is allocated as a simple percentage uplift to all costs – in other words an overhead. It is sometimes the case that organisations make capital purchases but want to represent in their accounts the fact that this capital loses value over time. There are commonly two types of indirect cost – absorbed costs where the costs can be apportioned across a number of different groups based on their respective usage of the resource concerned. in other words. And finally Transfer.000.

in other words they become a profit centre in their own right. Some organisations allow their IT departments to sell their services externally to the company. If a service that is charged for on a fixed price basis is based on cost elements that are variable then if the workload increases dramatically the cost of providing the service may end up being greater than the money being recouped. in ITIL terms. There will need to be a mechanism for setting the charges. difficulties can arise if the volumes end up being less than predicted. This is often a useful policy when outsourcing is being considered. and if so on what basis. What is important is that costs are understood and that there is budgetary control.attempting to get back from the other business units just the cost of providing IT to them is known as the ‘zero-balance’ policy. But there are potential pitfalls here. There are a number of general charging policies which are usually considered. People are then aware of how much their business is spending on IT services. The problem with a no-charging policy is that it does not provide a means of managing customer expectations or manipulating demand. Fixed costs remain constant regardless of usage. The converse of this is also true – if charges are variable. a “Cost Plus” policy is where IT expects to recoup more than they spend. because it may be charged for on the basis of the amount of traffic that uses it. The concept of fixed and variable can also be applied to charging. is not normally a decision for IT financial management – those kind of high level business decisions are almost always made at very senior management levels within the business. Finally we might decide on a negotiated “Fixed Price’ policy. invoices and for resolving disputes. perhaps as a mechanism for dealing with potential variation in demand over a number of years. but they are not charged. A “Going Rate’ approach. there are fixed and variable costs. Section 5. If it is decided to charge for services. which will be a benefit to the business as a whole. It is worth spending some time in studying this cost model. then “Cost Recovery” . ‘Market rate’ charging uses an external cost comparison. All of that requires gathering and processing of data. The decision on whether to implement charging. The degree of ‘subsidy’ from the business as a whole will be a high level management decision. whereas variable costs increase in proportion to the usage made of a resource. allows the charges to be based on what other internal departments charge for their services or what other IT departments in similar organisations charge their internal customers. Alternatively. then possible charging policies can be considered. we are not attempting to recoup all of the costs from the individual business units but do want to achieve some element of cost consciousness. might be that there are costs involved in charging.Lesson 5b Financial Management for IT Services Finally. Here. where the actual price we charge Charging Policies Once budgeting and accounting procedures have been well established. or possibly as a basis for funding investment in new infrastructure components. and the business will need to decide how the extra money generated will be used. An example of a fixed cost might be a leased communication line – the price of which does not change regardless of how much or how little it is used. This will tend to mitigate in favour of market-rate pricing. and a mix of financial and IT skills in order to be effective. On the other hand an ISDN line might be an example of a variable cost. It is also possible to subsidise the service and to go for a ‘Cost Minus’ policy. but costs are fixed. for sending out bills and 75 . One of the reasons for deciding on this policy. where we see what external providers would charge the business for the sort of services we’re offering and use that figure as our charge. It is quite valid for the organisation to decide that they are not going to charge for IT services.3 of the Service Delivery manual – or Page 50 of the little ITIL book contains a useful illustration of how the different cost types and categories that we have discussed can combine to build a cost model for arriving at the total cost figure for a given customer.

and subject to control by the business.1. we have evaluated seven different charging policies that can be applied to IT services. Budgeting. We have considered 6 types of cost that are commonly encountered and have seen how these can be classified into one of six accounting cost categories. Clearly it is very important to get those prices about right. Benefits and Problems of ITFM The benefits of and potential difficulties with Financial Management for IT Services are listed on Page 51 of the little ITIL book and in Sections 5. otherwise an over-recovery might discourage users from using our services.7 and 5.9 of the Service Delivery Manual. an under-recovery would mean that IT would have to be rescued at the end of the year by the business as a whole. 76 . Finally. Conversely.1. Summary In this lesson we have learned what is meant by Financial Management in an IT services context and why it is a necessary process within ITIL We have explored in some detail the three main elements that define the scope of financial management – namely. Accounting and Charging. when it comes to actual pricing for services. understandable by the business. ITIL best practice advises that charges should be fair. Whatever charging policy is decided upon.Lesson 5b Financial Management for IT Services is a result of an agreement between ourselves and the customer group.

means no staff accommodation. BCM will need to look at cost effective ways of. no office.’ IT Service Continuity Management or ITSCM focuses on the IT services that support the business. particularly when you consider that statistics suggest that 80% of businesses that suffer a ‘disaster’. VBF’s are the critical parts or components of a service. or a disgruntled ex employee deleting critical data. which the ITIL guidance concentrates on. As a result you can’t service customer accounts. It’s likely that you will lose existing and new customers. or the alternative office location hasn’t any chairs or desks. these potential threats seem more likely. day-today business operations are going to stop. one very good way. This all seems pretty unlikely. • Have an understanding of the Business Continuity Lifecycle and have seen ITIL’s risk analysis techniques. and • Having a ‘disaster recovery’ mechanism in place to deal with any threat that does materialize. In the ITIL guidance. it’s important that IT service management staff point out the critical need for the ‘business’ to have a Business Continuity Plan. but if we consider some other scenarios. if the business has no Business Continuity Management process in place. then there’s little point in having a ITSCM process in place. which is described in chapter 7 of the ITIL Service Delivery book. the business is insured. and the extent to which the business depends on IT. take or despatch orders. collect payment and so on. So. so the insurance company will sort everything out. ‘Well. So how does a business prepare for such eventualities? Well. Ultimately the business could fail. such as a computer virus infecting the servers via email. your bank has a network of ATM’s.’ But what happens at start of business tomorrow morning? Firstly and pretty obviously. ITSCM are primarily concerned with Vital Business Functions or VBFs. go out of business within six months of it happening. or a local river flooded your offices? Your answer might be. Put simply. and as such must be ‘reinstated’ as quickly as possible. Business Continuity Management is concerned with evaluating business processes. no staff means no ongoing business activity. and appreciate the relationship between these two processes • be able to identify a Vital Business Function is. For example. a business focused element (Business Continuity Planning) and a technology element (IT Service Continuity Management Planning). Once you have completed this lesson you will. Remember. • Reducing the likelihood of a threat occurring • Minimising the impact on the business if the threat does occur. including printing or 77 . and recovery options Let’s start this lesson by posing a question. and be aware IT Service Continuity Managements links to other ITIL processes. Vital Business Functions -VBF’s Business Continuity Management.Lesson 6a Continuity Management Lesson 6A Continuity Management Objectives The subject of this lesson is IT Service Continuity Management. if these processes can’t be performed. Amongst other things. and it’s this process. Which of these processes is a sub set of the other depends on the nature of individual business. it is assumed that IT Service Continuity Management is a sub set of Business Continuity Management. What do you think would happen to your business immediately after a ‘disaster’. and so by association. however. if staff don’t know where they should go after a disaster. sales and revenue. which dispense cash and offer a selection of other services. is to implement Business Continuity Management or BCM. if any. in ITIL terms. The BCM activity incorporates two elements. so we’ll follow their example in this lesson. • Understand the terms Business Continuity Management and IT Service Continuity Management. for example if your offices burnt down. and considering the impact. which prevents ‘business as usual activities. that there is no point in making huge efforts to maintain IT services under disaster conditions.

the business can establish the level of criticality of its services. and IT may have developed contingency plans for systems perceived to be critical. Other linkages include: Availability Management . In the next few pages we will be looking at the Business 78 .delivering risk reduction measures to maintain ‘business as usual. The bank might consider that the only VBF performed by the ATM is the dispensing of cash. might have components missing. Sometimes a service. Some parts of the business may have already established individual continuity plans based on manual workarounds. and not the other services. and Strategy determines and agrees risk reduction measures and recovery options to support the requirements. Continuity lifecycle and its four stages. and a relevant amount of the available budget is assigned to each. which are. or BIA. The implementation stage includes the detailed planning required to create the disaster recovery plan. as a result of a disaster or other service disruption. is a key driver in determining ITSCM requirements. The business may be prepared to live without certain aspects of the IT infrastructure in the short term. The role of ITSCM is to identify the IT VBF’s and services. ‘How much the organisation stands to lose. This amount of money assigned to a VBF is proportional to its business importance. From this. The ITSCM Processes It’s not possible to develop an effective ITSCM plan in isolation. This can provide a worthwhile starting point for the process. agreeing the project and quality plans • • • • The Requirements and Strategy Stage. ITSCM has to have strong linkages with other ITIL disciplines. effective ITSCM is dependent on supporting vital business functions. as the title suggests. This includes putting in place risk reduction and risk mitigation measures. split into two sections.’ Configuration Management – defining the core infrastructure Capacity Management – ensuring that business requirements are fully supported through appropriate IT hardware resources Change Management – ensuring the currency and accuracy of the Continuity Plans through established processes and regular reviews And finally the use of statistics provided by Service Desk and the Incident Management process. performs Business Impact Analysis and Risk Assessment. We will discuss Risk Analysis in more detail later in the lesson.Lesson 6a Continuity Management displaying a balance. Risk analysis techniques such as CRAMM the CCTA’s Risk Analysis and Management Methodology. or the throughput performance of the network might be reduced. are performed in the Requirements and Strategy Stage. Not all aspects of the IT services will require contingency plans in the event of a disaster. in particular Availability Management and Service Level Management. and agree with the business how quickly those VBF’s and services need to be recovered. It’s important that agreement is sort from business that a ‘reduced service’ is better than no service at all. however. and Business Impact Analysis. which is reinstated quickly. and ensuring that the available budget is applied in the most appropriate way. is. it’s important that it supports the requirements of the business. Requirements. • • • • Initiation Requirements and Strategy Implementation Operational Management The initiation stage The activities to be considered during the initiation process will depend on the level of contingency facilities already in place with the organisation. For example. The initiation process covers the whole of the organisation and consists of the following activities: Policy Setting Specifying terms of reference and scope The allocation of resources Defining the project organisation and control structure • And finally. statements in SLA’s should define what service levels are likely to be available under ‘disaster’ as well as ‘normal’ operations. So the focus of ITSCM is directed at the Vital Business Functions.

A particular concern of ITSCM. A business response to this low level risk might be to ‘just deal with it if it happens. to go back to manual ordering for a short period of time. We could mitigate the risk. Also during the implementation phase. Risk Assessment and Counter Measures There a number of other approaches to assessing risk. The first option is ‘do nothing’. contracts will be signed with third party standby facility providers. a low impact and a low probability would mean a ‘low risk’ category. if they are required. it is useful to have a Service Catalogue available. This involves the identification of risks. rating.’ We mentioned the CCTA’s Risk Analysis and Management Method or CRAMM earlier. Assets could be hardware. and the introduction of an automated sprinkler system. Conversely. software. we are generally aware there is a threat of flood. by sharing it with another service. are ‘Hidden SPOF’s’. people. This is rarely used now except for the off-site storage. Risk Analysis can also be applied at component level. Surprisingly this can be a valid response. A Significant failure would occur if the cable were severed during building works. where organisations agree to back each other up in an emergency. It then examines the various threats that could exist. as it assumes that both organisations have enough spare capacity to fully support the other. We might then find that our mainframe computer systems are vulnerable to this threat. This analysis could identify a component failure risk in a particular service. or Single Point Of Failure. Any component within the IT infrastructure that has no backup capability. the business might have insurance in place to cover any potential ‘loss of business’. We can use information from this document to help asses the risk levels on different IT services. because they are housed in a site. that is made up of the same components. perhaps the simplest looks at the probability of something occurring. 79 . The business then has to take measures to deal with that risk. and it contains a list of services available to customers or users. This is possibly the most unlikely option suggested by the ITIL guidance. any associated threats. if the business has decided that the complete loss of some service in a disaster is acceptable. For example. For example. This approach can be represented in a matrix format as shown here. buildings. is known as a SPOF. ‘Manual back up’ can be an effective interim measure until the IT service is resumed. Would it be possible for example. and therefore this would give us a ‘high risk’ Contingent Risk Countermeasures ITIL suggests a number of possible options when dealing with a ‘disaster recovery’ situation. and judging what risks they are subject to. rather than a computerised system? The third option is a ‘Reciprocal Arrangement’. In order to do this type of risk analysis. by looking at Configuration Items. The final stage ‘Operational Management’ is responsible for educating all users and IT about the service continuity processes. and specifically what will happen in the event of a disaster. somebody will have to liase with the press in a public relations role. The results can provide a ‘risk rating’ which is very useful to the business. telecommunications and so on. You’ll remember that the service catalogue featured in the lesson on Service Level Management. which is below the water level of a tidal river. and can cause impact to the business and users when it fails. The highest risk status being one with both a high probability and impact. Implementing counter measures can be very costly. so a business case might be required to justify the level of investment. The asset would be significant in terms of the computer equipment and the services based on it. For example. and how vulnerable the assets are to these threats. Also remember that people will need to be trained in their ‘disaster recovery plan’ roles. and the impact if it did. CRAMM is a very useful method for looking at threats that might affect the availability of service. vulnerabilities and impacts. and training might be needed for this. An example of a hidden SPOF might be the point where multiple data cables enter an office via an underground duct. Any procedures should be well documented and understood. as it focuses on asset values.Lesson 6a Continuity Management An example of this might be a smoking ban. together with the subsequent implementation of cost justifiable counter measures.

have been put into place. but would involve moving site twice. and documents recovery procedures in an IT Service Continuity Plan. network wiring and so on. including the ‘hot standy’ could be at risk from a disaster. This would reduce third party costs. but it’s the most disruptive to the day-to-day business activities. or on a service by service basis. If it is fixed. Any of which can be provided either internally. to make sure that any lessons learned from the disaster. the whole site. but the general definition of immediate recovery is to allow up to 24 hours for full recovery. This would normally involve the use of an alternative site with continuous mirroring of the live environment and data. and trying to run critical services. where there are significant time differences. The question now is. In all cases the alternative environment that the business moves to. Recovery could be almost instantaneous. which must be made by the ITSCM process. air conditioning. This can be the most effective way of finding flaws in the plan. but this is a very good time to perform a test. which might involve visiting the remote site. while the internal intermediate site is configured. how can we be sure that the plan will work successfully when we actually use it? Well the obvious answer is to test it! The ITIL guidance suggests that plans should be tested. A ‘Warm Standby’ facility will have the required computer equipment in place. and where they are going to be kept. • After the plan has been written • After any major changes. or a local bank. The plans can be tested altogether as a ‘big-bang’ approach. For example. unannounced test. There are potential risks from having a ‘hot standby’ site in very close proximity to the business’s main site. An example of a portable solution might consist of a ‘mobile computer room’ which is placed adjacent to the business’s existing building. how ITSCM activities prepare the business against any internal or external threats. Testing IT Service Continuity Plans We have seen so far in this lesson.Lesson 6a Continuity Management There are examples of Reciprocal Arrangements working effectively on an international basis. and might include the use of a ‘hot standby’ third party site for a two or three days. Although it reduces logistical and network issues. or externally by a contracted third party. then the business goes to a particular location to make use of the services. Key ITSCM Decisions There are a number of critical decisions. An important one is deciding on how many copies of the Continuity Plan we should have. The facility doesn’t contain any computer equipment. Remember that all copies should be kept in ‘sync’ to reflect any changes to the infrastructure or the plan. The most difficult and expensive test type. Intermediate Recovery is also known as ‘Warm Standby’ and is used where recovery is needed between 24 and 72 hours. It relies on a network switch to allow communication to an alternative processing environment ‘out of hours’. either in the plan. This option is used when a business can function for a period of 72 hours or more without IT services. or to the IT infrastructure itself • At least annually • And after we’ve actually had to use the plan and have restored ‘normal’ service. The next three options are Gradual. Another key decision is how and when to invoke the contingency plan. Intermediate or Immediate recovery. by the business itself. Immediate Recovery is also known as ‘Hot Standby’. and the way the plan worked in practice. Test types include ‘dry runs’. This option involves providing only the essential services such as power. The IT Service Business Continuity Manager may well keep copies at home. Gradual recovery is also known as ‘Cold Standby’. The main difference between these options is the time scale of recovery. where we walk through the stages of the plan. If it is portable then the services may be brought to the business premises. So combinations of these options are sometimes used. can be either fixed or portable. and each staff member ‘plays’ their designated role. is the full. How long are we going to wait before we act after a major failure? 80 . This sounds a bit odd. it would be very risky to have just one copy of the plan stored at the site it provides contingency for! Many organisations keep plans at the alternative site. Next we can plan a test on an agreed future date. but it wouldn’t be configured or loaded with current operational software.

The process of leaving the recovery site. and have seen how ITSCM defines key IT activities as Vital Business Functions. Benefits and Possible Problems with ITSCM The key benefits of the ITSCM process include. we looked at how to test IT Service Continuity Plans. everyone should understand their role. and by the criticality of the services that are being disrupted. And finally. Ultimately it will be driven by the business. have in place. IT Service Management guide. We have seen some of the Risk Analysis techniques used in the Requirements and Strategy stage of the lifecycle. ITIL helps here. Including those for operational and recovery systems. Lesson Summary In this lesson we have been examining the Business Continuity Management and IT Service Continuity Management processes. Some Service Recovery Organisations have in place. It’s also important to tell them to visit the back up site if they are called out. We looked at the relationship between the two processes. and listed all of the ITIL Recovery options. a switching facility. The management of risk. which team members go to the alternative site. who books hotel accommodation. For example. should be addressed. We saw how ITSCM links to other ITIL processes. a reduced impact from failures in the IT infrastructure Potentially lower insurance premiums as a result of implementing good counter-measures And the fulfilment of mandatory and regulatory requirements. does our contingency supplier.Lesson 6a Continuity Management Invoking a disaster recovery plan is an expensive and complex process. where they can transfer demand to other sites in other countries. You can see a comprehensive list of benefits and potential problems associated with ITSCM on pages 62 and 63 of the ITSMF’s. Deciding how long to wait before invoking the plan is difficult. Ask the question. Ultimately this makes their service more robust. And finally. where third party recovery service providers. Who does what during the disaster recovery period. Questions like. and as a consequence. their own contingency plan. so the temptation is to wait and hope that it’s an Availability Issue rather than a Continuity Management issue. and went on to look in some detail at the Business Continuity Lifecycle. and returning to normal working at the original site. have been literally ‘deluged’ by demand. and that clearly defined processes are in place for the move. particularly those who are providing recovery services. and at some of the key decisions required by the IT Service Continuity Management process. serious flooding has resulted in them receiving multiple requests for help. the details of third party contractors. should also be to hand. This pro forma contains an annex for all the contact details. Leaving them unable to fulfil their contractual obligations. 81 . should also be documented. There have been several recent examples. Make sure that all the necessary work has been done at the home site before the returning. A comprehensive list of all third party infrastructure suppliers should also be drawn up. or the little ITIL book for short. Errors are easily made at this point. Similarly. should also be documented. Importantly. by providing a Pro Forma disaster recovery plan that can be used as a basis for creating our own version. so particular attention should be made to removing all commercial or confidential data from the back up site before departure.

Once you are regularly scoring in excess of 30 out of 40 in the exam simulator you can be reasonably sure that will you pass the real Foundation exam. Those that you probably know the answer to but the wording of the question needs some digesting. do your remember at school. The examination is “closed book” – in other word you can take no notes or documentation of any kind into the exam room with you. read the manuals and the “little ITIL” books and practice in the exam simulator. by the ISEB who are based in Swindon in England and EXIN who are a Dutch organisation. The vast majority of people finish the exam well within this time – so Tip 1 – Don’t feel under time pressure. Every class had at least one of them! The reason that they did get through was not down to luck . and they worked out how to stack the odds in their favour. Introduction & Background The ITIL examinations are administered. You have plenty of time. In order to achieve a pass at least 26 questions must be answered correctly – in other words 65% or more of the questions asked. that there were always some kids who may not have been that bright. The Foundation questions can be categorised into three types: Those that you find really easy and can answer without too much thought. This is something that you have not had the luxury of doing in the exam simulator. and may not have worked that hard – but they always got through the exams OK. you are allowed 60 minutes to answer 40 questions. This course only addresses the first of these. what it contains and how it works in practice. The Foundation Exam Assuming that you have done all your preparation and that you have all the required knowledge. the next step is to focus on the examination itself. There are a lot of “negative” type questions so do be careful over these. You have already seen questions which are typical of those asked in the Foundation exam as we have worked through this course. In this session we will be looking at how you too can increase your chances of getting a good result in the Foundation exam – not just by knowing ITIL well – but by approaching the examination in an objective and systematic manner. even though you understand the question. The objective of the Foundation exam is to confirm a very broad-brush knowledge across the whole of ITIL and therefore does not demand a very detailed knowledge within any specific area. It is a prerequisite for going on the take the more advanced certificates. The exam itself consists of 40 such multiple choice questions and one hour is allowed. Remain cool and stick to your game plan. The first tip for doing well at Foundation level is therefore to do your homework. which is.Lesson 7a Passing the ITIL Foundation Exam Lesson 7a Passing The ITIL Foundation Examination Objectives So far in this course. Foundations. As we have seen. There are currently three examination levels and associated qualifications. the entry-level qualification. on behalf of the OGC. Those that. we have concentrated on your knowledge of ITIL – what it is. they are: There are three internationally recognised ITIL certificates.they were just good at taking exams. as you would expect. you are not 100% sure of the answer. 82 . Well. Practitioner’s and Manager’s. Study this course material. A good strategy is therefore to do the exam paper in three passes. They had the right mental approach. In simple terms this is a test that you are broadly familiar with the contents of the Service Delivery and Service Support manuals. Although do be careful with the exact semantics of some of the questions and make sure that you have properly read the questions.

Once you have worked out what a question means. Use your mouse to drag and drop the right words into position to correctly interpret these acronyms. 83 . In the meantime try this little test. if you know the answer then answer the question. Now it’s time for the third and final pass. count up how many questions still remain unanswered and allocate a maximum time for each one so that you will just get them all answered. One final tip – be very careful about changing any of your answers. ITIL is nothing if not full of acronyms – and many of the questions in the Foundation exam assume that you are familiar with most of them. Avoid any temptation to deliberate too long over any question. Marks don’t get subtracted for wrong answers so if you have 4 or 5 questions that you just don’t know the answer to – make guesses – by random chance you will get at least one of them right. If you have 5 unanswered questions and 5 minutes left – don’t spend more than one minute on any one question. otherwise move on to the next unanswered question. So. answering all the questions where the right answer is immediately obvious to you. Now go back to the beginning of the paper and start work on all the second category of questions. If in doubt move on to the next one. This first pass will ensure that – in the unlikely event that you do run out of time – at least you will have answered all the easy questions. Again – never submit a paper unless all the questions have been answered. Go back to the start of the paper again and consider each of the questions that you have not yet answered. work your way through.Lesson 7a Passing the ITIL Foundation Exam When you are first presented with the paper. So it is worthwhile running through the list of acronyms given in the little ITIL books and the manuals themselves and memorising the less obvious ones. At this stage you may the timing – what you out of time and unanswered – even if answers. Experience has shown that about two thirds of changes that candidates make to their answers are in fact changing a correct answer to an incorrect one. For anybody who has done the right level of background study and preparation this alone will probably be enough to secure a pass. Often your first instincts are the right ones. need to be careful over don’t want to do is run leave any questions you have to guess the Now one last exercise. This time when you get to the end of the paper you should have answered all the questions that you understand and that you are confident of the answers – hopefully by now you will have answered the majority of the 40 questions.

Acronyms ACD AMDB ASP AST ATM Automatic Call Distribution Availability Management Database Application Service Pro vider Agreed Service Time Automatic Teller Machine B BCM BCP BIA BITA BQF BRM BSC BSi Business Continuity Management Business Continuity Plan(ning) Business Impact Analysis Business IT Alignment British Quality Foundation Business Relationship Management Balanced Scorecard British Standard Institution C C&CM CAB CAB/EC CASE CCTA CDB CFIA CI CIA CMDB CMM COP Configuration and Change Management Change Advisory Board Change Advisory Board/Emergency Committee Computer-Aided Systems Engineer Central Computer and Telecommunications Agency Capacity Database Component Failure Impact Analysis Configuration Item Confidentiality. Integrity and Availability Configuration Management Database Capability Maturity Model C d fP ti 84 .

Acronyms CRAMM CRM CSBC CSF CSS CTI CCTA Risk Analysis & Management Method Customer Relationship Management Computer Services Business Code Critical Success Factor Customer Satisfaction Survey Computer Telephony Integration D DBMS DHS DHL DISC DR DRP DSL DT DataBase Management System Definitive Hardware Store Definitive Hardware Library Delivering Information Systems to Customers Disaster Recovery Disaster Recovery Plan(ning) Definitive Software Library Down Time E EDI EFQM EUA EUDT EUPT EXIN Electronic Data Interchange European Foundation for Quality Management End User Availability End User Down Time End User Processing Time Examen Instituut (Dutch Examination Board) F FSC FTA Forward Schedule of Change Fault Tree Analysis G GUI G hi lU I t f 85 .

Acronyms H HD Help Desk I ICAM ICT ID IDEF IP IR IS ISEB ISO ISP IT ITAMM ITIL ITSC ITSCM ITSM itSMF IVR Intergrated Computer-Aided Manufacturing Information and Communication Technology(ies) Identification ICAM Definition Internet Protocol Incident Report Information System(s) / Information Service(s) Information Systems Examination Board International Standards Organisation Internet Service Provider Information Technology IT Availability Metrics Model Information Technology Infrastructure Library IT Service Continuity IT Service Continuity Management IT Service Management IT Service Management Forum Interactive Voice Response J JD Job Description K KE KEL KER Known Error Known Error Log K E R d 86 .

Acronyms KPI KSF Key Performance Indicator Key Success Factor L LAN Local Area Network M MBNQA MIM MTBF MTBSI MTTR Malcolm Baldrige National Quality Award Major Incident Management Mean Time Between Failures Mean Time Between System Incidents Mean Time To Repair O OGC OLA OLTP Office of Governnment Commerce Operational Level Agreement On-line Transaction Processing P PAD PC PER PIR PM PKI PR PRINCE2 PSA Package Assembly/Disassembly device Personal Computer Project Evaluation Review Post-Implementation Review Problem Management Public Key Infrastructure Problem Record Projects IN Controlled Environments Projected Service Availability Q QA QMS Quality Assurance Q lit M tS t 87 .

Acronyms R RAG RAID RCM RFC RFS ROCE ROI RWO Red-Amber-Green Redundant Array of Inexpensive Disks Resource Capacity Management Request For Change Request For Service (Service Request) Return On Capital Employed Return On Investment Real World Object S SAC/D SCI SCM SIP SLA SLAM SLM SLO SLR SMO SMT SOA SPICE SPOF SQP SSADM Service Acceptance Certificate/Document Software Configuration Item Software Configuration Management Service Improvement Programme Service Level Agreement SLA Monitoring Service Level Management Service Level Objective Service Level Requirement Service Maintenance Objectives Service Management Team System Outage Analysis Software Process Improvement Capability dEtermination Single Point of Failure Service Quality Plan Structured Systems Analysis and Design Method 88 .

Acronyms T TCO TOP TOR TP TQM Total Cost of Ownership Technical Observation Post Terms of Reference Transaction Proccessing Total Quality Management U UPS Uninterruptible Power Supply V VBF VOIP VSI Vital Business Function Voice Over Internet Protocol Virtual Storage Interrupt W WAN WFD WIP Wide Area Network Work Flow Diagram Work in Progress 89 .

i. Assets can include people. The term may be applied where production costs only. not only on the financial targets but also on the internal processes. is included in costs of specific products or saleable services. Ability of a component or service to perform its required function at a stated instant or over a stated period of time.e. The difference between overhead cost incurred and overhead cost absorbed: it may be split into its two constituent parts for control purposes. Equipment and techniques used to match circuits to each other ensuring minimum transmission impairment. It helps to focus. accommodation. paper records. in a given period of time. Underor over-absorbed overhead. by means of absorption rates. within a phase of a plan. In a communications sense. which is normally done in blocks. A cost that can be directly identified with a business unit. Customers and learning and growth issues. It is usually expressed as the availability ratio. allocated to recovery teams and individuals. without additional timing information. Synchronous transmission is usually more efficient than the asynchronous method. networks.Glossary of Terms Absorbed overhead Overhead which. Defined actions. Baseline Bridge 90 . This method of transmitting data is sometimes called start/stop. Synchronous working involves the use of timing information to allow transmission of data. A cost that is shared by a number of business units (an indirect cost). Absorption costing Action lists Alert phase Allocated cost Apportioned cost Asset Asynchronous /synchronous Availability B Balanced Scorecard An aid to organisational performance management. the proportion of time that the service is actually available for use by the Customers within the agreed service hours. Component of a business process. A principle whereby fixed as well as variable costs are allotted to cost units and total overheads are absorbed according to activity level. fax machines. the baseline remains unchanged and available as a reference of the original state and as a comparison against the current position (PRINCE 2). These are supported by reference data. Although the position may be updated later. computer systems. or costs of all functions are so allotted. A snapshot or a position which is recorded. the ability to transmit each character as a self-contained unit of information. This cost must be shared out between these units on an equitable basis. The first phase of a business continuity plan in which initial emergency procedures and damage assessments are activated. etc.

Glossary of Terms BS7799 The British standard for Information Security Management. software compile and load. IT. marketing services. Traditionally this was the accommodation and machinery necessary to produce the enterprise's product. i. Documents describing the roles. delivering services. e. accounting for money received. The techniques used in the evaluation can be summarised as non-discounting methods (i. The process of identifying major expenditure as Capital. The most common item for this to be li d t i ft h th d l di h h d Capital investment appraisal Capitalisation 91 . A business unit within an organisation. branch. The desired time within which business processes should be recovered. selling products. to reduce the impact on the current financial year of such expenditure.e. e. return on capital employed and discounted cash flow methods (i. This standard provides a comprehensive set of controls comprising best practices in information security. division. A defined group of personnel with a defined role and subordinate range of actions to facilitate recovery of a business function or process. Build Business function Business process Business recovery objective Business recovery plan framework Business recovery plans Business recovery team Business unit C Capital Costs Typically those costs applying to the physical (substantial) assets of the organisation. distributing products. Capital Costs are the purchase or major enhancement of fixed assets.e. Typical business processes include receiving orders. responsibilities and actions necessary to resume business processes following a business disruption. The process involves taking one of more input Configuration Items and processing them (building them) to create one or more output Configuration Items e. A template business recovery plan (or set of plans) produced to allow the structure and proposed contents to be agreed before the detailed business recovery plan is produced.g. yield. invoicing for services. The final stage in producing a usable configuration. A segment of the business entity by which both revenues are received and expenditure are caused or controlled. such revenues and expenditure being used to evaluate segmental performance. a department. whether there is a substantial asset or not. personnel. A business process usually depends upon several business functions for support. other business processes will depend on it and it will depend on other processes. accommodation. A business process rarely operates in isolation.g. assets and services required within this time. for example computer equipment (building and plant) and are often also referred to as 'oneoff' costs. A group of business activities undertaken by an organisation in pursuit of a common goal. simple pay-back). and the minimum staff. The process of evaluating proposed investment in specific fixed assets and the benefits to be obtained from their acquisition. net present value and discounted pay-back).g.e.

infrastructure change request. hardware. The processes by which an organisation retains overall co-ordination of its recovery effort during invocation of business recovery plans. Sometimes referred to as the Configuration Board. modification or removal of approved. Raised. A group that is given the authority to approve Change. application. See 'Gradual Recovery'. Auditable information that records. Request for Change. The procedure to ensure that all Changes are controlled. Implemented. system. environment. and raising the relevant invoices for recovery from customers.Glossary of Terms Category Classification of a group of Configuration Items. showing information on each Change. enabling approved Changes with minimum disruption. Process of formally identifying incidents. When the Customer is satisfied that an Incident has been resolved. Closed. environment.g. Change control form. validation change request. Approved. by who and why. Reviewed. A group of people who can give expert advice to Change Management on the implementation of Changes. by the project board. A record containing details of which CIs are affected by an authorised Change (planned or implemented) and how. analysis. documentation. in a controlled manner. Change documents or problems. Process of controlling Changes to the infrastructure or any aspect of services. network. Change record. control and communications 92 . Change Change Advisory Board Change authority Change control Change document Change history Change log Change Management Change record Charging Classification Closure Cold stand-by Command. for example. This board is likely to be made up of representatives from all areas within IT and representatives from business units. what decisions have been made and its current status. what was done. Change order. its evaluation. application.g. Process of formally identifying Changes by type e. software. problems and known errors by origin. implementation and post-implementation of the Change. The process of establishing charges in respect of business units. symptoms and cause. e. e. when it was done.g. including the submission. A log of Requests for Change raised during the project. project scope change request. supported or baselined hardware. desktop build or associated documentation. decision making. approval. software. The addition.g. Process of formally grouping Configuration Items by type e.

It includes the allocation of identification characters or numbers to the Configuration Items and their documents. production. automatic support for Change. design and documentation of computer software. deviations and waivers that impact on the configuration. Configuration Management Tool (CM Tool) Configuration Structure Contingency Planning A hierarchy of all the CIs that comprise a configuration. A software product providing Configuration or version control. Configuration documentation Configuration identification Configuration Item (CI) Configuration Management Configuration Management Database Configuration Management plan A document setting out the organisation and procedures for the Configuration Management of a specific product. such as a Request for Change. The process of identifying and defining the Configuration Items in a system. Activities comprising the control of Changes to Configuration Items after formally establishing its configuration documents.which is (or is to be) under the control of Configuration Management. analysis. the term has been used to refer to planning for the recovery of IT systems rather than entire business processes. build. the selection of Configuration Items. system design. It also includes the unique numbering of configuration control forms associated with Changes and Problems. and enables that product or system to be rebuilt at a later date. recording and reporting the status of Configuration Items and Requests for Change. support group or service. project. co-ordination. The implementation of Changes includes changes. system. 93 . Traditionally. Configuration of a product or system established at a specific point in time.or an item. and the documentation of the Configuration Item's physical and functional characteristics including interfaces and subsequent Changes. CIs may vary widely in complexity. and verification for a configuration item. Documents that define requirements. Component of an infrastructure . size and type . A database which contains all relevant details of each CI and details of the important relationships between CIs. Planning to address unwanted occurrences that may happen at a later time. which captures both the structure and details of the product or system. associated with an infrastructure .from an entire system (including all hardware. approval or rejection of Changes. and verifying the completeness and correctness of configuration items.Glossary of Terms Computer Aided Systems Engineering Configuration Baseline (see also Baseline) Configuration control A software tool for programmers. Activities that determine the product structure. It includes the evaluation. It provides help in the planning. software and documentation) to a single module or a minor hardware component.

Glossary of Terms


The amount of expenditure (actual or notional) incurred on, or attributable to, a specific activity or business unit. Ensuring that there is a proper balance between the quality of service on the one side and expenditure on the other. Any investment that increases the costs of providing IT services should always result in enhancement to service quality or quantity. All the procedures, tasks and deliverables that are needed to fulfil an organisation's costing and charging requirements. In the context of CSBC the cost unit is a functional cost unit which establishes standard cost per workload element of activity, based on calculated activity ratios converted to cost ratios. The process of identifying the costs of the business and of breaking them down and relating them to the various activities of the organisation. A check or restraint on the service designed to enhance security by reducing the risk of an attack (by reducing either the threat or the vulnerability), reducing the Impact of an attack, detecting the occurrence of an attack and/or assisting in the recovery from an attack. The processes by which an organisation manages the wider impact of a disaster, such as adverse media coverage. Owner of the service; usually the Customer has responsibility for the cost of the service, either directly through charging or indirectly in terms of demonstrable business need. It is the Customer who will define the service requirements.

Cost effectiveness

Cost Management

Cost unit



Crisis management Customer

Data transfer time The length of time taken for a block or sector of data to be read from or written to an I/O device, such as a disk or tape. The library in which the definitive authorised versions of all software CIs are stored and protected. It is a physical library or storage repository where master copies of software versions are placed. This one logical storage area may in reality consist of one or more physical software libraries or filestores. They should be separate from development and test filestore areas. The DSL may also include a physical store to hold master copies of bought-in software, e.g. fire-proof safe. Only authorised software should be accepted into the DSL, strictly controlled by Change and Release Management. The DSL exists not directly because of the needs of the Configuration Management process, but as a common base for the Release Management and Configuration Management processes. A release that includes only those CIs within the Release unit that have actually changed or are new since the last full or Delta Release. For example, if the Release unit is the program, a Delta Release contains only those modules that have changed, or are new, since the last full release of the program or the last Delta Release of the modules - see also 'Full Release'.

Definitive Software Library (DSL)

Delta Release


Glossary of Terms


The reliance, either direct or indirect, of one process or activity upon another. The loss in value of an asset due to its use and/or the passage of time. The annual depreciation charge in accounts represents the amount of capital assets used up in the accounting period. It is charged in the cost accounts to ensure that the cost of capital equipment is reflected in the unit costs of the services provided using the equipment. There are various methods of calculating depreciation for the period, but the Treasury usually recommends the use of current cost asset valuation as the basis for the depreciation charge. Charging business customers different rates for the same work, typically to dampen demand or to generate revenue for spare capacity. This can also be used to encourage off-peak or night time running. A cost that is incurred for, and can be traced in full to a product, service, cost centre or department. This is an allocated cost. Direct costs are direct materials, direct wages and direct expenses. A series of processes that focus only upon the recovery processes, principally in response to physical disasters, that are contained within BCM. An evaluation of the future net cash flows generated by a capital project by discounting them to their present-day value. The two methods most commonly used are:


Differential charging

Direct cost

Disaster recovery planning

Discounted cash flow

• •

Yield method, for which the calculation determines the internal rate of return (IRR) in the form of a percentage Net present value (NPV) method, in which the discount rate is chosen and the answer is a sum of money.


The offering to business customers of reduced rates for the use of offpeak resources (see also Surcharging). Memory that is used to store blocks of data that have been read from the disk devices connected to them. If a subsequent I/O requires a record that is still resident in the cache memory, it will be picked up from there, thus saving another physical I/O. Full duplex line/channel allows simultaneous transmission in both directions. Half duplex line/channel is capable of transmitting in both directions, but only in one direction at a time.

Disk cache controller

Duplex (full and half)

Echoing A reflection of the transmitted signal from the receiving end, a visual method of error detection in which the signal from the originating device is looped back to that device so that it can be displayed. The constituent parts of costs according to the factors upon which expenditure is incurred viz., materials, labour and expenses. Th h th i d t d b i

Elements of cost

E d U


Glossary of Terms


A collection of hardware, software, network communications and procedures that work together to provide a discrete type of computer service. There may be one or more environments on a physical platform e.g. test, production. An environment has unique features and characteristics that dictate how they are administered in similar, yet diverse manners. In some organisations it is common to use 'Super' Users (commonly known as Super or Expert Users) to deal with first-line support problems and queries. This is typically in specific application areas, or geographical locations, where there is not the requirement for full-time support staff. This valuable resource however needs to be carefully coordinated and utilised. One of the measures, against which a delivered IT service is compared, expressed in terms of the customer's business.

Expert User

External Target

Financial year An accounting period covering 12 consecutive months. In the public sector this financial year generally coincides with the fiscal year which runs from 1 April to 31 March. Contains details of all the Changes approved for implementation and their proposed implementation dates. It should be agreed with the Customers and the business, Service Level Management, the Service Desk and Availability Management. Once agreed, the Service Desk should communicate to the User community at large any planned additional downtime arising from implementing the Changes, using the most effective methods available. The total cost of all the resources used in supplying a service i.e. the sum of the direct costs of producing the output, a proportional share of overhead costs and any selling and distribution expenses. Both cash costs and notional (non-cash) costs should be included, including the cost of capital. See also 'Total Cost of Ownership' All components of the Release unit are built, tested, distributed and implemented together - see also 'Delta Release'.

Forward Schedule of Changes

Full cost

Full Release

Gateway Equipment which is used to interface networks so that a terminal on one network can communicate with services or a terminal on another. Previously called 'Cold stand-by', this is applicable to organisations that do not need immediate restoration of business processes and can function for a period of up to 72 hours, or longer, without a reestablishment of full IT facilities. This may include the provision of empty accommodation fully equipped with power, environmental controls and local network cabling infrastructure, telecommunications connections, and available in a disaster situation for an organisation to install its own computer equipment.

Gradual Recovery


The identification of critical business processes. Hot stand-by typically referred to availability of services within a short timescale such as 2 or 4 hours whereas immediate recovery implies the instant availability of services. Telecommunications and Data Networking Technologies into a single technology. because it has been incurred for a number of cost centres or cost units.Glossary of Terms Hard charging Descriptive of a situation where. or may cause. A cost incurred in the course of making a product providing a service or running a cost centre or department. A host computer comprises the central hardware and software resources of a computer complex. See 'Immediate Recovery'. customer services will be unable to operate for two days. Often equal to the extent of a distortion of agreed or expected Service Levels. CPU. It is important to distinguish between the previous definition of 'hot stand-by' and 'immediate recovery'. actual funds are transferred from the customer to the IT organisation in payment for the delivery of IT services. channels. e. and the potential damage or loss that may be caused to the organisation resulting from a disruption to those processes. an interruption to.g. facilities and services needed to enable business processes to continue to operate at a minimum acceptable level · the time within which they should be recovered. Usually related to a business process and will always refer to a period of time. Any event which is not part of the standard operation of a service and which causes. which a program was using. e. The time within which full recovery of the business processes is to be achieved is also identified. service or department. the quality of that service. This means that another piece of memory must be found to accommodate the code or data. Measure of the business criticality of an Incident. Description of the type of impact on the business that could follow a business disruption. or a reduction in. Problem or Request for Change. but which cannot be traced directly and in full to the product. Previously called 'Hot stand-by'.g. These costs are apportioned to cost centres/cost units. Hard fault Host Hot stand-by I ICT The convergence of Information Technology. provides for the immediate restoration of services following any irrecoverable incident. memory. The term is used to denote all non-network items. disk and magnetic tape I/O subsystems plus operating and applications software. Business impact analysis identifies: · the form the loss or damage will take · how that degree of damage or loss is likely to escalate with time following an incident · the minimum staffing. Indirect costs are also f dt h d Immediate Recovery Impact Impact analysis Impact scenario Incident Indirect cost 97 . has been redeployed by the operating system for some other purpose. The situation in a virtual memory system when the required page of code or data. within an organisation. and will involve physical reading/writing of pages to the page file.

ITIL K Known Error An Incident or Problem for which the root cause is known and for which a temporary Work-around or a permanent alternative has been identified. i. that IT investment is both efficiently and economically directed. Interface Intermediate Recovery Internal target Invocation (of business recovery plans) Invocation (of stand-by arrangements) Invocation and recovery phase ISO9001 Putting stand-by arrangements into operation as part of business recovery activities. The second phase of a business recovery plan.a set of guides on the management and provision of operational IT services. team or group with functional responsibility within an organisation for ensuring that spend on IS/IT is directed to best effect. it remains a Known Error unless it is permanently fixed by a Change. in relation to business case development. and is used by organisations that need to recover IT facilities within a predetermined time to prevent impacts to the business process. typically involves the reestablishment of the critical systems and services within a 24 to 72 hour period. One of the measures against which supporting processes for the IT service are compared. e. Putting business recovery plans into operation after a business disruption.e. and that progress towards effective business solutions is monitored. Usually expressed in technical terms relating directly to the underpinning service being measured.Glossary of Terms Informed Customer An individual. The term is often used in relation to the outsourcing of IT/IS. Physical or functional interaction at the boundary between Configuration Items. 98 . The 'Informed' Customer function ensures that the needs of the business are effectively translated into a business requirements specification. The 'Informed' Customer should play an active role in the procurement process. an RFC will be raised. If a business case exists. that the business is receiving value for money and continues to achieve the most beneficial outcome. The internationally accepted set of standards concerning quality management systems. Previously called 'Warm stand-by'. in any event.g. The OGC IT Infrastructure Library . Sometimes also called 'Intelligent Customer'. but. In order to fulfil its role the 'Informed' Customer function must gain clarity of vision in relation to the business plans and assure that suitable strategies are devised and maintained for achieving business goals. and also in ensuring that the services and solutions obtained are used effectively within the organisation to achieve maximum business benefits.

Maturity level/Milestone Metric O Operational Costs Those costs resulting from the day-to-day running of the IT Services section. It is normally defined by manufacturers as being half the disk rotation time. Measurable element of a service process or function. That request may. The process by which functions performed by the organisation are contracted out for operation. The lifecycle represents an approval process for Configuration Items. connected by allowable transitions. hardware maintenance and electricity. Problem Reports and Change documents. and relating to repeating payments whose effects can be measured within a short timeframe.g. based upon the investment already made. A read or write request by a program. necessitate a physical I/O. usually less than the 12-month financial year. Operational Level Agreement Opportunity cost (or true cost) Outsourcing Overheads P Package assembly /disassembly device A device that permits terminals. For example. Lifecycle Logical I/O M Marginal Cost The cost of providing the service now. A PAD converts data to/from packets and handles call set-up and addressing. by third parties. wages and expenses. That is the cost of using resources in a particular operation expressed in terms of foregoing the benefit that could be derived from the best alternative use of those resources. or may not. An internal agreement covering the delivery of services which support the IT organisation in their delivery of services. A series of states. to access such a network. The total of indirect materials. e. A program interruption that occurs when a page that is marked 'not in l 'i f dt b ti Page fault 99 . The degree to which BCM activities and processes have become standard business practice within an organisation.Glossary of Terms L Latency The elapsed time from the moment when a seek was completed on a disk device to the point when the required data is positioned under the read/write heads. on the organisation's behalf. on a read request the required record may already be in a memory buffer and therefore a physical I/O is not necessary. The value of a benefit sacrificed in favour of an alternative course of action. staff costs. which do not have an interface suitable for direct connection to a packet switched network.

re-routing circuits at the physical level on a backbone network) while data communications is in progress. The process of planning and regulating. with the objective of performing the process in an effective and efficient way. and reads new pages from disk. Alternative title for the BSI publication 'A Code of Practice for IT Service Management'. Unknown underlying cause of one or more Incidents. the operating system writes old pages to disk. It is often caused by changes to the circuits and network equipment (e. The program therefore has to wait in a queue to obtain service from that device. so that the required data and instructions are in real memory. The amount of time that a hardware device is busy over a given period of time. Diff tl l f RAID b li d t id f t ili 100 . For example. With insufficient real memory.Glossary of Terms Paging The I/O necessary to read and write to and from the paging disks: real (not virtual) memory is needed to process data. Changes etc. if the CPU is busy for 1800 seconds in a one hour period. activities. A connected series of actions. direct labour and direct expenses.g. The standard UK government method for project management. Sequence in which an Incident or Problem needs to be resolved. is already busy. A collection of activities and projects that collectively implement a new corporate requirement or function. A communications error reported by a computer system that is not detected by network monitoring equipment. The term prime cost is commonly restricted to direct production costs only and so does not customarily include direct costs of marketing or research and development. performed by agents with the intent of satisfying a purpose or achieving a goal. The total cost of direct materials. which a program wishes to use.a mechanism for providing data resilience for computer systems using mirrored arrays of magnetic disks. PD0005 Percentage utilisation Phantom line error Physical I/O Prime cost PRINCE2 Priority Problem Process Process Control Programme Q Queuing time Queuing time is incurred when the device. based on impact and urgency. A read or write request from a program has necessitated a physical read or write operation on an I/O device. R RAID Redundant Array of Inexpensive Disks . its utilisation is said to be 50%.

number of I/Os and memory usage. The resources are typically computer and related equipment. The IT Services section needs to provide the customers with the required services. A collection of new and/or changed CIs which are tested and introduced into the live environment together. units have to be established by logical groupings. those assets. facilities or organisational (people). The total resource costs that are consumed by an individual online transaction. Because computer resources come in many shapes and forms. The amount of machine resource that a given task consumes. and vulnerabilities of. It is usually expressed in terms of CPU seconds. Form. and the reduction of those risks to an acceptable level. This may be a Work-around. A set of responsibilities. batch job or program.Glossary of Terms Reference data Information that supports the plans and action lists. This is a combination of the likelihood of a business disruption occurring and the possible loss that may result from such business disruption. Examples are: a) CPU time or instructions b) disk I/Os c) print lines d) communication transactions. The phase within a business recovery plan which re-establishes normal operations. such as names and addresses or inventories. The identification and assessment of the level (measure) of the risks calculated from the assessed values of assets and the assessed levels of threats to. Used on some systems to describe swapping. A measure of the exposure to which an organisation may be subjected. used to record details of a request for a change to any CI within an infrastructure or to procedures and items associated with the infrastructure. which is indexed within the plan. or screen. Release Request for Change (RFC) Resolution Resource cost Resource profile Resource unit costs Resources Return to normal phase Risk Risk Analysis Risk Management Risk reduction measure Role Roll in roll out (RIRO) 101 . Resource units may be calculated on a standard cost basis to identify the expected (standard) cost for using a particular resource. activities and authorisations. Measures taken to reduce the likelihood or consequences of a business disruption occurring (as opposed to planning to recover after a disruption). Action which will resolve an Incident. selection and adoption of countermeasures justified by the identified risks to assets in terms of their potential impact upon services if failure occurs. The identification. software. This resource is usually expressed in seconds for the CPU or the number of I/Os for a disk or tape device.

Management of Services to meet the Customer's requirements. that documents agreed Service Levels for a Service. agreeing. The single point of contact within the IT organisation for users of IT services. Every Incident not being a failure in the IT Infrastructure. while it is waiting for the required data to come under the read/write heads (latency). Self-insurance Service Service achievement Service Catalogue Service Desk Service Improvement Programme Service Level Agreement Service Level Management Service Management Service provider Service quality plan Service Request Services Third-party organisation supplying services or products to customers. that are required and cost justified. the services do not consist merely of making computer resources available for customers to use. The process of defining. A formal project undertaken within an organisation to identify and introduce measurable improvements within a specified work area or work process. It can give extremely accurate results. Unfortunately. It describes the elapsed time taken to move heads to the right track. Written statement of IT services. The actual service levels delivered by the IT organisation to a customer within a defined life-span. It is most beneficial in extremely large or time-critical systems h th i f i ll Simulation modelling 102 . default levels and options. A decision to bear the losses that could result from a disruption to the business as opposed to taking insurance cover on the risk. The written plan and specification of internal targets designed to guarantee the agreed service levels. The deliverables of the IT Services organisation as perceived by the Customers. S Seek Time Occurs when the disk read/write heads are not positioned on the required track.Glossary of Terms Rotational Position Sensing A facility which is employed on most mainframes and some minicomputers. it demands a great deal of time and effort from the modeller. documenting and managing the levels of customer IT service. One or more IT systems which enable a business process. This facility usually improves the overall performance of the I/O subsystem. Written agreement between a service provider and the Customer(s). Using a program to simulate computer processing by describing in detail the path of a job or transaction. When a seek has been initiated the system can free the path from a disk drive to a controller for use by another disk drive.

A defined measurement unit that is used for storage type equipment to measure usage. A technique which uses standards for costs and revenues for the purposes of control through variance analysis. A pre-determined calculation of how much costs should be under specified working conditions. for the valuation of work in progress and for fixing selling prices. where there is not the requirement for full-time support staff. and for central processors it is based on the product of power and CPU-time. The advantages of such devices are that the service times are much faster than real disks since there is no seek time or latency. It is now rescued and put back into service. these include accommodation. It is built up from an assessment of the value of cost elements and correlates technical specifications and the quantification of materials. IT systems and networks. database management system. The main disadvantage is that they are much more expensive. Software Configuration Item (SCI) Software Environment Software used to support the application such as operating system. it is on a list of 'free' pages. labour and other costs to the prices and/or wages expected to apply during the period in which the standard cost is intended to be used. or geographical locations. A controlled collection of SCIs designated to keep those with like status and type together and distinctly segregated. In some organisations it is common to use 'expert' Users (commonly known as Super or Expert Users) to deal with first-line support problems and queries. Memory devices that are made to appear as if they are disk devices. compilers. and application software. operation and maintenance. The unit value equals the number of bytes stored. development tools. As 'Configuration Item'. Its main purposes are to provide bases for control through variance accounting. i. excluding hardware and services. Software work is a generic term devised to represent a common base on which all calculations for workload usage and IT resource capacity are then based. Specifies in detail what the customer wants (external) and what consequences this has for the service provider (internal) such as required resources and skills. telecommunications and sometimes people. but it is still actually in memory. A unit of software work for I/O type equipment equals the number of bytes transferred. Typically. This is typically in specific application areas.e. Arrangements to have available assets which have been identified as replacements should primary assets be unavailable following a business disruption. This valuable resource however needs to be carefully codi t d d tili d Software Library Software work unit Solid state devices Specsheet Standard cost Standard costing Stand-by arrangements Storage occupancy Super User 103 . to aid in development.Glossary of Terms Soft fault The situation in a virtual memory system when the operating system has detected that a page of code or data was due to be reused.

Costs distributed over individual component usage. typically a PC or workstation. accommodation. it can be assumed that. an online device such as a VDU or remote printer. A read from.Glossary of Terms Surcharging Surcharging is charging business users a premium rate for using resources at peak times. Calculated including depreciation. all real memory pages of an address space may be moved at one time from main storage to auxiliary storage). facilities and people. ICL C03. and planned renewal. Swapping System T Terminal emulation Software running on an intelligent device. The person who uses the service on a day-to-day basis. maintenance. Terminal I/O Third-party supplier Thrashing Total Cost Of Ownership Tree structures U Underpinning contract Unit costs A contract with an external supplier covering delivery of services that support the IT organisation in their delivery of services.000. One node is termed the root and is the starting point of all paths. An enterprise or group. It is the physical movement of an entire task (e. software. if a box of paper with 1000 sheets costs £10. external to the Customer's enterprise. In data structures. The reaction of the operating system to insufficient real memory: swapping occurs when too many tasks are perceived to be competing for limited resources. that provides a capability to satisfy a stated need or objective. A cost centre for the provision of support services to other cost centres. Urgency User Utility cost centre (UCC) 104 . other nodes termed leaves terminate the paths. A condition in a virtual storage system where an excessive proportion of CPU time is spent moving data between main and auxiliary storage. Similarly if a CPU costs £lm a year and it is used to process 1. then each sheet costs 1p. or a write to. An integrated composite that consists of one or more of the processes. a series of connected nodes without cycles. which allows that device to function as an interactive terminal connected to a host system. Examples of such emulation software includes IBM 3270 BSC or SNA. For example. staff costs. or Digital VT100. hardware.000 jobs that year. Measure of the business criticality of an Incident or Problem based on the impact and on the business needs of the Customer. each job costs on average £1. which provides services and/or products to that Customer's enterprise.g.

Workloads generally represent discrete business applications and can be further sub-divided into types of work (interactive. Variance analysis is an analysis of the factors that have caused the difference between the pre-determined standards and the actual results. A system that enhances the size of hard memory by adding an auxiliary storage layer residing on the hard disk. The lowest level of detail relevant to the customer. which could be exploited by threats. budgeted or standard cost and actual cost (or revenues). test or production. Workloads WORM (Device) 105 . Optical read only disks. Version Version Identifier Virtual memory system Virtual storage interrupt (VSI) Vulnerability A weakness of the system and its assets. either by a temporary fix or by a technique that means the Customer is not reliant on a particular aspect of the service that is known to have a problem. A version number. timesharing. An ICL VME term for a page fault. An identified instance of a Configuration Item within a product breakdown structure or configuration structure for the purpose of tracking and auditing change history. Also used for software Configuration Items to define a specific identification released in development for drafting. In the context of Capacity Management Modelling. Variances can be developed specifically related to the operations carried out in addition to those mentioned above. review or modification.Glossary of Terms V Variance analysis A variance is the difference between planned. standing for Write Once Read Many. version date. W Warm stand-by Waterline Work-around See 'Intermediate Recovery'. a set of forecasts which detail the estimated resource usage over an agreed planning horizon. or version date and time stamp. batch). Method of avoiding an Incident or Problem.

106 .

Sign up to vote on this title
UsefulNot useful