ITIL_Intermediate_ServiceTransition_Handbook_ATO 3

ITIL® Service Transition HandbookThe definitive media library (DML)The definitive media library (DML) is the secure library in which the definitive authorized versions of allmedia CIs are stored and protected. It stores master copies of versions that have passed qualityassurance checks. This library may in reality consist of one or more software libraries or file-storageareas, separate from development, test or live file store areas. It contains the master copies of allcontrolled software in an organization. The DML should include definitive copies of purchased software(along with license documents or information), as well as software developed on site. Master copies ofcontrolled documentation for a system are also stored in the DML in electronic form.Configuration baselineA configuration baseline is the configuration of a service, product or infrastructure that has beenformally reviewed and agreed, which thereafter serves as the basis for further activities and can bechanged only through formal change procedures. It captures the structure, contents and details of aconfiguration and represents a set of configuration items that are related to each other.Establishing a baseline provides the ability to:  Mark a milestone in the development of a service, e.g. service design baseline  Build a service component from a defined set of inputs  Change or rebuild a specific version at a later date  Assemble all relevant components in readiness for a change or release  Provide the basis for a configuration audit and back-out, e.g. after a change.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 151 of 360

ITIL® Service Transition HandbookSnapshotA snapshot is the current state of a configuration item or an environment, e.g. from a discovery tool.This snapshot is recorded in the CMS and remains as a fixed historical record. Sometimes this is referredto as a footprint. A snapshot is not necessarily formally reviewed and agreed on – it is just adocumentation of a state, which may contain faults and unauthorized CIs. One example is where asnapshot is established after an installation, perhaps using a discovery tool, and later compared to theoriginal configuration baseline.The snapshot:  Enables problem management to analyze evidence about a situation pertaining at the time incidents actually occurred  Facilitates system restore  Supports security scanning software.Copyright © AXELOS Limited 2011. Reproduced under licence from AXELOS. All rightsreserved.The configuration identification process activities should:  Define and document criteria for selecting configuration items and the components that compose them.  Select the configuration items and their components according to documented criteria.  Assign unique identifiers to configuration items.  Specify the relevant attributes of each configuration item.  Specify when each configuration item is placed under control of service asset and configuration management.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 152 of 360

ITIL® Service Transition Handbook  Identify the owner responsible for each configuration item.SACM – Management and PlanningConfiguration structures and the selection of configuration itemsThe configuration model should describe the relationship and position of configuration items (CIs) ineach structure. There should be service configuration structures that identify all the components in aparticular service (e.g. the retail service). An important part of SACM is deciding the level at whichcontrol is to be exercised, with top- level CIs broken down into components, which are themselves CIs,and so on.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 153 of 360

ITIL® Service Transition HandbookSACM - IdentificationNaming configuration itemsNaming conventions should be established and applied to the identification of CIs, configurationdocuments and changes, as well as to baselines, builds, releases and assemblies.Labeling configuration itemsAll physical device CIs should be labeled with the configuration identifier so that they can be easilyidentified. Plans should be made to label CIs and to maintain the accuracy of their labels.Attributes for configuration itemsAttributes describe the characteristics of a CI that are valuable to record and which will support SACMand the ITSM processes it supports.Defining configuration documentationThe characteristics of a CI are often contained in documents. For example, the service definition,requirements specification and service level agreement for a service describe the characteristics of aservice CI. Many organizations specify mandatory and optional documents that describe a CI and usedocument templates to ensure that consistent information is entered. RACI (Responsible, Accountable,Consulted, Informed) chart, which illustrates the types of documentation of service assets orconfiguration items that are the responsibility of different service lifecycle stages and typicaldocumentation.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 154 of 360

ITIL® Service Transition HandbookRelationshipsRelationships describe how the configuration items work together to deliver the services. Theserelationships are held in the CMS – this is the major difference between what is recorded in a CMS andwhat is held in an asset register.Types of configuration itemComponents should be classified into CI types because this helps to identify and document what is inuse, the status of the items and where they are located. Typical CI types include service, hardware,software, documentation and staff.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 155 of 360

ITIL® Service Transition HandbookSACM – Configuration ControlConfiguration control ensures that there are adequate control mechanisms over CIs while maintaining arecord of changes to CIs, versions, location and custodianship/ownership. Without control of thephysical or electronic assets and components, the configuration data and information there will be amismatch with the physical world.No CI should be added, modified, replaced or removed without an appropriate controllingdocumentation or procedure being followed. Policies and procedures should be in place to cover thefollowing features:  License control, to ensure that the correct number of people are using licences, that there is no unlicensed use and that unused licences are kept to a minimum  Change management  Version control of service asset, software and hardware versions, images/builds and releases  Access control, e.g. to facilities, storage areas and CMS  Build control, including the use of build specification from the CMS to perform a build  Promotion, migration of electronic data and information  Taking a configuration baseline of assets or CIs before performing a release (into system, acceptance test and live) in a manner that can be used for subsequent checking against actual deployment  Deployment control including distributioniCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 156 of 360

ITIL® Service Transition Handbook  Installation  Maintaining the integrity of the DML.There are many procedures that can change a CI; these should be reviewed and aligned with the CItypes where possible as standardization prevents errors. During the planning stage it is important todesign an effective configuration control model and implement this in a way that allows staff to easilylocate and use the associated training products and procedures.If many SACM tools are used, there is often a control plan for each tool that is aligned with the overallconfiguration control model. If configuration data is updated manually, then it is important that theupdate uses a documented procedure, supported by checklists where appropriate.Each CI will have one or more discrete states through which it can progress. The significance of eachstate should be defined in terms of what use can be made of the CI in that state. There will typically be arange of states relevant to the individual CIs.A simple example of a lifecycle is:  Development or draft Denoting that the CI is under development and that no particular reliance should be placed on itiCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 157 of 360

ITIL® Service Transition Handbook  Approved Meaning that the CI may be used as a basis for further work  Withdrawn Meaning that the CI has been withdrawn from use, either because it is no longer fit for purpose or because there is no further use for it.The method by which CIs move from one state to another should be defined: e.g. an application releasemay be registered, accepted, installed or withdrawn. This will include defining the type of review andauthorization required and the authority level necessary to give that authorization. The process that canpromote the CI from accepted to installed is ‘release and deployment management’. At each lifecyclestatus change the CMS should be updated with the reason, date-time stamp and person who made thestatus change. The planning activities should also establish any attributes that should be updated ateach state.Configuration status accounting and reporting is concerned with ensuring that all configuration data anddocumentation is recorded as each CI progresses through its lifecycle. It provides the status of theconfiguration of a service and its environment as the configuration evolves through the service lifecycle.Status reporting provides the current and historical data concerned with each CI, which in turn enablestracking of changes to CIs and their records (i.e. tracking the status as a CI changes from one state toanother, e.g. ‘development’, ‘test’, ‘live’ or ‘withdrawn’).iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 158 of 360

ITIL® Service Transition HandbookSACM – Verification and AuditThe activities include a series of reviews or audits to:  Ensure that there is conformity between  the documented baselines (e.g. agreements, interface control documents) and the actual business environment to which they refer  Verify the physical existence of CIs in the organization or in the DML and spares stores, the functional and operational characteristics of CIs and to check that the records in the CMS match the physical infrastructure  Check that release and configuration documentation is present before making a release.Before a major release or change, an audit of a specific configuration may be required to ensure that thecustomer’s environment matches the CMS. Before acceptance into the live environment, new releases,builds, equipment and standards should be verified against the contracted or specified requirements.There should be a test certificate (or some other relevant document – e.g. change record), which provesthat the functional requirements of a new or updated CI have been verified.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 159 of 360

ITIL® Service Transition HandbookSACM – Process RelationshipBy its very nature as the single virtual repository of configuration data and information for IT servicemanagement SACM supports and interfaces with every other service management process and activityto some degree. Some of the more noteworthy interfaces are:  Change management identifying the impact of proposed changes  Financial management for IT services capturing key financial information such as  cost, depreciation methods, owner and user (for budgeting and cost allocation), maintenance and repair costs  ITSCM awareness of the assets on which the business services depend, control of key spares and software  Incident/problem/error providing and maintaining key diagnostic information; maintenance and provision of data to the service desk  Availability management in detection of points of failure.The relationship with change and release and deployment management is synergistic, with theseprocesses benefiting greatly from a single coordinated planning approach. Configuration control issynonymous with change control understanding and capturing updates to the infrastructure andservices.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 160 of 360

ITIL® Service Transition HandbookSACM also has close relationships with some business processes, especially fixed asset management andprocurement.Triggers, inputs, outputs and interfacesTriggers - Updates to service asset and configuration management could be triggered by:  Updates from change management  Updates from release and deployment management  Purchase orders  Acquisitions  Service requests.Inputs - Inputs to service asset and configuration management include:  Designs, plans and configurations from service design packages  Requests for change and work orders from change management  Actual configuration information collected by tools and audits  Information in the organization’s fixed asset register.Outputs - Outputs from service asset and configuration management include:  New and updated configuration records  Updated asset information for use in updating the fixed asset register  Information about attributes and relationships of configuration items, for use by all other service management processes. This information should be presented in appropriate views for each audience  Configuration snapshots and baselines  Status reports and other consolidated configuration information  Audit reports.Interfaces - By its very nature as the single virtual repository of configuration data and information for ITservice management SACM supports and interfaces with every other service management process andactivity to some degree.Some of the more noteworthy interfaces are:  Change management – identifying the impact of proposed changes  Financial management for IT services capturing key financial information  ITSCM – awareness of the assets on which the business services depend, control of key spares and software  Incident/problem/error – providing and maintaining key diagnostic information; maintenance and provision of data to the service desk  Availability management in detection of points of failure.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 161 of 360

ITIL® Service Transition HandbookSACM – Key Performance IndicatorsAs with all processes the performance of SACM should be monitored, reported on and action taken toimprove it.SACM is the central support process facilitating the exchange of information with other processes, andas such it has few customer-facing measures. However, as an underlying engine to other processes inthe lifecycle, SACM must be measured for its contribution to these parts of the lifecycle and the overallKPIs that directly affect the customer.The following list includes some sample CSFs for service asset and configuration management. Eachorganization should identify appropriate CSFs based on its objectives for the process. Each sample CSF isfollowed by a small number of typical KPIs that support the CSF. These KPIs should not be adoptedwithout careful consideration.Each organization should develop KPIs that are appropriate for its level of maturity, its CSFs and itsparticular circumstances. Achievement against KPIs should be monitored and used to identifyopportunities for improvement, which should be logged in the CSI register for evaluation and possibleimplementation.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 162 of 360

ITIL® Service Transition Handbook Critical Success Factors (CSF) Key Performance Indicators (KPI) KPI Improved accuracy in budgets and charges for the assetsCSF Accounting for, managing and protecting utilized by each customer or business unit the integrity of CIs throughout the service KPI Increase in re-use and redistribution of under-utilized lifecycle resources and assets KPI Reduction in the use of unauthorized hardware andCSF Supporting efficient and effective service software, non-standard and variant builds that increasemanagement processes by providing accurate complexity, support costs and risk to the business services KPI Reduced number of exceptions reported during configuration information at the right time configuration audits KPI Percentage improvement in maintenance schedulingCSF Establishing and maintaining an accurate over the life of an asset (not too much, not too late) and complete configuration management KPI Improved speed for incident management to identify system (CMS) faulty CIs and restore service KPI Reduction in the average time and cost of diagnosing and resolving incidents and problems (by type) KPI Improved ratio of used licences against paid-for licences KPI Improvement in time to identify poor- performing and poor-quality assets KPI Reduction in risks due to early identification of unauthorized change KPI Reduced percentage of changes not completed successfully or causing errors because of poor impact assessment, incorrect data in the CMS, or poor version control KPI Reduction in business impact of outages and incidents caused by poor service asset and configuration management KPI Increased quality and accuracy of configuration information KPI Improved audit compliance KPI Shorter audits as quality configuration information is easily accessible KPI Fewer errors caused by people working with out-of-date information.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 163 of 360

ITIL® Service Transition HandbookSACM – Critical Success FactorsiCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 164 of 360

ITIL® Service Transition HandbookSACM – ChallengesChallenges to SACM include:  Persuading technical support staff to adopt a checking in/out policy this can be perceived as being a hindrance to a fast and responsive support service; if the positives of such a system are not conveyed adequately, staff may be inclined to try and circumvent it. Even then, resistance can still occur placing this as an objective in annual appraisal is one way to help enforce the policy.  Attracting and justifying funding for SACM, since it is typically out of sight to the customer units empowered with funding control; in practice it is typically funded as an ‘invisible’ element of change management and other ITSM processes with more business visibility.  An attitude of ‘just collecting data because it is possible to do’; this leads SACM into a data overload, which is impossible, or at least disproportionately expensive, to maintain.  Lack of commitment and support from management who do not understand the key role it must play in supporting other processes.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 165 of 360

ITIL® Service Transition HandbookSACM – RisksRisks to successful SACM include:  The temptation to consider it technically focused (rather than service and business- focused), since technical competence is essential to its successful delivery.  Degradation of the accuracy of configuration information over time, which can cause errors and be difficult and costly to correct.  Setting the scope too wide, causing excessive cost and effort for insufficient benefit.  Setting the scope too narrow, so that the process has too little benefit.  The CMS becomes out of date due to the movement of hardware assets by non- authorized staff; regular physical audits should be conducted with discrepancies highlighted and investigated; managers should be informed of inconsistencies in their areas. The frequency of these audits could range from 10% of assets audited very two months to a full audit four times a year, depending on the size of the organization, the number and value of the assets, and the historical rate of audit issues.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 166 of 360

ITIL® Service Transition HandbookiCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 167 of 360

ITIL® Service Transition HandbookRelease Deploy Management - ContentsiCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 168 of 360

ITIL® Service Transition HandbookRelease Deploy Management – Purpose & GoalThe purpose of the release and deployment management process is to plan, schedule and control thebuild, test and deployment of releases, and to deliver new functionality required by the business whileprotecting the integrity of existing services.The objectives of release and deployment management are to:  Define and agree release and deployment management plans with customers and stakeholders  Create and test release packages that consist of related configuration items that are compatible with each other  Ensure that the integrity of a release package and its constituent components is maintained throughout the transition activities, and that all release packages are stored in a DML and recorded accurately in the CMS  Deploy release packages from the DML to the live environment following an agreed plan and schedule  Ensure that all release packages can be tracked, installed, tested, verified and/or uninstalled or backed out if appropriate  Ensure that organization and stakeholder change is managed during release and deployment activities (see Chapter 5)  Ensure that a new or changed service and its enabling systems, technology and organization are capable of delivering the agreed utility and warrantyiCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 169 of 360

ITIL® Service Transition Handbook Record and manage deviations, risks and issues related to the new or changed service and take necessary corrective action Ensure that there is knowledge transfer to enable the customers and users to optimize their use of the service to support their business activities Ensure that skills and knowledge are transferred to service operation functions to enable them to effectively and efficiently deliver, support and maintain the service according to required warranties and service levels.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 170 of 360

ITIL® Service Transition HandbookRelease Deploy Management – ScopeThe scope of release and deployment management includes the processes, systems and functions topackage, build, and test and deploy a release into live use, establish the service specified in the servicedesign package, and formally hand the service over to the service operation functions. The scopeincludes all configuration items required to implement a release, for example:  Physical assets such as a server or network  Virtual assets such as a virtual server or virtual storage  Applications and software  Training for users and IT staff  Services, including all related contracts and agreements.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 171 of 360

ITIL® Service Transition HandbookRelease Deploy Management – Value to BusinessEffective release and deployment management enables the service provider to add value to thebusiness by:  Delivering change, faster and at optimum cost and minimized risk  Assuring that customers and users can use the new or changed service in a way that supports the business goals  Improving consistency in implementation approach across the business change, service teams, suppliers and customers  Contributing to meeting auditable requirements for traceability through service transition.Well-planned and implemented release and deployment management will make a significant differenceto an organization’s service costs.A poorly designed release or deployment will, at best, force IT personnel to spend significant amounts oftime troubleshooting problems and managing complexity. At worst, it can cripple the environmentand degrade live services.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 172 of 360

ITIL® Service Transition HandbookRelease Deploy Management – Release UnitCopyright © AXELOS Limited 2011. Reproduced under licence from AXELOS. All rightsreserved.A ‘release unit’ describes the portion of a service or IT infrastructure that is normally released as a singleentity according to the organization’s release policy. The unit may vary, depending on the type(s) oritem(s) of service asset or service component such as software and hardware. An IT service made up ofsystems and service assets, which are in turn made up of service components. The actual components tobe released on a specific occasion may include one or more release units, or exceptionally may includeonly part of a release unit. These components are grouped together into a release package for thatspecific release.The general aim is to decide the most appropriate release-unit level for each service asset orcomponent. An organization may, for example, decide that the release unit for business-criticalapplications is the complete application in order to ensure that testing is comprehensive. The sameorganization may decide that a more appropriate release unit for a website is at the page level.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 173 of 360

ITIL® Service Transition HandbookRelease Deploy Management – Release PackageA ‘release package’ is a set of configuration items that will be built, tested and deployed together as asingle release. Each release will take the documented release units into account when designing thecontents of the release package. It may sometimes be necessary to create a release package thatcontains only part of one or more release units, but this would only happen in exceptionalcircumstances.The following factors should be taken into account when deciding the appropriate level for release units:  The ease and amount of change necessary to release a release unit  The amount of resources and time needed to build, test, distribute and implement a release unit  The complexity of interfaces between the proposed unit and the rest of the services and IT infrastructure  The storage available in the build, test, distribution and live environments.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 174 of 360

ITIL® Service Transition HandbookRelease Deploy Management – Release DesignService design will define the approach to transitioning from the current service to the new or changedservice or service offering. The SDP defines the service and solution design components to betransitioned to deliver the required service.Common options for release and deployment that are considered in service design are discussed below.The selected option will have a significant impact on the release and deployment managementresources as well as the business outcomes. It is important to understand the patterns of businessactivity (PBA) and user profiles when planning and designing the releases.‘Big Bang’ versus ‘Phased Deployment’  Big Bang option The new or changed service is deployed to all user areas in one operation. This will often be used when introducing an application change and consistency of service across the organization is considered important. This option is sometimes called ‘parallel deployment’  Phased approach The service is deployed to a part of the user base initially, and then this operation is repeated for subsequent parts of the user base via a scheduled deployment plan. This will be the case in many scenarios such as in retail organizations for new services being introduced into the store’s environment in manageable phases.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 175 of 360

ITIL® Service Transition HandbookPush and Pull approaches  A push approach is used where the service component is deployed from the centre and pushed out to the target locations. In terms of service deployment, delivering updated service components to all users – either in big bang or phased form – constitutes ‘push’, since the new or changed service is delivered into the users’ environment at a time not of their choosing.  A pull approach is used for software releases where the software is made available in a central location, but users are free to pull the software down to their own location at a time of their choosing or when a user workstation restarts. The use of ‘pull’ updating a release over the internet has made this concept significantly more pervasive. A good example is virus signature updates, which are typically pulled down to update PCs and servers when it best suits the customer; however, at times of extreme virus risk this may be overridden by a release that is pushed to all known users.Automation versus ManualAutomation versus manual methods Whether by automation or other means, the mechanisms to deploythe correctly configured service components should be established in the release design stage andtested in the build and test stages.Automation will help to ensure repeatability and consistency. The time required to provide a well-designed and efficient automated mechanism may not always be available or viable. If a manualmechanism is used, it is important to monitor and measure the impact of many repeated manualactivities, as they are likely to be inefficient and error-prone. Too many manual activities will slow downthe release team and create resource or capacity issues that affect the service levels.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 176 of 360

ITIL® Service Transition HandbookRelease Deploy Management – PlanA service may be deployed into the live environment in a number of ways. Service design will select themost suitable release and deployment models that include the approach, mechanisms, processes,procedures and resources required to build, test and deploy the release on time and within budget.The release methods used during the early build and test stages may differ significantly from liveoperations, so plan ahead to ensure that appropriate release methods are adopted at the right time.Common situations where release and deployment models might be useful include:  Release of a new version of an existing desktop application  Deployment of a new virtual server with a standard configuration  Upgrade of the server operating system software to a new version  Implementation of a security patch for network appliances.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 177 of 360

ITIL® Service Transition HandbookRelease Deploy Management – Build & Test Planning, Planning PilotsBuild and test planning establishes the approach to building, testing and maintaining the controlledenvironments prior to live use. Build and test planning must work with service validation and testing toensure that test plans can be carried out.The activities include:  Developing build plans from the SDP, design specifications and environment configuration requirements  Establishing the logistics, lead times and build times to set up the environments  Defining a configuration baseline for the build environment, to ensure that each build is carried out in a known environment  Testing the build and related procedures  Scheduling the build and test activities  Assigning resources, roles and responsibilities to perform key activities, for example: o Security procedures and checks o Technical support o Preparing build and test environments o Managing test databases and test data o Software asset and licence management o Service asset and configuration management configuration audit, build and baseline management  Defining and agreeing the build exit and entry criteria.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 178 of 360

ITIL® Service Transition HandbookPilots are useful for testing the service with a small part of the user base before rolling it out to thewhole service community. It is important to determine the appropriate scope of a pilot (how much ofthe service is to be included in the pilot, size of department or user base). This is a key step inestablishing the pilot effort. If the scope is too small, insufficient functionality and implementationvariations will be tested, and the likelihood of significant errors not being discovered until fulldeployment is higher. If the scope is too large, it will not deliver sufficient speed and flexibility toprovide the expected benefits but will effectively be a first deployment.A pilot can be used to establish the viability of most, if not all, aspects of the service. But this will onlyhappen if all stakeholders are actively involved in the pilot and use the service as if it were part of a fulldeployment.The pilot should include steps to collect feedback on the effectiveness of the release and of thedeployment plan. This can include:  Surveying views and satisfaction from: o End users o Customers o Suppliers o Service desk and other support staff  Service operation functions  Data and knowledge management. statistics on use and effectiveness  Analyzing statistics from service desk calls, suppliers, capacity and availability.Copyright © AXELOS Limited 2011. Reproduced under licence from AXELOS.All rights reserved.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 179 of 360

ITIL® Service Transition HandbookRelease Deploy Management – Questions during Deployment PlanningThere are many planning considerations that need to be considered. Planners should be able to answer the questions included in table below Deployment Question ExamplesWhat needs to be deployed? Package? What are the Do you have a good understanding of the servicebusiness drivers for the deployment? Is it required to and release that is being deployed? What are themeet a critical business need? components that make up the releaseWho are the users? Which users are affected by the deployment? What language do they use? Do they need anyAre there location dependencies? special training? Are there any holidays, shut-downs or otherWhere are the users? interruptions to normal business at this location? What level of detail needs to be recorded, e.g. building, floor, room? Are all the users and systems local to the deployment, or are some remote, and how will this affect the logistics?iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 180 of 360

ITIL® Service Transition HandbookWho else needs to be prepared well in advance? Do the service desk and support staff need training? Are there any access issues to be solvedWhen does the deployment need to be completed? – security or physical? Does the deployment need to be completed by aWhy is the deployment happening? understand what certain date and time or can it be completed byis coming? following a flexible schedule? Is the deployment needed to fix a problem or is it required for some new functionality that has been requested, and do the usersWhat are the critical success factors and exit criteria? How will you know that the deployment has been successful? Who will authorize the deployment? How will you know when the deployment is finished? What are the current services, processes andWhat is the current capability of the service provider? service management capability capacity, financial aspects, current systems and infrastructure?iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 181 of 360

ITIL® Service Transition HandbookRelease Deploy Management – Service RehearsalsA service rehearsal (sometimes referred to as ‘model office’) is a simulation of as much of the service aspossible in an extensive and widely participatory practice session. It is the ultimate stage of internaltesting – the last stage before any public live running. This is like a ‘dress rehearsal’ of a play, setting outall the elements – costume, lighting etc. – in a last private run-through of the performance. It can deliversignificant benefits by identifying errors and unworkable procedures before they impact the business inlive operation. However, service rehearsals are complex, time- consuming and relatively expensive toprepare, deliver and document. A careful and deliberate balance is therefore required between theanticipated costs and the issues that they could prevent.A service rehearsal takes place just before deployment of the service. If it is held too early there is asignificant chance that the environment, technology, people and legislation into which the service isbeing released will change and invalidate the results; if it occurs too close to the declared release date,any issues found will not be addressed before the service goes live.The objectives of the service rehearsal include:  Confirmation that all stakeholders have been identified and are committed to operating or using the service, if not this will be evidenced through lack of players for roles within the service rehearsaliCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 182 of 360

ITIL® Service Transition Handbook Verification that all stakeholders have processes and procedures in place and are ready to receive process and resolve incidents, problems and changes relating to the new or changed service Testing the effectiveness of ‘mistake proofing’ included within the service procedures. (Mistake proofing, often referred to by the Japanese term ‘Poka Yoke’, is about introducing advance warnings of user mistakes or bad practice and where possible introducing steps in the procedures to prevent these mistakes . for example electrical switch interlocks, and check-sum digits in data entry.) While testing can check how a service reacts for predicted user error, the service rehearsal will encourage unforeseen behavior and establish how that behavior affects the service’s ability to deliver the required benefits.When the deployment activities are complete, it is important to verify that users, service operationfunctions, other staff and stakeholders are capable of using or operating the service. The tests shouldspecifically verify that:  The service, service assets and service capability/ resources are in place, e.g. by performing an audit such as a configuration audit of the deployed baseline against the as-planned baseline.  Updates to documentation and information are completed, e.g. service catalogue, contracts, agreements, and contact details in the supplier and contract management information system (SCMIS).  Communications, orientation and learning materials are ready to distribute to stakeholders, service operation functions and users.  All roles are assigned to individuals/organizations.  People and other resources are prepared to operate and use the new or changed service or service capability in normal, emergency and disaster situations.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 183 of 360

ITIL® Service Transition Handbook People have access to the information necessary to use, operate or support the service. Measurement and reporting systems are established to assess performance of the service and underlying resources.Copyright © AXELOS Limited 2011. Reproduced under licence from AXELOS. All rightsreserved.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 184 of 360

ITIL® Service Transition HandbookRelease Deploy Management – ELSCopyright © AXELOS Limited 2011. Reproduced under licence from AXELOS. All rightsreserved.Early life support (ELS) provides the opportunity to transition the new or changed service to serviceoperation in a controlled manner and establish the new service capability and resources. Formalhandover of the new or changed service to the service operation functions happens in two stages. At thebeginning of early life support there should be a formal notification that the service is now in live use. Atthe end of early life support there should be a formal notification that all SLAs are now being enforcedand the service is fully operational.In service design, the stakeholders will have agreed the entry and exit criteria from early life support,but it may be necessary to renegotiate performance targets and exit criteria in this stage. This can helppeople to understand the deployment verification process and set customer and stakeholderexpectations about the handover of the service to service operation.ELS provides appropriate resources to resolve operational and support issues quickly, centrally andlocally, to ensure that the users can use the service to support their business activities withoutunwarranted disruption. The deployment teams should analyse where users and support resourcesmight experience problems, perhaps based on previous experience; for example it might be helpful toclarify the following:iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 185 of 360

ITIL® Service Transition Handbook Role assignments, roles and responsibilities Financial and funding arrangements Procurement and request fulfilment Security policies and procedures Raising incidents and change requests Escalation procedures Complaints procedure Use of diagnostics tools and aids Software licensing rules.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 186 of 360

ITIL® Service Transition HandbookRelease Deploy Management – Review & Close a DeploymentWhen reviewing a deployment the following activities should be included:  Capture experiences and feedback on customer, user and service provider satisfaction with the deployment, e.g. through feedback surveys.  Highlight quality criteria that were not met.  Check that any actions, necessary fixes and changes are complete.  Review open changes and ensure that funding and responsibility for open changes are agreed before handover.  Review performance targets and achievements, including resource use and capacity such as user accesses, transactions and data volumes.  Make sure there are no capability, resource, capacity or performance issues at the end of the deployment.  Check that any problems, known errors and workarounds are documented and accepted by the customers/business and/or suppliers.  Review the risk register and identify items that impact service operation and support. Address risks or agree action such as moving the risks to the service transition risk register.  Check that redundant assets have been removed.  Check that the service is ready for transition from early life support into service operation.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 187 of 360

ITIL® Service Transition HandbookEach deployment should consider whether any relevant issues have been detected that should bepassed through to CSI, such as:  Feedback on the deployment model and plan  Errors in procedures detected  ‘Near misses’ where things could have gone wrong in foreseeable circumstances or where intervention was required  Incorrect data or information in relevant records  Incident and problems caused by deployment  Difficulties with updating records.Triggers - Release and deployment management starts with receipt of an authorized change to plan,build and test a production-ready release package. Deployment starts with receipt of an authorizedchange to deploy a release package to a target deployment group or environment, e.g. business unit,customer group and/or service unit.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 188 of 360

ITIL® Service Transition HandbookRelease Deploy Management – InputsThe inputs to release and deployment management are:  Authorized change  Service design package (SDP) including: o A service charter that defines the requirements from the business/customer for the service, including a description of the expected utility and warranty, as well as outline budgets and timescales o Service models that describe the structure and dynamics of how the service is operated and managed o Service acceptance criteria  IT service continuity plan and related business continuity plan  Service management and operations plans and standards  Technology and procurement standards and catalogues  Acquired service assets and components and their documentation  Build models and plans  Environment requirements and specifications for build, test, release, training, disaster recovery, pilot and deployment  Release policy and release design from service design  Release and deployment models including template plans  Exit and entry criteria for each stage of release and deployment management.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 189 of 360

ITIL® Service Transition HandbookRelease Deploy Management – OutputsThe outputs from release and deployment management are:  New, changed or retired services  Release and deployment plan  Updates to change management for the release and deployment activities  Service notification  Notification to service catalogue management to update the service catalogue with the relevant information about the new or changed service  New tested service capability and environment including SLA, other agreements and  contracts, changed organization, competent and motivated people, established business and service management processes, installed applications, converted databases, technology infrastructure, products and facilities  New or changed service management documentation  SLA, underpinning OLAs and contracts  New or changed service reports  Tested continuity plans  Complete and accurate configuration item list with an audit trail for the CIs in the release package and also the new or changed service and infrastructure configurations  Updated service capacity plan aligned to the relevant business plans  Baselined release package checked in to DML and ready for future deploymentsiCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 190 of 360

ITIL® Service Transition Handbook  Service transition report.Triggers: Release and deployment management starts with receipt of an authorized change to plan,build and test a production-ready release package. Deployment starts with receipt of an authorizedchange to deploy a release package to a target deployment group or environment, e.g. business unit,customer group and/or service unit.Interfaces  Service design coordination - The service design coordination process creates the service design package that defines the new service, including all aspects of how it should be created.  Release and deployment management also has a significant role to play in production of the SDP.  Transition planning and support - Each transition will include a requirement for release and deployment.  Change management - Release and deployment management must be tightly integrated with change management.  Service asset and configuration management - Release and deployment management depends on data and information in the CMS, and provides many updates to the CMS.  Service validation and testing - Release and deployment management must coordinate with service validation and testing, to ensure that testing is carried out when necessary, and that builds are available when required by service validation and testing.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 191 of 360

ITIL® Service Transition HandbookRelease Deploy Management – Critical Success FactorsiCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 192 of 360

ITIL® Service Transition HandbookRelease Deploy Management – Key Performance IndicatorsThe following list includes some sample CSFs for release and deployment management. Eachorganization should identify appropriate CSFs based on its objectives for the process. Each sample CSF isfollowed by a small number of typical KPIs that support the CSF. These KPIs should not be adoptedwithout careful consideration. Each organization should develop KPIs that are appropriate for its level ofmaturity, its CSFs and its particular circumstances. Achievement against KPIs should be monitored andused to identify opportunities for improvement, which should be logged in the CSI register forevaluation and possible implementation.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 193 of 360

ITIL® Service Transition Handbook Critical Success Factors (CSF) Key Performance Indicators (KPI) CSF Defining and agreeing release plans with KPI Increased number and percentage of releases that make use of a common framework of standards, re- customers and stakeholders usable processes and supporting documentation KPI Increased number and percentage of releases that CSF Ensuring integrity of a release package meet customer expectations for cost, time and quality and its constituent components throughout the KPI Reduced number of CMS and DML audit failures related to releases transition activities KPI Reduced number of deployments from sources other than the DML CSF Ensuring that the new or changed service is KPI Reduced number of incidents due to incorrect capable of delivering the agreed utility and components being deployed warranty KPI Reduced variance from service performance required by customersCSF Ensuring that there is appropriate knowledge KPI Number of incidents against the service transfer (low and reducing) KPI Increased customer and user satisfaction with the services delivered KPI Decreased customer dissatisfaction service issues resulting from poorly tested or untested services increase the negative perception on the service provider organization as a whole KPI Reduced resources and costs to diagnose and fix incidents and problems in deployment and live use KPI Reduced number of incidents categorized as ‘user knowledge’ KPI Increased percentage of incidents solved by level 1 and level 2 support KPI Increased score in surveys of customer, user and service operation function satisfaction with release and deployment management.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 194 of 360

ITIL® Service Transition HandbookRelease Deploy Management – ChallengesChallenges for release and deployment management include:  Developing standard performance measures and measurement methods across projects and suppliers  Dealing with projects and suppliers where estimated delivery dates are inaccurate and there are delays in scheduling service transition activities  Understanding the different stakeholder perspectives that underpin effective risk management for the change impact assessment and test activities  Building a thorough understanding of risks that have impacted or may impact successful service transition of services and releases  Encouraging a risk management culture where people share information and take a pragmatic and measured approach to risk.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 195 of 360

ITIL® Service Transition HandbookRelease Deploy Management – Purpose & GoalRisks to successful release and deployment management include:  Poorly defined scope and understanding of dependencies in earlier lifecycle stages leading to scope creep during release and deployment management  Using staff who are not dedicated to release and deployment management activities, especially if the effort takes a significant amount of their time  Failing to use the release and deployment management process to manage service retirement  Finances: o Shortage of finances o Delays move deployment into a different financial year o Lack of clarity on funding for changes/fixes during transition  Controls: o Inadequate corporate policies, e.g. security, software licensing o Lack of definition of the required controls leads to poorly evaluated and unauthorized changes, adversely affecting release and deployment plans o Difficulty tracking and managing software licences, e.g. due to complexity o Unexpected changes in regulatory controls or licensing requirementsiCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 196 of 360

ITIL® Service Transition Handbook Management of organizational and stakeholder change: o Unclear expectations/objectives from customers, users, suppliers and other stakeholders o Cultural differences/misunderstandings o Human factors o Relationships with suppliers/partners o Poor communication o Organizational change affecting employee morale o Problems arising from infringement of personal data protection criteria o Personality clashes o Key personnel who have inadequate authority to fulfil their roles o Poor staff recruitment and selection procedures o Lack of clarity over roles and responsibilities o Vested interests creating conflict and compromising quality o Individual or group interests given unwarranted priority Poor commitment and decision-making Failure to obtain appropriate authorization at the right time Indecision or late decision-making Lack of operational support Inadequate or inaccurate information Health and safety compromised Time allowed for release and deployment management . will it make or break the project? Suppliers/sourcing/partnering relationships during transition: o Failure of suppliers to meet contractual obligations; this could be in terms of quality, quantity, timescales or their own exposure to risk o Delays in contract negotiation o Organizational change having a major impact on employee morale, employee and supplier performance o Data protection impacting on data sharing o Shrinking resource pool from disaffected employees o Senior management commitment missing in one or other of the organizations o Immature or non-existent supplier management process o Changes in work practices and procedures adversely affecting one or other of the organizations Inadequate ‘back-out’ or ‘econtingency’ plan if sourcing/partnering fails Application/technical infrastructure risks: o Inadequate design o Professional negligence o Human error/incompetence o Infrastructure failure o Differences/dependencies in infrastructure/ o applications o Increased dismantling/decommissioning costs o Safety being compromisediCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 197 of 360

ITIL® Service Transition Handbooko Performance failure (people or equipment)o Breaches in physical security/information securityo Unforeseen barriers or constraints due to infrastructure.iCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 198 of 360

ITIL® Service Transition HandbookiCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 199 of 360

ITIL® Service Transition HandbookService Validation & Testing - ContentsiCert Global. All rights Reserved | \"ITIL® is [registered ] trademark of Axelos Limited. The Swirl logoTM is a Trade Mark of the Axelos Limited,used under the permission of Axelos Limited. All rights reserved. Page 200 of 360