itil v2 release and control (iprc) full certification online learning and study book course - the...

ITIL Practitioner: Release and Control (IPRC) Complete Certification Kit

Second Edition

ITIL® V2 Practitioner: Release and Control (IPRC) Complete Certification Kit – Second Edition

Copyright The Art of Service

Brisbane, Australia │ Email: [email protected] │Web: http://theartofservice.com │eLearning: http://theartofservice.org │Phone: +61 (0)7 3252 2055 2

ITIL Practitioner: Release and Control (IPRC) Complete Certification Kit– Second Edition Copyright © Notice of rights All rights reserved. No part of this book may be reproduced or transmitted in any form by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher. Notice of Liability The information in this book is distributed on an “as is” basis without warranty. While every precaution has been taken in the preparation of the book, neither the author nor the publisher shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the instructions contained in this book or by the products described in it. Trademarks Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations appear as requested by the owner of the trademark. All other product names and services identified throughout this book are used in editorial fashion only and for the benefit of such companies with no intention of infringement of the trademark. No such use, or the use of any trade name, is intended to convey endorsement or other affiliation with this book.

ITIL® V2 Practitioner: Release and Control (IPRC) Certification Kit – Second Edition



Write a review to receive any free eBook from our Catalogue - $99 Value! If you recently bought this book, we would love to hear from you! Benefit from receiving a free eBook from our catalogue at http://www.emereo.org/ if you write a review on Amazon (or the online store where you purchased this book) about your last purchase! How does it work? To post a review on Amazon, just log in to your account and click on the Create your own review button (under Customer Reviews) of the relevant product page. You can find examples of product reviews in Amazon. If you purchased from another online store, simply follow their procedures. What happens when I submit my review? Once you have submitted your review, send us an email at [email protected] with the link to your review, and the eBook you would like as our thank you from http://www.emereo.org/. Pick any book you like from the catalogue, up to $99 RRP. You will receive an email with your eBook as download link. It is that simple!

http://www.emereo.org/

mailto:[email protected]?subject=Free%20eBook%20for%20my%20review

http://www.emereo.org/




Table of Contents

Table of Contents ......................................................................................................................... 4 Foreword ...................................................................................................................................... 6 1. How to access the eLearning Program.................................................................................. 7 2. Workbook Overview .............................................................................................................. 8 3. Introduction ............................................................................................................................ 9

The IT Infrastructure Library ................................................................................................................. 9

Restructuring the IT Infrastructure Library .......................................................................................... 10

Target audience ................................................................................................................................. 11

Who is a practitioner? ........................................................................................................................ 11

4. The IT Infrastructure Library (ITIL) ...................................................................................... 12

Why Service Management? ............................................................................................................... 13

Benefits of Service Management ........................................................................................................ 13

The Functionally Oriented Organization ............................................................................................. 14

The Process Driven Organization ....................................................................................................... 15

5. IT Service Management (ITSM) Focus ................................................................................ 16

The Four Perspectives ....................................................................................................................... 16

The Objective Tree............................................................................................................................. 17

Change and Continuous Improvement ............................................................................................... 18

6. Release & Control Implementation ...................................................................................... 19

Dealing with learning and change ...................................................................................................... 23

7. Release Management ......................................................................................................... 25

Release Management Concepts ........................................................................................................ 25

Release – Policy & Planning .............................................................................................................. 26

Release Types ................................................................................................................................... 28

Definitive Software Library (DSL) ....................................................................................................... 29

Definitive Hardware Store (DHS) ........................................................................................................ 29

Configuration Management Database ................................................................................................ 30

Release – Build, test and back-out plans ........................................................................................... 31

Release Management benefits ........................................................................................................... 31

Planning ............................................................................................................................................. 33

Implementation .................................................................................................................................. 35

Activities of the Release Management Process .................................................................................. 37

8. Change Management .......................................................................................................... 43

Release and Control processes ......................................................................................................... 43

Change Management Concepts ......................................................................................................... 45

Activities of the Change Management Process .................................................................................. 50

Planning and Implementation of the Change Management process. .................................................. 60




Change Management Procedures ...................................................................................................... 62

9. Configuration Management ................................................................................................. 64

Configuration Management Concepts................................................................................................. 65

Configuration Management Database ................................................................................................ 69

Planning and Implementation ............................................................................................................. 72

Activities for Configuration Management ............................................................................................ 77

Process Control for Configuration Management ................................................................................. 85

10. Relationships – Release and Control Processes ............................................................. 87

Configuration Management ................................................................................................................ 87

Change Management ......................................................................................................................... 88

Release Management ........................................................................................................................ 88

Release and Control Support Tools .................................................................................................... 91

Process Organization and Design ...................................................................................................... 93

11. Answers ........................................................................................................................... 97 12. Glossary ........................................................................................................................... 98




Foreword

As an education and training organization within the IT Service Management (ITSM) industry, we have watched with enthusiasm as the ITIL framework has grown and progressed since its conception in the 1980s. The evolution of the core principles and practices provided by the standard provides the holistic guidance needed for an industry that continues to mature and develop at a rapid pace. Our primary goal is to provide the quality education and support materials needed to enable the understanding and application of the ITIL version 2 framework in a wide-range of contexts. This comprehensive book is designed to complement the in-depth accredited eLearn ITIL v2 Release & Control Practitioner program provided by The Art of Service. The interactive eLearn-ing program uses a combination of narrated PowerPoint presentations, with mandatory assign-ments, which will ultimately prepare you for the ITIL v2 Release & Control Practitioner certification exam. We hope you find this book to be a useful tool in your educational library and wish you well in you IT Service Management career! The Art of Service © The Art of Service Pty Ltd „All of the information in this document is subject to copyright. No part of this document may in any form or by any means (whether electronic or mechanical or otherwise) be copied, reproduced, stored in a retrieval system, transmitted or provided to any other person without the prior written permission of The Art of Service Pty Ltd, who owns the copyright.‟ ITIL® is a Registered Community Trade Mark of OGC (Office of Government Commerce, London, UK), and is Registered in the U.S. Patent and Trademark Office.




1. How to access the eLearning Program

1. Direct your browser to: www.theartofservice.org 2. Click „login‟ (found at the top right of the page) 3. Click „Create New Account‟ 4. Follow the instructions to create a new account. You will need a valid email address to

confirm your account creation. If you do not receive the confirmation email check that it has not been automatically moved to a Junk Mail or Spam folder.

5. Once your account has been confirmed, email your User-ID for your new account to:

[email protected]

6. You will receive a return email with an enrolment key that you will need to use in order to access the eLearning program. Next time you login to the site, you will need to access the program associated with this study guide and enter the enrolment key that was sent to you.

7. If you have any difficulties using the program or enrolling please email [email protected]

Minimum system requirements for accessing the eLearning Program:

Processor : Pentium 4 (1 GHz) or higher

RAM : 256MB (512 MB recommended)

OS : Windows XP, Vista, MCE, Mac OSX

Browser : Macromedia Firefox 3+ (recommended), Internet Explorer 6.x or higher, Safari, Opera, Chrome, all with cookies and JavaScript enabled.

Plug-Ins : Macromedia Flash Player 8 or higher

Internet Connection

: Due to multimedia content of the site, a minimum connection speed of 512kbs is recommended. If you are behind a firewall and are facing problems in ac-cessing the course or the learning portal, please contact your network adminis-trator for help

If you are experiencing difficulties with the Flash Presentations within the eLearning Programs please make sure that: 1) You have the latest version of Flash Player installed, by visiting 2) You check that your security settings in your web browser do not prevent these flash mod-ules playing. 3) For users of Internet Explorer 7 a solution involves DESELECTING "Allow active content to run files on my computer" in Internet Explorer -->Tools, Options, Advanced, Security settings.

http://www.theartofservice.org/

mailto:[email protected]

mailto:[email protected]




2. Overview

To ensure quality and consistency of the services provided to their customers, IT departments must control their infrastructure and manage how and when changes are made. This can be achieved by effectively implementing the Release and Control processes within an IT infrastruc-ture. In this book, you learn how to plan, implement and optimize the Change Management, Release Management and Configuration Management processes. In conjunction with the classroom course or eLearning, you gain the skills necessary to successfully take the ITIL Practitioner Release and Control Certification Exam.

Audience

This course is valuable for managers, supervisors, team leaders and operational staff who participate in managing, organizing and optimizing the Change, Release and Configuration Management processes. The Foundation Certificate in IT Service Management is required to take the IPRC Certification Exam.

Skills Gained

Prepare for and take the ITIL Practitioner Release and Control (IPRC) Certification Exam Plan key activities for Change Management, Release Management and Configuration

Management Define the monitoring and reporting of key performance indicators and achievements Propose continuous improvements for the Release and Control processes Organize the relationships between the Release and Control processes Monitor and optimize the Release and Control processes

Prerequisites

ITIL knowledge at ITIL Foundation Certification level is assumed. The Foundation Certificate in IT Service Management is required to take the IPRC Certification Exam.

Examinations

ITIL Practitioner Release and Control Certification Exam.




3. Introduction

The IT Infrastructure Library

The IT Infrastructure Library (ITIL) was developed in the late 1980s as a guide for the UK government. It has now become the worldwide standard in Service Management. The frame-work has proved useful to organizations in all sectors through its adoption by many Service Management companies as the basis for consultancy, education and software tools support. Today, ITIL is known and used worldwide.

Public domain framework

From the beginning, ITIL has been publicly available. This means that any organization can use the framework described by the CCTA in its numerous books. Because of this, the IT Infrastruc-ture Library guidance has been used by such a disparate range of organizations, local and central government, energy, public utilities, retail, finance, and manufacturing. Very large organ-izations, very small organizations and everything in between have implemented ITIL processes.

Best practice framework

The IT Infrastructure Library documents best practice guidance. It has proved its value from the very beginning. Initially, CCTA collected information on how various organizations addressed Service Management, analyzed this and filtered those issues that would prove useful to CCTA and to its Customers in UK central government. Other organizations found that the guidance was generally applicable and markets outside of government were very soon created by the service industry. Being a framework, ITIL describes the contours of organizing Service Management. The mod-els show the goals, general activities, inputs and outputs of the various processes, which can be incorporates within IT organizations. ITIL does not cast in stone every action you should do on a day-to-day basis because that is something which will differ from organization to organiza-tion. Instead it focuses on best practice that can be utilized in different ways according to need. Thanks to this framework of proven best practices, the IT Infrastructure Library can be used within organizations with existing methods and activities in Service Management. Using ITIL doesn‟t imply a completely new way of thinking and acting. It provides a framework in which to place existing methods and activities in a structured context. By emphasizing the relationships between the processes, any lack of communication and cooperation between various IT func-tions can be eliminated or minimized. ITIL provides a proven method for planning common processes, roles and activities with appro-priate reference to each other and how the communication lines should exist between them.

De facto standard

By the mid-1990s, ITIL was recognized as the world de facto standard for Service Management. A major advantage of a generally recognized method is a common language. The books de-scribe a large number of terms that, when used correctly, can help people to understand each other within IT organizations. An important part of IT Infrastructure Library projects is getting people to speak the language. That is why education is the essential basis of an implementation or improvement program. Only when the people involved use a common language can a project be successful.




Quality Approach

In the past, many IT organizations were internally focused and concentrated on technical issues. These days, businesses have high expectations towards the quality of services and these expectations change with time. This means that for IT organizations to live up to these expectations, they need to concentrate on service quality and a more customer oriented ap-proach. Cost issues are now high on the agenda as is the development of a more businesslike attitude to provision of service. ITIL focuses on high quality services with a particular focus on customer relationships. This means that the IT organization should provide whatever is agreed with customers, which im-plies a strong relationship between the IT organization and their customers and partners. Tactical processes are centered on the relationships between the IT organization and their customers. Service Delivery is partially concerned with setting up agreements and monitoring the targets within these agreements. Meanwhile, on the operational level, the Service Support processes can be viewed as delivering service as laid down in these agreements. On both levels you will find a strong relationship with quality systems such as ISO9000 and a total quality framework such as European Foundation for Quality Management (EFQM). ITIL will support these quality systems by providing defined processes and best practice for the man-agement of IT Services, enabling a fast track towards ISO certification. General benefits of quality management include:

Improved quality service provision

Cost-justifiable service quality

Services that meet business, customer and user demands

Integrated centralized processes

Everyone knows their role and knows their responsibilities in service provision

Learning from previous experience

Demonstrable performance indicators.

itSMF

The itSMF (IT Service Management Forum) was set up to support and influence the IT Service Management industry. It has through its very large membership been influential in promoting industry best practice and driving updates to ITIL.

Restructuring the IT Infrastructure Library

The concept of managing IT services for the improvement of business functions is not new; it predeates ITIL. The idea to bring all of the Service Management best practice together under one roof however was both radical and new. The first series of ITIL amalgamated Service Management from an IT standpoint but could have done more to capture the interest of the business. The business perspective series was published to bridge the gap between business and management and although a success, the series was published at a time when the original ITIL guidance was becoming outdated in some areas. The impact of the new series was there-fore limited in the market, but a catalyst in the Service Management industry. ITIL was originally produced in the late 1980s and consisted of ten core books covering the two main areas of Service Support and Service Delivery. These core books were further supported by 30 complimentary books covering a range of issues from Cabling to Business Continuity Management. In this revision, ITIL has been restructured to make it simpler to access the information needed to manage your services. The core books have now been pulled together




into two books, covering the areas of Service Support and Service Delivery, in order to elimi-nate duplication and enhance navigation. The material has also been updated and revised for consistency and sharpness of focus. Lastly, the material has been reengineered to focus on the business issues of infrastructure management as well as to ensure a closer synergy with the new IS guides published by CCTA.

Target audience

This book is relevant to anyone involved in the delivery or support of services. It is applicable to anyone involved in the management or day-to-day practice of Service Management, in-house or outsourced, as well as anyone defining new processes or refining existing processes. Business managers will find the book helpful in understanding and establishing best practice IT services and support. Managers from supplier organizations will also find this book relevant when setting up agreements for the delivery and support of services.

Who is a practitioner?

Someone who:

Knows how to manage processes

Is able to execute, organize and monitor the activities of the process

Understands how processes can be improved

Recognizes/overcomes difficulties.




4. The IT Infrastructure Library (ITIL)

There are eight core components (books) of the ITIL Framework. These books combine to form a natural bridge between The Business and The Technology the business uses to achieve its objectives. The core set of material is the following set of tightly coupled areas:

Service Delivery

Service Support

Security Management

Business Perspective: The IS View on Delivering Services to the Business (Vol I)

Applications Management

ICT Infrastructure Management

Planning to implement Service Management

Software Asset Management.




Why Service Management?

Businesses are now more dependent on IT

The complexity of technology has increased

Customers are demanding more

Environment is becoming more competitive

The focus is on controlling the costs of IT

To improve customer satisfaction

Some IT organizations are losing credibility.

Benefits of Service Management

Improved quality of service – more reliable business support

IT Service continuity procedures more focused, more confidence in the ability to follow them when required

Clearer view of current IT capability

Better information on current services (and possible one where changes would bring most benefits)

Greater flexibility for the business through improved understanding of IT support

More motivated staff, improved job satisfaction through better understanding of capability and better management of expectations

Enhanced customer satisfaction as service providers know and deliver what is expected of them

Increased flexibility and adaptability is likely to exist within the services

System-led benefits, e.g. improvements in security, accuracy, speed, availability as re-quired for the required level of service

Improved cycle time for changes and greater success rate. The requirement to look at the provision of IT Services in a professional way is driven by a variety of factors. Organizations understand the benefits of having Information Technology (IT) throughout their structure. However, few realize the potential of truly aligning the IT department‟s objectives with the business objectives. Most organizations are beginning to recognize IT as being a crucial delivery mechanism of services to their customers. The starting point for IT Service Management (ITSM) and the ITIL Framework is not the tech-nology, not the processes; it is the organizational objectives.




The Functionally Oriented Organization

Most businesses are arranged hierarchically. They have departments, which are responsible for a group of employees. There are various ways of structuring departments, for example by customer, product, region or discipline. Quick Question In this type of arrangement, we often see that: (Select one of the following) a) Communication is ineffective b) Inter department activities are clearly defined c) Processes are optimized to reduce duplication of effort




The Process Driven Organization

A process is a logically related series of activities for the benefit of a defined objective. This slide illustrates cross-functional process flows. Quick Question Can the concept of processes “linking” functional areas together apply to business departments as equally as it can to IT functional areas? YES/NO Four key activities or concepts with processes: 1. Inputs 2. Outputs 3. Goals 4. Monitoring




5. IT Service Management (ITSM) Focus

The Four Perspectives

There are four perspectives to explain the concept of ITSM. Organization Perspective Involved with alignment of the vision, strategy, goals of the day-to-day activities in IT. The organizational perspective (the issue ensures that we align the vision, strategy and goals of the business with the delivery of IT services. People Perspective Concerned with the “soft” side: IT staff, customers, & effective management of external suppli-ers. The people issue is without doubt where we – as IT Service Management professionals face our greatest challenges. Technology Perspective Takes into account hardware & software, budgets, tools. Historically, the technology considera-tions got most attention. Now we understand that without well-defined processes we can often make inappropriate selections in this area. Process Perspective Relates the end-to-end delivery of service-based on-process flows. More and more people see the importance of processes (the primary purpose of this program is studying some of these in detail).




The Objective Tree

If we accept that the objectives are the starting point for the provision of IT Services, how can we position the delivery of services and the utilization of the ITIL Framework? The objective tree is a very powerful tool, not only because it shows the benefit and alignment of IT and Service Management principals, but also in being able to effectively sell the concepts to busi-nesses. See if you can follow along in the following para-graphs and match the sentences to the above objective tree. To meet organizational objectives, the organization has business processes in place. Examples of business processes are sales, admin and financial departments working together in a “sales process” or logistics, customer service and freight who have a “customer returns process”.

Each of the units involved in these business processes needs one or more services (e.g. CRM application, e-mail, word processing, financial tools). Each of these services runs on IT infrastructure. IT Infrastructure includes hardware, software, procedures, policies, documentation, etc. This IT Infrastructure has to be managed. ITIL pro-vides a framework for the management of IT Infrastructure. Proper management of IT Infrastructure will ensure that the services required by the business processes are available, so that the organizational objectives can be met.




Change and Continuous Improvement

The Deming Cycle

This model is the work of Dr Edwards Deming, an American statistician whose theories were a major contributor to the Japanese economic revival in the post-World War 2 period. His ideas regarding design improvement, product quality, testing and sales led to many Japanese suc-cesses, including the growth and domination of their automobile industry. “We have learned to live in a world of mistakes and defective products as if they were neces-sary to life. It is time to adopt a new philosophy...” W. Edwards Deming (1900-1993) The four key stages of the Deming Cycle are plan, do, check and act, after which a consolida-tion phase prevents the „circle‟ from rolling down the hill, as shown above. This consolidation phase enables the organization to take stock of what has been taking place and to ensure that improvements are properly embedded.




6. Release & Control Implementation

Process improvement model

© Crown Copyright 2007 Reproduced under license from OGC

Where do we want to be?

To impress stakeholders (e.g. customers, investors, personnel) your organization will have to communicate the „vision‟ and why they should do business with you, e.g. because you are the cheapest, the most reliable etc. The vision can be communicated in the form of a mission statement (see slide). The mission statement should be a short, concise description of the objectives of the organization and the values it believes in. A vision statement will address the following:

Ensure all have a common understanding of the “direction”.

Encourage all to take actions that promote the “direction”.

Draw together the actions of many.

Act as a summary for senior management As a check to ensure that the vision is suitable, you should be able to answer “yes” to the following: Can I outline the vision within 5 minutes? If asked can I explain to each stakeholder “what is in it for them?”

Next – is there a business case?

What risks do we face?

What gaps have to be bridged?




The “GQM” paradigm

Tools assessment. The most important question that needs answering is whether the “initiative” or adoption of a CSIP (Continuous Service Improvement Program) will deliver sufficient revenue/savings to justify the expense. The principle challenge is that much of the benefit cannot be quantified (e.g. quality, flexibility, service satisfaction). Concerning Risk Management, we must remember that this initiative is not the only one com-peting for organizational budget. What is the effect on other initiatives if this IT initiative is successful at attracting funds? In addition, what risks will be faced after the program has be-gun? The salient point is that risks will always be present, so do not attempt to eliminate them – simply get to understand them. The gap analysis is generally an opportunity to use “scores” to measure current and future expected levels of maturity. For example, a five level model of maturity is defined in the OGC “Planning to Implement Service Management” text (Initial, Repeatable, Defined, Managed, and Optimized).

Where are we now?

A „health check‟ based on the current procedures can be used as an objective way of assessing the effectiveness of Service Management Processes in an organization. This assessment should aim to identify those areas running well, determine which best practices are in current use and should be retained, and pinpoint problems or constraints. This can be carried out as „self-assessment‟ as well as commercially available solutions. Health checks also determine the maturity of your organization. This is important if your target is better IT and business alignment.

How will we get there?

Starting point determined by maturity

Awareness campaign

Managing organizational change

Cultural change

Roles & Responsibilities

Education

Tools. The starting point should not be determined on the emotions or “feelings” of an individual. The starting point will be a combination of current maturity levels of the IT organization, the IT processes as well as overall organization priorities, IT “pain points”, process interdependencies (e.g. you cannot have Problem without Incident Management) and other factors (including budget, available resources and current workloads). The most important aspect of the communication plan is that it needs to be ongoing and not just given enthusiastic support at the outset of the CSIP initiative. Under the banner of managing organizational change, it simply is not enough to get a group of people together that have project management and ITIL skills and experience. There is a multitude of issues that have to




be considered and addressed (including resistance, gaining and keeping commitment, involve-ment and communication). Cultural change is largely reflected in the leadership/management style that is prevalent in the organization. Remember that some organizations suit dominant leadership styles (e.g. Regi-mented organizations such as military units). Careful role definition is required (see later section on using the ARCI model), especially when considering the allocation of new activities to exist-ing staff (overload) or the conflict that could arise when processes are implemented across traditional hierarchical models. As people are an integral part of the CSIP, there is a need to provide appropriate levels of education: the critical element being timing of delivery. All too often we see education programs delivered only to witness a lack of follow up activity that gives the participant an opportunity to put the theory into practice. Finally, tools. The raging debate is which comes first: tools or processes? In reality, most organizations have a variety of IT Service Management tools already. It is not the place of this program to suggest that existing tools are a wasted investment; however, the commonly ac-cepted principle is that the processes should be supported by the tools and not the other way around.

How do we know when we’ve arrived?

Critical Success Factors (CSFs)

Key Performance Indicators (KPIs)

Organizational drivers o Delivering the business wish list.

We need to use measures and metrics to help us determine a “point of acceptance” with regard to process improvements and progress of the CSIP. CSFs are quite simply the things that we have to be able to do. They tell us in qualitative terms the basic objective for a process (e.g. the CSFs for Change Management can be (a) a repeata-ble change process, (b) ability to deliver change quickly, (c) deliver organizational benefits via change management). KPIs can be considered the quantitative elements of a process that give us a guide to the process efficiency (e.g. the KPIs for Change Management can be (a) the number of rejected RFCs, (b) the size of the change backlog, (c) quantity of changes delivered according to RFC schedule). Note that there are generally a lot more KPIs than CSFs for a given process. Organizational drivers are the points raised by “business people” as their “wish list” for the IT department. There have been many surveys conducted over many years, but the essence of what business people want from their IT departments can be condensed into several points. These include support business operation, facilitate delivery of electronic services, help to deliver business strategies, enable change to match pace with required business change.

How do we keep going?

Deliver quick wins

Encourage a sense of “Process? Yes - that is the way it‟s done around here”

Ongoing monitoring and reviews




Revisit the “vision”

Manage knowledge base. Elements derived from the OGC – Planning to Implement Service Management Quick wins should be used to help drive more change that is medium to long-term. Also, consider what your legacy of change will be. Consider in 10 years time when all current staff have moved on or been replaced. When asked why certain activities are carried out the way they are – what will be the response? “That is the way it‟s done around here.” Perhaps that could be considered a good legacy, if part of “the way it‟s done around here” involves continual monitoring and reviews. The real essence of a CSIP is the first word of the acronym. Continuous! The way to create continuity is to go back to the start and begin again. Remember it begins with the VISION. The vision must essentially promote business and IT alignment. Knowledge management is another way to ensure the legacy of the work you do is not lost. The rate of change, staff turnover, expectations of performance and market place competition are all heading in an upwards direction. With these trends, the organization cannot afford to retain knowledge and learn from previous mistakes and lessons. The CSIP must include in its overall design elements consideration for the gathering, organizing and accessibility of da-ta/information/knowledge.

A follow up point - KPIs

If you don‟t measure it, you can‟t manage it.

If you don‟t measure it, you can‟t improve it.

If you don‟t measure it, you probably don‟t care.

If you can‟t influence it, then don‟t measure it. The importance of Key Performance Indicators (KPIs) is further enhanced by this quotation from the OGC ITIL Service Delivery Book (Availability Management). While it is specifically men-tioned in Availability Management, the message is applicable to all process areas. KPIs for:

Release

Change

Configuration.




Dealing with learning and change

Model from Elizabeth Kubler-Ross

This is a useful concept from Elizabeth Kubler-Ross. Human beings are generally predictable. When faced with change most of us go through a series of emotions as reflected in the above diagram. Perhaps you can even relate this diagram to yourself. Implementing ITIL Service Management is about going through changes. The key point is that these emotions are a natural response and they cannot be bypassed. Awareness and educa-tion prepare people for the resistance that everybody will feel. Goal: The goal of Release Management is to conduct management and distribution of software and hardware versions in use, which are required to provide IT services in order to comply with agreed levels of service. Release Management controls the actual “doing” of the change. (The actual rollout, and the associated work leading up to the rollout). Why do we have Release Management? How does it differ from Change Management?




Scope: Planning, designing, building, configuration and testing of hardware and software to create a set of Release components for a live environment. The Release Management process is often thought of as a “doing” process. However, we need to remember that the process is controlling the doing work, not actually doing the work itself. The actual “doing” work is carried out by people with specific and relevant skills. The process activities coordinate the planning, preparation and scheduling of a release to a live environment.




7. Release Management

Release Management Concepts

Release definition (& identification)

Release Policy & Planning

Release unit

Release Types (full, delta, package)

DSL

DHS

CMDB

Build, Test, Back-out plans. Release - Definition

A collection of authorized changes to an IT Service

Defined by the RFCs that “it” implements Release - Identification Typically, releases are identified as:

Major software releases and hardware upgrades

Minor software release and hardware upgrades

Emergency software and hardware fixes. Major Release – important roll out of software and / or hardware. This would be a large-scale upgrade to your infrastructure or a critical IT Service. Minor Release – minor patches, fixes, or small improvements resulting from the incident / problem processes. Emergency Fix – Be careful with this one. People tend to use Emergency Fixes and Emergency Changes as an excuse to fast track releases. All environments need to be careful about this.




Release – Policy & Planning

Contents of the Policy

Release numbering and naming conventions

Definition of major and minor releases

Direction on the frequency of major and minor Releases

ID of business critical times to avoid for implementations

Expected deliverables for each type of Release

Guidance as to how and where Releases should be documented

The policy on the production and degree of testing of back-out plans

The agreed role

A description of the control process. The policy establishes the rules for the process. The policy is typically presented as a document that will define the (unique) numbering of releases, as well as the allowable frequency and times that are permitted by the business. There may be one document per organization, or an umbrella set of guidelines for each supported system or IT service. Finally, the level to which releases need to be managed will be defined in the Release Policy. For example, it may be decided that controlled releases are not required for printers.




The portion of the IT Infrastructure that is normally released together.

The key word in this ITIL definition is “normally”. ITIL always allows room for exceptions. In the diagram, we can see that the release unit could be defined at a Module, Program, Suite or System level. If we decide on a system level release unit, we need to understand the impact on all the individual components. The important point to remember here is that you can select different release units for different elements of the infrastructure. The decision on release units will be dependent on a variety of factors. Considerations relating to resource requirements, complexity of interfaces, ease of implementation, availability of test environments, etc. will all have an impact on the decision.




Release Types

Quick Question If deploying a Standard Operating Environment (SOE) containing the operating system and several applications and various patches, is it a delta, full or package release? Answer: The concept of different release types helps IT Service Management professional ensure that software and hardware is released in “logical bundles” (referred to as “release units”). Delta Release = release of only the changed items (error solution (“quick fix”) Full Release = release of the full program (including the parts that have not been changed) Package Release = bundled release of multiple changes (multiple error solutions, new/added functionalities)




Definitive Software Library (DSL)

A secure compound where definitive authorized versions of all software CIs are stored and protected. “Secure” allows us to see that the software needs to be protected. The compound can be a physical and electronic storage area. “Definitive” means ultimate, perfect, best. By this, we can see that the DSL must hold the „good‟ version of any software that is installed. “All software” reminds us that as service management professionals we are interested in all the software that is used to deliver the services that we provide. The Definitive Software Library is a physical repository for your authorized versions of Software. It stores all physical copies of your software, past and present. It can also hold software that has not been released, including:

storage of software items

installation scripts

images

firmware

manuals

block diagrams

development specifications Quick Question If the DSL holds the “actual” software, where do we store information about the software? Answer:

Managing the DSL

It contains:

Agreed versions of software including source codes, objects, executables, etc. including the related documentation.

Authorized master software, without unauthorized additions o Licenses are paid

Physical storage of up-to-date and undamaged storage media o Disk, tape, CD…

Approval by Change Management o Registration in CMDB

It is fully separated from the development, testing and production environment. What are the challenges involved in the DSL? How do I manage more than one DSL? What is the relationship to Change Management and Configuration Management?

Definitive Hardware Store (DHS)




The DHS is a secure physical storage area for spare infrastructure hardware. Items in the DHS should be referenced in the Configuration Management Database (CMDB). Quick Question If the DHS holds “actual” hardware, which process can utilize the actual equipment held there? Answer:

Managing the DHS

It contains:

physical storage of agreed hardware o stock spare parts including the related documentation o stock basic configurations including the related documentation

authorized master hardware, without unauthorized additions o maintenance fees are paid

fully separated from the development, testing and production environment

approval by Change Management o registration in CMDB

What are the challenges involved in the DHS? How do I manage more than one DHS? What is the relationship to Change Management and Configuration Management?

Configuration Management Database

Updates to the CMDB will match updates to the DSL & DHS

Information about o Definitions of a release & links to originating RFC o CIs that will be affected by a release o Information about targets for a release.

(CI = Configuration Item) We store “information” in the CMDB. Therefore, it is clear that as we make changes to the DSL and DHS we need to make changes to the CMDB. The CMDB must be able to be interrogated to learn what RFC is driving the release activity, what will actually be released, what CIs will be indirectly affected by the release and what actual CIs will be replaced/modified/updated, etc.




Release – Build, test and back-out plans

Build o reproducible, often automated

Test o functional, operational, performance integration,

Back-out plans o complete reversal o contingency.

When building a release we want to do it in such a way that will provide consistent results. In a software sense, we often rely on tools to “package” up a set of software components into a single executable file that can then be distributed. When considering the testing of releases (both hardware and software) we need to consider a variety of areas – importantly the functional testing must come from those that understand and utilize the functions of a service (typically these are end-users). Back-out plans can be provided in two primary methods. The complete reversal is a strategy of returning to our “pre-release” state, whereas a contingency back-out reflects the reality that often a complete back-out is not practical, so we need to have an alternative path to follow.

Release Management benefits

Quality of hardware & software in the correct version(s) under supervision of Change Management

Minimal chance of errors in combinations of hardware and software (stable environments)

Virus free and bona fide software

Detection of wrong versions and/or unauthorized copies

Fewer releases

Management of distribution: less risk of incidents This list represents a summary of the many advantages of a well-implemented and managed Release Management process. The OGC Service Support text lists many benefits, but overall the process allows organizations to deal with the increasing requirement for more releases without compromising the quality of existing service provision. It is important to note that the benefits cannot be delivered in isola-tion. Benefits can only be derived when all the Release & Control processes are working.




Points of attention

Resistance from personnel regarding the new way of working

Resistance from development staff

Time pressure with urgent fixes (bypassing)

Testing: ensure an optimally equipped test environment

Awareness: IT management may find Release Management bureaucratic and expensive

Out of sync installations (distributed sites). It is naïve to suggest that any implementation of a new process will not be faced with some challenges. The above list provides a summary of the possible problems that could be encoun-tered.




Planning

Release Policy

One per organization (or umbrella set of guidelines)

Provide guidance on planning releases

Release naming, conventions, frequency

Business critical periods to avoid

Expected release deliverables

Expected standards (documentation, etc)

Producing back out plans

Managing the DSL & DHS

Urgent changes and releases. Ideally, an organization would have just one Release Policy and this may be accompanied by a series of underpinning guidelines. Like most policies, this should be developed in consultation with other ITSM process managers and stakeholders to avoid duplication and generate buy-in. The policy establishes the rules for the process.

Release and rollout planning procedures

Plan procedures, guidance & templates

Inputs: o Current organizational standards o SLAs and OLAs o Platform specific release building procedures o Training requirements o Licensing and support agreements o Disposal procedures o Security policies and guidelines.

The creation of procedures is often treated as an “un-required task”. However, while all existing staff may have a sound understanding of how certain activities are carried out, we need proce-dures to help formalize and develop a common understanding. Quite often when a procedure is written two people working together on the same tasks, will disagree over the procedure itself. If such a situation occurs then new staff can often be confused when starting. Having an agreed upon procedure will help to eliminate ambiguity and provide a consistent approach for all staff. Procedures, templates & guidance should be planned to enable the central release manage-ment staff to take products from application groups and projects and then to release the soft-ware and hardware effectively and efficiently. There are a series of inputs, procedures and documents that are required to plan the Release and rollout procedures.




Release and distribution procedures

Hardware

Software o Moving from test to live environments o Archiving previous live versions o Backup live data o Consider geographical spread of sites o Minimize number of dependent steps and staff.

Release procedures should be made as simple as possible and involve the least number of staff possible. Rollback procedures should also be simple, which will reduce downtime should rollback be required.

Release and distribution procedures

Updating the CMDB

Rollback plan testing

Release verification

Communication plans & protocols.

Roles and responsibilities

Change manager

Release Manager

Test Manager

Other „functional‟ managers (not part of the process).

Staffing

Critical for access to live environment

Enough trained staff to cover absences

Sound technical background

Awareness of Change and Configuration Management

Knowledge of business (to set priorities). Because Release Management is on the critical path between application development and live operations, and is involved in all-important Changes to live systems, there should be enough trained staff to cater for all aspects of the process AND to cover for absences. Release Managers require a solid technical background, with a good understanding (or an ability to get it) of the IT infrastructure and the services it provides. A good working knowledge of support tools and utilities, and a good grasp of the ITSM principles and practices are essen-tial. A good knowledge of the business assists in (helping to) set priorities.




Training

Technical o Software maintenance and development o Support tools and utilities

Process o Change, Configuration, Release o Release Policy, procedures, tools

Organizational o Business Issues

End-users

Release staff. Typically, the technical training requirements are met well. However, there is a variety of train-ing requirements that cover staff from both IT and non-IT. Remember that one of the primary benefits from training is an “appreciation” of how others will be affected by actions you take. So this is why discussing organizational issues becomes a critical component of the overall training program.

Implementation

Software Release and distribution

Build DSL & build environment(s)

Migrate current live software into the DSL and inform Configuration Management (CMDB)

Test management & software distribution

Allow remediation time. Once the DSL and build environments are available, ensure the necessary security permissions are in place. Application Development staff should be told when to start delivering Release material for inclusion in the DSL and arrangements should be made for all bought-in software to be deli-vered to Release Management for lodging in the DSL and passed to Configuration Manage-ment for recording in the CMDB. Although the procedures should be thoroughly tested before being brought into live use, time should be allowed to resolve any teething problems in the early stages of live use.

To ensure proper adoption, the Release Manager should: o Champion new processes o Monitor uptake and performance o Report exceptions to policy o Automate Release procedures o Ensure staff are thoroughly trained.




Once the Release Management process has been implemented, the Release Manager will need to maintain the momentum so the benefits are realized as quickly as possible.

Costs

Development

Education

Staff (operate tools, distribution)

Storage

Spares

Tools.

Documentation

Initial Business Justification

Release Management Implementation Plan

Release Policy

Release Procedures Handbook o DHS and DSL Library Documents o Release Review Results

Release Business Management Reports. Throughout the planning, design, implementation and review of the Release Management Process, a series of different documentation will be generated. During the planning, design and implementation stages, an initial business case and implemen-tation plan would be delivered as part of any project management framework (e.g. PRINCE2). Once established, the organization‟s Release Management Policy and Procedures Handbook would be employed to ensure that the day-to-day operational activities of release management meet the agreed objectives. Release Business Management Reports provide the organization with the ability to assess the effectiveness and efficiency of the release management process against its agreed objectives. This provides an opportunity not only to identify and address issues, but also to highlight its positive contribution to maintaining a stable production environment.




Activities of the Release Management Process

Release planning

Define the “who, how and when”

Back-out plans

Plan acceptance requirements

Supplier quotes, negotiations

Site surveys. Release planning includes activities that define what will be required to design, build, test and implement a new release. This includes any initial investigation work. The planning for a release requires inputs. The process relies on information provided by the release policy, authorized RFCs, as well as business requirements and any other constraints and dependencies when planning the release.




Back-out planning

Certainly if multiple RFCs are involved (Package Release) the various back-out plans need to be aligned.

Are the back-out plans ready if a release cannot be turned back?

Testing of the back-out plan(s). This topic is typically overlooked or only given scant attention. How many times can you recall a situation where the installation work of a release did not go according to the plan? What typically happens? The staff involved say, “We just need a few more minutes!” Quick Question Even if a good back out plan was created what is the primary reason it is not used when the criteria for using it are met? Answer: The production of back-out plans for each Change is the responsibility of Change Management, but Release Management has a role in ensuring that the back-out plans for each Change within a Release operate together to create a back-out plan.

Design, build, configure / assemble

Standard procedures

In house or “bought-in” software

Automated installation routines (accuracy)

Configuration management control o Build results stored in the CMDB to allow reuse

Specific test plans for rollout. The release assembly instructions will need to consider the IT platforms involved. One release may be the combination of many small, multiple platform-specific releases. Each platform-specific release will require unit assembly and then system assembly. Instructions for building platform-specific releases should be detailed in the Release Procedures Handbook. The release assembly instructions should be included part of the release definition. Any automated installation scripts should have associated rollback routines developed. Manual installation processes should be developed in case the automated processes fail. Make use of the CMDB to ensure that required version and number of CIs for a release are available. Steps on managing any discrepancies should be detailed in the Release Procedures Handbook. Rollback plans should be developed and later tested. Assumptions should also be documented for each rollback plan.




Release acceptance and testing

Test the release beforehand o in a (repeatable) controlled test environment o functional testing by users o operational testing by IT service provision

Also test the back-out procedures!

When a release is rejected back to Change Management! Develop written steps on using the organization's test environments for release testing. If a test environment for a specific platform is not available, steps on escalating and managing this issue should be documented. The release acceptance test plan should be based on the release acceptance criteria. Similar to modern IT application development testing, the release should be tested independently to ensure it meets the acceptance criteria. Defects may arise in the release testing and documented processes on how to manage these should be outlined in the release procedures handbook. What evidence have you seen of actual user acceptance testing (UAT)? How was it performed (random, structured and controlled)? Quick Question Which group of IT staff are often overlooked but could provide excellent insight with regard to testing? Answer:

Roll-out planning

Producing an exact, detailed timetable of events, as well as who will do what i.e. a re-source plan.

Listing the CIs to install and decommission.

Documenting an action plan specific to the site.

Producing Release notes and communications to end-users.

Planning communication.

Developing purchase plans

Scheduling meetings for managing staff and parties involved in the Release. Remember that there is NOT a flow of activities. It is why in this activity step we see the plan-ning of and the actual purchase of hardware and software (and subsequent storage of informa-tion in the CMDB). Remember that we have already covered the design, build, configure activity. Naturally, items will be purchased prior to, during and after this actual work. Essentially, release planning involves the prioritizing and scheduling of approved releases into production. While there are no hard and fast rules on the prioritization criteria, if one is set for an organization then it should be outlined in the Release Procedures Handbook.




Once the release schedule is finalized, the details for publishing this updated schedule should also be in the handbook. If particular staff or roles need to notified of such changes in the release schedule, their details should be included in the Release Procedures Handbook. All affected CIs (those introduced, modified and/or removed) should have their details updated in the CMDB. The agreed process for managing urgent releases and any potential negative impact on the production environment should be detailed.

Roll out sequence

This image (from the OGC Service Support text) helps us to understand the approaches availa-ble with regard to the roll out of releases. The first point to note is that the Release policy sets the rules for the actual roll out approach adopted. In the first block we can see an initial launch followed by two additional units (consider each of the units to be a workstation, or server, or other piece of infrastructure). In the second release, we see a “big bang” approach and then a phased rollout in the third release. Big bang is generally considered high risk (due to the high impact of failure). Phased rollouts are only possible where release units of differing versions can co-exist.

Communication, preparation, training

Who is involved? (Who isn‟t?)




o Service Desk o Customer Relations Management o Operational Management o End-user organization/representatives

Joint sessions for acceptance of releases

Joint sessions for training & awareness

Health and safety

Constraints (e.g. cannot use PC for x hours).

Distribution and installation

From build, to test, to live

Protection of software during distribution

Timing (distributed sites)

Receipt and dispatch of goods

Distribution and installation can be separate

Final checks following installation

CMDB updates.

Key Performance Indicators (KPIs)

Releases built and implemented on time

Number of backed-out Releases

Security and accuracy of the DSL & DHS

Compliance with all legal restrictions relating to bought-in software

Level of use of unauthorized software

Accurate and timely recording of all build, distribution and implementation activities within the CMDB.

Any process benefits from an ability to measure its performance using numbers. Metrics or Key Performance Indicators (KPIs) are terms we can use interchangeably. The benefit of using numbers is that they are simple, easy to understand and do not generally require a great deal of supporting information to explain them. The numbers tell the story!

Reporting

Major and minor Releases per reporting period

Release attributable problems in the live environment

New, changed and deleted objects introduced

The number of Releases completed in the agreed timescales (according to Policy defini-tions and release plans).




Most of us face an endless barrage of reports and information on a daily basis. The challenge when designing the reporting structure for any process is not what should be provided; it is what will be done with it? We have almost limitless aspects that we can report on. Therefore, the question is not what reports to provide, but what benefit the report will provide. As a process designer, you will also want to consider how to report on actual improvements that should be made to the process itself on an on-going basis (continuous improvement philoso-phy).

Process relationships

Configuration Management

Change Management

Software from Developers and suppliers

Problem Management and the Service Desk

Project Management and for example, PRINCE 2.

Guidance for success


Change Management

Release Management

Application Design

Positioning of software. Configuration Management – automated software/hardware auditing, data collection, integrity of files (checksums), good status accounting to reduce fees for un-required/unused soft-ware/hardware, control policies to prevent unauthorized installations, reduction/consolidation in officially supported variations of the organizational standard. Change Management – limit ability of users to make changes to their own systems, meetings and control points with relevant stakeholders to discuss proposed changes. Release Management – establishing a good (life like) test environment, automation of distribu-tion and installation, disciplined testing by real end-users Application Design – centrally held or distributed data, centrally run or local run of applications, applications covering different countries (languages), and time zones. Positioning of software – thin client model, falling cost of hardware may offset the benefits from centrally run, no/controlled local data storage.




8. Change Management

Release and Control processes

Let‟s now have a look at some of the concepts, terms and language of the Release, Change and Configuration Management process. A robust Change Management process ensures that the Change Manager is in full control of the changes to the IT infrastructure. Change Management is NOT about performing changes risk free. It is about performing changes with a minimal risk OR consciously taken risk. It is therefore important to involve the clients or client representatives in the change management process. The basic essence of Change Management is control & co-ordination and managerial; rather than technical (to contrast Incident Management has a strong emphasis on the mechanical nature of service restoration). Goal: To ensure that standardized methods and procedures are used for efficient and prompt han-dling of all changes, in order to minimize the impact of any related incidents upon services , and consequently to improve the day-to day operations of the organization. Or to put it another way… Any element of the infrastructure that you “care” about; you want to ensure that changes to that element is done according to a predefined set of activities and checks that will minimize the likelihood of a detrimental change to that element. Quick Question Change Management is more of a: (a) Doing process (b) Coordination process (c) Strategic process Scope: The Change Management process should account for changes to all elements of the infrastruc-ture that you (as an IT Service professional) are interested in. This will (or should) include:

Hardware

Communications equipment and software

System software

„Live‟ applications software

All documentation and procedures associated with the running, support and maintenance of live systems.

A change is a process of moving from defined state to another.




Is this too broad a definition? Consider using Change Management procedures to make changes to passwords of mission critical systems. How often do the passwords change? Every day, every week, every month? The reality is that if you want to, you will use Change Management to track the changes. A change does not necessarily mean that we have to call a meeting to approve it. We can define standard changes and appoint relevant parties to carry out the change, provided a pre-defined work procedure is followed.




Change Management Concepts

Requests for Change (RFC)

Change Advisory Board (CAB)

Change Models, Forward Schedule of Change (FSC) & Projected Service Availability (PSA)

Outsourcing Although some of these elements may have been discussed and covered at the Foundation level, in this program we look in greater detail at the “building blocks” of the process. The process needs to have “high visibility”.

Request for Change (RFC)

Triggers

Scope

Contents

Life cycle

Post Implementation Review (PIR) The Request for Change (RFC) is the most commonly understood concept within the Change Management process. It is typically the focal point of discussion when a specific change is being discussed. An RFC can be triggered by a variety of reasons. “Trigger” examples include:

Required solution of an Incident or Problem report

User or customer dissatisfaction expressed via CRM or SLM

The proposed introduction or removal of a new CI

A proposed upgrade to some component of the infrastructure

Changed business requirements or direction

New or changed legislation

Location change

Product or service changes from vendors or contractors. The PIR/Change Review is designed as a final check that the intended outcome for the change was actually delivered.




Items in a RFC form:

RFC Number (unique identification)

Description and identity of CIs

Reason for Change

Effect of not implementing

Name, location, phone number of person proposing the Change

Date that the Change was proposed

Change priority

Impact & resource assessment

CAB recommendations

Authorization signature, date & time

Scheduled implementation

Location of Release / Implementation plan

Details of Change builder / implementer

Back-out plan

Actual implementation date & time

Review date

Review results

Risk assessment & management

Impact on contingency plans

Status i.e. „logged‟, „assessed‟, „rejected‟, „accepted‟, „sleeping‟.




Change Advisory Board

A group of people who can give advice to Change Management on the implementation of Change.

Representatives

CAB/EC

Assessment criteria. Most organizations tend to have the same staff attend each change meeting. According to the best practice definition of ITIL the CAB would actually be flexible and dependant on the changes being assessed. When time pressures do not allow a full meeting of the CAB, it will be necessary to identify a smaller organization with authority to make emergency decisions. Such a body is known as the CAB Emergency Committee (CAB/EC). Whether changes are “standard” or “emergency” to improve the efficiency of the process it is necessary to establish a set of (predefined) measures. Having these measures in place brings the added benefit that many changes can be managed through automated systems.

Change Models

Standard to Complex

Forward Schedule of Changes (FSC) o A schedule that contains details of all Changes approved for implementation and

their proposed implementation dates.

Projected Service Availability (PSA) o A document that contains details of Changes to agreed SLAs and service availa-

bility. There is a growing awareness that defining change models can save time, effort, resources (and by association money). Models are typically defined for “smaller” changes. However, using the Capacity Management process (modeling) will also permit building of more complex change models. Forward Schedule of Change (FSC) – Changes that have been approved and their date/time of implementation Projected Service Availability (PSA) – agreed details regarding changes to SLAs and service availability Both FSC and PSA require customer involvement – SLM, Service Desk, and Availability Man-agement.




Outsourcing

Questions to ask a supplier regarding Change Management

Who is responsible?

What controls do we retain?

How are business impacts considered?

Who sits on the CAB?

How is security dealt with?

How are changes costed? Outsourcing organizations have a right to make profits. The way they do this is typically by employing “economies of scale”. Such economies of scale come from sharing infrastructure and even sharing services among a number of clients. While we can respect this right, we do need to ask a series of questions of the outsourcing organization. These questions are designed to protect the business and ensure that the out-sourcer is aware that their actions can have major impacts.

Benefits

IT to business alignment

Fewer adverse impact changes

Fewer back outs

Greater cost controls

Increase productivity for end users and IT personnel through stable IT services

Large number of changes can be handled without making the IT environment unstable.

Costs

Staff costs include those people involved with the Change Advisory Board, change builders and those staff involved with release and configuration management activities. We should expect that such costs at the outset of working with a new process would be higher. Support tools will quite often be an integrated system that supports a variety of processes (e.g. Change, Configuration, Incident/Service Desk and Problem Management).




Points of attention

Cultural challenges o a single process that is used for all elements of the infrastructure

Bypassing

„Missing link‟ with other processes

Commitment the supplier(s) to the process

Volume of changes. Understanding the possible problems ahead of time allows us to be prepared for and (prefera-bly) avoid them altogether. With regard to Change Management, the list above indicates the typical issues that can be faced. Bypassing is perhaps the greatest challenge and it can be created by pressure from customers OR self created by IT staff that do not see the need to use the process for what they consider to be an insignificant change. Steps to help prevent unauthorized changes will include:

Audits

Control over configuration items

Limiting user access

Education and awareness.




Activities of the Change Management Process

This model is a derivative of many of the Change Management activities. Each section is explored in greater detail further (the text outside the box are the actual ITIL activity names). Quick Question Why is the Build/Test/Implement section shown as outside the actual Change Management process? Answer:




Logging and filtering

Logging

Complete / Check information

Advise o Use an integrated Service Management tool o All members of the organization should be authorized to request Changes (stay

innovative!) Filtering

Which RFCs are totally impractical?

If rejected o Return to applicant with reasons o Applicant has the right to appeal.

The IT department has traditionally placed heavy controls on this one area. By only allowing a limited number of people to raise RFCs there is a danger that innovative ideas and suggestions could be missed. However, there is a danger that the change process becomes over burdened if there aren‟t some filter points that will prevent change proposals that have not been properly thought through to proceed.




Classification

Allocation of priorities

May already have been assigned by Problem Management (?), but….

Determines the order of changes. Change categorization

Establishes the resources required

Based on the impact. Ideally, the priority will be agreed upon with the initiator of the change – not left to the initiator. Without a “check” on the priority, we may see a cost justification imbalance (e.g., when Problem Management sees an issue as critical, but the CAB/Change Manager, with other external information, determines the issue is medium priority only). The category of a change helps us understand the level of resources required to actually im-plement that change. Be careful not to create too many categories, as confusion can cause the value of reporting to diminish. You can create a multitude of categories that may essentially all say the same thing. For exam-ple:

Facilities Management

Move Add Change

Software Upgrade

Software Installation. In such situations, some staff would use the MAC for a Software Installation, while others will select Software Installation.




Allocation of priorities Possible coding: Priority “Immediate”: URGENT CHANGE

Total limitation in use of essential services

Departure from normal change procedures o resources need to be made available instantly o all previous planning is postponed

Emergency meeting of CAB/EC probably necessary. Priority “High”

Severe disruption for a number of users, or

Disruption for large group of users

Departure from normal change procedures o resources need to be made available instantly o all previous planning is postponed

Top priority for CAB. Priority “Medium”

No high urgency or high impact, but

The change cannot be postponed until a suitable moment

Processing in next CAB. Priority “Low”

The change is desired, but can wait until a suitable moment o Next release o Next planned maintenance moment.




Assessment

Assessment of:

Effect on the infrastructure and service delivery

Capacity and performance

Contingency plans

Security

Effect on other services

What if change is not implemented?

Current FSC and PSA

Costs

Extra resources required post change. The CAB, CAB/EC or others nominated by the Change Manager, will carry out actual assess-ment. Some questions that may help in the assessment of a change:

What are the benefits (to the business) of this change?

What are the costs of making this change?

Is there a sound plan to implement the change?

Is this technically the best way?

What are the risks associated with this change (both of doing the change and of not doing the change)?

Are these risks under control?

Are the benefits, costs and risks in balance? How often should the CAB meet? It is important to note that the CAB may not actually meet very often - perhaps a physical meeting every six months. However, the members of the CAB can use electronic tools to review, sign-off, etc. The CAB meetings are also a place to make decisions, not to learn, so meeting agenda and other relevant papers should be sent to participants ahead of the actual meeting.




The CAB is an advisory body. If an agreement cannot be reached, the final decision will rest with the Director of IT, Change Manager, Service Manager or whoever is named as the autho-rized signatory for change (defined in Change Procedures and/or SLAs). The size and risk associated with a change will often determine who can actually make the approval.




Coordination

While IT staff may desire a single change policy, in reality, it is simply not a practical option (for most organizations). Apart from the negative image that users and customers would form of the IT department under such conditions, there is the added factor that there can be no economies of scale for multiple, single changes. The scheduling of changes will also need to factor in changes that will be required to dependant items (e.g. changing hardware may require an operating system upgrade). We also need to consider the number of changes that can occur at the same time (e.g., a rollout of multiple desktops can be treated as a single change (and the single change will be delivered as a “package release”). To balance these factors we must also consider ways to limit the risks involved should the change not go according to plan. In such a case, we want the single change to be of such a size that we can back out within an amount of time that will allow reversion to the pre-change situation that suits business needs. Forward schedule of changes

Based on known plans

Short, medium, long (?)

Distribution.




Build, Test and Implementation

Development and building

Also the back-out procedures! Testing

Also the back-out procedures!

Preferably in a separate test environment

Points of attention for all Service Management processes

Use modeling techniques. Implementing

Are the end-users familiar with the implementation?

Is the Service Desk familiar with the implementation?

Do the back-out procedures work?

At times that the impact on the IT service provision will be minimal. Once approved the change will be sent to the relevant groups. It is at this point that the actual work of creating the change will begin. The activities associated with Application Development, modifications to standard operating environments, etc. are outside the scope of the Change Management process. However, we can break the activities down into the three major points. Building must ensure that the same methods for building are used in order to maintain consis-tency. It is also at this stage that the back out plans are developed. Testing is a critical component and should be completed across a number of aspects (perfor-mance, security, etc.) It is also appropriate to have separate test environments that are as closely reflective of the production environment as possible. Implementation will take place at a time where any potential disruption to the business will be minimized (traditionally this is outside of work hours, but perhaps there is the opportunity to think laterally and conduct implementation during predefined times of the working day (provided these are known and accepted by business representatives and documented in SLAs).




Evaluation

Was the planning correctly carried out?

Was the impact correctly estimated?

Was the usage of resources correctly estimated?

Was the right result for the change realized?

Are the users satisfied with the result?

Number incidents on the change

Were / are there unexpected side effects?

Have detected anomalies been communicated to the CAB for future changes? The evaluation or change review is our opportunity to learn some lessons that could help to improve future changes and/or avoid mistakes made. The review can be based on a series of questions. It need not be a long exercise. It is important that there is some form of follow up action to ensure that the lessons learned are not lost over time. It may be that the follow up includes a redesign of the actual Change Management process or a modification to the approval matrix. Interestingly, such changes should themselves be done under the control of Change Manage-ment. Quick Question Who is involved in the evaluation? Answer:





Change Manager o Co-ordinate the CAB o Authorize o Report o Measure

Change Advisory Board (CAB) o Non-static group o Understand changes o Provide advice

CAB/EC

(Service desk) o Authorize.

The Change Manager (who can delegate) will carry out a number of change related activities including:

Calling and chairing all CAB meetings

Issuing relevant paperwork prior to any change related meetings

Authorize RFCs (that have met their change approval criteria)

Receive, log and prioritize change requests

Issue the FSC (via the Service Desk)

Look for any negative change related trends

Compile and issue change related reports. The CAB will be a dynamic group that includes stakeholders relevant to the changes under review. The Change Manager will chair CAB meetings. The group will review tabled changes (prior to any meeting) and provide advice on any proposed change – regarding authorization or rejection. The CAB/EC primary role is to be available should there be a need to conduct an urgent review. The Service Desk is mentioned, as we should remember that they might have the authority to approve minor changes or changes that meet some pre-defined criteria of measurement.




Planning and Implementation of the Change Management process.

Planning

Existing role, new role

Decide on Scope

Single Change and Configuration Management system

Training

Metrics, reports, review process. In most organizations, the Change Management role already exists, or it can easily be assigned to an existing individual. If the process is new to the organization, one of the first tasks that must be completed is to establish the scope of Change Management. Agreeing the scope will be done in conjunction with or will be reflective of the scope for configu-ration management. Similarly the selection of a tool is further complicated with the knowledge that the same system should be used for Configuration Management. Training in the use of the system should be carried out prior to implementation and contingency must exist to train new staff as they join the IT organization. Quick Question Why is there such a strong connection between the Change and Configuration Management processes? Answer: Finally, the measures of performance and the way the Change Management process itself will be assessed and reviewed need to be designed.

Implementation

Supporting processes (dependencies) o Release * o Configuration * o Problem o Service Desk

Procedures o Existing practices & cut-over

People o Support o Participation

Timing o Service Level Management & „change slots‟.

There are some processes that simply must be implemented concurrently with Change Man-agement. Our discussions to date have already provided the answer as to what these




processes are (Release and Configuration). However, other areas would be required in order to deliver a truly effective change management process. The two most notable of these are Problem Management and the Service Desk (function). Problem Management is an important generator of change. Once a known error is discovered in the IT infrastructure, it is necessary to remove that known error. Providing information about upcoming known changes AND receiving information that may generate and RFC AND carrying out pre-defined (minor) changes helps us to understand the importance of communication. The Service Desk is a focal point of communication in the IT Department. Actual procedural examples are provided shortly. We must take into account existing proce-dures when implementing the process. It will not be practical to run two processes in parallel, so the actual cutover point must be considered. With regard to people issues and Change Management, we need support of management for the process itself and then we need active participation. This is especially true for the IT staff who may attempt to by-pass new practices and procedures as they see them as an unneces-sary overhead. Finally, when the process is implemented we may want to consider establishing „change slots‟. These will be times that changes are permitted on a pre-defined, but regular basis. If they can be agreed upon, then it is appropriate to document them in any Service Level Agreements (and OLAs and UCs) that support the affected service/s.




Change Management Procedures

Change process and procedures

Typical procedures will include:

Initiation of RFCs

Handling of Urgent Changes

Impact assessment

Change authorization

Building and testing of RFCs

Implementation of RFCs

Reviews. Typical work instructions and guidelines will include:

Using support tools

Performing impact analysis with the aid of the CMDB

Registering RFCs

Planning Changes

Creating an agenda for a CAB meeting

Convening and running a CAB meeting

Drawing up Change models

Metrics and Reporting for Change Management

Change mgt metrics

Change Ratio

Points of origin

Rejection rate

Change backlog

Change related incidents

Successful change count

Number of back outs

Specific CI change count. Quick Question When is it acceptable to have a large number of changes? Answer:




Perhaps it is better to create some form of change ratio. Typically, a large number of changes indicated an unstable infrastructure environment and something that would lead to a high degree of customer/end-user dissatisfaction. However, what if the change were driven by those customers/end-users? If the amount of business change is low, then we should be looking for low levels of change in the IT infrastructure; conversely high change rates in the business can potentially be met with continuous changes in IT to keep pace.

Types of reports

Risk Reports

Business Impact Reports

Bottleneck reports

Emergency changes

Costs of change

General Reports on changes: o Changes per CI o Number of „back-outs‟ o Major change reviews.

Interestingly in the British Standard for IT Service Management (BS15000), which was adopted by Australia, under the banner of AS8018 (and internationally under ISO20000) there is a new defined section for “Service Reporting”. The standard requires that each service report will be clear in its identity, purpose and audience and that the details of the source information provided shall be stated. The purpose for any reports (echoed in the standard) is that they are agreed, timely, reliable and allow for informed decision-making.




9. Configuration Management

Goal: Configuration management provides a logical model of the infrastructure or a service by identi-fying, controlling, maintaining and verifying the versions of Configuration items (CIs) in exis-tence. Or to put it another way… Any element of the infrastructure that you “care” about; you want to hold information about that element, so that you can control it. The objective statement indicates that Configuration Management is the verification of compo-nents. Scope: Identification, recording and reporting of IT components, including their versions, constituent components and their relationships. The Configuration Management process is often thought of as the most important of all the processes. While the ITIL text will not support such a statement, it soon becomes apparent that Configuration Management provides information to and relies on information from the other ITIL processes. While this could be said of each process for Configuration Management, seeing these connections is a lot easier. Quick Question: What is the principle difference between Asset Management and Configuration Management? Answer:




Configuration Management Concepts

Configuration Management Planning

Strategy, Policy, Scope, Objective

Key Success Factors (KSFs).

Configuration Identification and CIs

Hardware

Software

Documentation. While all process implementations require planning, the concept is highlighted here due to the central role that Configuration Management plays with regard to other best practice processes. During planning the objective and scope must be defined. The Configuration Management plan will also document interfaces to other processes (especially Change and Release Manage-ment). There will be an explanation of tools, roles & responsibilities and locations of storage areas (for hardware, software and documentation). The hardware, software and documentation managed by the IT Department are referred to as Configuration Items (CIs). They are identified and labeled as part of the process implementation and on-going management. The relationships between CIs are a critical element of this process and help us to understand the primary difference between Configuration and Asset Management.

Identification and registration

Scope: determine width and depth of the CMDB

Identify CIs o Determine naming conventions o Record, determine attributes o Define interrelationships o Define the level of detail

Hardware and software Network (components) Databases, operating systems, etc.

Configuration Control

Only authorized CIs

Change Management relationship.

Configuration Status Accounting

Allows tracking through life cycle.

On the various components on a daily basis o Attribute status

being developed, purchased, tested, repaired, … o General status




number and sort incidents, problems, known errors, changes, licenses. Configuration control ensures that we consider how to control the recording of only authorized CIs from their point of arrival to their point of departure. The basic control question is “what will be used to allow updates?”. The most obvious answer to this question comes from the Change Management process and the associated Request for Change (RFC). One element of controlling the CIs is knowing where each Configuration Management (CI) is in regard to its life cycle. The value of the concept can be appreciated when we consider the various reports that could be generated that show different CIs and their incidence of status changes.




Configuration Baseline

Snap shot

Link to Change Management and Problem Management. One of the more “visible” concepts for Configuration Management is the verification and audit activity. This concept is a basic but crucial requirement that is often used as an indicator of the overall process effectiveness. The more errors found when checking “actual” against “expected” is a clear indication of how well the process is performing, in conjunction with the closely aligned Change Management process. This step is also a key element in the management of updates into the live environment (strong link to Release Management in this regard). The Baseline for configuration is a “snap-shot” that allows for future comparison. It is a key requirement when we are considering rollbacks after a change and/or in depth problem analy-sis.

Configuration Verification and Audit

Check actual presence against recorded details in the data store

Vital step in checking release contents prior to implementation in the live environment

Daily check o Build a procedural check

The Service Desk o Logging an incident

Audit (by an internal party) o Partial or extensive?

Audit (by an external party) o Review of the process o Actual verification.

New employees joining the organization can be educated to complete a daily procedural check on their local infrastructure. Service Desk personnel can conduct mini audits, by asking callers about their location and equipment numbers, etc. However, there is still a place for the more formal methods (especially required for non-visible items like routers, servers, etc.). The external audits can be both a check that the process defined by the organization is being followed; as well as an actual check of CMDB information against actual infrastructure.




Configuration Management Database (CMDB)

Exist to some degree

Technology required to support complexity

Auto-discovery

Personnel details, supplier details

Legal benefits

Software and Document Libraries

Collection of software and documents of known status

Controlling mechanism for software release. The Configuration Management Database (CMDB) is the data store for CI information. Most organizations already have a series of spreadsheets and small databases on infrastructure within the IT department. In larger organizations, the growing size and complexity of the infra-structure has forced the use of technology to manage all the associated information. The CMDB can hold a variety of information including details on users, customers, user groups, business units (Caution: consider privacy legislation at this point). The CMDB is also demonstr-able and as an auditable concept, it can be used as a compliance mechanism for legal require-ments. CI information relating to incidents, problems, known errors, changes, releases; as well as inter CI relationships will be stored in the database.


Master copy – software

Logical area.

License Management

Fines, even imprisonment

Internet downloads may require disciplinary measures. The definitive software library (DSL) is the LOGICAL storage location for master copies of software. The word “definitive” means „ultimate‟, „perfect‟, „best‟. Regarding license management, business people now face harsh financial penalties if they are found to be unable to control and monitor their software usage/licenses. Configuration Man-agement is a crucial process in assisting in the control of software licenses.




Configuration Management Database

Without knowing it there are already many organizations engaged in Configuration Manage-ment practices. Most already have some form of crude Configuration Management Database (CMDB). These CMDBs are often spreadsheets, local databases or even paper records regarding IT asset location, owner, cost, etc. However, the growth in size and complexity of IT environments has dictated the need to adopt sophisticated support tools (including a Configuration Manage-ment Database (CMDB). Configuration Management Data Base = a repository of data regarding IT components and their relationships

Configuration Item and Variants

A configuration item is a component of your infrastructure that is in place to help deliver a service. This component can be hardware, software, or even documentation (Service Level Agreement). Variants can be used when CIs are similar but not exact. Variants help to keep the total number of CIs down, but they can introduce complexity into the design of the CMDB (and subsequently other process areas that rely on the CMDB information).

Configuration Item and attributes

Different CIs require different attributes to be stored. Often the “tool” will determine what attributes can be stored (be cautious of allowing the tool to determine all aspects of the process).

Benefits

Management of IT resources

Economical, quality services o Less mistakes, therefore less “double costs”

Effective and efficient problem solution

Effective and efficient processing of changes

Optimal support on security issues

Helps ensure compliance to legal obligations o Insight in illegal copies, licenses, due dates of contracts

Optimal support on issues of budgeting and spending.

Central Data Repository

Having all CI data in one central repository provides all the normal efficiencies of data centrali-zation. The information supports all other ITSM processes such as Release, Change, Incident, Problem, Capacity Management and IT Service Continuity Planning. Providing one database with supporting database views for different purposes provides enhanced reporting at lower costs.




Legal Obligations

Poor management of CIs can have negative legal and financial repercussions on an organiza-tion. An accurate CMDB, with good Change Management practices can:

Reduce the introduction of unauthorized software/hardware

Support more timely and accurate auditing

Make software changes more visible and therefore reduce the chances of accidental breaches of licensing agreements.

Supports IT Service Continuity Management. In recent times, IT Service Continuity Management has risen to become a higher priority of organizations. Good Configuration Management practices supported by regular offsite backups of the CMDB, DSL & DHS will improve an organization‟s ability to restore operations in a mi-nimal amount of time.

Costs

Personnel o Management CMDB, audits, clean up poor data

Accommodation o Physical storage of process documents, servers, people

Software o In house vs. off the shelf o Tools and equipment for CMDB, audits, reporting…

Hardware o Data storage o Collection points and collation servers

Education o Tools, procedures, how to audit

Procedures o Designing & managing Configuration Management, documentation, instruction

sets. This is an expensive process to implement and maintain! There is no way to disguise the fact that in major organizations the costs associated with track-ing and controlling IT infrastructure can be enormous. However, consider the costs of not implementing this process. Computer fraud, software cor-ruptions, viruses, breach of license agreements, etc. The penalties for these events can spell the end to any business. The good news is that while the costs will be relatively high at the start of the implementation, with practice and refined procedures and tools, the operational costs should be able to be kept down.




Points of attention

Wrong level of CI detail (too high or too low)

Sticking to manual system

Authorization in case of urgent changes outside business hours

Over ambitious planning and too high expectations

Lack of management commitment

Costs-benefit analysis is difficult

Time pressure on implementation

Overly bureaucratic process/implemented in isolation

Tool lacks flexibility.

CMBD Development

The development of an automated CMDB and its associated processes should be treated as per any new system development in an organization. Adequate system specification and design should be undertaken to ensure that what is built meets the desired outputs and outcomes.

Adherence to Configuration Management Processes

After implementation, clearly written and supported Configuration Management processes (e.g. using the CMDB) should be developed, communicated and disseminated to ensure that the CMDB maintains its accuracy. A loss of accuracy in the CMDB can have long-term negative implications for the Configuration Management process and your ITIL implementation.




Planning and Implementation

Controlling IT infrastructure and services across distributed systems, across multiple locations and support groups requires careful planning. As there are many interdependencies among them, the planning should include Change, Configuration, Release and IT Service Continuity Management. Purpose and scope

Consult on purpose, objectives, scope and priorities

Standalone vs. consolidated process

Purpose statement. The purpose, objectives, scope and priorities for Configuration Management should be carefully considered with other ITSM process managers and IT managers. This will not only ensure accuracy but support buy-in at an early stage. You will also consider whether Configuration Management should operate as a stand-alone function or as a clustered set of inter-linked processes (along with Change and Release Man-agement). A purpose and scope statement should be developed as part of the project plan. For example: To implement one consistent Configuration, Change and Release Management process for <insert organization name>, which will ensure all IT assets are correct and accounted for in all IT environments. The objective might be: To bring all <insert organization name>‟s all IT services and infrastructure components, with their associated documentation, under control, and to provide an information service to facilitate the effective and efficient planning, release and implementation of Changes to the IT services. Objectives

Correct and accurate data

Documented procedures

Standardized naming & labeling

Control authorized CIs

Audit trails.

Priorities based on the organization. For many organizations, some form of phased implementation, including Change Management is essential. The implementation approach may be on an organizational, geographical, custom-er group, support group basis. Your priorities may be based on the CI relationships (systems, network, desktops), or your implementation approach (e.g. standalone or consolidated with Change & Release Manage-ment). A consolidated Configuration, Change & Release Management implementation will take longer and have higher initial costs, but inter-process relationships will be clearer and reduce future maintenance costs from incorporating these processes later.




Manager and team

Considerations

Dedicated staff or other roles/projects

Joint Configuration, Change and Release team

Size of IT infrastructure

Change size, frequency and complexity. The typical role titles in the Configuration Management team include Configuration Manager and Configuration Librarian.

Current state analysis

Identify and analyze current:

Processes

Scope and resources

Tools (databases/interfaces)


Owners of CIs. Most organizations have some form of Configuration Management process already in place. Even if it is a simple spreadsheet, listing traditional IT assets owned. This is in fact true of most of the ITIL processes. There are elements of each process in place – even if it is not referred to as ITIL. In order to move to new & improved state, we must gain a picture of the current Configuration Management situation. This will help identify points of concerns to address, as well as points of strength that need to continue.

Plans and design

Structure of the CM plan(s)

Steers the design of CM process

Affects the CMDB design. Most organizations delegate elements of Configuration Management control to support groups that have expertise in a particular technology or platform. In such cases, the support group manager is responsible for the control of the CIs owned and maintained by the group. Where this responsibility has been delegated, the organization needs to use one central or a consistent set of Configuration Management Plans to ensure consistent practices. A centralized function ensures common practices and procedures. Delegation requires careful management and regular auditing AND all groups need to share a common understanding regarding the process of Change Management as it relates to the management of the CMDB. Regardless of the structure of the Configuration Management Plan, it will play a major role in the design of the Configuration Management process and CMDB.




Planning for implementation

Same as major project activities. Key activities include:

Detailed analysis of existing process & staff knowledge

Review current data

Select CMDB tools

Detailed system design

Set up CIs. The activities carried out in the detailed planning for implementation are similar to those tradi-tionally carried out in a major system development. More key activities include:

Detail procedures

Test CMDB and interfaces

Finalize roles and responsibilities

Promote project

Train staff and users. Now we must begin some of the actual work of implementation. Up to this point, we have only identified and analyzed. Most people looking at the ITIL framework are seeking flow charts for all activities. It is relevant at this time to point out that, while a flow chart can provide a good pictorial overview of a process, a lot of the time many activities happen concurrently – and not in a structured flow.




CMBD and DSL set up

Consider Change freeze during set up. Populate and audit CMDB. Test:

Security

Backup & restoration

CMDB interfaces

Contingency plans. Ideally, during the CMDB setup, the organization could place a freeze on changes while the CMDB is being populated with existing CIs. This will ensure accuracy from day one but depend-ing on the implementation timeframe, this may not be practical. Quick Question Who should populate the DSL & DHS? The Configuration Management or Release Manage-ment team and why? Answer. If the Release Management team exists, they should populate the DSL & DHS in parallel with populating the CMDB. If the team does not exist, the Configuration Management should popu-late them and then perform a handover when the Release Management team forms. After the CMDB, DSL & DHS are populated, the following should be implemented and tested:

Security permissions

CMDB backup and restoration services

CMDB interfaces to other systems

Any contingency plans. The population of the CMDB could become your first opportunity to manage discrepancies in your CI fleet. Migrating asset data from your existing CI register(s) to the new CMDB may expose losses/thefts in your CI fleet, which will need to be managed and resolved.




Changeover and considerations

Once operational, Configuration Management controls all CI changes. Considerations:

Enough trained staff to avoid bottlenecks

Start with important CIs

Review o Activities against Plan o Resource effort o Data accuracy.

The changeover to the new Configuration Management will be influenced by the decision of whether to carry out a phased implementation or „flick switch‟ approach. During phased or parallel implementation, any changes will need to advise both parallel processes to maintain accuracy. Once the new Configuration Management system is in operation, no changes to the CIs should be implemented with Configuration Management approval. This decision should be well adver-tised with the organization. After commencing operations, the Configuration Management process will continue to require management & staff commitment. If staff start to bypass the process (regardless of the reason), the benefits of the process will not be realized. This may be an ongoing challenge for the Confi-guration Manager. Quick Question As the Configuration Manager, you have realized that some staff are bypassing the Configura-tion management process. Broadly, what steps would you take to address this issue? Answer. Traditionally when Configuration Management audits are mentioned, people normally think of auditing the CMDB (and DHS & DSL). Auditing the activities, procedures and expended effort is also important, as issues in these parts will lead to inaccurate CMDB data.




Activities for Configuration Management

Configuration Management planning

Configuration identification and CIs

Configuration control

Configuration status accounting

Configuration verification and audit

CMDB Backups, housekeeping, etc. The Configuration Management activities can be developed into specific procedures that will give instruction and guidance. The stakeholders for the configuration management procedures will include staff that are in-volved with introduction, maintenance and removal of CIs Any actual handbook will be found in the same area as the Configuration Management policy document. The procedural handbook can also be supplemented with a variety of flow charts/diagrams. The ultimate objective for the handbook is to detail how operational staff will actually carry out the day-to-day activities of Configuration Management.




Configuration Management planning

Reference existing procedures and plans

Plan first 3-6 months in detail, next 12 months broadly

6 monthly reviews o Consider CMDB o Staff numbers & IT resources o Purge CI data to maintain efficient CM function o Review links with other ITSM processes o Review procedures handbook.

The Configuration Management plan needs to explain the rules for the process. In the rulebook, we need to see roles and responsibilities, naming conventions, interface details with third parties, CMDB management, related policies and process interfaces. Generally, the Configuration Management activity will grow over time as the number of CIs grows. This expected growth and future business needs should be considered at review times. Purging CI data may be considered as a means to trim the costs of the Configuration Manage-ment process.

Configuration identification and CIs

Level of „independent change‟

All hardware & software

CI or COMPONENT?

Consider: o Auditing needs o Supply of CIs (packaged or parts).

It may be too simplistic to suggest a guide as to how “deep” the breakdown of CIs should go in an organization; but we need to start somewhere. As a rule, it may be helpful to consider identi-fying CIs to a level of detail that will allow independent change. That is, can I change that CI without affecting others? The depth of the CI levels will affect the size of your CMDB and the amount of effort to audit your CIs. If information at a low CI level would not be valuable – for example, if a laser printer cartridge is not manually exchanged independently or it seen as a consumable, then do not store. The approved CI levels outlined in the Configuration Management Plan should be regularly reviewed to ensure that the levels are adequate for the business. Choosing the right CI level is a matter of achieving a balance between the information available, the right level of control and the resources and effort needed to support it.




Attributes

Name

Type

Location

Serial Number

Version Number. The attributes of a CI is the elements that allow us to define what the CI actually is. It is not possible to list all the attributes that a CI could have. However, we should consider keeping the number of attributes kept about a CI (or family of CIs) to as few as possible. NOTE: “as few as possible” is not designed to reduce our work load, but it helps us to focus on ensur-ing that we store the right amount of information and do not get overloaded with information that adds to value to the organization. Some other attributes include:

Manufacturer

Date received

Date commissioned

Product Manager (or CI owner). The VALUE is of an attribute is the answer to what the attribute asks. For example, if the attribute is “version” the value may be “1.0” or “2.0”

Relationships

Asset register vs. Configuration Management

Relationships provide dependency information.

For example: o Parent/child relationship o A CI is connected to another o A CI uses another CI.

Now we reach the part that helps us to understand the principal difference between asset registers and the configuration management process. By creating, storing and maintaining relationship information between CIs the process adds real value to the IT department and (more importantly and indirectly) the organization. Relationships allow us to understand what CIs are dependent on other CIs. Quick Question Which process will gain an incredible benefit from this relationship information? Answer:

Identification of configuration baselines

Purpose




o Sound basis for future work (where are we now) o What will be affected by new RFCs o Fallback position

Contain CI documentation as well info about themselves

Use version numbering rather than live, next, old. The creation and management of baselines serves a variety of purposes. The baseline may also provide a “trigger” for customer sign off regarding the configuration of a service (which could coincide with a review of Service Level Agreements). Baselines are particularly useful when a series of items are to be purchased, developed over an extended period. The baseline numbering scheme should be well thought out – as there may be many baselines in use at any one time (e.g. different countries, different regions, etc.). The Baseline will need to include associated documentation that was used in the creation of the base lined CIs

Naming conventions

Apply to: o CIs, changes, baselines, releases and assemblies

Unique

Support existing organization conventions

Permit growth

Reflect relationships. The creation of naming convention for software and hardware is not a simple task. However, once achieved, the convention will assist staff in identifying CIs and aid in the development of the CMDB and the overall control of CIs and other components.




Configuration control

Ensures that only authorized and identifiable CIs are recorded in the CMDB upon receipt

Procedures need to cover all stages. Examples: o Registration o Updates (RFC to CI relationship) o Decommissioning o Data integrity protection.

The configuration control procedures should protect the integrity of the organization‟s data, systems and processes by ensuring that unauthorized changes are virtually impossible. The configuration management procedures handbook will need to inform IT staff how to man-age CIs, their attributes, relationships and events throughout a CIs life in an organization. During the development of the procedures, the author will need to consider the existing ITSM procedures and the existing IT service management processes, especially Change and Re-lease Management. Focus on avoiding duplication in procedures and encouraging input from other process manag-ers. Configuration Management is widely utilized by other ITSM processes and procedures should not developed in isolation. We will step through some key on-going control processes: Registration, Updating, Removing, and Protection.

CI Registration

Secure environment

Verify received goods

Consider procurement processes

Off the shelf

In-house developed o When to register? (Development, test, production).

The registration of new CIs should be conducted in secure environment, as assets are vulnera-ble to loss/theft during handover from supplier to customer. New goods should be verified upon receipt. Registration procedures should incorporate existing procurement processes to reduce duplica-tion. Assembly and delivery procedures from suppliers could be reviewed to potentially incorporate elements of your registration procedures. For example, bar coding of new equipment by the supplier prior to delivery. The procedures may need to manage off-the-shelf equipment as well as in-house developed CIs. For software developed in-house, you may consider registering software either at the develop-ment, acceptance test or production stage. The management overhead cost on application development staff in maintaining an in-house system‟s CI status needs to be considered.




CI Updating

Consider the entire CI lifecycle

Be able to update: o CIs o Attributes o Relationships o Events

Seek linkages with other system for update automation. There is a natural progression for the status of a CI as it moves through its life cycle (progres-sion from procurement to perish!). Ideally, we would rely on technology to a large degree to carry out automated discovery and updates of CIs. This is also true for related documentation (e.g. document management sys-tems), licenses, etc. Procedures will need to detail how to update statuses of CIs, attributes, relationships and events. Examples include new documentation for CIs and new license agreements for off-the-shelf software. Consider the ability to update CIs „owners‟. The staff that manage or have responsibility for CIs, and may leave their current role or leave the organization. The ability to automate this task with a linkage between the CMDB and an organizations‟ HR system is advantageous.

CI Removal

Same considerations as CI registration

Consider existing disposal methods

Another vulnerable period for CIs. Incorporating existing disposal procedures not only reduces duplication but also ensures any legal obligations will be met; as such disposal procedures which are generally built on “business practices” – not necessarily IT practices. CI removal (or disposal) is another vulnerable period for loss/theft so security measures are encouraged.




Integrity of configurations

Protection of CIs and their components

Covering o Procurement o Storage, Dispatch, Receipt o Disposal

For software CIs o Virus protection o Environmental considerations.

The principle purpose for this activity is the ability to “recreate” a known good configuration at some point in the future. Without considering how the CIs will be protected during all aspects of the CIs life – then the ability to do this will be severely compromised. Even to the point of software CIs and the requirement to refresh magnetic data and protection from disaster.

Configuration Status Accounting

Status accounting report generation o Who can request a report o How to request a report or how to generate report independently o Report formats o Report publishing rules.

Status accounting reports on the current, previous and planned states of CIs. The procedures for developing status accounting reports may include:

Verifying who can request a report

How to request a report

How to run a report

Report formats: are they fixed or custom-made and how to generate them

Publishing reports: dissemination procedures (public or private access).

Configuration verification and audit

Other ITSM processes depend upon an accurate CMDB

Detail o Audit frequency o Depth of audit o Staff involved

Use automated tools (detail instructions)

Log and manage discrepancies. The integrity of the CMDB should be audited as numerous ITSM process assume that the CMDB is accurate. Procedures for carrying out such audits should detail (at least) the audit frequency, depth of audit, staff involved and steps for sign-off and communicating audit out-comes. Each approved and released CI should have an approved RFC associated with it.




Use of automated tools for auditing is encouraged and instructions for using such tools should be detailed. Procedures on logging and managing discrepancies and conducting investigations into missing CIs should be detailed. These procedures may include managing any issues with the proce-dures and the behavior of personnel. Any internal security investigation procedures may also be incorporated. CMBD backup, housekeeping

Back-up CMDB (restore procedures)

Archiving information

Frequency and retention policy

Retention based on usefulness

Regular checks to remove obsolete/redundant CI information. Archiving is a distinctively separate activity from backing up the CIs. A CI may become obsolete and is no longer required in the production environment. However, information about the CI may be needed for financial and security auditing reasons. Therefore, procedures should be developed to archive and later review this data – if called upon.

Configuration Management - Service

As a service, CM can add value by providing these recommended services:

Regular & adhoc reporting

Advice on policy & procedures

Advice on configuration complexity

Auditing service

Library service

License management. Once Configuration Management is established, the team should help to provide a variety of services to other ITSM processes and business units. Providing a „value-added‟ service will enhance the IT organization‟s reputation by moving from just day-to-day Configuration Item (CI) management to pro-active CI management.




Process Control for Configuration Management

Configuration Reports

Efficiency: o Productivity:

Number of changes per period o Value add:

Number of release back outs

Effectiveness: o Timeliness:

Resolution time o Accuracy:

% correct resolution o Quality:

% solved within SLA Decrease in % of back-outs necessary

Look to consolidate reporting needs

Carry out report reviews o Seek stakeholder feedback o Support other ITSM processes? o Is report archiving working?

Quick Question What is the fundamental difference between effectiveness and efficiency? Answer:

Configuration KPIs

Number of discovered unauthorized configurations

Audit reviews

Poor impact assessment that lead to inefficient change

Change related incidents/problems.

Tools

Like all system developments, start with clear specifications

Support end to end CI lifecycle

Automation

Incorporate DSL or provide linkages to

Entirely new system or leverage existing tools.




Depending on your organization, the Configuration Management tool needs to effectively support:

The lifecycle of CIs from beginning to end

Provide support to the other ITSM processes

Provide flexible reporting tools

Allow easy auditing of CIs

Store and show relationships between CIs

Store events associated with CIs. Regardless of the size of an organization, an automated CMDB will provide a more efficient service than a paper-based service. Ideally, the CMDB will be linked to the DSL and other software development configuration management tools. If this is not possible, the CMDB should at least allow CI information to be exchanged between the software development configuration management tools and it. For auditing purposes, if the DSL is not integrated with the CMDB it may be worth automating the comparison of the DSL contents with the CMDB. Accurate and detailed auditing tools will mean that staff focus on managing exceptions, rather than doing the audit itself.




10. Relationships – Release and Control Processes


Configuration Management is an integral part of all other Service Management processes. With current, accurate and comprehensive information about all components in the infrastructure the management of change, in particular, is more effective and efficient. Change Management can be integrated with Configuration Management. As a minimum it is recommended that the logging and implementation of changes be done under control of a comprehensive Configura-tion Management system and that the impact assessment of changes is done with the aid of the Configuration Management system. All change requests should therefore be entered in the Configuration Management Database (CMDB) and the records updated as the change request progresses through to implementation. The Configuration Management system identifies relationships between an item that is to be changed and any other components of the infrastructure, thus allowing the owners of these components to be involved in the impact assessment process. Whenever a change is made to the infrastructure, associated Configuration Management records should be updated in the CMDB. Where possible, this is best accomplished by the use of integrated tools that update records automatically as changes are made. The CMDB should be made available to the entire Service Support group so that incidents and problems can be resolved more easily by understanding the possible cause of the failing com-ponent. The CMDB should also be used to link the incident and problem records to other ap-propriate records such as the failing Configuration Item (CI) and the user. Release Management will be difficult and error prone without the integration of the Configuration Management process. The Service Delivery processes also rely on the CMDB data. For example:

Service Level Management needs to identify components that combine together to deliv-er the service so that underpinning agreements can be set up

Financial Management for IT needs to know the components utilized by each business unit especially when charging is in place

IT Service Continuity and Availability Management need to identify components to per-form risk analysis and component failure impact analysis.




Change Management

The Change Management process depends on the accuracy of the configuration data to ensure the full impact of making changes is known. There is therefore a very close relationship be-tween Configuration Management, Release Management and Change Management. Details of the change process are documented in SLAs to ensure that users know the proce-dure for requesting changes and the projected target times for, and impact of the implementa-tion of changes. Details of changes need to be made known to the Service Desk. Even with comprehensive testing there is an increased likelihood of difficulties occurring following change implementation wither because the change is not working as required or expected, or because of queries on the change in functionality. The Change Advisory Board (CAB) is a group of people who can give expert advice to the Change Management team on the implementation of changes. This board is likely to be made up of representatives from all areas within IT and representatives from business units.

Release Management

Changes may often result in the need for new hardware, new versions of software, and/or new documentation, created in-house or bought in, to be controlled and distributed, as part of a new „packaged release‟. The procedures for achieving secure, managed rollout should be closely integrated with those for Change Management and Configuration Management. Release proce-dures may also be an integral part of Incident Management and Problem Management, as well as being closely linked to the CMBD in order to maintain up-to-date records.




This diagram shows the complexity of the relationships and the processes involved in Release and Control management activities. The release process and the configuration management process are first stimulated by the change management processes. This does not mean that the Change Management process has precedence though. ITIL is very clear however that the Configuration Management process should not be implemented before Change Management. The User, in this instance it may be the Customer of the IT Department or a User in the organi-zation, would request a change in the form of a RFC. Change Management would accept or reject this change depending on the information and any assessments that have been carried out. If the change goes ahead, as it does in this example, for redoing a desktop environment, we need to know look at the available equipment needed. We can look in both the CMDB and the DSL / DHS. The DSL / DHS is where the physical hardware and software will come from. This of course is recorded in the CMDB. The release management process will ensure that the hardware and software are correctly built into releases and distributed and installed across the infrastructure according to the change management plans. Other processes and functions will be included in this as necessary.

Tools are often thought of as complex and expensive. However, there is no rule that says that a simple database cannot be used to control information about Configuration Items or that a paper-based form cannot be the beginning point for all infrastructure changes.




What determines the complexity? Tools are generally used to help us deal with volumes of work that could not be dealt with without them! Tools help us to overcome resource shortages (principally money and people). They are becoming ingrained in most organizations, as our world becomes increasingly IT complex, with multiple vendors and growing acceptance of international standards. Tools deliver the ability to centralize & automate activities, analyze data, identify trends and take preventative measures.




Release and Control Support Tools

Quick Question Which comes first – a process or the tools? Answer: Tools are often thought of as complex and expensive. However, there is no rule that says that a simple database cannot be used to control information about Configuration Items (CIs), or that a paper-based form cannot be the beginning point for all infrastructure changes. Tools are generally used to help us with volumes of work that could not be dealt with without them. Tools help us overcome resource shortages (principally money and people). They are becoming ingrained in most organizations, as our world becomes increasingly IT complex, with multiple vendors and growing acceptance of international standards. Tools deliver the ability to centralize and automate activities, analyze data, identify trends and take preventative measures.

Tool selection

Non-core selection criteria

Supplier o Reputation/history, Support focus, Training & consulting, Future plans (new mod-

ules?), References

Ongoing costs o Customizations, upgrades, maintenance

Adaptability o Flexibility to support the changing organization.

Often overlooked these three elements must be part of any selection criteria exercise. We have referred to them as “non-core” as they are not specifically linked to a particular process/activity. Of these, the issue of adaptability has the potential to completely ruin the tool selection process. What was an excellent decision at the time can quickly become a poor choice, when tools cannot be adapted to meet the (inevitable) organizational changes (e.g. Mergers, takeovers, expansion into new territories/countries).




Tool selection

80% fit on requirements

Delivery on mandatory requirements

Out of the box

“ITIL compliance”

Low/known administration costs

Low/known maintenance costs. This list gives us some elements to consider when looking at the actual service management software itself. The list is not compulsory, but serves as a guide. The best demonstration of this point is the “ITIL compliance” point. You would not reject a tool simply because it did not have a sticker on the box.

Costs associated with tools:

Tool costs: o Back end o Front end: licenses

Equipment costs: o Server / disk space o Network capacity o Desktop requirements?

Training: o Support staff o Tool maintenance staff

Consulting: o Tool configuration o (Future) changes: adaptability?

The list allows us to appreciate that while there are obvious costs associated with the use of service management tools, hidden costs that can be overlooked. An important consideration that is not mentioned above is the increased likelihood that the deployment of a tool within the organizational infrastructure could create service outages. This is a real risk for the organization and while the supplier will promote their products‟ stability and excellent performance at other sites, will they offer any guarantee that the tool will not create such outages?




Process Organization and Design

Process and Procedures The difficulty with defining what a process is, what a procedure is, etc. is made complicated due to peoples backgrounds, experiences and Wikipedia (http://en.wikipedia.org) defines a process as “naturally occurring or designed se-quence of operations or events, possibly taking up time, space, expertise or other resource, which produces some outcome. A process may be identified by the changes it creates in the properties of one or more objects under its influence.” Whereas the same resource describes a procedure as “a series of activities, tasks, steps, decisions, calculations and other processes, that when undertaken in the sequence laid down produces the described result, product or outcome. Following a procedure should produce repeatable results for the same input conditions. It is interesting to note that even in the definition of what a procedure is the word process appears!

Process, Procedure and Work Flow swim lanes

Swim lanes are similar to flow charts, with the added information of explicitly showing WHO will do a process step. The “who” can be an individual, department or organization. In this simple example, we can see the start of an incident and how an organization may define the flow of activities and the “HAND OFF” points. The hand off points give us clear places to look at with regard to poor communication or a lack of understanding. Important to note that this example is very simple and that the standard flow chart icons can be used (not used in this example).




Brainstorming techniques

Freewheeling

Carousel

One-Two-Six

Slip Method Creating processes and procedures can often require input and ideas from a variety of people. Here are some basic techniques to help generate ideas that can then be used as the starting point for creation. Freewheeling – Simply calling out ideas and exact words are written down Carousel – Create a series of questions/topics on sheets of paper spread around a room. Small groups spend a few minutes at one sheet, before they move on to the next. One-Two-Six – each person writes down one idea. Participants pair off to share ideas and select one. Participants form groups of six to share their ideas and select one. Slip Method – Small groups, ideas are written on cards (slips) and then organized into groups or themes.

Creativity technique

S - substitute

C - combine

A - adapt

M - modify

P - put to another use

E - eliminate

R - reverse This technique is generally used in manufacturing, when looking at creation of a new product. The SCAMPER points can be addressed directly or used as prompts for lateral thinking. Note: the letters do not represent a flow that has to be followed, but are prompts for creativity. Let‟s try to apply the technique to the creation of a procedure.

Substitute – replace all or parts of an existing procedure with all or parts of a procedure defined by a governing body Combine – create joint procedures with suppliers and distributors Adapt - use outside consultants to develop all procedures Modify – use diagrams only (no long text based descriptions) Put to another use – sell developed procedures to external organizations Eliminate – rely on word of mouth and commonsense Reverse – develop an industry framework.




RACI Model

The concept of this technique is similar to SWIM LANES. Both are designed to show WHO is involved. The RACI model extends the swim lanes by recognizing the different types of action required for each step of the procedure. The RACI model helps show how a process actually does work end to end across sever-al functional groups. R – Responsibility (actually does the work for that activity but is responsible to the function or position that has an “A” against it. A – Accountability (is made accountable for ensuring that the action takes place, even if they might not do it themselves). C – Consult (advice / guidance / information can be gained from this function or position prior to the action taking place). I – Inform (the function or position that is told about the event after it has happened). General Rules:

• Only 1 “A” per Row (ensures accountability, more than one “A” would confuse this) • At least 1 “R” per Row (shows that actions are taking place)




When the technique is applied, we can analyze the table both VERTICALLY and HORIZONTALLY. Vertical analysis can help us identify roles or groups that we may be over-reliant on. If multiple columns have identical entries, than there may be a potential to merge those groups from an activity point of view. Horizontal analysis allows us to identify events that cross many functional roles/groups (which may be an indication of high bureaucracy or of potential for breakdowns in communication (hand offs).




11. Answers

Answers to the Quick Questions…

Page Answer

14 (a) Communication is ineffective

15 Yes

28 Package release

29 Configuration Management Database (CMDB)

30 Configuration Management Database (CMDB)

38 (a) All stakeholders accept the risk of proceeding and (b) Impact of rollback exceeds impact of deployment.

39 Service Desk

43 (b) Coordination process

50 (a) Change Mgt is responsible for assessing and authorizing changes and (b) Release Mgt does the build, test and implementation

58 CAB – all appropriate stakeholders for the change – IT, business, financial and supplier.

60 Because accurate configuration records require change control. Change Mgt relies on accurate information to make decisions.

62 High volumes of business change

64 Asset – manage the life cycle of physical assets. Configuration – manage all CIs to understand relationships between services, components and other infrastruc-ture.

75 Release Management

76 Investigate and interview, education and awareness, process documentation, implement improvements

79 Change and release

85 Effectiveness identifies objectives being met or supported. Efficiency identifies performance, resources used or bottlenecks.

91 Process.




12. Glossary

Availability Ability of a Configuration Item or IT Service to perform its agreed Function when required. Availability is determined by Reliability, Maintainability, Serviceability, Performance, and Security. Availability is usually calculated as a percentage. This calculation is often based on Agreed Service Time and Downtime. It is Best Practice to calculate Availability using measurements of the Business output of the IT Service.

Build The Activity of assembling a number of Configuration Items to create part of an IT Service. The term Build is also used to refer to a Release that is authorized for distribution. For example Server Build or laptop Build.

Category A named group of things that have something in common. Categories are used to group similar things together. For example Cost Types are used to group similar types of Cost. Incident Categories are used to group similar types of Incident, CI Types are used to group similar types of Configuration Item.

Change The addition, modification or removal of anything that could have an effect on IT Services. The Scope should include all Configuration Items, Processes, Docu-mentation etc.

Change Advisory Board (CAB)

A group of people that assists the Change Manager in the assessment, prioritiza-tion and scheduling of Changes. This board is usually made up of representatives from all areas within the IT Service Provider, representatives from the Business, and Third Parties such as Suppliers.

Change Authority

A group that is given authority to approve Change, e.g. by a project board. Some-times referred to as the Configuration Board.

Change history

Information about all changes made to a Configuration Item during its life. Change History consists of all those Change Records that apply to the CI.

Change Management

The Process responsible for controlling the Lifecycle of all Changes. The primary objective of Change Management is to enable beneficial Changes to be made, with minimum disruption to IT Services.

Change Record

A Record containing the details of a Change. Each Change Record documents the Lifecycle of a single Change. A Change Record is created for every Request for Change that is received, even those that are subsequently rejected. Change Records should reference the Configuration Items that are affected by the Change. Change Records are often stored in a Configuration Management Database.

Classification

The act of assigning a Category to something. Classification is used to ensure consistent management and reporting. CIs, Incidents, Problems, Changes etc. are usually classified.

Closure

The act of changing the Status of an Incident, Problem, Change etc. to Closed.

Configuration Configuration of a product or system established at a specific point in time, which




Baseline captures both the structure and details of that product or system, and enables that product or system to be rebuilt at a later date.

Configuration Control

The Activity responsible for ensuring that adding, modifying or removing a CI is properly managed, for example by submitting a Request for Change or Service Request.

Configuration Identification

The Activity responsible for collecting information about Configuration Items and their Relationships, and loading this information into the CMDB. Configuration Identification is also responsible for labeling the CIs themselves, so that the corresponding Configuration Records can be found.

Configuration Item (CI)

Any Component that needs to be managed in order to deliver an IT Service. Information about each CI is recorded in a Configuration Record within the CMDB and is maintained throughout its Lifecycle by Configuration Management. CIs are under the control of Change Management. CIs typically include hardware, soft-ware, buildings, people, and formal documentation such as Process documenta-tion and SLAs.


The Process responsible for maintaining information about Configuration Items required to deliver an IT Service, including their Relationships. This information is managed throughout the Lifecycle of the CI. The primary objective of Configura-tion Management is to underpin the delivery of IT Services by providing accurate data to all IT Service Management Processes when and where it is needed.

Configuration Management Database (CMDB)

A Database used to manage Configuration Records throughout their Lifecycle. The CMDB records the Attributes of each CI, and Relationships with other CIs. A CMDB may also contain other information linked to CIs, for example Incident, Problem or Change Records. The CMDB is maintained by Configuration Man-agement and is used by all IT Service Management Processes.

Configuration Structure

The hierarchy and other Relationships between all the Configuration Items that comprise a Configuration.

Customer

Someone who buys goods or Services. The Customer of an IT Service Provider is the person or group who defines and agrees the Service Level Targets. The term Customers is also sometimes informally used to mean Users, for example "this is a Customer Focused Organization".

Definitive Hardware Store (DHS)

One or more physical locations in which hardware Configuration Items are se-curely stored when not in use. All hardware in the DHS is under the control of Change and Release Management and is recorded in the CMDB. The DHS contains spare parts, maintained at suitable revision levels, and may also include hardware that is part of a future Release.


One or more locations in which the definitive and approved versions of all soft-ware Configuration Items are securely stored. The DSL may also contain asso-ciated CIs such as licenses and documentation. The DSL is a single logical storage area even if there are multiple locations. All software in the DSL is under the control of Change and Release Management and is recorded in the CMDB. Only software from the DSL is acceptable for use in a Release.

Delta A Release that includes only those Components of a Release Unit that have




Release

actually changed since the last Release. A Delta Release is also referred to as a partial Release.

Environment

A subset of the IT Infrastructure that is used for a particular purpose. For Exam-ple: Live Environment, Test Environment, Build Environment. It is possible for multiple Environments to share a Configuration Item, for example, Test and Live Environments may use different partitions on a single mainframe computer. Also used in the term Physical Environment to mean the accommodation, air condi-tioning, power system etc.

Full Release

A Release that includes all Components of a Release Unit, including those that have not changed.

Impact

A measure of the effect of an Incident, Problem or Change on Business Processes. Impact is often based on how Service Levels will be affected. Impact and Urgency are used to assign Priority.

Incident

An unplanned interruption to an IT Service or reduction in the Quality of an IT Service. Any event which could affect an IT Service in the future is also an Inci-dent. For example Failure of one disk from a mirror set.

Lifecycle

The various stages in the life of a Configuration Item, Incident, Problem, Change etc. The Lifecycle defines the Categories for Status and the Status transitions that are permitted. For example: The Lifecycle of an Application includes Design, Build, Test, Deploy, Operate etc. The lifecycle of an Incident includes Detect, Respond, Diagnose, Repair, Recov-er, Restore. The lifecycle of a Server may include: Ordered, Received, In Test, Live, Disposed etc.

Priority

A Category used to identify the relative importance of an Incident, Problem or Change. Priority is based on Impact and Urgency, and is used to identify required times for actions to be taken. For example the SLA may state that Priority2 Incidents must be resolved within 12 hours.

Process

A structured set of Activities designed to accomplish a specific Objective. A Process takes one or more defined inputs and turns them into defined outputs. A Process may include any of the Roles, responsibilities, tools and management Controls required to reliably deliver the outputs. A Process may define Policies, Standards, Guidelines, Activities, and Work Instructions if they are needed.

Process Control

The Activity of planning and regulating a Process, with the Objective of perform-ing it in an Effective, Efficient, and consistent manner.

Release

A collection of hardware, software, documentation, Processes or other Compo-nents required to implement one or more approved Changes to IT Services. The contents of each Release are managed, tested, and deployed as a single entity.

Request for Change (RFC)

A formal proposal for a Change to be made. A RFC includes details of the pro-posed Change, and may be recorded on paper or electronically. The term RFC is often misused to mean a Change Record, or the Change itself.




Resolution

Action taken to repair the Root Cause of an Incident or Problem, or to implement a Workaround.

Role A set of responsibilities defined in a Process and assigned to a person or team. One person or team may have multiple Roles, for example the Roles of Configu-ration Manager and Change Manager be carried out by a single person.

Service Level Agreement (SLA)

An Agreement between an IT Service Provider and a Customer. The SLA de-scribes the IT Service, documents Service Level Targets, and specifies the responsibilities of the IT Service Provider and the Customer. A single SLA may cover multiple IT Services or multiple customers.

Service Request

A request from a User for information or advice, or for a Standard Change. For example to reset a password, or to provide standard IT Services for a new User. Service Requests are usually handled by a Service Desk, and do not require an RFC to be submitted.

System

A number of related things that work together to achieve an overall Objective. For example: A computer System including hardware, software and Applications. A management System, including multiple Processes that are planned and managed together. For example a Quality Management System. A Database Management System or Operating System that includes many software modules that are designed to perform a set of related Functions.

Urgency

A measure of how long it will be until an Incident, Problem or Change has a significant Impact on the Business. For example a high Impact Incident may have low Urgency, if the Impact will not affect the Business until the end of the Finan-cial Year. Impact and Urgency are used to assign Priority.

User

A person who uses the IT Service on a day-to-day basis. Users are distinct from Customers, as some Customers do not use the IT Service directly.

Version

A Version is used to identify a specific Baseline of a Configuration Item. Versions typically use a naming convention that enables the sequence or date of each Baseline to be identified.

Workaround

Reducing or eliminating the Impact of an Incident or Problem for which a full Resolution is not yet available. For example by restarting a failed Configuration Item. Workarounds for Problems are documented in Known Error Records. Workarounds for Incidents that do not have associated Problem Records are documented in the Incident Record.




INDEX*

A

ability 13, 21, 34, 36, 41-2, 82-3, 90-1, 98 organization‟s 70 accountability 95

accuracy 13, 38, 41, 71-2, 75-6, 85, 88 activities automate 90-1 change management 50 configuration management 48, 77 adaptability 13, 91-2

agreements 10-11, 55, 101 alignment 16-17, 22 Amazon 3 applicant 51 applications 6, 28, 42, 100-1 Art of Service Pty Ltd 6 assessment 20, 54, 89, 98

assets 72-3, 81 attributes 65, 69, 79, 81-2, 99 audit frequency 83 auditing 76, 78, 84, 86 automated software/hardware 42 audits 67, 70, 78, 83, 86 authorization, impact assessment change 62

automated tools 83-4 availability 13, 27, 98 Availability Management 22, 47 Awareness of Change and Configuration Management 34 B

back-out plans 4, 25, 31, 38 back-out procedures 39, 57 balance 54, 56, 78 baselines 67, 80, 101

benefits 2-3, 10, 13, 15, 17, 20, 31, 36, 41-2, 47-8, 54, 69, 76 Benefits of Service Management 4, 13 best practices 9-10, 20, 98

book 2-3, 6, 8-9, 11-12 core 11 browser 7 budgets, organizational 20 business 10, 12-14, 16-17, 19, 21-2, 26, 34, 48, 54, 56-7, 63, 70, 78, 97-8, 101 business alignment 20, 48 business change 63, 97

required 21 business processes 17, 100 business units 68, 84, 87-8 C CAB (Change Advisory Board) 45, 47-8, 53-5, 58-9, 88, 97-8

CAB/Change Manager 52 CAB/EC 47, 53-4, 59 CAB meeting 62 can‟t 22 catalogue 3 categories 52, 98, 100 CCTA 9, 11

centralize 90-1 change 4, 8, 21-3, 34-5, 38, 44-8, 52-9, 61-3, 66-7, 69, 72, 78, 87-9, 97-101 changed legislation Location 45 detrimental 43 independent 78 insignificant 49 managing organizational 20

negative 59




passwords 44 pro-posed 100 required post 54

single 56, 98 Change & Release Management 72 Change & Release Management implementation 72 Change Advisory Board, see CAB Change and Configuration Management process 43 Change and Configuration Management processes 60 Change and Continuous Improvement 4

Change and Re-lease Management 81 Change and Release Management 65, 72 control of 99 Change and Release Management process 72 Change and Release team Size 73 Change Authority 98 change backlog 21

Change builder 46, 48 change categorization 52

change control 97 change history 98 change implementation wither 88 Change Management 4-5, 8, 21, 23, 29-31, 38-9, 42-4, 47-9, 60-2, 72-3, 87-9, 98

control of 58, 99 Configuration Management xf0b7 42 Change Management and Configuration Management 29-30, 88 Change Management and Problem Management 67 Change Management Concepts 4 change management procedures 44, 62 Change Management process 4, 43, 45, 50, 57-8, 60, 66, 88-9

aligned 67 effective 61 robust 43 change management processes 89 change management role 60 Change Manager 43, 54-5, 59, 98

Change Mgt 97

change models 47, 62 complex 47 defining 47 Change on Business Processes 100 change procedures, normal 53 change rates, high 63

change ratio 63 Change Record documents 98 Change Records 98-100 change request 87 change slots‟ 60-1 change 58 organizational 20

change date 46 Changed business requirements 45

changeover 76 change‟ xf0b7, independent 78 CI (Configuration Item) 30, 49, 63-6, 69, 76, 78-9, 82, 84, 87, 89, 91, 98-101 CI change 62 CI fleet 75

CI information 68, 86 CI levels 78 CIs (Configuration items) 30, 38-40, 64-6, 69-70, 73-84, 86, 91, 97-9 CIs, authorized 65-6 Classification 52, 98 CMDB (Configuration Management Database) 4-5, 29-30, 34-5, 38-41, 68-71, 73, 75-6, 78, 80-3, 86-7, 89,

97-9 CMDB information 67, 69 communication 9, 14, 21, 39-40, 61, 93, 96-7 Complete Certification Kit- Second Edition Copyright 2




complexity 13, 27, 68-9, 73, 89-90 components 27, 35, 45, 57, 64-5, 69, 78, 80, 87, 97, 99-100 concept 10, 15-17, 23, 28, 43, 45, 65-7, 95

configuration 8, 24, 35, 48, 60-1, 67, 72, 80, 83, 97-9 configuration control 65-6, 99 Configuration Identification 99 Configuration identification and CIs 77-8 Configuration Item, see CI Configuration Items 30, 65, 69, 84, 87, 89, 91, 98-101 Configuration items, see CIs

Configuration Management 5, 35, 42, 60, 64-8, 72-3, 75-9, 81, 84, 86-8, 99 Configuration Management Database, see CMDB Configuration Management Planning 65 Configuration Management Plans 65, 73, 78 Configuration Management process 43, 60, 64, 71, 73, 76, 78-9, 87, 89 configuration management system 76, 87 Configuration Manager 76

Configuration Records 97, 99 Consider Change 75

consolidation phase 18 control 8, 43, 54, 64, 66, 68, 72-3, 78, 80, 87 control information 89, 91 Control Support Tools Quick Question 91

conventions, naming 65, 78, 80, 101 costs 10, 13, 36, 42, 48, 54, 69-70, 78, 91-2, 98 creation 7, 33, 80, 94 criteria, change approval 59 Critical Success Factors (CSFs) 21 CSFs (Critical Success Factors) 21 CSFs for Change Management 21

CSIP 20-2 Cultural change 20-1 customers 8-10, 13-14, 16, 19, 49, 56, 68, 81, 89, 99, 101 D danger 51

data, organization‟s 81

Data Repository 69 database 68-9, 89, 91, 99 Definitive Hardware Store, see DHS Definitive Software Library, see DSL delivery 11, 16, 21, 81, 99 delta 25, 28, 99

Deming Cycle 18 department 8, 14, 21, 51, 56, 61, 65, 68, 79, 89, 93 design 5, 36-9, 69, 71, 73, 93, 100 designations 2 Details of Change builder 46 development 10, 29-30, 35, 57, 71, 80-1 application 34-5, 39, 57

DHS (Definitive Hardware Store) 4, 30, 89, 99 diagram 23, 27, 89, 94

direction 19, 22 distribution 23, 31, 35-6, 41-2, 98 distribution procedures 34 documentation 17, 29-30, 33, 36, 43, 65, 69-70, 82, 88, 98-100 don‟t measure 22

DSL & DHS 33, 41, 70, 75 DSL (Definitive Software Library) 4, 29-30, 35, 68, 86, 89, 99 duplication 14, 33, 81-2 E eBook 3

free 3 education 6, 9-10, 21, 23, 97 Edwards Deming 18 effort 14, 47, 78




EFQM (European Foundation for Quality Management) 10 Emergency Changes 25 emotions 20, 23

End-user organization/representatives 41 environments 25, 35, 48, 69, 72, 81, 100 errors, known 61, 66, 68 European Foundation for Quality Management (EFQM) 10 evaluation 58 F

filtering 51 flow charts 74, 93 focus 4, 10-11, 13, 16, 79, 81 Forward Schedule of Change, see FSC Foundation Certificate 8 framework 6, 9, 17 frequency 26, 73

FSC (Forward Schedule of Change) 45, 47, 54, 59 functional areas 15

Functionally Oriented Organization 14 functions 9, 31, 61, 72, 78, 89, 95, 98, 101 G

goods 81, 99 government 9 groups 14, 20, 39, 47, 57, 59, 73, 88, 94, 96, 98-9 growth, organization conventions Permit 80 guidance 9, 33, 42, 77, 95 guide 7, 9, 11, 21, 78, 92

H handbook 40, 77 hardware 16-17, 24-5, 28, 30-1, 33, 39, 42, 65, 69, 78, 80, 88-9, 99-101 changing 56 hardware upgrades Emergency software 25

I

identification 25, 64-5, 77 impact 10, 27, 43, 52, 57-8, 88, 97, 100-1 impact assessment 85, 87 implementation 4-5, 10, 27, 32, 35-6, 47, 57, 60, 67, 70-2, 74, 87-8, 97 phased 72, 76 implementation approach 72

in-house 11, 81 Incident 45, 69, 98, 100-1 incidents 25, 31, 43, 66-8, 87, 93, 98, 100-1 industry 6, 10 information 2, 6, 11, 13, 29-30, 37, 39, 41-2, 61, 64, 68-9, 78-9, 84, 89, 93, 97-9 [2] information service 72 infrastructure 8, 17, 25, 27, 34, 40, 43, 49, 54, 61, 63-4, 67-70, 72, 87, 89, 97 [1]

organizational 92 infrastructure components 72

Infrastructure Library 4, 9-10, 12 infrastructure Change size 73 initiative 20 initiator 52 installation 41-2

instructions, release assembly 38 international standards, growing acceptance of 90-1 Internet Explorer 7 IPRC Certification Exam 8 IT Service Management (ITSM) 4, 6, 8, 10, 13, 16, 21, 28, 63, 81, 99 items, changed 28

ITIL compliance 92 ITIL Framework 12-13, 17 ITIL Practitioner Release and Control Certification Exam 8 ITSM, see IT Service Management




ITSM processes 69, 78, 81, 83-5 itSMF 10 it‟s 21-2

J Joint sessions 41 K key, enrolment 7 Key Performance Indicators, see KPIs

Key Success Factors (KSFs) 65 knowledge 22, 34, 60 KPIs (Key Performance Indicators) 8, 21-2, 41 KPIs for Change Management 21 KSFs (Key Success Factors) 65 Kubler-Ross, Elizabeth 23

L lanes, swim 93, 95

languages 10, 42-3 common 9-10 legacy 22 lessons 22, 58

liability 2 life cycle 65-6, 82, 97 lifecycle 86, 98-100 linkages 82, 85 list 21, 31-2, 49, 79, 92 live environments 24, 34, 67, 100 locations 46, 65, 67, 99

logging 51, 67, 84, 87 loss/theft 81-2 M management 8, 10-11, 13, 17, 32, 61, 65, 67, 73, 76, 80, 84 license 68

managing 8, 10, 29-30, 38-9, 84

maturity 20 medium 22, 53, 56 meeting 42, 44, 47, 55, 59 Metrics 41, 60, 62 metrics, change mgt 62 Minor software release 25

models 9, 18, 23, 47, 50 modifications 57-8, 98 money 90-1 N number 21, 34, 38, 41, 48, 53, 56-7, 59, 63, 78-9, 98, 101 large 9, 48, 62-3

66, 85

O objective tree 4, 17 objectives 12, 17, 19, 36, 72 organizational 13, 17 OGC 19-20, 22

OGC ITIL Service Delivery Book 22 OGC Service Support text 31, 40 online 3 Optimal support 69 organization name 72 Organization Perspective 16

organization priorities 20 organizational benefits 21 Organizational drivers 21 organizational perspective 16




organizational standards 33 organizations 4, 9-10, 13, 15, 17-22, 26, 31, 33, 47, 60, 67-73, 75-6, 78-9, 81-2, 86, 89-93 [6] changing 91

external 94 organizations delegate elements 73 organization‟s Release Management Policy 36 organization‟s reputation 84 Oriented Organization 4 Outsourcing organizations 48

P paper-based form 89, 91 person 2, 6, 46, 94, 99, 101 perspectives 4, 16 Phased rollouts 40 PIR (Post Implementation Review) 45 PIR/Change Review 45

planning 4-5, 9, 24, 33, 36-7, 39, 53, 58, 60, 65, 72, 74, 100 Planning to Implement Service Management 20

Planning to Implement Service Management Quick 22 plans 8, 18, 33, 38-9, 56-7, 73, 75-6, 91 change management 89 platform 33, 38-9, 73

populate 75 Post Implementation Review (PIR) 45 practices, change management 70 practitioner 4, 11 preventative measures 90-1 priorities 52-3, 70, 72 Priority 53, 100-1

Problem 20, 60, 69, 98-101 Problem Management 52, 61 procedures disposal 33, 82 registration 81 Process Control for Configuration Management 5, 85

process implementations 65

Process Organization and Design 5 procurement 82-3 program 7, 16, 20-1, 27-8, 45 eLearning 4, 7 Projected Service Availability, see PSA prompts 94

PSA (Projected Service Availability) 45, 47, 54 publisher 2 Q Quick Question 14-15, 28-30, 38-9, 43, 50, 58, 60, 62, 64, 75-6, 79, 85, 97 R

RACI model 95 receipt 81, 83

Regimented organizations 21 registration 29-30, 65, 81 relationship information 79 maintaining 79 relationships 5, 8-10, 29-30, 64-5, 69, 79-82, 86-7, 89, 97, 99

strong 10 Release 4, 25, 33-5, 38-9, 43, 46, 60-1, 69, 72, 98-100 Release & Control Implementation 4, 19 Release & Control Practitioner certification exam 6 Release & Control Practitioner program 6 Release and Configuration Management processes 8

Release and Control 2-101 Release and Control processes 4, 8, 43 Release and Control Support Tools 5, 91 Release Business Management Reports 36




Release Management 4-5, 23, 25, 32, 34-6, 38, 42, 65, 67, 72, 75, 87-8, 97, 99 Release Management and Change Management 88 Release Management and Configuration Management processes 8

release management benefits 4, 31 release management process 4, 24, 36-7, 72, 89 release management staff 33 Release Managers 34-6 release planning 37, 39 Release Policy 26, 33, 35, 37 Release Procedures Handbook 38-40

release schedule 40 release units 27-8, 40, 99-100 releases 24-6, 28, 30-1, 33, 37-41, 48, 53, 68, 72, 80, 85, 89, 97 package 28, 38, 56, 97 Reporting for Change Management 62 reports 42, 59-60, 63, 66, 83 representatives 88, 98

request 45, 83, 89, 98-101 Requests for Change, see RFC

resource shortages 90-1 resources 20, 47, 52-3, 58, 73, 78, 93, 97 responsibilities 10, 34, 38, 59, 65, 73, 78, 82, 95, 100-1 reversal, complete 31

reverse 94 review 3, 22, 36, 54, 58-9, 67, 80, 84 RFC (Requests for Change) 25, 30, 45, 51, 61-2, 66, 80, 84, 89, 100-1 risks 19-20, 31, 43, 54-6, 97 Roles of Configu-ration Manager and Change Manager 101 roll 25, 40 Rollback plans 38

rollout 23, 38, 56 Row 95 S sales 17-18 scope 24, 43, 57, 60, 64-5, 72, 98

Second Edition Activities 37

Second Edition Activities for Configuration Management 77 Second Edition Allocation of priorities 52-3 Second Edition Assessment 54 Second Edition Baseline 99 Second Edition Brainstorming techniques 94 Second Edition Build 57

Second Edition Change Advisory Board 47 Second Edition Change and Continuous Improvement 18 Second Edition Change Management 88 Second Edition Change Management Concepts 45 Second Edition Change Management Procedures 5 Second Edition Configuration 81 Second Edition Configuration Baseline 67

Second Edition Configuration Management Concepts 65 Second Edition Configuration Management Database 68-9

Second Edition Configuration Management planning 78 Second Edition Dealing 23 Second Edition Depending 86 Second Edition Identification of configuration baselines 80 Second Edition Integrity of configurations 83

Second Edition Items 46 Second Edition Legal Obligations 70 Second Edition Manager 73 Second Edition meeting agenda 55 Second Edition Most 42 Second Edition Outsourcing 48

Second Edition Planning 74 Second Edition Planning and Implementation 72 Second Edition Points 32, 49, 71 Second Edition Process Organization and Design 93




Second Edition Release 26, 31, 34, 100 Second Edition Resolution 101 Second Edition Roles 59

Second Edition Table of Contents 4 Second Edition Tool selection 92 Second Edition Write 3 Service 25, 43, 84, 98-101 service availability 47 Service Continuity Management 70, 72 Service Continuity Planning 69

Service Delivery 10, 17 Service Desk 41-2, 47, 57, 59-61, 67, 88, 97, 101 Service Level Agreement, see SLAs Service Level Agreements 61, 69, 80, 101 Service Management 4, 6, 8-13, 16-17, 28 Service Management Processes 20, 87, 99 service management software 92

service management tools 92 Service Provider 13, 98-9, 101

service provision 10, 31, 39, 57 service quality 10 Service Requests 99, 101 Service Support and Service Delivery 11

service 13, 25 services 2, 8, 10-11, 13, 16-17, 23, 26, 29, 31, 34, 43, 54, 64, 72, 84, 97-101 [3] customer 17 support of 11, 87 services 13, 48 sheets 94 single change policy 56

skills 8, 24 SLAs (Service Level Agreement) 33, 47, 55, 58, 61, 69, 80, 85, 88, 99-101 SOE (Standard Operating Environment) 28, 57 software 16-17, 23-5, 28-9, 31, 35, 39, 41-2, 65, 68-9, 78, 80-1, 88-9, 99-101 software CIs 29, 83 software components 31

software development configuration management tools 86

Software Installation 52 software releases 25, 35, 68 software tools support 9 spare infrastructure hardware 30 spreadsheets 68-9, 73 staff 16, 21-2, 33-5, 38-40, 47-9, 52, 56, 60-1, 76-7, 80-3

trained 34, 76 stakeholders 19, 33, 42, 59, 77, 97 Standard Change 101 Standard Operating Environment (SOE) 28, 57 statement, mission 19 storage, physical 29-30, 70 strategy 16, 31

substitute 94 supplier organizations 11

suppliers 48-9, 81, 92, 94, 97-8 support 10-11, 20, 43, 60-1, 64, 78, 85-6, 91 support groups 72-3 support tools 34-5, 48, 62, 69 systems 42, 44, 60, 72, 81-2, 85, 98-9, 101

organizations‟ HR 82 T team 73, 75, 84, 101 technique 94-6 technology 12-13, 68, 73, 82

test environments, organization's 39 tools 6-7, 16-17, 21, 31, 35-6, 60, 65, 69-70, 84-5, 89-92, 100 trademarks 2 training 35, 40-1, 60, 91




training organization 6 types 14, 26, 63, 95, 98

U UAT (user acceptance testing) 39 un-required/unused software/hardware 42 unauthorized additions 29-30 updates 66-7, 81-2 Updating 81-2 upgrades, change software 52

URGENT CHANGE 53 user acceptance testing (UAT) 39 users 7, 39, 42, 48, 53, 56, 58, 68, 74, 87-9, 99, 101 utilities 34-5 V value 3, 9, 19, 52, 66, 79, 84-5

Variants 69 vendors, multiple 90-1

verification 64, 67 Very large organizations 9 vision 16, 19, 22 vulnerable period 82

W Workarounds 101 www.emereo.org 3