Service Transition - Preparing for Change PDF

28/8/07 14:01 Page 75 | Service Transition – preparing for change equirements The business/customers Service Strategy Resource and Constraints Policies Objectives from Requirements Strategies Service Design SDPs Standards Architectures Solution Designs Service Transition SKMS Transition Plans IT wor...

28/8/07 14:01 Page 75 | Service Transition – preparing for change equirements The business/customers Service Strategy Resource and Constraints Policies Objectives from Requirements Strategies Service Design SDPs Standards Architectures Solution Designs Service Transition SKMS Transition Plans IT world, many business innovations are achieved h project initiatives that involve IT. In the end, er these are minor operational improvements or transformational events, they all produce change. In eceding chapter we looked at creating and ving services through the design stage of the e. Now we must ensure that what is planned to be mented will achieve the expected objectives. It is at oint the knowledge that has been generated and ill be needed to manage services once in the live Tested Solutions In this chapter we will discuss a few of the key concepts within Service Transition:  Transition Planning  Asset and Configuration Management  Release and Deployment Management  Change Management  Testing and Validation. The purpose of Service Transition is to: 75 28/8/07 14:01 Page 76 Service Transition – preparing for change vide a consistent and rigorous framework for aluating the service capability and risk profile before ew or changed service is released or deployed ablish and maintain the integrity of all identified vice assets and configurations as they evolve ough the Service Transition stage vide good-quality knowledge and information so t Change and Release and Deployment nagement can expedite effective decisions about moting a release through the test environments d into production vide efficient repeatable build and installation chanisms that can be used to deploy releases to the t and production environments and be rebuilt if uired to restore service ure that the service can be managed, operated and pported in accordance with the requirements and nstraints specified within the Service Design. ve Service Transition can significantly improve a e Provider’s ability to handle high volumes of e and releases across its customer base. It enables rvice Provider to: gn the new or changed service with the customer’s siness requirements and business operations ure that customers and users can use the new or anged service in a way that minimizes value to the siness operations. cally, Service Transition adds value to the business proving: e ability to adapt quickly to new requirements and rket developments (‘competitive edge’) nsition management of mergers, de-mergers, quisitions and transfer of services  The predictions of service levels and warranties for new and changed services  Confidence in the degree of compliance with business and governance requirements during change  The variation of actual against estimated and approved resource plans and budgets  The productivity of business and customer staff because of better planning and use of new and changed services  Timely cancellation or changes to maintenance contracts for hardware and software when components are disposed or decommissioned  Understanding of the level of risk during and after change, e.g. service outage, disruption and re-work. The processes covered in Service Transition (see Figure 6.1) are:  Transition Planning and Support  Change Management  Service Asset and Configuration Management  Release and Deployment Management  Service Validation and Testing  Evaluation  Knowledge Management. 6.1 TRANSITION PLANNING AND SUPPORT The goals of Transition Planning and Support are to:  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. 28/8/07 14:01 Page 77 Service Transition – preparing for change | 6.1 The Service Transition process Continual Service Improvement Change Management (4.2) RFC1 RFC2 RFC3 RFC4 RFC5 RFC6 Service Asset and Configuration Management (4.3) BL BL BL BL BL BL BL Service Transition Planning and Support (4.1) Oversee management of organization and stakeholder change (5) Evaluation of a Change or Service (4.6) E1 ervice rategy Service Design Plan and prepare release E2 Build and test Service testing and pilots E3 Plan and prepare for deployment Transfer, deploy, retire Review and close service transition Service Operation Early Life Support Release and Deployment Management (4.4) Service Validation and Testing (4.5) Knowledge Management (4.7) Focus of activity related to service transition Other ITIL core publication ITIL process in this publication that supports the whole service life cycle E BL RFC Point to Evaluate the Service Design Point to capture Baseline Request for Change 77 28/8/07 14:01 Page 78 Service Transition – preparing for change ure that all parties adopt the common framework standard re-usable processes and supporting tems in order to improve the effectiveness and ciency of the integrated planning and coordination ivities vide clear and comprehensive plans that enable the tomer and business change projects to align their ivities with the Service Transition plans. ganization should decide the most appropriate ach to Service Transition based on the size and of the core and supporting services, the number equency of releases required, and any special needs users – for example, if a phased rollout is usually ed over an extended period of time. rvice Transition strategy defines the overall ach to organizing Service Transition and allocating ces. The aspects to consider are: pose, goals and objectives of Service Transition ntext, e.g. service customer, contract portfolios ope – inclusions and exclusions plicable standards, agreements, legal, regulatory and ntractual requirements ganizations and stakeholders involved in transition mework for Service Transition teria ntification of requirements and content of the new changed service ople proach iverables from transition activities including ndatory and optional documentation for each stage hedule of milestones ancial requirements – budgets and funding. it in a Service Design Package (SDP). The SDP includes the following information that is required by the Service Transition team:  Applicable service packages (e.g. Core Service Package,        Service Level Package) Service specifications Service models Architectural design required to deliver the new or changed Service including constraints Definition and design of each release package Detailed design of how the service components will be assembled and integrated into a release package Release and deployment plans Service Acceptance Criteria. 6.1.1 Planning an individual Service Transition The release and deployment activities should be planned in stages as details of the deployment might not be known in detail initially. Each Service Transition plan should be developed from a proven Service Transition model wherever possible. Although Service Design provides the initial plan, the planner will allocate specific resources to the activities and modify the plan to fit in with any new circumstances, e.g. a test specialist may have left the organization. A Service Transition plan describes the tasks and activities required to release and deploy a release into the test environments and into production, including:  Work environment and infrastructure for the Service Transition  Schedule of milestones, handover and delivery dates  Activities and tasks to be performed 28/8/07 14:01 Page 79 Service Transition – preparing for change | d times and contingency. ing resources to each activity and factoring in ce availability will enable the Service Transition r to work out whether the transition can be ed by the required date. If resources are not ble, it may be necessary to review other transition itments and consider changing priorities. Such es need to be discussed with Change and Release ement as this may affect other changes that may be dents or prerequisites of the release. Integrated planning planning and management are essential to deploy a across distributed environments and locations into ction successfully. An integrated set of transition hould be maintained that are linked to lower-level uch as release, build and test plans. These plans be integrated with the change schedule, release eployment plans. Establishing good-quality plans at tset enables Service Transition to manage and nate the Service Transition resources, e.g. resource ion, utilization, budgeting and accounting. erarching Service Transition plan should include the one activities to acquire the release components, ge the release, build, test, deploy, evaluate and vely improve the service through early life support. also include the activities to build and maintain the s and IT infrastructure, systems and environments e measurement system to support the transition es. Adopting programme and project management best practices st practice to manage several releases and responsibilities such as operations or through a team brought together for the purpose. Elements of the deployment may be delivered through external suppliers, and suppliers may deliver the bulk of the deployment effort, for example in the implementation of an off-theshelf system such as an ITSM support tool. Significant deployments will be complex projects in their own right. The steps to consider in planning include the range of elements comprising that service, e.g. people, application, hardware, software, documentation and knowledge. This means that the deployment will contain sub-deployments for each type of element comprising the service. 6.1.4 Reviewing the plans The planning role should quality review all Service Transition, release and deployment plans. Wherever possible, lead times should include an element of contingency and be based on experience rather than merely supplier assertion. This applies even more for internal suppliers where there is no formal contract. Lead times will typically vary seasonally and they should be factored into planning, especially for long timeframe transitions, where the lead times may vary between stages of a transition, or between different user locations. Before starting the release or deployment, the Service Transition planning role should verify the plans and ask appropriate questions such as:  Are these Service Transition and release plans up to date?  Have the plans been agreed and authorized by all relevant parties, e.g. customers, users, operations and support staff?  Do the plans include the release dates and deliverables 79 28/8/07 14:01 Page 80 Service Transition – preparing for change ve the impacts on costs, organizational, technical d commercial aspects been considered? ve the risks to the overall services and operations pability been assessed? s there been a compatibility check to ensure that Configuration Items that are to be released are mpatible with each other and with Configuration ms in the target environments? ve circumstances changed such that the approach eds amending? re the rules and guidance on how to apply it evant for current service and release packages? the people who need to use it understand and ve the requisite skills to use it? he service release within the SDP and scope of what transition model addresses? s the Service Design altered significantly such that it no longer appropriate? ve potential changes in business circumstances been ntified? planning of service transition and support will the need for corrective measures during and after into live operation. Refer to the Service Transition ublication for full details on the Transition Planning upport process. CHANGE MANAGEMENT urpose of the Change Management process is to that: ndardized methods and procedures are used for cient and prompt handling of all changes changes to Service Assets and Configuration Items recorded in the configuration management system The goals of Change Management are to:  Respond to the customer’s changing business requirements while minimizing value and reducing incidents, disruption and re-work  Respond to the business and IT requests for change that will align the services with the business needs. Reliability and business continuity are essential for the success and survival of any organization. Service and infrastructure changes can have a negative impact on the business through service disruption and delay in identifying business requirements, but Change Management enables the service provider to add value to the business by:  Prioritizing and responding to business and customer change proposals  Implementing changes that meet the customers’ agreed service requirements while optimizing costs  Contributing to meet governance, legal, contractual       and regulatory requirements Reducing failed changes and therefore service disruption, defects and re-work Delivering change promptly to meet business timescales Tracking changes through the Service Lifecycle and to the assets of its customers Contributing to better estimations of the quality, time and cost of change Assessing the risks associated with the transition of services (introduction or disposal) Aiding productivity of staff through minimizing disruptions due to high levels of unplanned or Emergency Change and hence minimizing service availability 28/8/07 14:01 Page 81 Service Transition – preparing for change | sing with the business change process to identify portunities for business improvement. s that support Change Management include: ating a culture of Change Management across the anization where there is zero tolerance for authorized change gning the service Change Management process with siness, project and stakeholder change management cesses oritization of change, e.g. innovation vs preventive detective vs corrective change ablishing accountability and responsibilities for anges through the Service Lifecycle gregation of duty controls ablishing a single focal point for changes in order to nimize the probability of conflicting changes and ential disruption to the production environment venting people who are not authorized to make a ange from having access to the production vironment egration with other service management processes establish traceability of change, detect unauthorized ange and identify change-related incidents ange windows – enforcement and authorization for eptions formance and risk evaluation of all changes that pact service capability formance measures for the process, e.g. efficiency d effectiveness. The seven Rs of Change Management lowing questions must be answered for all changes. ut this information, the impact assessment cannot business benefits or even having a detrimental, unexpected effect on the live service.  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? The Request for Change (RFC) is a key information source and the catalyst for the change activities of:  Create and record  Review  Assess and evaluate  Authorize  Plan  Coordinate  Review  Close. Each RFC will follow a selected Change Model that is appropriate for the nature and type of change. Change Models are pre-established process flows with the necessary steps to satisfy the type of change and level of authorization needed to properly assess risk and impact. Three basic Change Models are included in Service Transitions which can be adapted to suit individual organizational circumstances and need.  Standard Change Model – Used for pre-authorized repetitive, low-risk, well-tested changes. Often these 81 28/8/07 14:01 Page 82 Service Transition – preparing for change  Emergency Change Model – A model reserved only rmal Change Model – The full model for changes t must go through assessment, authorization and ange Advisory Board (CAB) agreement before plementation for highly critical changes needed to restore failed high availability or widespread service failure, or that will prevent such a failure from imminently occurring. Figure 6.2 depicts the high-level flow of a Normal Change Model. 6.2 Normal Change Model Create RFC Change proposal (optional) Record the RFC Initiator requested Review RFC ready for evaluation Assess and evaluate change ready for decision Authorize Change proposal Work orders Authorize Change Change Authority authorized Plan updates Change Management scheduled Co-ordinate change implementation* Change Management implemented Work orders Update change and configuration information in CMS Change Management 28/8/07 14:01 Page 83 Service Transition – preparing for change | Change Advisory Board AB is a body that exists to support the authorization nges and to assist Change Management in the ment and prioritization of changes. As and when a convened, members should be chosen who are e of ensuring that all changes within the scope of B are adequately assessed from both a business and nical viewpoint. AB may be asked to consider and recommend the on or rejection of changes appropriate for higher uthorization and then recommendations will be ted to the appropriate change authority. ieve this, the CAB needs to include people with a nderstanding across the whole range of stakeholder The Change Manager will normally chair the CAB otential members include: stomer(s) er manager(s) er group representative(s) plications developers/maintainers ecialists/technical consultants vices and operations staff, e.g. Service Desk, test nagement, ITSCM, security, capacity ilities/office services staff (where changes may affect ves/accommodation and vice versa) ntractor’s or third parties’ representatives, e.g. in sourcing situations. rvice Transition core publication contains the full e Management process. ASSET AND CONFIGURATION MANAGEMENT 83 on one another. If one system fails, the others will eventually succumb, unless provided additional lifesupporting intervention. Services are systems with similar levels of interdependency. These are service assets which have configurations specific to the functions they perform and, ultimately, the service they collectively deliver. No organization can be fully efficient or effective unless it manages its assets well, particularly those assets that are vital to the running of the customer’s or organization’s business. This process manages the service assets in order to support the other service management processes. The goal of optimizing the performance of service assets and configurations improves the overall service performance and optimizes the costs and risks caused by poorly managed assets, e.g. service outages, fines, correct licence fees and failed audits. Service Asset and Configuration Management (SACM) provides visibility of accurate representations of a service, release, or environment that enable:  Better forecasting and planning of changes  Changes and releases to be assessed, planned and delivered successfully  Incidents and Problems to be resolved within the service level targets  Service levels and warranties to be delivered  Better adherence to standards, legal and regulatory obligations (fewer non-conformances)  More business opportunities as able to demonstrate control of assets and services  Changes to be traceable from requirements  Creation of the ability to identify the costs for a service. 6.3.1 Configuration Items 28/8/07 14:01 Page 84 Service Transition – preparing for change exity, size and type, ranging from an entire service em including all hardware, software, documentation pport staff to a single software module or a minor are component. CIs may be grouped and managed er, e.g. a set of components may be grouped into a. CIs should be selected using established selection , grouped, classified and identified in such a way ey are manageable and traceable throughout the e Lifecycle. will be a variety of CIs; the following categories may o identify them. rvice Lifecycle CIs such as the Business Case, vice management plans, Service Lifecycle plans, vice Design Package, release and change plans, and t plans. They provide a picture of the Service vider’s services, how these services will be ivered, what benefits are expected, at what cost, d when they will be realized rvice CIs such as: Service capability assets: management, organization, processes, knowledge, people Service resource assets: financial capital, systems, applications, information, data, infrastructure and facilities, people Service model Service package Release package Service acceptance criteria ganization CIs – some documentation will define characteristics of a CI whereas other cumentation will be a CI in its own right and need be controlled, e.g. the organization’s business ategy or other policies that are internal to the anization but independent of the Service Provider.  Internal CIs comprising those delivered by individual projects, including tangible (data centre) and intangible assets such as software that are required to deliver and maintain the service and infrastructure  External CIs such as external customer requirements and agreements, releases from suppliers or subcontractors and external services  Interface CIs that are required to deliver the end-toend service across a Service Provider Interface (SPI). 6.3.2 Configuration Management System To manage large and complex IT services and infrastructures, Service Asset and Configuration Management (SACM) requires the use of a supporting system known as the Configuration Management System (CMS). The CMS holds all the information for CIs within the designated scope. Some of these items will have related specifications or files that contain the contents of the item, e.g. software, document or photograph. For example, a Service CI will include the details such as supplier, cost, purchase date and renewal date for licences and maintenance contracts and the related documentation such as SLAs and underpinning contracts. The CMS is also used for a wide range of purposes; for example asset data held in the CMS may be made available to external financial asset management systems to perform specific asset management process reporting outside configuration management. The CMS maintains the relationships between all service components and any related incidents, problems, known errors, change and release documentation and may also contain corporate data about employees, suppliers, locations and business units, customers and users. 28/8/07 14:01 Page 85 utes for Configuration Items tes describe the characteristics of a CI that are le to record and which will support SACM and the rocesses it supports. CM plan references the configuration information ata architecture. This includes the attributes to be ed for each type of asset or CI. Typical attributes e: que identifier ype me/description sion (e.g. file, build, baseline, release) cation pply date ence details, e.g. expiry date ner/custodian tus pplier/source ated document masters ated software masters torical data, e.g. audit trail ationship type plicable SLA. attributes will define specific functional and physical teristics of each type of asset and CI, e.g. size or ty, together with any documentation or cations. usiness value of SACM is often not recognized until e of the CMS is used with other service ement processes within the Service Lifecycle. The part of a larger Service Knowledge Management m (see the Service Transition core publication) that Service Transition – preparing for change | CI information is critical for responsive service provision and assists in areas such as:  Service Desk – impact of service failure, SLA targets       associated to the service that the CI(s) are supporting, owner and technical support information, recent changes to the CI to aid in Incident triage Event Management – trending of events logged against CI for possible service stability issues Incident Management – logging of faults against CIs and ability to see upstream and downstream impacts Financial Management – asset and replacement lifecycle information, contributing the service valuation activities Availability and Continuity – identification of point of failure vulnerability through CI relationship and redundancy information in the CMS Service Level Management – identifying dependencies and relationships of components that contribute to an end-to-end service Change Management – identification of impact of changes to services. 85 28/8/07 14:01 Page 86 Service Transition – preparing for change 6.3 Service Asset and Configuration Management – interfaces to the lifecycle Planning, management resources, time Management support Working relationships Resources, facilities, CMS and tools Training and Guidance y, Standards, trategy, ce Portfolio, mer Portfolio, act Portfolio, t requirements Requirements Design, Maintenance, Release, Deployment, Operations plans Configuration Management Plan, Contract Control Management and Planning CI Identification, naming, labelling, data and documentation Baseline and Release Id Configuration Identification Configuration Control RFC/ change to CI Change and Configuration Records and Documentation Feedback RELEASE AND DEPLOYMENT MANAGEMENT ve Release and Deployment Management practices the Service Provider to add value to the business by: ivering change, faster and at optimum cost and nimized risk Updated RFC, updated CI Status Record/Report Configuration information and Performance Status Accounting and Reporting Physical CIs, Test results Audit/discovery tools Verification and Audit Action items Confidence in service and infrastructure  Improving consistency in implementation approach across the business change and service teams, suppliers and customers  Contributing to meeting auditable requirements for traceability through Service Transition. Well-planned and implemented release and deployment will make a significant difference to an organization’s 28/8/07 14:01 Page 87 Service Transition – preparing for change |  There is knowledge transfer to enable the customers exity. At worst, it can cripple the environment and de the live services. oal of Release and Deployment Management is to releases into production and enable effective use service in order to deliver value to the customer. bjective of Release and Deployment Management is ure that: ere are clear and comprehensive release and ployment plans that enable the customer and siness change projects to align their activities with se plans elease package can be built, installed, tested and ployed efficiently to a deployment group or target vironment successfully and on schedule ew or changed service and its enabling systems, hnology and organization are capable of delivering agreed service requirements, i.e. utilities, warranties d service levels and users to optimize their use of the service to support their business activities  Skills and knowledge are transferred to operations and support staff to enable them to effectively and efficiently deliver, support and maintain the service according to required warranties and service levels  There is minimal unpredicted impact on the production services, operations and support organization  Customers, users and service management staff are satisfied with the Service Transition practices and outputs, e.g. user documentation and training. A key to Release and Deployment Management is defining the appropriate release package type for a given type of release. Figure 6.4 illustrates one example of a release package. 6.4 Example of a release package Current Baseline (as-is) Business/Organization Architecture Release Package BA RO1 Delivery, feedback and monitoring Service Portfolio Service Architecture Using Business/Organization Architecture Delivery, feedback and monitoring SA RO1 Supported by Application Architecture Target Baseline (to-be) Service Portfolio Service Architecture Supported by Information and Data Architecture Manipulated by AA RO1 Application Architecture Using Information and Data Architecture Manipulated by 87 28/8/07 14:01 Page 88 Service Transition – preparing for change neral aim is to decide the most appropriate releasevel for each service asset or component. An zation may, for example, decide that the release unit siness critical applications is the complete ation in order to ensure that testing is ehensive. The same organization may decide that a appropriate release unit for a website is at the page lowing factors should be taken into account when ng the appropriate level for release units: e ease and amount of change necessary to release d deploy a release unit e amount of resources and time needed to build, t, distribute and implement a release unit e complexity of interfaces between the proposed t and the rest of the services and IT infrastructure e storage available in the build, test, distribution and environments. SERVICE VALIDATION AND TESTING RELEASES ve build and test environment management is al to ensure that the builds and tests are executed peatable and manageable manner. Inadequate l of these environments means that unplanned es can compromise the testing activities and/or significant re-work. Dedicated build environments be established for assembling and building the onents for controlled test and deployment nments. ation of the test environments includes building, ng or enhancing the test environments ready to e the release. suppliers, are installed and configured together to create the solution as designed. Standardization facilitates the integration of the different building blocks to provide a working solution and service. Automating the installation of systems and application software onto servers and workstations reduces the dependencies on people and streamlines the procedures. Depending on the release and deployment plans, the installation may be performed in advance (for example, if equipment is being replaced) or it may have to occur in situ in the live environment. The physical infrastructure elements, together with the environment in which they will operate, need to be tested appropriately. Part of the testing may be to test the replication of the infrastructure solution from one environment to another. This gives a better guarantee that the rollout to the production environment will be successful. Test environments must be actively maintained and protected using service management best practices. For any significant change to a service, the question should be asked (as it is for the continued relevance of continuity and capacity plans): ‘If this change goes ahead, will there need to be a consequential change to the test data?’ During the build and test activities, operations and support teams need to be kept fully informed and involved as the solution is built to facilitate a structured transfer from the project to the operations team. Figure 6.5 provides an example of service testing through the Service Transition stage of the lifecycle. There is an invisible separation between Change, Configuration, Release and Deployment. Each works hand in hand to ensure minimal disruption and risk to the 28/8/07 14:01 Page 89 Service Transition – preparing for change | 6.5 Service testing and validation E1 Service Design Evaluation E3 Service Acceptance Evaluation prior to Closure E2 Service Evaluation prior to Deployment Evaluation E1 E3 E2 Service Design Release Package Test Facilities Validate Service Design Release Packaging and Build Service Release Test Deployment and Early Life Support *SORT Pilot Pilot Service Requirement Test SLM and reporting Service Management Test CSI performance measurement Operations Test User Test Deployment Tests Operations test User testing (sampling at user locations etc) SPI, Contract and Compliance Tests Verify service assets and components Verify environment against expected requirements (inc. configuration audit) Verification *Service Operational Readiness Test Validation Service Operation and CSI 89 28/8/07 14:01 Page 90 28/8/07 14:01 Page 91 28/8/07 14:01 Page 92