lesson-10-service-transition-processes-part-1.pdf

/d/>&/d^D

Lesson 10 Study Guide ^dWW

The ITIL Foundation Certificate in IT Service Management

www.itiltrainingzone.com

Page 1 of 18 2011 IT Training Zone LTD www.ITILTrainingZone.com

ITIL is a registered trademark of the Office of Government Commerce in the United Kingdom and other countries

Welcome to the tenth chapter of your Study Guide. This document is supplementary to the information available to you online, and should be used in conjunction with the videos, quizzes and exercises.

After your subscription to the course has finished online, you will still have the Study Guide to help you prepare for your exam - if youve not taken the exam by the time your subscription expires.

Youll download a Study Guide at the end of most Lessons as you progress through the course.

This Chapter contains the Study Guide information for Lesson 10 Service Transition Processes: Part 1.

Use this Study Guide in conjunction with your own notes that you make as you progress through the course. You may prefer to print the Study Guides out, or use them on-screen.

After each Lesson, you can consolidate what you have learnt whilst watching the videos and taking the quizzes by reading through the chapter of the Study Guide.

If you progress on to the formal exam, your Study Guide will provide you with vital revision information.

Remember, your Study Guide is yours to keep, even after your subscription to the course has finished.

Service Transition Processes Part 1





Study Guide Icons 3

Lesson Contents 4

Change Management Purpose, Objectives, Scope 5

Change Management Key Concepts 9

Exercise Change Request 9

The Change Advisory Board 15

Change Management Interfaces 18

Table of Contents





Watch out for these icons as you use your Study Guide. Each icon highlights an important piece of information.

Tip this will remind you of something you need to take note of, or give you some exam guidance.

Definition key concept or term that you need to understand and remember.

Role a job title or responsibility associated with a process or function.

Exercise Solution suggested solution to one of the exercises you will complete throughout the course.

Goal or Objective for a particular process or core volume.

Study Guide Icons





This Lesson was the first of two Lessons addressing the Service Transition processes.

We studied:

Change Management

Text in "italics and quotation marks" is drawn from the ITIL core volumes Quoted ITIL text is from Service Strategy, Service Design, Service Transition, Service Operation and Continual Service Improvement Crown copyright 2011 Reproduced under license from OGC.

Lesson Contents





Every organization has to deal with and manage change. Changes come from many sources including customer requirements, legislative or external business changes, as well as internal improvements and fixes.

New and changed IT services need to be carefully managed to ensure they transition successfully into the production environment.

Because service providers have to deal with high volumes of change, often in complex environments, they need to have processes in place that will allow them to manage change in the most efficient way possible.

Process Purpose and Objectives

The purpose of change management is to control the lifecycle of all changes, so that positive changes can be made without disrupting service.

By successfully managing change and having efficient change management processes in place, we can smoothly transition new and changed services into our production environment.

The Change Management process has a number of objectives, including:

Respond to changing business requirements while minimizing disruption Manage and implement changes to make sure that services stay aligned with

business needs Make sure that changes are recorded and managed from inception through to

implementation and review Make sure all changes are recorded in the CMS Optimize business risk

Change Management





Process Scope

The first part of managing change effectively is to define exactly what we mean by a change.

Organizations need to ask:

What kind of changes do we need to manage? What kind of changes do we deal with regularly? What kind of changes are threats to our production environment?

What constitutes a Change will be different for different organizations. Service providers must arrive at their own definition.

Change Management has a clearly defined scope. The process covers the management of change to all configuration items across the whole service life cycle. In other words, anything that contributes to the delivery of a service can fall within the scope of change management.

This could include physical assets like servers, virtual assets like storage or documents such as Service Level Agreements.

The scope of change management also includes any changes to the 5 aspects of Service Design:

Design of service solutions Design of management information systems and tools Design of technology and management architectures Design of processes Design of measurement systems

No change is risk free. All changes, regardless of their size, carry some degree of risk. The smallest, simplest changes can be the ones that cause the most damage when introduced into production environments.





The diagram below shows the scope of change management.

Service Transition fig. 4.1 Scope of Change management and Release and Deployment Management for services

Crown copyright 2011. Reproduced under license from OGC

Change Management might need to work with business change management and supplier change management processes as part of its role.

Changes will come from many sources:

Service Strategy and the Service Portfolio might initiate strategic changes Service Design, CSI, Service Level Management and Service Catalogue management

might initiate service changes Service Operation might initiate corrective changes to fix an incident





There are some areas that are out of scope Change Management:

Business changes such as a building move or relocation will be managed by business change management with support from IT change management if necessary

Operational changes such as the repair of a PC Coordination of service management processes involved in a change





Change Proposals

Change Proposals are normally created by Service Portfolio Management and passed to Change Management to authorize.

The proposal describes a possible service introduction or significant change at a high level, normally including a business case and proposed implementation schedule.

Change Management reviews change proposals. They need to consider the effect on existing services, resources and any other changes happening at the same time.

If the proposal is approved, its passed back to Service Portfolio Management who will allocate resources to the change. Change proposals usually then create requests for change for individual pieces of work.

Change Request

A change request is a formal communication requesting a change to one or more configuration items. It could be a service desk call, project document, Request for Change, or change proposal. Organizations should use templates to capture change information without introducing too much bureaucracy.

Exercise Change Request

This Lesson included an Exercise to look at the information that should be captured for a change request. If you didnt have time to complete the exercise during the Lesson, why not attempt it now?

Exercise

Youve been asked to create a template for a Request for Change form. The template will be

applied to your service management tool and used to capture information for all changes.

List at least 10 pieces of information you need to capture for every change.

Change Management Key Concepts





Exercise Solution

Some of the information you need to capture could include:

Unique ID such as a change number Name of requestor Reason for request Proposed date Service(s) affected Technology/configuration item(s) affected Detailed description Any related incidents or problems Reviewers who need to see the change Implementation plan Test plan Remediation/back out plan

The document will probably be updated as it progresses through to approval so date and time stamps will be necessary.

Remember, if you found this exercise challenging or have any questions, you can email a tutor at tutor@itiltrainingzone.com.

Types of Change

Service Providers will have to deal with different levels of change. The Change Management process will vary depending on whether the change is classed as high impact, medium impact or low impact, and the level of risk associated with that change.

For the very high impact and high risk changes, senior business management approval could be required, and the change may be managed by a cross-functional project management team. The project will then raise individual requests for changes to IT services as necessary.

Low impact and risk changes such as minor repairs may be handled in a pre-defined, streamlined way, with no need for individual assessment. Change Management should, however, be involved in defining and pre-authorizing these low impact, low risk changes.

For each organization, the service provider will need to define the different levels of change and work out the most appropriate way to handle them.





There are three main types of change defined within the ITIL core volumes:

Standard Change

A Standard Change is a change to a service or infrastructure for which an approach has been agreed and pre-authorized by Change Management. A procedure will have already been defined and accepted within the organization for this low risk, low impact type of change. Authority for recording and carrying out standard changes can be delegated, for example to the Service Desk. As Change Management processes mature, more and more standard changes will be identified and authorized. There are some crucial elements of standard changes. A standard change must have a defined trigger, it must be low risk, and it must be carried out using a proven, documented procedure. Approval for standard changes is given in advance when the change is pre-authorized. Authorization for standard changes can be delegated to a nominated authority. For example, the Service Desk team leader might be authorized to approve the installation of a piece of standard business software. However, they will need to check a license is available each time a request is made. Normal Change Normal changes are triggered by a request from a change initiator. Normal changes may be higher risk than a standard change, or may be a change that has not been experienced previously within the organization. The process for handling a normal change allows the organization to ensure the change is fully assessed by relevant stakeholders. Assessment means that any potential difficulties are identified and addressed before the change is implemented. Typical examples of normal changes could include the installation of an organization wide upgrade to an existing application, or approval for a brand new application. Emergency Change Emergency changes should be much less frequent than normal and standard changes. They happen in response to major incidents or failures affecting a business critical service. Although these changes are emergencies, they still need to be designed, managed and tested as much as possible to ensure that they dont have a negative impact on the organization. Because of the urgent nature of the situations that can trigger an emergency change, some details may need to be recorded retrospectively, after the change has been implemented. However, the change should still be designed and tested as far as possible within the timescales involved.





Carefully defined levels of authority must be put in place within the organization to manage emergency changes. For example, a small group of empowered people or managers can analyze the situation quickly and provide a well reasoned response.

Changes may also be categorized as major, significant and minor. The categorization will depend on the level of risk associated with the change.

Remember, a change includes the addition, modification or removal of anything that could have an effect on IT services.

Change Models Change models are used by organizations to document and define the specific steps that are required to manage a particular type of change.

Models are repeatable ways of doing something. They can be applied to service management processes such as Change Management and Incident Management.

Once a model has been carefully defined, it should be automated using a support tool to help remove the possibility of any human errors. Automation also supports process measurement.

A model will typically include:

The actual steps to be taken The timescales involved in each step and chronological order The responsibilities of the people involved How escalations should be managed

As the Change Management process matures, more and more models can be defined to support the efficiency and effectiveness of managing changes.





The diagram below shows an example of a process flow for a normal Change Model.

Service Transition fig. 4.2 Example of a process flow for a normal change

Crown copyright 2011. Reproduced under license from OGC





We studied the steps in detail.

Step Notes Create RFC The RFC is created by a change initiator. The RFC may include the creation

of a change proposal, containing approvals from the business and the business case.

Record RFC In a tool or using manual documents if appropriate.

Review RFC Change Management check all relevant information is present and accept the change into the process.

Assess and evaluate

Assessment may include consultation with various stakeholders and knowledge holders, including members of a Change Advisory Board.

Authorize change build and test

Approval is given to allocate resources and carry out the build and test activities.

Coordinate change build and test

Change Management will monitor progress and check the service change will perform as it should. They will not physically carry out the activities

Authorize deployment

This will happen if the build and test have been successful

Coordinate deployment

Again, monitoring for anything unusual

Review and close

All changes are reviewed to ensure they met their original objectives. The review also ensures that the change management process is working as it should.

Organizations will use models like this to deal with all normal changes. The process itself will be modified to handle the many different types of changes it may face over time for example software, hardware or network changes.





Remediation Planning

Not all changes go according to plan. Its important to plan for what to do if things go wrong during change implementation. This planning is known as remediation planning.

Remediation could include invoking a back out plan to remove the change, initiating IT Service Continuity Management or taking other actions to protect the business process affected.

All changes must have a remediation plan. The change implementation plan will include triggers for example, if a step isnt completed in the agreed time, the remediation plan will be invoked.

Some changes cannot be backed out. These need a different approach for remediation, and can be higher risk than changes which can be easily removed. If the change fails, a fix needs to be found that restores the service required by the business.





The Change Advisory Board or CAB is the group of stakeholders and knowledge holders that meet to review and support change management in the assessment, prioritization and scheduling of changes.

The CAB will meet regularly, and CAB membership may be different each time, depending on the types of changes being discussed.

The change manager will normally be the chair of the CAB, and membership may include customers, users, developers, third parties and any other required attendees.

CAB meetings can be run as regular face to face meetings - or virtually over audio or video conferencing systems - depending on the organizations preference. The aim is to ensure that all the correct attendees are present regardless of their location and time-zone.

CAB members will:

Review and approve normal changes Be involved in reviewing standard changes periodically Review emergency changes after they have been implemented

The CAB is usually an advisory board, and if a decision cannot be made at CAB, the change may be escalated to senior management for their input, advice or a decision.

A standard CAB meeting agenda could include:

Reviews of failed, unauthorized and backed out changes Reviews of new requests for change Review of emergency and standard changes, As well as a review of the change management process itself

The Change Advisory Board





Emergency CAB

Emergency changes need to be implemented quickly normally in response to a major incident or because of a failure affecting a business critical service. There may not be time to convene a meeting of the CAB in an emergency situation.

However, emergency changes still need to be carefully managed and controlled.

Due to the timescales involved it is not always practical for a full CAB to meet to approve an emergency change since it often takes too long to convene and speak to all the CAB members. Instead, a subset of the CAB called the E-CAB, or Emergency Change Advisory Board, can be convened.

The E-CAB consists of a few, select, senior people who can be quickly convened and have the appropriate level of authority to make a quick decision.

E-CAB authority may be delegated if necessary. For example a single manager who is on call and available twenty four hours day - may fulfill the E-CAB role out of hours.

In other words, whilst an ideal E-CAB would consist of two to three people, it could on occasion be made up of just one person.

Dont forget all emergency changes still need to be designed and tested as much as possible. They must also be reviewed after they have been implemented by the full CAB.





Change management can only be effective if it has good relationships within IT and with the business.

People need to be aware that change management exists, and need to inform the process when changes are taking place.

Change Management and Business Change Management

Change Management needs a strong interface with Business Change Management. For example, if a company is moving offices. This will be managed by business change management, but there will be lots of IT changes moving infrastructure, setting up new environments and so on.

Business and IT Change Management need to work closely together to achieve success.

Change Management Interfaces

Program and project management change management needs to be involved in projects as early as possible to identify any possible impact

Organizational and stakeholder change management - to check if any changes will affect the overall organizational structure or staff

Sourcing and partnering change management needs to work with internal and external vendors and partners, integrating with their change management processes if required

Change Management Interfaces

lesson-10-service-transition-processes-part-1.pdf

Documents

Transcript of lesson-10-service-transition-processes-part-1.pdf

Lesson Plan Sem 3

Lesson 1 Menu

Lesson: Electron Microscopy Lesson Developer: Anuradha ...

Dw lessons 01 lesson

Lesson 27: Evaluating Definite Integrals

Lesson 3: Basic theory of stochastic processesLesson 3: Basic theory of stochastic processes Umberto Triacca Dipartimento di Ingegneria e Scienze dell’Informazione e Matematica Universit

Lesson 10: Covariances of causal ARMA Processes · Umberto Triacca Lesson 10: Covariances of causal ARMA Processes. Ergodicity under Gaussianity Let fx t;t 2Zgbe a stationary process

1st Lesson

Architecture lesson #3 the pantheon

METALS IN THE ICM LESSON 3. OUTLINE OF THE LESSON INSTRUMENTATION FOR X-RAY SPECTROSCOPY MEASUREMENT TRICKS ENRICHMENT PROCESSES AND RELATIVE CONTRIBUTION.

Lesson 6-2c

Module 1 Lesson 21 to Lesson 25.notebookmsaddmath.weebly.com/uploads/8/6/7/9/86792872/module_1_lesso… · Module 1 Lesson 21 to Lesson 25.notebook 1 November 03, 2016 Oct 3112:54

Lesson 4 Phase Identification - Profexprofex.doebelin.org/wp-content/uploads/2016/09/Lesson-4.pdf · Lesson 4 Phase Identification Nicola Döbelin RMS Foundation, Bettlach, Switzerland

Lesson 11 - 2

LESSON 22

Lesson 06 Mathjazz

Events Team - Transition

Industrial Design - Lesson 2

Lesson Objective

Transition metalbonding