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

1. IT Service Management2011年度教育部-IBM精品课程 同济大学软件学院 严海洲 yanhaizhou@tongji.edu.cn

2. Chapter 4 Service Transition

3. Tivoli Software 服务导入 •服务导入为如何将新的和变更的服务导入到运营环境的能力开发和改 进提供指导 • 《服务导入》介绍了如下的主题和流程： Service • Service Transition Principles • Service Transition Processes Change Management Service Asset & Configuration Mgmt Knowledge Management Service Release Planning Performance and Risk evaluation Acquire Assets, Build and Test Release Service Release Acceptance Test and Pilot Deployment, Decommission and Transfer • Technology Considerations • Implementation Considerations Design Service Strategy ITIL Service Transition

4. 4.1 Introduction

5. Service Transition (ST) • • Plan and implement the deployment of all releases to • create 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 live • environment • • Transition services to/from other organizations • • Decommission or terminate services

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

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

8. Scope of ST • Management and coordination of processes, systems and functions to: – Package, build, test and deploy a release into production – Establish the service specified in the customer and stakeholder requirements

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

10. Service Transition Overview

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

12. 4.2Transition Planning and Support

13. Transition Planning and Support Process • Process to plan appropriate capacity and resources to package a release, build, release, test, deploy and establish the new or changed service into production • Goals: --Plan and coordinate the resources to ensure that the requirements of Service Strategy encoded in Service Design are effectively realized in Service Operations --Identify, manage and control the risks of failure and disruption across transition activities

14. 4.3 CHANGE MANAGEMENT

15. Change — Objectives and purpose • Respond to changing business requirements – Respond to Business and IT requests to align Services with 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

16. Change — Scope • Addition, Modification or Removal of – Any Service or Configuration Item or associated documentation Including – Strategic, Tactical and Operational changes Excluding – Business strategy and process – Anything documented as out of scope

17. 4.3 Change Management • Goals, objectives and purpose • Scope • Value to the business • Basic concepts • Activities • Roles • Interfaces • Key metrics • Challenges

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

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

20. Change — Activities

21. 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 and implementation of the change? • What is the RELATIONSHIP between this change and other changes?

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

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

24. Change — Value to the business • Prioritizing and responding to requests • Implementing changes in required times • Meet agreed service requirements while optimizing costs • Reducing failed changes and rework • Correctly estimating quality, time and cost • Assessing and managing risks • Managing staff time

25. Change — Interfaces • Inputs • Outputs • Interfaces with other processes

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

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

28. Change — Process interfaces • Asset and Configuration Management • IT Service Continuity Management • Capacity and Demand Management • Release and Deployment Management • Security Management

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

30. Change — Challenges • People who ignore the process • Inadequate Configuration Management • Business pressure to “just do it” • Lack of “Standard Changes” • Scalability across large organizations

31. 4.4 Service Asset and Configuration Management

32. Service Asset and ConfigurationManagement (SACM) • Objectives • Basic concepts • Roles

33. SACM — Objectives • For service assets, configuration items, and (where appropriate) customer assets – Protect integrity throughout their lifecycle – Provide accurate information to support business and service management • Establish and maintain a Configuration Management System – As part of an overall Service Knowledge Management System

34. SACM — Basic concepts • Configuration Items • Logical Model

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

36. SACM logical model

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

38. SKMS/CMS/CMDB

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

40. DML and CMDB relationship

41. Service Transition V Model

42. Service Transition V Model

43. 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, and formal documentation such as Process documentation and SLAs

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

45. 4.5 RELEASE AND DEPLOYMENT MANAGEMENT

46. Release and Deployment Management • Objectives • Basic concepts • Roles

47. Release and Deployment — Objectives • Clear, comprehensive release and deployment plans – Supporting customer and business change projects • Release packages can be built, installed, tested and deployed – Efficiently, successfully and on schedule. – With minimal impact on production services, operations, and support teams – Enabling new or changed services to deliver agreed service 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 service

48. Release and Deployment—Basic concepts (1 of 3) • Release Unit – CIs that are normally released together – Typically includes sufficient components to perform a useful 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

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

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