ITIL Practitioner Release and Control (IPRC) All-in-one Exam Guide and Certification Work book; CMDB and IT Service Management with Change Management, Release Management and Configuration Management

ITIL Practitioner Release and Control (IPRC) Certification Workbook CMDB and IT Service Management with Change Manageme...

Author: Gerard Blokdijk

50 downloads 888 Views 3MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

ITIL Practitioner Release and Control (IPRC) Certification Workbook CMDB and IT Service Management with Change Management, Release Management and Configuration Management Gerard Blokdijk

ITIL Practitioner Release and Control (IPRC) Certification Workbook Copyright © 2008 by Gerard Blokdijk 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 he 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.

3

COURSE OVERVIEW

To ensure quality and consistency of the services provided to its customers, IT departments must control what is in the infrastructure and manage how and when changes are made. By effectively implementing the Release and Control processes within an IT infrastructure, this goal can be achieved. In this course, you learn how to plan, implement and optimize the Change Management, Release Management and Configuration Management processes. Through interactive workshops, 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 the level ITIL Foundation Certification is assumed.

Examinations ITIL Practitioner Release and Control Certification Exam.

The Art of Service Email: [email protected] | Web: http://theartofservice.com | eLearning: http://theartofservice.org Phone: +61 (0)7 3252 2055 | Brisbane, Australia

4

COURSE OUTLINE

Introduction and Overview • • • •

Managing, organizing and optimizing the Release and Control processes Controlling the changing environment Ensuring quality releases Mapping the configuration environment

Planning the Key Release and Control Activities Change Management • • •

Determining the objectives and scope Defining the roles and responsibilities Performing risk assessments and obtaining approval

Release Management • •

Establishing release policies Planning the monitoring and reporting of process effectiveness

Configuration Management • • •

Defining the Configuration Management Database (CMDB) scope Determining Configuration Item (CI) naming conventions Planning for CMDB data discovery, collection and population

Exchanging Information • •

Establishing information exchange between the Release and Control processes Integrating with other Service Management processes

Monitoring and Reporting • • • •

Monitoring and managing the Release and Control activities Identifying key issues impacting effective operation Establishing metrics and management information Developing and monitoring critical success factors and key performance indicators The Art of Service Email: [email protected] | Web: http://theartofservice.com | eLearning: http://theartofservice.org Phone: +61 (0)7 3252 2055 | Brisbane, Australia

5

Maintaining the Procedures • • • •

Mapping Release and Control procedures to daily work activities Defining criteria for Change prioritization Planning resource allocation for releases Ensuring CMDB quality through verification and audit

Establishing Change Management Classifying, Prioritizing and Approving Changes • • • • • • •

Standard Intermediate Urgent Emergency High Medium Low

Change Manager Responsibilities • • •

Filtering Requests for Change (RFC) Selecting Change Advisory Board (CAB) and CAB/Emergency Committee membership Ensuring effectiveness through post-implementation review

Release Management Activities Planning for Releases • • •

Release identification Determining requirements for full, delta and package releases Establishing Definitive Hardware Store (DHS) and Definitive Software Library (DSL)

Designing, building and configuring Releases • • •

Build management Ensuring fit-for-purpose testing Constructing back-out plans

Distribution and installation • •

Training and communicating to all stakeholders Considering all technical and non-technical aspects of Releases


6

Applying Configuration Management • • • •

Managing physical and logical relationships Establishing CI attributes Confirming software license compliance Identifying downtime through Status Accounting

Optimizing the Release and Control Processes • • • • • •

Analyzing process outputs Proposing process improvements Utilizing key performance indicators Implementing reviews for process effectiveness Establishing ongoing quality improvements Applying quality standards


7

Slide 1

i-Track Practitioner Program ITIL Release & Control Processes

All course material is copyright The Art of Service Pty Ltd (ABN: (ABN: 19 095 825 308) It is forbidden to use this material other than than for study purposes. It is not allowed To change, copy or store this course material in any way or form without prior written Approval of The Art of Service Service Pty Ltd. [September 2001] Approval for commercial purposes will never be granted.

Welcome to this “Clustered Practitioner Program” from The Art of Service.

This program is fully accredited by the globally recognized accreditation agency for IT Service Management programs – EXIN.

The program has been developed and accredited in accordance with guidelines provided by EXIN.


8

Slide 2

Introductions

Your presenter

You

The Art of Service

Your role(s) Your experience

2

© The Art of Service 2005

Space for notes about your Instructor:

Space for notes about your fellow students:


9

Slide 3

Program



Learn – theory and from others Evaluate – the good, the bad Test/Review – in course assessments Prepare – practice for your exam



Times of day are not important at this level.

  

3


We have a lot to get through and we’re all mature enough to collectively agree that when we need a break we’ll take one.

Lunch is around the middle of the day, but other than that the times are flexible.

The idea of this program is to allow you the opportunity to LEARN – to learn from each other and to learn from the instructor. However, you are your own greatest teacher and these next few days give you the opportunity to learn if you want to take it.

We’ll take a close look at what we learn. We’ll investigate it, diagnose it, discuss it and EVALUATE it.

We’ll TEST what we’ve learned – through presentations, in course assessments and mock examinations. This is all designed to help you retain knowledge. Then you will have time to PREPARE for your real examination.


10

Slide 4

Agenda 

Day One: – – –



Day Two, Three, Four – – – –



General Introduction ITSM Overview Exercises, formal assessment

Process Goals, Activities, relationships Procedures & Work Instructions Reporting Exercises, formal assessment

Day Five – –

Exam preparation, revision, Mock exam, feedback (EXAM)

4


A pass in the IT Service Management – Foundation certificate is a prerequisite for this course.

Day 1 It may have been a while since you took this exam or underwent the study. Therefore, some time will be spent on going through the entire ITIL model. Special focus will be on the relationships between Release Management, Change Management and Configuration Management processes.

Days 2 to 4 Covering the specific processes in detail and (most importantly) their relationships to each other and other ITIL processes

Day 5 Review of the course material, study time, mock examination, marking and review (there is more on the exam shortly).


11

Slide 5

Course Objectives    

Understand the Release, Change and Configuration Management processes Understand the relationships with all other IT Service Management processes. The Release, Change and Configuration Management activities in detail. Preparation for the EXIN Practitioner Exam – –

120 minutes 40 multiple choice questions (pass mark = 26 points)

5


The ITIL Practitioner Release and Control is intended for professionals who will participate in managing, organizing, and optimizing, the operations of the Release and Control processes in an IT Service organization.

Typically such organizations will have implemented, or started to implement, elements of the ITIL Framework or may be looking to make improvements in these process areas.

Notes:


12

Slide 6

Course Approach 

Presentations



Discussions



Exercises



Hand outs

–

–

–

–

Slide handouts in your binders Exchange experiences Going through the process of reaching a solution Reference materials for back in the office: 

 6

Text book, Fact sheets

Assessment © The Art of Service 2005

As you can see from this slide, the program is not one that is dominated by slide material and traditional instructor lead delivery.

The program requires discussion and healthy debate. We use the slides to generate discussion and we provide specific discussion points that will help bring the theory into real terms for you.

We will also be spending a large amount of time on exercises. Exercises help to enforce the learning process and give you an opportunity to practice a variety of skills (presentation, sales, dealing with difficult audiences).


13

Slide 7

Assessment



Step 1 - In Course assessments and exercises



Step 2 - Preparation and study for the formal assessment (exam)



Step 3 - Taking the formal assessment (exam)

7


Let’s spend just a few minutes on the assessment side of this program.

You can read later the information from EXIN regarding the assessment (Track Description). The first step in the process is participation using classroom exercises (which could be verbal or written). Also included in this step are the three formal assessments that cover the Management, Organization and Optimization of each of the Release, Change and Configuration processes.

The second step is time you will spend preparing: revision, study, analysis.

Finally, you will sit the exam. The exam format is 40 multiple-choice questions, which have to be answered within 2 hours.


14

Slide 8

Exercise: Expectations

8


Your instructor will explain the Exercise:

Expectations – Mine 1 2 3

Expectations – Others 1 2 3 4 5


15

Slide 9

ITIL Model Planning to Implement Service Management Service Support Security Management

ICT Infrastructure Mgt.

Service Delivery

The Technology

The Business

The Business Perspective

Applications Management Software Asset Management 9


The IT Infrastructure Library is a set of books/CDs with best (good) practice processes on how to manage the provision of IT services. It is the “process” part of the Service Management challenge (people, process and technology).

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


16

Slide 10

Why Service Management?       

Business more dependent on IT Complexity of technology increases Customers demand more Environment becomes more competitive Focus on controlling costs of IT Low customer satisfaction Falling credibility of some IT organizations

10


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. More and more 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 technology, not the processes; it is the organizational objectives.


RESULT

17

Slide 11

Most businesses are hierarchically arranged. They have departments, which are responsible for a

The Functionally Oriented Organization

ees. There are various ways of structuring departments, for example by customer, product, region

GOAL

GOAL

GOAL

ACTIVITIES

ACTIVITIES

ACTIVITIES

ACTIVITIES

GOAL

GOAL

Quick Question: FEEDBACK

RESULT

RESULT

RESULT

RESULT

RESULT

the lines decide 11 (select one of the following)

ACTIVITIES

FEEDBACK

FEEDBACK

FEEDBACK

FEEDBACK

In this type of arrangement we often see that:


a) Communication is ineffective b) Inter department activities are clearly defined c) Processes are optimized to reduce duplication of effort


to IT functional areas?

18

Slide 12

YES/NO

The Process Driven Organization

Space for naming some IT Functions:

12

the processes decide



19

Slide 13

IT Service Management (ITSM) Focus

13


Fill in the blanks:

More and more people see the importance of ___________ (the primary purpose of this program is studying some of these in detail).

The ______________ issue ensures that we align the vision, strategy and goals of the business with the delivery of IT services.

The _________ issue is without doubt where we – as IT Service Management professionals face our greatest challenges.

Historically, the ____________ considerations got most attention. Now we understand that without well-defined processes we can often make inappropriate selections in this area.


20

Slide 14

Service Management = The Objective Tree = Quality Flexibility Cost management

ORGANIZATION

Ho

IT SERVICE PROVISION

organization

t? ha

effective

/W

! hy

w

W

BUSINESS PROCESSES

efficient effective IT service provision

efficient

14

SERVICE MANAGEMENT


So 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 in showing the benefit and alignment of IT and Service Management principals to the business, but also in being able to effectively sell the concepts as well.

See if you can follow along in the following paragraphs 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).


21 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 provides 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.


22

Slide 15

Change and Continuous Improvement P_____D___C_______A___ Ongoing measurement of: -

Benefits Realization, ROI

-

Continuous improvement

P

D

A

C

No one said it would be easy !

Power and Authority

e e enc ang end al Ch p e n rd tio Inte aniza Org tance y Resis ge enc l Chan Urg ultura f C o lition se Guiding Coa Sen

Reason for Change 15

Issues to Address

Source: Kotter, Deming

Instrumental Social / Emotional Negotiation Create/Communicate Vision

Embedding the Change

TIME


If we accept that the challenge of Service Management is more than the simple implementation of processes, we can start to appreciate new dimensions. This model combines the works of two famous authors – Deming and Kotter.

Have a look at the Deming cycle first of all. PDCA! Fill in the blanks above as you discuss with your instructor this cycle of continuous improvement.

Now review the Kotter model for organizational change. Sense of urgency = ______________________

During the implementation of any aspect of organizational change (including Service Management/the ITIL Framework) you will come across many issues that Kotter summarized as: Interdependence (of independent units or people) The need for organizational change (move from functional to processes) Resistance (loss of control and vulnerability) Cultural change (information sharing rather than power play)


23 The need for a guiding coalition (senior management support)

Kotter said that the effects or outcomes required from the challenges are: Shift in power and delegation of authority Instrumental (new org. chart and policies/procedures) Social/Emotional (new relationships and teams) Negotiation (common goal, shared values) Continuous communication of the vision


24

Slide 16

Questions? + Time for Self Study

16


Notes:

Self Study

Read and digest the assigned Case Study. Start to imagine that you are part of this organization, as assessments and presentations will be based on it. Read and make notes on the following sections of the Service Support Text book: Appendix B (Process Theory and Practice) Appendix C (Implementing) Appendix D (Quality) Appendix E (Cost Benefits)


25

Slide 17

Exercise •Presentation to Board of Directors Structured approach

E-mail to Financial Controller Cost Benefits

Don’t forget who the reader/audience is Use familiar language for them (not you) Not a technical discussion 17


Notes:

Exercise/Home work

Prepare a presentation to the case study Board of Directors in which you outline the requirement to adopt a structured process framework for IT infrastructure management. Write an e-mail to the Financial Controller of the case study organization discussing the cost benefits of improving the quality of IT Service provision to the company.

In both exercises, ensure you remember who your audience is. Work of this nature will not necessarily be technical in nature and must be expressed in terms that are familiar with the reader/audience.


26

Slide 18

Managing an Implementation Release & Control

18


Notes:


27

Slide 19

Release & Control Implementation 1. Where are we now? A C

P D

2. Where do we want to be? 3. How will we get there? 4. How do we know when we’ve got there? 5. How do we keep going?

19


Derived from the OGC – Planning to implement Service Management

While it isn’t mentioned in the slide the first real step is to create a “VISION”. It’s the summary statement of “where do we want to be?”

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?”


28

Slide 20

Release & Control – Implementation

Where are we now? 

How mature is our IT organization?

Value Chain equal Business integration es tag Customer focus 5s Service extension of m

rity atu

Technical



basics

How mature are our IT processes? –

Baseline Scan

20


Elements derived from the OGC – Planning to Implement Service Management

IT organizational maturity progresses through a variety of stages (Technology focus, Product/Service focus, Customer focus, Business focus, Value Chain).

To move from one stage to the next requires management and control over people, processes, technology, steering, attitude and changing relationships between the business and the IT organization.

IT process maturity is best measured by using an assessment tool for a more detailed analysis. A variety of such assessments can be carried out as “self-assessments” as well as commercially available solutions. (Also discussed in the next slide)


29

Slide 21


Where do we want to be?     

First – is there a business case? What risks do we face? ice rv e What gaps have to be bridged? S us m uo gra The “GQM” paradigm n i o t on t P r Tools assessment = C men

GQM =

Goal s/ Q

uesti

IP v e CS pro Im

ons/M etrics

21



The first and most important question that needs to be answered 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).

With regards to Risk Management we must remember that this initiative is not the only one competing for organizational budget. What is the effect on other initiatives if this IT initiative is successful at attracting funds? Also what risks will be faced after the program has begun? The salient point is that risks will always be present, so don’t 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 5 level model of maturity is defined in the OGC “Planning to Implement Service Management” text (Initial, Repeatable, Defined, Managed, Optimized).


30

Slide 22


How will we get there?       

Starting point determined by maturity Awareness campaign Managing organizational change Cultural change Roles & Responsibilities Education Tools

22


Elements derived from the OGC – Planning to Implement Service Management (Notice some of the concepts raised by Kotter creeping through – the fundamentals are all the same).

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 isn’t 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, involvement and communication).

Cultural change is largely reflected in the leadership/management style that is prevalent/dominant in the organization. Remember that some organizations suit dominant leadership styles (e.g. Regimented 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 existing staff (overload) or the conflict that could arise when processes are implemented across traditional hierarchical models.


31 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 process? 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 accepted principle is that the processes should be supported by the tools and not the other way around.

(Service Management tools are covered later in the program)


32

Slide 23


How do we know when we’ve got there? 

Critical Success Factors (CSFs)



Key Performance Indicators (KPIs)



Organizational drivers 

23

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 repeatable 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 that are 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 down 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.


33

Slide 24


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

24



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 done 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, provided that 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 data/information/knowledge.


34

Slide 25


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.

Exercise In groups based on your current knowledge of Release, Change and Configuration Management list two KPIs for each process. 25


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 mentioned in Availability management, the message is applicable to all process areas.

KPIs for:

Release

Change

Configuration


35

Slide 26

Dealing with learning and change A follow up point – Resistance to change Emotion

denial

embedding

anger motivation negotiation

acceptance Source: Elizabeth Kubler-Ross 26

Time © The Art of Service 2005

Time to share 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.

The key point is that this is natural. You cannot bypass the emotions, so don’t try to and don’t try to jump over one.


36

Slide 27

Day 2 – Release Management

Notes:


37

Slide 28

Review Day 1       

28

Process vs Functional organizations 4 perspectives of ITSM Objective Tree Deming and Kotter Philosophy of continuous improvement Implementation stages KPIs, Resistance © The Art of Service 2005

Notes:


38

Slide 29 Change Management

Release & Control Processes

esk Service D

Release Management

Availability Management

Financial Management

security

Capacity Management

IT Service

Continuity Management

Release Management

for IT services

IT language of the Release, Change and Configuration Let’s now have a look at some of the concepts, terms and Service Level Management

Management process.

Infrastructure

Configuration Management Incident Management 29

Problem Management © The Art of Service 2005

Remember that these slides are based on the ITIL Theory, but they are designed to provoke thought and discussion. The true definition of the processes come from the definitive ITIL text.

Notes:


39

Slide 30

Release Management = Goal of the process =

Release Management conducts management and distribution of _________ and __________ versions in use, which are required to provide IT services in order to comply to agreed levels of service

30


… or to put it another way…

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?

Notes:


40

Slide 31

Release Management SCOPE 

The scope of Release Management –

Planning, design, build, configuration and testing of hardware and software to create a set of Release components for a live environment.

Source: OGC Text Service Support, Scope of Release Management 31


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.

Notes:


41

Slide 32

Release Management Concepts        

Release definition (& identification) Release Policy & Planning Release unit Release Types (full, delta, package) DSL DHS CMDB Build, Test, Back-out plans

32


We will spend the next few slides exploring the basic concepts of Release Management.

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.

Notes:


42

Slide 33

Release - Definition

33



A collection of authorized changes to an IT Service



Defined by the RFCs that “it” implements


Both of the definitions show the strong, unbreakable link to Change Management.

Essentially, the definition is telling us that we cannot have a release without having an associated Change.

Notes:


43

Slide 34

Release - Identification Typically Releases identified as: Major software releases and hardware upgrades



Minor software release and hardware upgrades



Emergency software and hardware fixes

34

Release Identification




This breakdown of identifying releases is an EXAMPLE (from the OGC Text).

Associated with these breakdowns we also need to have a UNIQUE NUMBERING SYSTEM.

LINK THE FOLLOWING EXAMPLES TO THE MOST RELEVANT DESCRIPTION

Version 1.0, 2.0 Emergency Fix

Version 1.1., 2.1 Minor

Version 1.1a, 2.1.1

Major

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. The Art of Service Email: [email protected] | Web: http://theartofservice.com | eLearning: http://theartofservice.org Phone: +61 (0)7 3252 2055 | Brisbane, Australia

44 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.


45

Slide 35

Release – Policy & Planning Contents of the Policy    

Numbering Frequency Times IT Infrastructure level

35


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 is permitted by the business.

Give examples of times that a business may consider inappropriate for “releases”

1. 2. 3.

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.


46

Slide 36

Release Units 

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

OGC Service Support text 36


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 units we need to fully 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 dependant 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.


47

Slide 37

Release Types

Release Unit

Delta Full Package

37


Thought challenge 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)


48

Slide 38

Release Management  



38

Definitive Software Library DSL secure compound where definitive authorized versions of all software CI’s 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 hasn’t been released. storage of software items installation scripts images firmware manuals block diagrams development specifications


49

SPOT QUIZ If the DSL holds the “actual” software, where do we store information about the software?


50

Slide 39

Release Management 

management of the DSL –

contains agreed versions of software 

source codes, objects, executables, etc. including the related documentation

–

authorized master software, without unauthorized additions

– –

fully separated from the development, testing and production environment physical storage of up-to-date and undamaged storage media

–

approval by Change Management







licences are paid

disk, tape, cd, …

registration in CMDB

What are the challenges involved in the DSL? 39


How do I manage more than one DSL?

What is the relationship to Change Management and Configuration Management?


51

Slide 40

Release Management  



40

Definitive Hardware Store DHS a secure storage of definitive hardware spares


The DHS (Definitive Hardware Store) is a physical storage area for spare infrastructure hardware. Items in the DHS should be referenced in the Configuration Management Database (CMDB).

SPOT QUIZ If the DHS holds “actual” hardware, which process can utilize the actual equipment held there?

Notes:


52

Slide 41

Release Management  management – physical  

stock spare parts including the related documentation stock basic configurations including the related documentation

– authorized

additions 

of the DHS

storage of agreed hardware

master hardware, without unauthorized

maintenance fees are paid

– fully

separated from the development, testing and production environment – approval by Change Management 

registration in CMDB

41


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?


53

Slide 42

Release – CMDB 

Configuration Management Database –

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

Information about – – –

42

Definitions of a release & links to originating RFC CIs that will be affected by a release 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.


54

Slide 43

Release – Build, Test, Back-out plans



Build



Test



Back-out plans

–

–

– –

reproducible, often automated functional, operational, performance integration, complete reversal contingency

43


This final slide for Release Management concepts introduces the requirement to coordinate building, testing and back-out planning.

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.


55

Slide 44

A BIT OF FUN ! – Word Search r

d

r

r

o

j

a

m

d

f

j

r

t

f

s

f

g

h

j

a

z

x

c

c

f

g

v

l

q

d

e

l

t

a

e

l

k

j

h

y

e

y

j

z

l

d

i

f

m

g

j

z

h

w

q

g

u

u

f

p

f

i

h

a

o

n

p

w

e

k

f

g

o

d

n

g

k

l

w

j

a

p

m

r

j

l

q

o

p

s

t

s

f

g

c

p

e

g

h

s

r

o

d

u

x

n

x

c

k

y

r

h

j

j

i

h

i

q

d

h

s

e

a

m

g

x

e

u

y

s

a

d

f

g

j

z

g

t

e

q

t

a

d

z

p

h

j

h

a

n

e

p

n

c

z

f

x

h

r

m

f

v

b

w

h

w

c

x

q

s

d

f

n

z

v

c

a

f

e

o

y

w

w

w

d

f

g

j

n

d

f

r

e

o

i

44


Time to search for some answers on Release Management.

In the grid above, see if you can track down:

Three types of Release Acronym for hardware store Acronym for software store Three identification categories


56

Slide 45

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 45

of distribution: less risk of incidents © The Art of Service 2005

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 isolation. Benefits can only be derived when all the Release & Control processes are working.


57

Slide 46

Release Management – Points of attention – resistance

from personnel regarding the new way of

working – resistance – time

from development staff

pressure with urgent fixes  (bypassing)

– testing:

ensure an optimally equipped test environment

– awareness:

IT management may find Release Management bureaucratic and expensive

– Out 46

of sync installations (distributed sites) © The Art of Service 2005

It is naïve to suggest that any implementation of a new process will not be faced with some challenges. This list provides a summary of the possible problems that could be encountered.


58

Slide 47

Presentation



Benefits and Challenges More information in the text Case Study



Presentation to:

 

– – –

47

External customers Senior Business Management Application Developers


To help reinforce the benefits and challenges of the release management process; you are to prepare a present an argument for and against the adoption of the release management process within the case study organization.

Remember who your audience is.

The program instructor will assign you to groups and allocate a “presentation group”.


59

Slide 48

Planning & Implementation of the Release Management process

48


This section outlines the steps for planning and implementing the Release Management process.

It is important that we understand this section is looking at planning and establishing the process itself, not actual releases. The day to day activities are discussed later.

Your organization’s release management documentation should give instruction and guidance on all the process activities.

The stakeholders for the release management procedures will include staff that are involved with development, testing, rollout, distribution as well as customers (e.g. for specific training needs) and support staff (e.g. Service Desk/Incident Management).

You will look to create a procedural handbook. It should be located in the same area as the Release Management policy document. The procedural handbook can also be supplemented with a variety of flow charts/diagrams.


60 The ultimate objective for the handbook is to detail how operational staff will actually carry out the day to day activities of Release management.

Notes:


61

Slide 49


Planning – – – – – –



Release Policy Release & rollout planning procedures Release & distribution procedures (Hardware & Software) Release roles & responsibilities Staffing Training

Implementation – –



– Planning & Implementation

Software release & distribution Release manager considerations during implementation

Costs

49


There are a variety of topics that need to be addressed when planning the implementation of the Release Management process.

Listed above, we will now look at each point in further detail.


62

Slide 50

Release Management – 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

50


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.


63

Slide 51

Release Management – Planning 

Release Policy cont’d –

Expected release deliverables

–

Expected standards (documentation, etc)

–

Producing back out plans

–

Managing the DSL & DHS

–

Urgent changes and releases

51


The Release Policy should outline:

expected deliverables for each type of release (e.g. Installation instructions and Release note), standards for creating and storing documentation (tools, use of templates), degree to which back out plans are produced and tested, description of the Release Management control process (e.g. Review meetings, progress assessments, escalation, impact analysis and co-requisites checks), guidelines on managing the DSL and DHS (who, what, when), and procedures to manage urgent changes and releases.


64

Slide 52


& rollout planning procedures

– Plan

procedures, guidance & templates – Inputs:       

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

52


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 procedures 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 management staff to take products from application groups and projects and then to release the software and hardware effectively and efficiently.

There are a series of inputs, procedures and documents that are required to plan the Release and rollout procedures. Refer to the Service Support manual, page 216 for more details.


65

Slide 53


& distribution procedures

– Hardware

– Software

53



Moving from test to live environments



Archiving previous live versions



Backup live data



Consider geographical spread of sites



Minimize number of dependent steps and staff


The detailed issues related to the release and distribution procedures for hardware are included in the ICT Infrastructure Management book.

For both hardware and software releases you need to consider the impact the release will have on your live environment. You should include the business hours (and critical periods) of all sites in this consideration.

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


66

Slide 54


54

& distribution procedures



Updating the CMDB



Rollback plan testing



Release verification



Communication plans & protocols


Notes:


67

Slide 55

Release Management - Planning  Roles

and Responsibilities

– Change

Manager

– Release

Manager

– Test

Manager

– Other

55

“functional” managers (not part of the process)


Exercise:

Locate the example of the “Responsibility Matrix” within Release Management. Study the examples and read the supporting text. Explain and discuss the practical use of such a matrix and how this differs from the concept of “common roles”.

Also discuss the purpose of “control records” listed in the responsibility matrix.

See how the matrix promotes flexibility by allowing certain types of release (i.e. ones that fall within pre-defined operational constraints to be released by functional groups (e.g. Service Desk, Desktop Support, etc.). This reduces the bureaucracy of the process leading to increased IT creditability and overall higher satisfaction


68

Slide 56

Release Management – Planning  Staffing

– Critical

for access to live environment

– Enough – Sound

trained staff to cover absences

technical background

– Awareness

of Change and Configuration Management

– Knowledge

of business (to set priorities)

56


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 essential.

A good knowledge of the business assists in (helping to) set priorities.


69

Slide 57

Release Management - Planning  Training – Technical  

Software maintenance and development Support tools and utilities

– Process  

Change, Configuration, Release Release Policy, procedures, tools

– Organizational 

Business Issues

– End

users staff

– Release 57


Typically the technical training requirements are met well. However, there is a variety of training 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.


70

Slide 58

Release Management – Implementation  Software – Build

Release and distribution

DSL & build environment(s)

– Migrate

current live software into the DSL

& inform Configuration Management (CMDB)

– Test

management & software distribution

– Allow

remediation time

58


Once the DSL & 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 delivered to Release Management for lodging in the DSL and passed to Configuration Management 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.


71

Slide 59

Release Management – Implementation 

To ensure proper adoption, the Release Manager should: –

Champion new processes

–

Monitor uptake and performance

–

Report exceptions to policy

–

Automate Release procedures

–

Ensure staff are thoroughly trained

59


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.

Notes:


72

Slide 60

Release Management - Costs      

Development Education Staff (operate tools, distribution) Storage Spares Tools Discussion: Examples of each

60


Notes:

Development:

Education:

Staff:

Storage:

Spares:

Tools:


73

Slide 61

Release Management - Documentation  

 



Initial Business Justification Release Management Implementation Plan Release Policy Release Procedures Handbook •

DHS and DSL Library Documents

•

Release Review Results

Release Business Management Reports

61


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 implementation 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 to highlight its positive contribution to maintaining a stable production environment.


74

Slide 62

Activities of the Release Management process

62


Notes:


75

Slide 63

Release Management - Activities Release planning Design , build, configure (or order & purchase) Release acceptance & testing Roll-out planning Communication, preparation & training Distribution & installation 63


We will now take a closer look at the actual activities for Release Management. Each topic here is covered in more detail in the following slides.

(The diagram does not represent a flow chart)

Notes:


76

Slide 64

Release Management  release – define

planning the “who, how and when”

– back-out – plan

acceptance requirements

– supplier – site

plans

quotes, negotiations

surveys

64


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.


77

Slide 65

Release Management  Crucial

element of release planning

– Back-out 

planning

certainly if multiple RFC’s 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)

65


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!”

Even if a good back out plan was created what is the primary reason it isn’t used when the criteria for using it are met?

Answer:


78

Slide 66


design, build, configure / assemble –

standard procedures

–

in house or “bought-in” software

–

automated installation routines (accuracy)

–

Configuration management control 

–

Build results stored in the CMDB to allow reuse

Specific test plans for roll-out

66


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 roll-back 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.

Roll-back plans should be developed and later tested. Assumptions should also be documented for each roll-back plan.


79

Slide 67

Release Management  release – test

acceptance and testing

the release beforehand



in a (repeatable) controlled test environment



functional testing by users



operational testing by IT service provision

– also

test the back-out procedures !!!

– when

a release is rejected  back to Change Management! Discussion Points

67


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.

Discussion points. What evidence have you seen of actual user acceptance testing (UAT)? How was it performed (random, structured and controlled)?

Which group of IT staff are often overlooked but could provide excellent insight with regard to testing?


80

Slide 68

Release Management  roll-out

planning

– detailed

roll-out schedule of tasks – list of necessary people – list of CI’s involved – write the activity plan – plan the purchase of hardware and software – purchase, store, identify & register in CMDB – scheduling meetings for involved staff – list

See the next slide for Roll-out options 68


Remember that there is NOT a flow of activities. It is why in this activity step we see the planning of and the actual purchase of hardware and software (and subsequent storage of information 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. The Art of Service Email: [email protected] | Web: http://theartofservice.com | eLearning: http://theartofservice.org Phone: +61 (0)7 3252 2055 | Brisbane, Australia

81


82

Slide 69

Roll out Sequence

69


This slide (the picture is from the OGC Service Support text) helps us to understand the approaches available 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 roll-out in the third release.

Big Bang approach also referred to as:

Phased Roll out also referred to as:

Big bang is generally considered high risk (due to the high impact of failure). Phased roll-outs are only possible where release units of differing versions can co-exist.


83

Slide 70

Release Management  communication, – who     

preparation, training

is involved? (who isn’t?)

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

– joint

sessions for acceptance of releases sessions for training & awareness – health and safety – constraints (eg. Cannot use PC for x hours) – joint

70


Notes:


84

Slide 71

Release Management  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 Discussion Points 71


Discussion point. What tools have you seen that illustrate the concept that distribution and installation can be two separate activities?

Can we implement any one process without implementing all others?

Notes:


85

Slide 72

Release Management –

Process Control

Key Performance Indicators

Management Reporting

72


Notes:


86

Slide 73

Release Management - KPIs        

1. 2. 3. 4. 5. 6. 7. 8.

Ch all en ge !

Hints: Backout, duplication, match, reversion 73


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 don’t generally require a great deal of supporting information to explain them.

The numbers tell the story!

Challenge In groups come up with a list of 5 KPIs that you can share. Leave space for three others that you may learn from others.


87

Slide 74

Release Management Reporting    

74

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 definitions 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?” but “what will be done with it?”.

We have almost limitless aspects that we can report on. So, 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 philosophy).


88

Slide 75

Release Management   

Configuration Management Change Management Software supplied – –

  

Process Relationships

Developers Suppliers

Problem Management Service Desk Project Planning Make the connection!

75

FSC CAB DSL CMDB PRINCE2 TRAINING Update following release RFC © The Art of Service 2005

This slide helps us to understand the importance that ITIL places on understanding relationships between processes and other functional areas.

Make the connection! Connect the left hand column to the concepts on the right and be able to explain the connection.


89

Slide 76

Questions? + Time for Self Study

76


Notes:

Self Study

Tools specific to the Release Management Process Impact of new technology


90

Slide 77

Release Management - Guidance

    

for success

Configuration Management Change Management Release Management Application Design Positioning of software

77


We have covered a lot of theory, now it is appropriate to look at what will contribute to the success of the Release Management process.

Configuration Management – automated software/hardware auditing, data collection, integrity of files (checksums), good status accounting to reduce fees for un-required/unused software/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 distribution 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), time zones.


91 Positioning of software – thin client model, falling cost of hardware may offset the benefits from centrally run, no/controlled local data storage.


92

Slide 78

ASSESSMENT 1 of 4



Release Management Assessment



Presentations, Reports, Procedures & Discussion – – –



Business Management IT Management Peers and work colleagues

Case Study (Maltese Shipping Company)

78


This is a formal assessment for the program.

Your instructor will provide you with a copy of the Maltese Shipping Company. This is the case study for your assessments and it must be used as the context for your submitted work.

This Release Management Assessment has two (2) mandatory parts: Presentation of Release Management, with regard to the Case Study organization, supported by written notes. Presentation of specific process activities and how they will benefit the Case Study organization, supported by notes.

Make sure that your answers provide evidence of your understanding of these topics. A well-written report is like a good story. There needs to be a flow and the reader needs to feel compelled to read through to the end. (TIP: use underlines, bold, italics, bullets, paragraphs, white space – make your answer VISUALLY appealing). A report must provide the information required by the reader to either learn or to assist in decision making.


93

Slide 79

ASSESSMENT 




Present a sound and defendable argument regarding the objective of the Release Management process. Relate your presentation to the case study organization. Presenting to Senior Business Management Supplement the presentation with a written report (or notes in the presentation) that supports your presentation.

  

79

2 of 4


PART 1 – EXTERNAL PROCESS EXPERT CONSULTANTS

Presentation to Senior Business Management. Answer the WHY question as part of this presentation. Involve all group participants in the preparation and presentation.

60 minutes to prepare your concise, business related presentation 15 minutes to present

Ensure that your presentation & report involves all group members – equally.

Your report must address the objective, scope and roles and responsibility definitions and how the process will be managed.


94

Slide 80

ASSESSMENT 




Present a concise explanation on the activities of the Release Management process. Relate your presentation to the case study organization. Presenting to Senior IT Management Supplement the presentation with a written report (or notes in the presentation) that supports your presentation.

  

80

3 of 4


PART 2 – Internal staff that are ITIL aware, presenting to IT staff (who are potentially non-ITIL aware)

Presentation to Senior IT Management. Answer the HOW question as part of this presentation. Involve all group participants in the preparation and presentation.

60 minutes to prepare your presentation 15 minutes to present

Ensure that your presentation involves all group members – equally.

Release Planning Designing, building and configuring releases Release Acceptance Roll-out planning of releases The Art of Service Email: [email protected] | Web: http://theartofservice.com | eLearning: http://theartofservice.org Phone: +61 (0)7 3252 2055 | Brisbane, Australia

95 Communication, preparation and training regarding releases Distribution and installation of releases


96

Slide 81

ASSESSMENT 




IF TIME PERMITS



Role play situation ‘Round table’ discussion Good meeting manners

 

81

4 of 4


This part of the formal assessment will be excluded or included by your instructor.

PART 3 – Discussion amongst experts regarding the scope for Release Management

Most organizations rely, not just on Information Technology infrastructure to deliver their products and services, but other functional areas as well. During this part of the assessment you will engage in a discussion regarding the suitability of the Release Management processes for non-IT areas.

As an expert in this field, you realize that many factors will need to be considered regarding a decision. As a group you must make sure that all such issues are tabled and discussed.

15 minutes for preparation. 30 minutes for discussion

Ensure that your discussion involves all group members – equally.


97

Slide 82

Reflection

82


This is the first of your formal assessments completed. You have demonstrated preparation, presentations, group interactions and communication ability during this assessment.

Further assessments will focus on different elements that you are expected to display at this level.

Notes:


98

Slide 83

Day 3 – Change Management

Notes:


99



esk Service D

Change Management



security

Capacity Management

IT Service


Release Management

for IT services


Management process.

Infrastructure



Remember that these slides are based on the ITIL Theory, but they are designed to provoke thought and discussion. The true definition of the processes come from the definitive ITIL text.

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).


100

Slide 85

Change Management = Goal of the process =

Change Management is the _________ that ensures that standardized methods and procedures are used for efficient and prompt handling of all _______, in order to minimize the impact of any related incidents upon _______ , and consequently to improve the day-to-day operations of the organization. 85



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.

Select one of the following answers for the issue.

Change Management is more of a:

(a) DOING PROCESS (b) COORDINATION PROCESS (c) STRATEGIC PROCESS

Make a list


101 What are the negative impacts of a poorly defined Change Management process?

Notes:


102

Slide 86

Change Management SCOPE 

The scope of Change Management – – – – –

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.

Source: OGC Text Service Support, Scope of Change Management 86


The Change Management process should account for changes to all elements of the infrastructure 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.

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 track the changes then you’ll use Change Management to track the changes. We’ll see that a Change does not necessarily mean that we have to call a meeting to approve each change. We can define standard changes and appoint relevant parties to carry out the change, provided a pre-defined work procedure is followed.


103

Slide 87

Major Concepts for the Change Management process

87


Notes:


104

Slide 88

Change Management Concepts 

Requests for Change (RFC)



Change Advisory Board (CAB)



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



Outsourcing

88


We will spend the next few slides exploring the basic concepts of Change Management.

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”.

(Reminder: A change is moving from defined state to another)

Where can changes originate?

1. ______________(Clue: the name of another ITIL Service Support process)

2. Result of proactively seeking business benefits (e.g.. Reducing costs, improving services)


105

Slide 89

Change Management Concepts Request for Change (RFC) – – – – –

89

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: ________________________ ________________________ ________________________ ________________________ ________________________

The PIR/Change Review is designed as a final check that the intended outcome for the change was actually delivered.


106

Slide 90

Request for Change (RFC) 

Items in a RFC form: – – – – – – – – – – –

90

RFC Number (unique identification) RFC 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

Source: OGC (Service Support) © The Art of Service 2005

Requests for Change are triggered for a wide variety of reasons, from a wide variety of sources. The reasons 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.


107

Slide 91

Request for Change (RFC) 

Items in a RFC form (cont.): – – – – – – – – –



91

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’

Discussion Topic Are Service Requests at any time Change Requests?

Source: OGC (Service Support)


Discussion topic notes:

A service request by definition is “every incident that is not a failure in the IT infrastructure”.

Following from this definition it stands that requests to change passwords, reset passwords, move equipment, etc. are service requests.


108

Slide 92

Change Management Concepts Change Advisory Board

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

  

92

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 a lot of changes can be managed through automated systems.


109

Slide 93

Change Management Concepts Change Models – Standard to Complex

Forward Schedule of Changes (FSC) A schedule that contains details of all Changes approved for implementation and their proposed implementation dates.



Projected Service Availability (PSA) A document that contains details of Changes to agreed SLAs and service availability.

93


Change Models 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 (modelling) 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, Availability Management


110

Slide 94

Change Management Concepts 

Outsourcing Questions to ask a supplier regarding Change Management      

94

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 outsourcer is aware that their actions can have major impacts.


111

Slide 95

Change Management - Benefits

95

–

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 © The Art of Service 2005

Notes:


112

Staff costs include those people involved with the Change Advisory Board, change builders and those staff involved

Slide 96and configuration management activities. We should expect that such costs at the outset of working with release with a new process will be higher.

Change Management - Costs 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).

Staff

costs

Support

96

Tools



113

Slide 97

Change Management – Points of attention

– cultural 

challenges

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

– bypassing – ‘missing

link’ with other processes

– commitment – volume

the supplier(s) to the process

of changes

97


Understanding the possible problems ahead of time allows us to be prepared for and (preferably) 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 don’t 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


114

Slide 98

Activites of the Change Management process

98


Notes:


115

Slide 99

Change Management Activities RFC Allocation of priorities Change Categorization

Impact and Resource

Logging & filtering

Change logging and filtering

Classification

Assessment

Change Approval

Authorization

Change Scheduling

Coordination

build / test / implement

Evaluation

Urgent B. T. I.

Change Review 99

Change B. T. I.


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)

Challenge question Why is the Build/Test/Implement section shown as outside the actual Change Management process?

Answer:


116

Slide 100

Logging & Filtering 

Logging – –

Complete / Check information Advise: 





Filtering – –

Which RFCs are totally impractical? If rejected:  

100

Use an integrated Service Management tool All members of the organization should be authorized to request Changes (stay innovative!)

RFC

Logging & filtering Classification Assessment Authorization Coordination

B, T & I

Evaluation

return to applicant with reasons applicant has the right to appeal © The Art of Service 2005

This is one area that the IT department has traditionally placed heavy controls on. 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.


117

Slide 101

Classification 

Allocation of priorities –

–

may already have been assigned by Problem Management (?!), but…. determines the order of changes

RFC

Logging & filtering Classification Assessment Authorization



Change categorization – –

Establishes the resources required based on the impact

Coordination

B, T & I

Evaluation

101


What are the two factors that determine the priority of a proposed change?

1. 2.

Ideally, the priority will be agreed 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 OGC Service Support text provides examples of priority ratings (Immediate, High, Medium, Low).

The category of a change helps us understand the level of resources required to actually implement that change. Be careful to not create too many categories, as confusion can be seen and the value of reporting is diminished.

You can create a multitude of categories that may essentially all say the same thing. For example; Facilities Management The Art of Service Email: [email protected] | Web: http://theartofservice.com | eLearning: http://theartofservice.org Phone: +61 (0)7 3252 2055 | Brisbane, Australia

118 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.


119

Slide 102

Allocation of priorities (I) impact impact priority priority urgency urgency



estimate: - people - means / resources - time

Possible coding: Priority “Immediate”:  URGENT CHANGE  

Total limitation in use of essential services Departure from normal change procedures – –

102

resources need to be made available instantly all previous planning is postponed  Emergency meeting of CAB/EC probably necessary


Notes:


120

Slide 103

Allocation of priorities (II) Priority “High” 

Severe disruption for a number of users, or Disruption for large group of users Departure from normal change procedures



Top priority for CAB

 

– –

resources need to be made available instantly all previous planning is postponed

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 – –

103

next release next planned maintenance moment


Notes:


121

Slide 104

Time for Self Study

104


Notes:

Self Study

Review the chapter from the Service Support text on Change Categorization.


122

Slide 105

Assessment 

Assessment of: – – – – – – – – –

effect on the infrastructure RFC Logging & filtering and service delivery Classification capacity and performance contingency plans Assessment security Authorization effect on other services What if change is not Coordination implemented? current FSC and PSA Evaluation costs extra resources required post change CAB recommendations

105

B, T & I


Actual assessment will be carried out by the CAB, CAB/EC or others nominated by the Change Manager.

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?


123 It is important to note that the CAB may not actually meet all that often. Perhaps a physical meeting every six months, but 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 authorized signatory for change (defined in Change Procedures and/or SLAs).


124

Slide 106

Authorization RFC Financial

Logging & filtering Classification Assessment Authorization

Approval principles Business

Coordination

Technology

B, T & I

Evaluation

Exercise – Authorization table 106


The size and risk associated with a change will often determine who can actually make the approval.

Exercise – Authorization table As a group exercise create a matrix for change approval. Consider your column and row headings and then at each intersection point there should be a role or group description. Work in pairs, then share your ideas with others to see what different groups use as the basis for change approvals.

Remember that all changes need to be approved but think laterally about this statement when making the matrix.


125

Slide 107

Coordination • One change at a time ? • Dependant changes • Concurrent changes • Size of change to limit damage 107

RFC


B, T & I

Evaluation

Self study and explain © The Art of Service 2005

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.

Self study and explain In the OGC Service Support text, locate the diagram the shows the boundaries between Change Management and program management. Take a few minutes to review this diagram and the supporting text


126

Slide 108

Coordination 

Forward Schedule of Change (FSC)

Changes & Projects

  

Based on known plans Short, medium, long(?) Distribution

Time

108


Notes:


127

Slide 109

Build, Test & 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 modelling techniques

Implementing – – – –

RFC


B, T & I

Evaluation

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

109


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 consistency. 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 (performance, 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).


128

Slide 110

Evaluation        

was the planning correctly carried out? was the impact correctly estimated? RFC was the usage of resources correctly estimated? was the right result for the change realized? are the users satisfied with the result? # incidents on the change were / are there unexpected side effects? have detected anomalies been communicated to the CAB for future changes?


B, T & I

Evaluation

Question: Who is involved in the change review? 110


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 Management!!

Question: Who is involved in the evaluation? Answer:


129

Slide 111

A BIT OF FUN ! – Word Search z

s

c

o

p

e

y

c

b

s

d

f

g

z

a

m

d

r

d

m

r

y

x

r

f

c

w

f

s

c

j

f

i

f

p

d

r

y

u

s

a

e

l

e

g

h

v

a

v

h

u

a

w

d

n

g

k

e

z

y

s

x

j

k

s

n

a

z

r

u

s

o

f

s

z

x

m

n

i

o

q

o

i

a

d

t

i

g

j

m

b

p

p

i

x

s

e

h

w

n

r

x

o

h

o

o

n

t

d

l

y

s

g

m

e

d

f

l

i

w

i

a

e

a

x

f

g

p

e

d

h

u

e

e

o

r

z

j

j

n

h

l

t

h

t

r

n

d

f

u

h

j

t

b

s

h

g

c

y

w

f

r

j

g

a

g

f

e

j

t

c

x

q

g

f

s

f

i

s

t

q

k

e

o

c

e

g

f

t

r

m

f

o

a

s

w

q

n

q

g

u

u

e

g

h

n

s

w

a

c

f

v

b

w

h

m

n

f

j

o

e

y

f

n

z

v

s

e

w

e

k

e

p

c

111


Time to search for some answers on Change Management.

In the grid above, see if you can track down:

The names of the two most closely linked processes to Change Three letter acronym that documents future known changes This is a danger if the process is overly complex and bureaucratic Impact and this determine the priority The most well known acronym for Change Management This topic is the same consideration for Change and Configuration Management We define these to ensure a consistent approach to changes


130

Slide 112

Roles and Responsibilities 

Change Manager    



Change Advisory Board (CAB)   

 

Co-ordinate the CAB Authorize Report Measure

Non-static group Understand changes Provide advice

CAB/EC (Service desk) 

Authorize

112


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 relevant stakeholders to changes being reviewed. 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.


131 The Service Desk is shown as we should remember that they may be given the authority to approve minor changes or changes that meet some pre-defined criteria of measurement.


132

Slide 113

Planning & Implementation of the Change Management process

113


This section outlines the steps for planning and implementing the Change Management process.

It is important that we understand this section is looking at planning and establishing the process itself, not actual change activities.

The day to day activities were discussed earlier.

Notes:


133

Slide 114

Change Management

– Planning & Implementation

 Planning – Roles

and responsibilities and tools – Reviews – Systems

 Implementation – Dependencies – Procedures – People – Timing

114


There are a variety of topics that need to be addressed when planning the implementation of the Change Management process.

We will now look at each point in further detail.

Notes:


134

Slide 115

Change Management - Planning     

Existing role, new role Decide on Scope Single Change and Configuration Management system Training Metrics, reports, review process Easy challenge question: Why is there such a strong connection between the Change and Configuration Management processes?

115


In most organizations the Change Management role already exists or it can be easily 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 configuration 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.

Easy challenge question: Why is there such a strong connection between the Change and Configuration Management processes? Answer:

Finally the actual measures of performance and the way that the Change Management process itself will be assessed/reviewed needs to be designed.


135

Slide 116

Change Management - Implementation 

Supporting processes (dependencies) – – – –

Release * Configuration * Problem Service Desk



Procedures



People

–

– –



Existing practices & cut-over Support Participation

Timing –

Service Level Management & ‘change slots’

116


There are some processes that simply must be implemented concurrently with Change Management. Our discussions to date have already provided the answer as to what these processes are (Release and Configuration). However, there are other areas that 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 procedures when implementing the process. It will not be practical to run two processes in parallel, so the actual cut-over point must be considered.


136 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 unnecessary 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, then it is appropriate to document them in any Service Level Agreements (and OLAs and UCs) that support the affected service/s.


137

Slide 117

Change Management Procedures

117


Notes:


138

Slide 118

Change Process & Procedures



118

Typical procedures will include: –

Initiation of RFCs

–

Handling of Urgent Changes

–

Impact assessment

–

Change authorization

–

Building and testing of RFCs

–

Implementation of RFCs

–

Reviews


Notes:


139

Slide 119

Change Process & Procedures



119

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


Notes:


140

Slide 120

Metrics & Reporting for Change Management

120


Notes:


141

Slide 121

Change Management - Metrics        

Interesting question: When Change Ratio !! is it acceptable to have a Points of origin large number of changes? Rejection rate Change backlog Change related incidents Successful change count Number of back outs Specific CI change count

121


Interesting 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 be potentially met with continuous changes in IT to keep pace.


142

Slide 122

Types of reports      

Risk Reports Business Impact Reports Bottleneck reports Emergency changes Costs of change General Reports on changes: – – –

Changes per CI Number of ‘Back-outs’ Major change reviews

122


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.


143

Slide 123

ASSESSMENT 1 of 4



Change Management Assessment



Presentations, Reports, Procedures & Discussion – – –



External suppliers Service Desk staff Internal auditors


123


This is a formal assessment for the program.

Your instructor will provide you with a copy of the Maltese Shipping Company. This is the case study for your assessments and it must be used as the context for your submitted work.

This Change Management Assessment has two (2) mandatory parts: Discussion paper to be raised with External suppliers. Presentation to internal Service Desk staff, supported by document templates.

Make sure that your answers provide evidence of your understanding of these topics.


144

Slide 124

ASSESSMENT 




Raise a discussion paper that is to be used as the basis for talks with an external supplier to the Case Study organization, regarding the Change Management process. Relate your presentation to the case study organization. Paper for External suppliers Ensure the paper is appropriately targeted and remains focused on Change Management.

  

124

2 of 4


PART 1 – DISCUSSION PAPER TO BE PREPARED FOR EXTERNAL SUPPLIERS

Written document for external suppliers. You are the controller of IT infrastructure change within the organization.

120 minutes to prepare your discussion paper

Your discussion paper must raise issues regarding communication and involvement in the Change Management process, along with Security issues.


145

Slide 125

ASSESSMENT 




Present a concise explanation on the activities of the Change Management process. Relate your presentation to the case study organization. Presenting to Service Desk staff Supplement your presentation with handout notes

  

125

3 of 4


PART 2 – Internal staff that are ITIL aware

Presentation to Service Desk staff. Answer the HOW question as part of this presentation. Involve all group participants in the preparation and presentation.

60 minutes to prepare your presentation 15 minutes to present


Each person to provide input Forward Schedule of Changes Projected Service Availability Request for Change The Art of Service Email: [email protected] | Web: http://theartofservice.com | eLearning: http://theartofservice.org Phone: +61 (0)7 3252 2055 | Brisbane, Australia

146 Communication of Change to internal staff Or from the slides dealing with Change Management procedures/work instructions.


147

Slide 126

ASSESSMENT 


IF TIME PERMITS  

Prepare a written response to regarding issues raised in a recent check of the Change Management process. Issues relate to: – – –

 

4 of 4

A lack of process improvement/self audit checks A lack of Key Performance Indicators & subsequent analysis Failure to conduct Change review meetings

Relate your presentation to the case study organization. Response to Internal Auditors

126



PART 3 – Written response to issues raised by recent internal audit

Internal Audit are responsible to ensure that internal processes are properly managed, organized and optimized. A recent targeted review of the Change Management process identified several weaknesses. Your response to these points is to identify how the issues raised are being dealt with.

90 minutes to prepare your response to the issues raised

The concept of “continuous improvement” for our IT processes ensures that we do not get complacent about the activities that are identified and implemented. Once effective processes are defined there is a need to “revisit” the process to look at ways they can be improved.

Numbers often tell the whole story.


148 This basic fact is often overlooked when implementing process improvements. KPIs is another term for metrics and they need to be SMART. (SMART = Simple, Measurable, Achievable, Realistic, Time driven)


149

Slide 127

Reflection

127


This is the second of your formal assessments completed. You have demonstrated preparation, presentations, group interactions and communication ability during this assessment.


Notes:


150

Slide 128

SLIDE INTENTIONALLY BLANK

128



151

Slide 129

Day 4 – Configuration Management

Notes:


152


esk Service D


Configuration Management



security

Capacity Management

IT Service


Release Management

for IT services


Management process.

Infrastructure



Remember that these slides are based on the ITIL Theory, but they are designed to provoke thought and discussion. The true definition of the processes comes from the definitive ITIL text.

Notes:


153

Slide 131



= Goal of the process =

Configuration management provides a logical model of the infrastructure or a service by identifying, controlling, maintaining and verifying the versions of Configuration items (CIs) in existence.


131


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 a Configuration Management is the verification of components.

Short Exercise: Create a list of verification techniques and tools:

Notes:


154

Slide 132

Configuration Management SCOPE 

The scope of Configuration Management –

Identification, recording and reporting of IT components, including their versions, constituent components and their relationships.

Configuration Management ≠ Asset Management

$ Source: OGC Text Service Support, Scope of Configuration Management 132


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.

Question: What is the principle difference between Asset Management and Configuration Management?

Answer: (clue: see the keyword underlined in the slide).

Notes:


155

Slide 133

Configuration Management Concepts 1 of 2     

133

Configuration Management Planning Configuration Identification and CIs Configuration Control Configuration Status Accounting Configuration Verification and Audit


The next set of slides preview the basic concepts for Configuration Management.


156

Slide 134

Configuration Management Concepts 2 of 2     

134

Configuration Baseline Configuration Management Database (CMDB) Software and Document Libraries Definitive Software Libraries License Management


The next set of slides preview the basic concepts for Configuration Management.


157

Slide 135

Configuration Management Concepts 

Configuration Management Planning – –



Strategy, Policy, Scope, Objective Key Success Factors (KSFs)

Configuration Identification and CIs – – –

Hardware Software Documentation

135


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 Management). 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.


158

Slide 136


identification and registration – –

scope: determine width and depth of the CMDB identify CI’s    

determine naming conventions record, determine attributes, define interrelationships define the level of detail – – –

136

hardware and software Network (components) Databases, operating systems, etc


Notes:


159

Slide 137


Configuration Control – –



Only authorized CIs Change Management relationship

Configuration Status Accounting –

Allows tracking through life-cycle

137


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 lifecycle. 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.


160

Slide 138


status accounting – on the various components on a daily basis 

attribute status –

being developed, purchased, tested, repaired, …

planned / ordered received tested implemented operational non operational in maintenance archived



general status –

138

time

number and sort incidents, problems, known errors, changes, licences, …


What are some common typical examples of a STATUS for a Configuration Item (CI)?

_______________________

_______________________

_______________________

Not so common examples?

_______________________

_______________________


161

Slide 139


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

Configuration Baseline – –

Snap shot Link to Change Management and Problem Management

139


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 roll-backs after a change and/or in depth problem analysis.


162

Slide 140


Verification & audits –

daily check

–

the Service Desk

–

audit (by an internal party)

–

audit (by an external party)







 

build a procedural check logging an incident partial or extensive? review of the process actual verification

140


The purpose for this slide is to prompt you to look for creative ways to conduct the verification/audit activity, as well as using the more traditional methods.

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.


163

Slide 141


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

141


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 infrastructure 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 demonstrable and as an auditable concept it can be used as a compliance mechanism for legal requirements.

CI information relating to incidents, problems, known errors, changes, releases; as well as inter CI relationships will be stored in the database.

Discussion point: Does the CMBD have to be one actual/physical database?


164

Slide 142


Definitive Software Library (DSL) – –



Master copy – software Logical area

License Management – –

Fines, even imprisonment Internet downloads may require disciplinary measures

142


The definitive software library (DSL) is the LOGICAL storage location for master copies of software. The word “definitive” means ‘ultimate’, ‘perfect’, ‘best’.

Discussion point: what is the difference between the DSL and the software and document libraries?

_______________________________________

_______________________________________

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 Management is a crucial process in assisting in the control of software licenses.


165

Slide 143


Configuration Items and Variants – –



How big should the CMDB be ? Principle of Maximum control with minimum records

Configuration Items and attributes

143


Configuration Management Database Without knowing it there are already many organizations engaged in Configuration Management practices. Most already have some form of crude Configuration Management Data Base (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 Management Database (CMDB).

Configuration Management Data Base = a repository of data regarding IT components and their relationships

Configuration Item and Variant 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).


166 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).


167

Slide 144

Benefits, Costs and Points of Attention Configuration Management

144


Notes:


168

Slide 145

Configuration Management - Benefits –

Management of IT resources

–

Economical, quality services

–

Effective and efficient problem solution



Less mistakes, therefore less “double costs”

–

Effective and efficient processing of changes

–

Optimal support on security issues

–

Helps ensure compliance to legal obligations

–

Optimal support on issues of budgeting and spending



Insight in illegal copies, licences, due dates of contracts, …

145


Central Data Repository. Having all CI data in one central repository provides all the normal efficiencies of data centralisation. 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 organization. An accurate CMDB, with good Change Management practices can: Reduce the introduction of unauthorized software/hardware, Support more timely and accurate auditing, and 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 as 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 minimal amount of time. The Art of Service Email: [email protected] | Web: http://theartofservice.com | eLearning: http://theartofservice.org Phone: +61 (0)7 3252 2055 | Brisbane, Australia

169


170

Slide 146

Configuration Management - Costs –

Personnel

–

Accommodation

–

Software





–

Physical storage of process documents, servers, people

–

In house vs off the shelf

•

tools and equipment for CMDB, audits, reporting, …

Hardware –

Data storage

–

Collection points and collation servers

–

Education

–

Procedures

–



146

Management CMDB, audits, clean up poor data

Tools, procedures, how to audit, 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 tracking and controlling IT infrastructure can be enormous.

However, consider the costs of not implementing this process. Computer fraud, software corruptions, 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.


171

Slide 147

Configuration Management - 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

147


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.


172

Slide 148

Planning and Implementation Configuration Management

148


Notes:


173

Slide 149


• • • • • • •

– Plan & Implementation

Purpose and Scope Manager & Team Current State analysis Plans and design Detailed Planning for Implementation CMDB & DSL setup Changeover & Considerations

149


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.

Here are the required activities for the planning and implementation of Configuration Management.

Each of these will be explored in more detail in the upcoming slides.


174

Slide 150

Configuration Management –

• • •

Purpose and Scope

Consult on purpose, objectives, scope and priorities Standalone vs consolidated process Purpose statement Exercise: How would that work?

150


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 Management).

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 , which will ensure all IT assets are correct and accounted for in all IT environments.

The objective might be: To bring all ’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.

Exercise: The Art of Service Email: [email protected] | Web: http://theartofservice.com | eLearning: http://theartofservice.org Phone: +61 (0)7 3252 2055 | Brisbane, Australia

175 One of the statements in this section indicates that we may look at treating Configuration Management as an entirely separate entity; or we may ‘bundle’ it with the Release and Change Management process. Spend a few minutes debating how these two approaches would work in reality. Work in groups and then share ideas.

Let’s explore further some detailed objectives for Configuration Management.


176

Slide 151


Purpose and Scope

Objectives • Correct and accurate data • Documented procedures • Standardized naming & labeling • Control authorized CIs • Audit trails Priorities based on the organization 151


For many organizations, some form of phased implementation, including Change Management is essential. The implementation approach may be on an organizational, geographical, customer 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 Management).

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.


177

Slide 152


– Manager & Team

Considerations: • Dedicated staff or other roles/projects • Joint Config, Change and Release team • Size of IT infrastructure • Change size, frequency and complexity Discussion: Role traits 152


The typical role titles in the Configuration Management team include Configuration Manager and Configuration Librarian.

Question. What type of personal traits should a typical Configuration Manager and Configuration Librarian have? Discuss this amongst the entire group.

Answer:


178

Slide 153


Current State analysis

Identify and analyze current: • Processes • Scope and resources • Tools (databases/interfaces) • Roles and responsibilities • Owners of CIs

153


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 which need to be continued.


179

Slide 154


– Plans and design

Structure of the CM plan(s) •

Steers the design of CM process

•

Affects the CMDB design

154


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.


180

Slide 155


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 Setup CIs

155


The activities carried out in the detailed planning for implementation are similar to those traditionally carried out in a major system development.

Question. What other activities would you include in your Configuration Management implementation?

Answer. More key activities are detailed in the next slide.


181

Slide 156


–

Planning for Implementation

More key activities include: • • • • •

Detail procedures Test CMDB and interfaces Finalize roles and responsibilities Promote project Train staff and users

156


Now we must begin some of the actual work of implementation. To this point we have identified and analysed.

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.


182

Slide 157


CMDB & DSL setup

Consider Change freeze during setup Populate and audit CMDB Test: • • • •

Security Backup & restoration CMDB interfaces Contingency plans

157


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 depending on the implementation timeframe, this may not be practical.

Question. Who should populate the DSL & DHS? The Configuration Management or Release Management 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 populate 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, and


183 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.


184

Slide 158


Changeover & Considerations

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

Enough trained staff to avoid bottlenecks Start with important CIs Review • • •

Activities against Plan Resource effort Data accuracy

158


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 be advised to 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 advertised 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 Configuration Manager.

Question. As the Configuration Manager, you have realized that some staff are bypassing the Configuration management process. Broadly, what steps would you take to address this issue?

Answer. Audit the CMDB and Configuration Management processes, The Art of Service Email: [email protected] | Web: http://theartofservice.com | eLearning: http://theartofservice.org Phone: +61 (0)7 3252 2055 | Brisbane, Australia

185 Attempt to isolate the ‘bypassed’ area (is it support group, a function, service), Interview stakeholders from the affected area, Draft countermeasures/procedure changes, Gain Change Management approval, Implement changes/countermeasures, and Communicate to stakeholders throughout.

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.

An example audit checklist is provided in the Service Support text.


186

Slide 159

Activities for Configuration Management

159


Notes:


187

Slide 160

Configuration Management - Activities

     

Configuration management planning Configuration identification and CIs Configuration control Configuration status accounting Configuration verification and audit CMDB Backups, housekeeping, etc.

160


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 involved 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.

Each of the listed activities is now explored further.


188

Slide 161

Configuration management planning   

Reference existing procedures and plans Plan first 3-6 months in detail, next 12 months broadly 6 monthly reviews – – – – –

consider CMDB Staff numbers & IT resources Purge CI data to maintain efficient CM function Review links with other ITSM processes Review procedures handbook

161


The Configuration Management plan needs to explain the rules for the process. In the rule book we need to see roles and responsibilities, naming conventions, interface details with 3rd 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 Management process.


189

Slide 162

Configuration identification and CIs Level of ‘independent change’



All hardware & software



CI or COMPONENT ?



Consider – –

? t: go in we Po ld n ou si o sh us w sc Di w lo o H



Auditing needs Supply of CIs (packaged or parts)

162

LES MP EXA

!!!


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 general rule it may be helpful to consider identifying 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 impact on 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.

Discussion Point: Is it sufficient to merely register a PC as a CI or is there a case to consider the monitor, base unit, keyboard and mouse? Discuss where this may be appropriate. What will be one consideration for the decision? The Art of Service Email: [email protected] | Web: http://theartofservice.com | eLearning: http://theartofservice.org Phone: +61 (0)7 3252 2055 | Brisbane, Australia

190

Examples of CIs


191

Slide 163

Configuration identification and CIs

     

163

Attributes

Name Type Location Serial Number Version Number …others….??


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 give consideration to 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 ensuring 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”


192

Slide 164


Relationships



Asset register vs. Configuration Management



Relationships provide dependency information.



For example: • • •

Parent/child relationship a CI is connected to another a CI uses another CI

Pr

es en ta

164

tio

n


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 dependant on other CIs.

Question: Which process will gain an incredible benefit from this relationship information? Answer:

Presentation: Working in groups create a set of CIs and their associated relationships. Use the case study organization as the basis for your work (or an agreed on situation/organization within your work group). Be creative and do not forget that CIs are more than just hardware and software.


193

Slide 165


Identification of configuration baselines 

Purpose – – –

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



Contain CI documentation as well info about themselves



Use version numbering rather than live, next, old

165


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 of time. 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

Notes:


194

Slide 166


Naming Conventions 

Apply to: –

CIs, changes, baselines, releases and assemblies



Unique



Support existing organization conventions



Permit growth



Reflect relationships

166


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..


195

Slide 167

Configuration control  

Ensures that only authorized and identifiable CIs are recorded in the CMDB upon receipt Procedures need to cover all stages. Examples: – – – –

Registration Updates (RFC to CI relationship) Decommissioning Data integrity protection

167


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 manage 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 Release Management.

Focus on avoiding duplication in procedures and encouraging input from other process managers. 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, Protection


196

Slide 168

Configuration control cont’d CI Registration – – – – –

Secure environment Verify received goods Consider procurement processes Off the shelf In-house developed 

When to register? (dev, test, production)

168


The registration of new CIs should be conducted in secure environment as assets are vulnerable 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 duplication.

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 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 development, 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.


197

Slide 169

Configuration control cont’d CI Updating – –

Consider the entire CI lifecycle Be able to update:    

–

CIs Attributes Relationships Events

Seek linkages with other system for update automation

169


There is a natural progression for the status of a CI as it moves through its life-cycle (progression 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 systems), licenses, etc.

Procedures will need to detail how to update status’s of CIs, attributes, relationships and events. Examples include: New documentation for CIs, New license agreements for off-the-shelf software.

Consider the ability to update CIs ‘owners’. The staff who 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.


198

Slide 170

Configuration control cont’d CI Removal

170

–

Same considerations as CI registration

–

Consider existing disposal methods

–

Another vulnerable period for CIs


Incorporating existing disposal procedures not only reduces duplication but ensures any legal obligations will be met; as such disposal procedures 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.


199

Slide 171

Configuration control cont’d Integrity of configurations  Protection of CIs and their components  Covering – – –



For software CIs – –

171

Procurement Storage, Dispatch, Receipt Disposal Virus protection Environmental considerations © The Art of Service 2005

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.


200

Slide 172

Configuration status accounting 

Status accounting report generation – – – –

Who can request a report How to request a report or how to generate report independently Report formats Report publishing rules

172


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, and Publishing reports: dissemination procedures (public or private access)


201

Slide 173

Configuration verification and audit  

Other ITSM processes depend upon an accurate CMDB Detail – – –

 

Audit frequency Depth of audit Staff involved

Use automated tools (detail instructions) Log and manage discrepancies

173


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 outcomes.

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 procedures and the behaviour of personnel. Any internal security investigation procedures may also be incorporated.


202

Slide 174

CMDB Back-up, Housekeeping

    

Back-up CMDB (restore procedures) Archiving information Frequency and retention policy Retention based on usefulness Regular checks to remove obsolete/redundant CI information

174


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.

Notes:


203

Slide 175

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

175


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.


204

Slide 176

Process Control for Configuration Management

176


Notes:


205

Slide 177

Configuration Reports Efficiency: Productivity: # changes per period Value add: # of release back outs etc…

Effectiveness: Timeliness: Resolution time Accuracy: % correct resolution Quality: % solved within SLA Decrease in % of backouts necessary etc…

177


What is the fundamental difference between effectiveness and efficiency?

ANSWER:

Notes:


206

Slide 178

Configuration Reports 

Look to consolidate reporting needs



Carry out report reviews – Seek

stakeholder feedback other ITSM processes? – Is report archiving working? – Support

178


Notes:


207

Slide 179

Configuration KPIs Number of discovered unauthorized configurations  Audit reviews  Poor impact assessment that lead to inefficient change  Change related incidents/problems 

179


Notes:


208

Slide 180

Configuration Management - 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

180


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, and Store events associated with CIs.

Regardless of the size of an organization, an automated CMDB will provide a more efficient service than a paperbased 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 itself. 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.


209

Slide 181

Time for Self Study

181


Notes:

Self Study

Review the chapter from the Service Support text on Tools specific to the Configuration Management process.


210

Slide 182

ASSESSMENT 

Configuration Management Assessment



Presentations, Reports, Procedures & Discussion – –



182

External university students IT Management




211

Slide 183

ASSESSMENT 




Prepare and deliver a presentation outlining information flows between Configuration Management and 5 (Five) other ITIL processes. Relate your presentation to the case study organization. Presenting to University Students Supplement the presentation with a fact sheet that explains the relationships.

  

183

2 of 4


PART 1 – EXTERNAL AUDIENCE of UNIVERSITY STUDENTS

Presentation to University Students (currently studying the importance of control in an IT environment) Involve all group participants in the preparation and presentation.

Select any other 5 Service Support or Service Delivery processes.

90 minutes to prepare your concise, educational presentation & Fact sheet 20 minutes to present


Each person to submit their own fact sheet (note the fact sheet can offer alternative processes to those used in the presentation).


212

Slide 184

ASSESSMENT 

Configuration Management Assessment3 of 4



Create a plan for the concurrent implementation of the Release and Control Processes. Relate your presentation to the case study organization. Writing to Senior IT Management

 

184


PART 2 – Internal IT Management – considering at multiple concurrent process implementation

Plan to be submitted to Senior IT Management. Address the benefits and challenges that such a strategy presents.

120 minutes to prepare your plan

Make sure your plan also addresses dependences, resource requirements and potential risks to the organization.


213

Slide 185

ASSESSMENT 




Presentation regarding the fundamental differences between Configuration Management and Asset Management. Relate your presentation to the case study organization. Presentation to internal Financial Controllers Include hand out notes in your presentation slides

  

185

4 of 4



PART 3 – Presentation to internal Financial Controllers

Historically, most organizations have used the technique of asset management to manage information about IT resources. We need financial control as IT assets have to be depreciated and reported as part of the company balance sheet or Profit and Loss statement. However, as an IT professional you understand that control of IT resources is more than just this financial perspective.

Your presentation will discuss just what Configuration Management is, the benefits it offers to the organization and its relationship to Asset Management.

60 minutes for preparation, including handout notes 20 minutes for discussion Ensure that your discussion involves all group members – equally.


214

Slide 186

Reflection

186


This is the first of your formal assessments completed. You have demonstrated preparation, presentations, group interactions and communication ability during this assessment.


Notes:


215

Slide 187

Day 5

Notes:


216

Slide 188

Relationships - Release and Control Processes

188

Source: OGC Service Support


This diagram shows the complexity of the relationships and the processes involved in Release & 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 organization, 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 or 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.


217

Slide 189

EXERCISE: Spiderweb Availability Availability Management Management

IT IT Continuity Continuity Management Management Release Release Management Management

Security Security Management Management

Change Change Management Management Configuration Configuration Management Management

Capacity Capacity Management Management Financial Financial Management Management for for IT IT Service Service Level Level Management Management 189

Service Service Desk Desk

Problem Problem Management Management Incident Incident Management Management © The Art of Service 2005

Information flow: Release & Change

Information flow: Release & Configuration

Information flow: Configuration & Release

Information flow: Configuration & Change

Information flow: Change & Release

Information flow: Change & Configuration


218

Slide 190

Release & Control Support Tools

190


Notes:

Question: Which comes first – process or the tools?

Answer:

Why?


219

Slide 191

Support Tools 

What are they?



Why the need?



What do they deliver?

191


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.


220

Slide 192

Tool Selection 

Non core selection criteria



Supplier –



Ongoing costs



Adaptability

– –

192

Reputation/history, Support focus, Training & consulting, Future plans (new modules?), References

Customizations, upgrades, maintenance Flexibility to support the changing organization © The Art of Service 2005

Often overlooked these three elements must be part of any selection criteria exercise. We’ve 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).


221

Slide 193

Tool Selection      

80% fit on requirements Delivery on MANDATORY requirements Out of the box “ITIL compliance” Low/known administration costs Low/known maintenance costs Discussion Point: ITIL Compliance

193


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. Would you reject a tool simply because it did not have a sticker on the box!


222

Slide 194

Costs associated with tools 

Tool costs: – –



Equipment costs: – – –



Server / disk space Network capacity Desktop requirements?

Training: – –



Back end Front end: licenses

Support staff Tool maintenance staff

Consulting: – –

Tool configuration (Future) changes: adaptability?

194


The list allows us to appreciate that while there are obvious costs associated with the use of service management tools, it is the hidden costs that can often 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 won’t create such outages?


223

Slide 195

Time for Self Study

195


Notes:

Self Study

Review the chapter from the Service Support text on Service Management Software Tools.


224

Slide 196

Release & Control Process Organization and Design

196


Notes:


225

Slide 197

Process & Procedures (Best Practice) Process Process

Why, What, Who, When Where?

Procedure How (exactly)?

Discussion: Examples of well written procedures and how they may differ from process documents/events. 197


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 sequence 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!


226

Slide 198

Process, Procedure & Work Flow Swim Lanes End User Service Desk

call

Acknowledge

discussion discussion

Create record

Record details

Provide reference

Desktop Support

Acknowledge receipt Joint activity (capable of having its own flow)

198

Provide details

Flow chart symbols can also be used in the swim lanes

Hand off point


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).


227

Slide 199

Brainstorming techniques 

Freewheeling



Carousel



One-Two-Six



Slip Method

199


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.


228

Slide 200

Creativity technique       

S - substitute C - combine A - adapt M - modify P - put to another use E - eliminate R - reverse

SCAMPER was created by Michael Mikalko in his book ' Thinkertoys'. 200


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


229

Slide 201

RESPONSIBILITY CHARTING (ARCI) Accountable

Position with yes/no authority

Responsible

Position working on the activity

Consult Inform

Position involved prior to decision or action

Position that needs to know of the decision or action

201


The concept of this technique is similar to SWIM LANES. Both are designed to show WHO is involved. The ARCI model extends the swim lanes by recongnizing the different types of action required for each step of the procedure.

The four types of action are explained further in the next slide.


230

Slide 202

RESPONSIBILITY CHARTING (ARCI) Th eR Accountability “A” Responsibility “R” Consult “C” Inform “I”

202

ule s

The individual who is ultimately responsible. Includes yes or no authority and veto power. Only one “A” can be assigned to a decision/activity.

!

The individual(s) who actually completes the task, the doer. Responsible for action/implementation. Responsibility can be shared. The degree of responsibility is determined by the individual with the “A”. MUST be at a minimum one “R” The individual(s) to be consulted prior to a final decision or action. This incorporates two-way communication. The individual(s) who needs to be informed after a decision or action is taken. This incorporates one-way communication.


Notes:


231

Slide 203

ARCI CHARTING

Index: A: Accountable (owns it) R: Responsible (does it)

EVENT

Activities

R

203

C: Consulted (provides info)

Functional Roles & Groups

A

A R

R

C

R

C

A

I

C

I

I: Informed (receives info)

C

C

C

C

C

R

R

R

C

R

A

I

C

R

I

C A

I A R C © The Art of Service 2005

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).


232

Slide 204

Practice Exam

Notes:


233

Slide 205

Closing

That brings us to the end of this clustered practitioner program. We hope that you have enjoyed the week and had a chance to increase your knowledge and understanding of the process areas.

We wish you all the best for your future endeavors that involve the Release and Control Processes.


ITIL Practitioner Release and Control (IPRC) All-in-one Exam Guide and Certification Work book; CMDB and IT Service Management with Change Management, Release Management and Configuration Management

ITIL Practitioner Plan and Improve (IPPI) All-in-one Exam Guide and Certification Work book; IT Service Management with Availabilty Management, Capacity ... Recovery, IT Service Continuity Management

ITIL Release Management: A Hands-on Guide

ITIL IT Service Management - 100 Most Asked Questions on IT Service Management and ITIL Foundation Certification, Training and Exams

ITIL Practitioner Support and Restore (IPSR) All-in-one Help Desk Exam Guide and Certification Work book; Define, Implement, Manage and Review Service ... Incident Management and Problem Management

Configuration Management Principles and Practice

Configuration Management Principles and Practice

Configuration Management Principles and Practice

Effective IT Service Management: To ITIL and Beyond!

ITIL V2 Release and Control (IPRC) Full Certification Online Learning and Study Book Course - The ITIL V2 Practitioner IPRC Complete Certification Kit, Second Edition

Effective It Service Management: To Itil and Beyond!

Effective IT Service Management To ITIL and Beyond!

Configuration Management: Expert Guidance for IT Service Managers and Practitioners

IT-Management mit ITIL® V3

Management Gurus and Management Fashions

Communication and Management at Work

Strategic Management: Awareness and Change

Stata Data-Management Reference Manual: Release 11

Change Management (Management Extra S.)

ITIL Capacity Management

Software Configuration Management

CMDB and Configuration Management Process, Software Tools Creation and Maintenance, Planning, Implementation Guide

Information and Knowledge Management: Management Extra

Leadership and Management in Organisations: Management Extra

Convergence of Project Management and Knowledge Management

Investment Management: Securities and Portfolio Management

Foundations of IT Service Management Based on ITIL, Volume 3

Foundations of IT Service Management: Based on ITIL Arabic

Configuration Management Metrics : Product Lifecycle and Engineering Documentation Control Measurements

ITIL Practitioner Agree and Define (IPAD) All-in-one SLA Exam Guide and Certification Work book; Define, Implement, Manage and Review Service Level Agreements ... level Management and Financial Management

Rosacea: Diagnosis and Management

ITIL Practitioner Release and Control (IPRC) All-in-one Exam Guide and Certification Work book; CMDB and IT Service Management with Change Management, Release Management and Configuration Management

ITIL Practitioner Plan and Improve (IPPI) All-in-one Exam Guide and Certification Work book; IT Service Management with Availabilty Management, Capacity ... Recovery, IT Service Continuity Management

ITIL Release Management: A Hands-on Guide

ITIL IT Service Management - 100 Most Asked Questions on IT Service Management and ITIL Foundation Certification, Training and Exams

ITIL Practitioner Support and Restore (IPSR) All-in-one Help Desk Exam Guide and Certification Work book; Define, Implement, Manage and Review Service ... Incident Management and Problem Management

Configuration Management Principles and Practice

Configuration Management Principles and Practice

Configuration Management Principles and Practice

Effective IT Service Management: To ITIL and Beyond!

ITIL V2 Release and Control (IPRC) Full Certification Online Learning and Study Book Course - The ITIL V2 Practitioner IPRC Complete Certification Kit, Second Edition

Effective It Service Management: To Itil and Beyond!

Effective IT Service Management To ITIL and Beyond!

Configuration Management: Expert Guidance for IT Service Managers and Practitioners

IT-Management mit ITIL® V3

Management Gurus and Management Fashions

Communication and Management at Work

Strategic Management: Awareness and Change

Stata Data-Management Reference Manual: Release 11

Change Management (Management Extra S.)

ITIL Capacity Management

Software Configuration Management

CMDB and Configuration Management Process, Software Tools Creation and Maintenance, Planning, Implementation Guide

Information and Knowledge Management: Management Extra

Leadership and Management in Organisations: Management Extra

Convergence of Project Management and Knowledge Management

Investment Management: Securities and Portfolio Management

Foundations of IT Service Management Based on ITIL, Volume 3

Foundations of IT Service Management: Based on ITIL Arabic

Configuration Management Metrics : Product Lifecycle and Engineering Documentation Control Measurements

ITIL Practitioner Agree and Define (IPAD) All-in-one SLA Exam Guide and Certification Work book; Define, Implement, Manage and Review Service Level Agreements ... level Management and Financial Management

Rosacea: Diagnosis and Management

Recommend Documents