IT Service Management2011 年度教育部 -IBM 精品课程

同济大学软件学院 严海洲yanhaizhou@tongji.edu.cn

Chapter 4 Service Transition

• Service Transition Principles• Service Transition Processes

Change ManagementService Asset & Configuration MgmtKnowledge ManagementService Release PlanningPerformance and Risk evaluationAcquire Assets, Build and Test ReleaseService Release Acceptance Test and PilotDeployment, Decommission and Transfer

• Technology Considerations• Implementation Considerations

Tivoli Software

服务导入• 服务导入为如何将新的和变更的服务导入到运营环境的能力开发和改进提供指导• 《服务导入》介绍了如下的主题和流程：

Service

Design

ServiceStrategy

ITIL

ServiceTransition

4.1 Introduction

Service Transition (ST)

• Plan and implement the deployment of all releases tocreate a new service or improve an existing service

• Assure that the proposed changes in the Service Design• Package are realized

Successfully steer releases through testing and into liveenvironment

• Transition services to/from other organizations

• Decommission or terminate services

5

Service Transition

• Concepts– V Model

– Configuration Item

– Configuration Management System

– Knowledge Management

– Data Information Knowledge Wisdom

– Service Knowledge Management System

– Definitive Media Library

• Processes– Change Management

– Service Asset and Configuration Management

– Release and Deployment Management6

Service Transition Objectives

• Plan and manage the resources to move services into

production within predicted cost, quality, time estimates

• Ensure minimal unpredicted impact on the production services, operations and support organization

• Raise satisfaction with the service transition practices

--Including deployment, communications, release documentation, training, knowledge transfer

• Increase proper use of the services and underlying

applications

and technology solutions

• Help customer and business change projects to align their

activities with the service transition plans7

Scope of ST

• Management and coordination of processes, systemsand functions to:– Package, build, test and deploy a release into production

– Establish the service specified in the customer andstakeholder requirements

8

Value to business of ST

• Ability to react quickly to give ‘competitive edge’

• Management of mergers, de-mergers, acquisitions,transfer of services

• Higher success rate of changes and releases

• Better prediction of service levels and warranties

• More confidence in governance and compliance

• Better estimating of resource plans and budgets

• Improved productivity of business and IT

• Timely savings following disposal or de-commissioning

• Reduced level of risk

9

Service Transition Overview

10

Service Transition processes

• Transition Planning and Support

• Change Management

• Service Asset and Configuration Management (SACM)

• Release and Deployment Management

• Service Validation and Testing

• Evaluation

• Knowledge Management

11

4.2Transition Planning and Support

Transition Planning and Support Process

• Process to plan appropriate capacity and resources topackage a release, build, release, test, deploy andestablish the new or changed service into production

• Goals:

--Plan and coordinate the resources to ensure thatthe requirements of Service Strategy encoded inService Design are effectively realized in ServiceOperations

--Identify, manage and control the risks of failureand disruption across transition activities

13

4.3 CHANGE MANAGEMENT

Change — Objectives and purpose

• Respond to changing business requirements– Respond to Business and IT requests to align Serviceswith business needs

• Minimize impact of implementing changes– Reduce incidents, disruption and rework

• Optimize business risk

• Implement changes successfully

• Implement changes in times that meet business needs

• Use standard processes

• Record all changes

15

Change — Scope

• Addition, Modification or Removal of

– Any Service or Configuration Item or associateddocumentation

Including– Strategic, Tactical and Operational changes

Excluding– Business strategy and process

– Anything documented as out of scope

16

4.3 Change Management

• Goals, objectives and purpose

• Scope

• Value to the business

• Basic concepts

• Activities

• Roles

• Interfaces

• Key metrics

• Challenges

17

Change — Basic concepts (1 of 2)

• Change types– Normal changes• Types are specific to the organization

• Type determines what assessment is required

– Standard changes• Pre-authorized with an established procedure

– Emergency changes• Insufficient time for normal handling

• Should use normal process as far as possible

18

Change — Basic concepts (2 of 2)

• Change, configuration, release and deployment– Should be planned together

– Should have coordinated implementation

• Remediation plans– Every change should have a backout plan

– Sometimes a change can’t be backed out• Must still have a plan for what to do

Change — Activities

20

7 Rs of Change Management

• Who RAISED the change?

• What is the REASON for the change?

• What is the RETURN required from the change?

• What are the RISKS involved in the change?

• What RESOURCES are required to deliver the change?

• Who is RESPONSIBLE for the build, test andimplementation of the change?

• What is the RELATIONSHIP between this change andother changes?

21

Change — Roles (1 of 2)

• Change Manager

– Process owner

– Ensures that process is followed

– Usually authorizes minor changes

– Coordinates and runs CAB meetings

– Produces change schedule

– Coordinates change/built/test/implementation

– Reviews/Closes Changes

22

Change — Roles (2 of 2)

• Change Advisory Board (CAB)

– Supports the change manager

– Consulted on significant changes

– Business, users, application/technical support, operations,service desk, capacity, service continuity, third parties…

• Emergency CAB (ECAB)– Subset of the standard CAB

– Membership depends on the specific change

23

Change — Value to the business

• Prioritizing and responding to requests

• Implementing changes in required times

• Meet agreed service requirements while optimizingcosts

• Reducing failed changes and rework

• Correctly estimating quality, time and cost

• Assessing and managing risks

• Managing staff time

24

Change — Interfaces

• Inputs

• Outputs

• Interfaces with other processes

25

Change — Inputs

• Change policy and strategy

• RFCs

• Change Proposals

• Service Management Plans

• Assets and configuration items

• Existing change management documents– Change schedule

– Projected Service Outage (PSO)

26

Change — Outputs

• Rejected and approved RFCs

• Changes to services and CIs

• Updated– Change schedule

– Projected Service Outage (PSO)

• Change plans, decisions, actions…

• Change documents and records

• Management reports

27

Change — Process interfaces

• Asset and Configuration Management

• IT Service Continuity Management

• Capacity and Demand Management

• Release and Deployment Management

• Security Management

28

Change — Key metrics• Compliance

– Reduction in unauthorized changes

– Reduction in emergency changes

• Effectiveness– Percentage of changes which met requirements

– Reduction in disruptions, defects and re-work

– Reduction in changes failed / backed out

– Number of incidents attributable to changes

• Efficiency– Benefits (value compared to cost)

– Average time to implement (by urgency/priority/type)

– Percentage accuracy in change estimates29

Change — Challenges

• People who ignore the process

• Inadequate Configuration Management

• Business pressure to “just do it”

• Lack of “Standard Changes”

• Scalability across large organizations

30

4.4 Service Asset and Configuration Management

Service Asset and ConfigurationManagement (SACM)

• Objectives

• Basic concepts

• Roles

32

SACM — Objectives

• For service assets, configuration items, and (whereappropriate) customer assets

– Protect integrity throughout their lifecycle

– Provide accurate information to support business andservice management

• Establish and maintain a Configuration ManagementSystem

– As part of an overall Service Knowledge ManagementSystem

33

SACM — Basic concepts

• Configuration Items

• Logical Model

34

SACM Configuration Items categories

• Service Lifecycle CIs

– Business case, plan, design package…

• Service CIs– Service package, acceptance criteria,…

– Service assets• Management, organization, process, knowledge, people,

information, applications, infrastructure, financial capital

• Organization CIs

• Internal and External CIs

35

SACM logical model

36

SACM — Roles

• Service Asset Manager

• Configuration Manager

• Each of these is the process owner for their area– Implement policy and standards

– Procure and manage finances

– Agree scope, processes and procedures

– Define and procure tools

– Recruit and train staff

– Oversee collection and management of data

– Manage audits

– Provide management reports37

SKMS/CMS/CMDB

38

Definitive Media Library (DML)

• Master copies of all software assets– In house, external software house , COTS…

– Scripts as well as code

– Management tools as well as applications

– Including licenses

• Quality checked– Complete, correct, virus scanned…

• The only source for build and distribution

39

DML and CMDB relationship

40

Service Transition V Model

41

Service Transition V Model

42

Configuration Item (CI)

• Anything that needs to be managed in order to deliver an IT

Service

• CI information is recorded in the Configuration Management

System

• CI information is maintained throughout its Lifecycle by Configuration Management

• All CIs are controlled by Change Management

• CIs typically include

– IT Services, hardware, software, buildings, people, andformal documentation such as Process

documentationand SLAs

43

Configuration Management System (CMS)

• Information about all Configuration Items– CI may be entire service, or any component

– Stored in 1 or more databases (CMDBs)

• CMS stores attributes– Any information about the CI that might be needed

• CMS stores relationships– Between CIs

– With incident, problem, change records etc .

• CMS has multiple layers– Data sources and tools, information integration,

knowledge processing, presentation44

4.5 RELEASE AND DEPLOYMENT MANAGEMENT

Release and Deployment Management

• Objectives

• Basic concepts

• Roles

46

Release and Deployment — Objectives

• Clear, comprehensive release and deployment plans– Supporting customer and business change projects

• Release packages can be built, installed, tested anddeployed

– Efficiently, successfully and on schedule.

– With minimal impact on production services, operations,and support teams

– Enabling new or changed services to deliver agreedservice requirements

• Skills and knowledge transfer to enable– Customers and users to optimize use of the service

– Operations and support staff to run and support the service47

Release and Deployment—Basic concepts (1 of 3)

• Release Unit

– CIs that are normally released together

– Typically includes sufficient components to perform auseful function. For example

• Fully configured desktop PC, payroll application

– Considerations include• Ease and amount of change needed to deploy

• Resources needed to build, test and deploy

• Complexity of interfaces

48

Release and Deployment—Basic concepts (2 of 3)

• Big bang versus phased approach

– Phased approach can be by users, locations,functionality…

• Push versus Pull deployment

• Automated versus manual deployment

• Release Package– Single release or many related releases

– Can include hardware, software, utility, warranty,documentation, training…

49

Release and Deployment—Basic concepts (3

of 3)

• Release and deployment models

– Standard approach for a release

– Overall structure for building the release

– Exit and entry criteria for each stage

– Build and test environments to use

– Roles and responsibilities

– Configuration baseline model

– Template schedules

– Release and deployment steps

– Supporting systems

– Handover activities50

Release and Deployment — Roles (1 of 2)

• Release package and build manager

– Establishes final release configuration

– Builds final release

– Tests final delivery prior to independent testing

– Establishes and reports known errors and workarounds

– Provides input to final implementation sign-off

51

Release and Deployment — Roles (2 of 2)

• Deployment manager

– Final physical delivery of the service implementation

– Co-ordinates documentation and communications• Including training and customer, service management and

technical release notes

– Plans deployment with Change, SKMS and SACM

– Technical and application guidance and support• Including known errors and workarounds

– Feedback on effectiveness of the release

– Records metrics for deployment• To ensure within agreed SLAs

52

4.6 Service Validation and Testing

Service Validation and Testing Process

• Process for establishing that the Service Design andrelease will deliver a new or changed service or serviceoffering that is fit for purpose and fit for use

• Goal: to assure that a service will provide value tocustomers and their business

• The Service V Model can be used to map the types oftest to each stage of development

54

Service Validation and Testing Process

55

4.7 Evaluation

Evaluation Process

• Evaluation is a generic process that considers whetherthe performance of something is acceptable, value formoney, etc. –and whether it will be proceeded with,accepted into use, paid for, etc.

• Purpose: to provide a consistent and standardizedmeans of determining the performance of a servicechange in the context of existing and proposed servicesand IT infrastructure

--Actual performance of a change is assessedagainst its predicted performance and any deviationsbetween the two are understood and managed

57

Evaluation Process

58

4.8 Knowledge Management

Knowledge Management Process

• The process of ensuring that the right information isdelivered to the appropriate place or competentperson, at the right time to enable informed decision

• Ensure that, at a given time and location, serviceprovider staff have adequate information on:

--Who is currently using their services

--The current states of consumption

--Service delivery constraints

--Difficulties faced by the customer in fully realizingthe benefits expected from the service

60

Knowledge Management (KM)

“The process responsible for gathering, analyzing,storing and sharing knowledge and information within an organization. The primary purpose of Knowledge Management is to improve efficiency by reducing the need to rediscover knowledge.”

61

Data, Information, Knowledge and Wisdom

(DIKW)

Wisdom

Knowledge

Information

Data

62

Service Knowledge Management System (SKMS)

• Data repository which contains knowledge of servicesprovided and includes data from the ConfigurationManagement Database (CMDB) and ConfigurationManagement System (CMS)

• Also includes information on:

--Experience of staff

--Records of peripheral matters

--Supplier and partners requirements, abilities andexpectations

--Typical and anticipated user skill levels

• Supports informed decision making

63

Information

IntegrationLayer

Data andInformatio

n

CMDB

CMDB

DML

Service Knowledge Base

Configuration ManagementSystem

Service Knowledge Management System(SKMS)

Wisdom – ability to make decisions

Presentation Layer

Knowledge Processing Layer

64

Service Knowledge Management System

(SKMS)

65