SlideShare a Scribd company logo

5 service transition

Download as PPT, PDF
S
sagaroceanic11

This document provides an overview of service transition concepts and processes including: - The V model for service transition - Configuration items, configuration management systems, knowledge management, and service knowledge management systems - Change management, service asset and configuration management, and release and deployment management processes - Key concepts for each process such as configuration baselines, configuration items, and definitive media libraries are defined to support effective service transition.

BusinessTechnology
1 of 75
Downloaded 401 times
1
2
3
Most read
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
© 2008 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Service Transition
2 Service Transition • Concepts − V Model − Configuration Item − Configuration Management System − Knowledge Management − Data Information Knowledge Wisdom − Service Knowledge Management System − Definitive Media Library • Processes − Change Management − Service Asset and Configuration Management − Release and Deployment Management
3 Service Transition V Model
4 Configuration Item (CI) • Anything that needs to be managed in order to deliver an IT Service • CI information is recorded in the Configuration Management System • CI information is maintained throughout its Lifecycle by Configuration Management • ALL CIs are controlled by Change Management • CIs typically include − IT Services, hardware, software, buildings, people, and formal documentation such as Process documentation and SLAs
5 Configuration Management System (CMS) • Information about all Configuration Items − CI may be entire service, or any component − Stored in 1 or more databases (CMDBs) • CMS stores attributes − Any information about the CI that might be needed • CMS stores relationships − Between CIs − With incident, problem, change records etc. • CMS has multiple layers − Data sources and tools, information integration, knowledge processing, presentation
6 Configuration Management System
© 2008 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Transition Planning and Support
8 Purpose/Goal/Objective The purpose of the Transition Planning and Support activities is to: − Plan appropriate capacity and resources to package a release, build, release, test, deploy and establish the new or changed service into production − Provide support for the Service Transition teams and people − Plan the changes required in a manner that ensures the integrity of all identified customer assets, service assets and configurations can be maintained as they evolve through Service Transition − Ensure that Service Transition issues, risks and deviations are reported to the appropriate stakeholders and decision makers − Coordinate activities across projects, suppliers and service teams where required. 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. The objective of Transition Planning and Support is to: − Plan and coordinate the resources to establish successfully a new or changed service into production within the predicted cost, quality and time estimates − Ensure that all parties adopt the common framework of standard re-usable processes and supporting systems in order to improve the effectiveness and efficiency of the integrated planning and coordination activities − Provide clear and comprehensive plans that enable the customer and business change projects to align their activities with the Service Transition plans.
9 Scope • The scope of the Service Transition Planning and Support activities includes: − Incorporating design and operation requirements into the transition plans − Managing and operating Transition Planning and Support activities − Maintaining and integrating Service Transition plans across the customer, service and contract portfolios − Managing Service Transition progress, changes, issues, risks and deviations − Quality review of all Service Transition, release and deployment plans − Managing and operating the transition processes, supporting systems and tools − Communications with customers, users and stakeholders − Monitoring and improving Service Transition performance
10 Value to Business • Effective Transition Planning and Support can significantly improve a service provider’s ability to handle high volumes of change and releases across its customer base. • An integrated approach to planning improves the alignment of the Service Transition plans with the customer, supplier and business change Project Plans.
11 Policies, principles and basic concepts • Service Design will – in collaboration with customers, external and internal suppliers and other relevant stakeholders – develop the Service Design and document it in a Service Design Package (SDP). • The SDP includes the following information that is required by the Service Transition team: − The applicable service packages (e.g. Core Service Package, Service Level Package) − The service specifications − The service models − The architectural design required to deliver the new or changed Service including constraints − The definition and design of each release package − The detailed design of how the service components will be assembled and integrated into a release package − Release and deployment plans − The Service Acceptance Criteria.
© 2008 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Change Management
13 Purpose/Goals/Objectives The purpose of the Change Management process is to ensure that: − Standardized methods and procedures are used for efficient and prompt handling of all changes − All changes to service assets and configuration items are recorded in the Configuration Management System − Overall business risk is optimized. The goals of Change Management are to: − Respond to the customer’s changing business requirements while maximizing 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. The objective of the Change Management process is: − To ensure that changes are recorded and then evaluated, authorized, prioritized, planned, tested, implemented, documented and reviewed in a controlled manner.
14 Scope • Addition, Modification or Removal of − Any Service or Configuration Item or associated documentation • Including − Strategic, Tactical and Operational changes • Excluding − Business strategy and process − Anything documented as out of scope
15 Scope of Change and Release Management
16 Value to the business • Prioritizing and responding to requests • Implementing changes in required times • Meet agreed service requirements while optimizing costs • Reducing failed changes and rework • Correctly estimating quality, time and cost • Assessing and managing risks • Managing staff time
17 Policies, principles and basic concepts • Change Types − Normal Changes • Types are specific to the organization • Type determines what assessment is required − Standard Changes • Pre-authorized with an established procedure − Emergency Changes • Insufficient time for normal handling • Should use normal process as far as possible
18 Sample of Normal Flow
19 Some things to consider The top five risk indicators of poor Change Management are: 1. Unauthorized changes (above zero is unacceptable) 2. Unplanned outages 3. A low change success rate 4. A high number of emergency changes 5. Delayed project implementations.
20 Remember • Change, configuration, release and deployment − Should be planned together − Should have coordinated implementation • Remediation Plans − Every change should have a back-out plan − Sometimes a change can’t be backed out • Must still have a plan for what to do
21 7 Rs of Change Management • Who RAISED the change? • What is the REASON for the change? • What is the RETURN required from the change? • What are the RISKS involved in the change? • What RESOURCES are required to deliver the change? • Who is RESPONSIBLE for the build, test and implementation of the change? • What is the RELATIONSHIP between this change and other changes?
22 Roles: Change Manager • Usually authorizes minor changes • Coordinates and runs CAB meetings • Produces change schedule • Coordinates change/build/test/implementation • Reviews/Closes Changes
23 Roles: CAB and ECAB • Change Advisory Board (CAB) − Supports the change manager − Consulted on significant changes − Business, users, application/technical support, operations, service desk, capacity, service continuity, third parties… • Emergency CAB (ECAB) − Subset of the standard CAB − Membership depends on the specific change
24 Key Metrics • Compliance − Reduction in unauthorized changes − Reduction in emergency changes • Effectiveness − Percentage of changes which met requirements − Reduction in disruptions, defects and re-work − Reduction in changes failed / backed out − Number of incidents attributable to changes • Efficiency − Benefits (value compared to cost) − Average time to implement (by urgency/priority/type) − Percentage accuracy in change estimates
25 Change – Challenges • People who ignore the process • Inadequate Configuration Management • Business pressure to “just do it” • Lack of “Standard Changes” • Scalability across large organizations
© 2008 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Service Asset and Configuration Management (SACM)
27 Purpose/Goals/Objectives The purpose are to: − Identify, control, record, report, audit and verify service assets and configuration items, including versions, baselines, constituent components, their attributes, and relationships − Account for, manage and protect the integrity of service assets and configuration items (and, where appropriate, those of its customers) through the service lifecycle by ensuring that only authorized components are used and only authorized changes are made − Protect the integrity of service assets and configuration items (and, where appropriate, those of its customers) through the service lifecycle − Ensure the integrity of the assets and configurations required to control the services and IT infrastructure by establishing and maintaining an accurate and complete Configuration Management System. The goals are to: − Support the business and customer’s control objectives and requirements − Support efficient and effective Service Management processes by providing accurate configuration information to enable people to make decisions at the right time, e.g. to authorize change and releases, resolve incidents and problems faster. − Minimize the number of quality and compliance issues caused by improper configuration of services and assets − Optimize the service assets, IT configurations, capabilities and resources. The objective of is: − To define and control the components of services and infrastructure and maintain accurate configuration information on the historical, planned and current state of the services and infrastructure.
28 Scope • Asset Management covers service assets across the whole service lifecycle. It provides a complete inventory of assets and who is responsible for their control. • It includes: − Full lifecycle management of IT and service assets, from the point of acquisition through to disposal − Maintenance of the asset inventory. • Configuration Management ensures that selected components of a complete service, system or product (the configuration) are identified, baselined and maintained and that changes to them are controlled. It also ensures that releases into controlled environments and operational use are done on the basis of formal approvals. It provides a configuration model of the services, assets and infrastructure by recording the relationships between service assets and configuration items. SACM may cover non-IT assets, work products used to develop the services and configuration items required to support the service that are not formally classified as assets. • The scope covers interfaces to internal and external service providers where there are assets and configuration items that need to be controlled, e.g. shared assets.
29 Value to Business • 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. • SACM provides visibility of accurate representations of a service, release, or environment that enables: − 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 (less non- conformances) − More business opportunities as able to demonstrate control of assets and services − Changes to be traceable from requirements − The ability to identify the costs for a service.
30 Policies, principles and basic concepts • Service Lifecycle CIs − Business case, plan, design package… • Service CIs − Service package, acceptance criteria,… − Service assets • Management, organization, process, knowledge, people, information, applications, infrastructure, financial capital • Organization CIs • Internal and External CIs
31 Policies, principles and basic concepts
32 Configuration Baseline • A configuration baseline is the configuration of a service, product or infrastructure that has been formally reviewed and agreed on, that thereafter serves as the basis for further activities and that can be changed only through formal change procedures. • It captures the structure, contents and details of a configuration 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.
33 Snapshot • A snapshot of 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 referred to a footprint. • A snapshot is not necessarily formally reviewed and agreed on – it is just a documentation of a state, which may contain faults and unauthorized CIs. • One example is where a snapshot is established after an installation, perhaps using a discovery tool, and later compared to the original configuration baseline. • The snapshot: − Enables problem management to analyse evidence about a situation pertaining at the time incidents actually occurred − Facilitates system restore to support security scanning software.
34 Definitive Media Library (DML) • The Definitive Media Library (DML) is the secure library in which the definitive authorized versions of all media CIs are stored and protected. It stores master copies of versions that have passed quality assurance checks. • Master copies of all software assets − In house, external software house, COTS… − Scripts as well as code − Management tools as well as applications − Including licenses • Quality checked − Complete, correct, virus scanned… • The only source for build and distribution
35 Relationship between DML and CMDB
36 Definitive Spares • An area should be set aside for the secure storage of definitive hardware spares. • These are spare components and assemblies that are maintained at the same level as the comparative systems within the controlled test or live environment. • Details of these components, their locations and their respective builds and contents should be comprehensively recorded in the CMS. • These can then be used in a controlled manner when needed for additional systems or in the recovery from incidents. Once their (temporary) use has ended, they are returned to the spares store or replacements are obtained.
37 SACM – Roles • Service Asset Manager • Configuration Manager • Each of these is the process owner for their area − Implement policy and standards − Procure and manage finances − Agree scope, processes, and procedures − Define and procure tools − Recruit and train staff − Oversee collection and management of data − Manage audits − Provide management reports
© 2008 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Release and Deployment Management
39 Purpose/Goals/Objectives The purpose of Release and Deployment Management is to: − Define and agree release and deployment plans with customers and stakeholders − Ensure that each release package consists of a set of related assets and service components that are compatible with each other − Ensure that integrity of a release package and its constituent components is maintained throughout the transition activities and recorded accurately in the CMS − Ensure that all release and deployment packages can be tracked, installed, tested, verified, and/or uninstalled or backed out if appropriate − Ensure that organization and stakeholder change is managed during the release and deployment activities − Record and manage deviations, risks, 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 operations and support staff to enable them to effectively and efficiently deliver, support and maintain the service according to required warranties and service levels. The goal of Release and Deployment Management is: − To deploy releases into production and establish effective use of the service in order to deliver value to the customer and be able to handover to service operations.
40 Purpose/Goals/Objectives The objective of Release and Deployment Management is to ensure that: − There are clear and comprehensive release and deployment plans that enable the customer and business change projects to align their activities with these plans − A release package can be built, installed, tested and deployed efficiently to a deployment group or target environment successfully and on schedule − A new or changed service and its enabling systems, technology and organization are capable of delivering the agreed service requirements, i.e. utilities, 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.
41 Release and Deployment – Objectives • Clear, comprehensive release and deployment plans − Supporting customer and business change projects • Release packages can be built, installed, tested and deployed − Efficiently, successfully and on schedule − With minimal impact on production services, operations, and support teams − Enabling new or changed services to deliver agreed service requirements • Skills and knowledge transfer to enable − Customers and users to optimize use of the service − Operations and support staff to run and support the service
42 Scope • The scope of Release and Deployment Management includes the processes, systems and functions to package, build, test and deploy a release into production and establish the service specified in the Service Design package before final handover to service operations.
43 Value to business • Effective Release and Deployment Management enables the service provider to add value to the business 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 will make a significant difference to an organization’s service costs. • A poorly designed release or deployment will, at best, force IT personnel to spend significant amounts of time troubleshooting problems and managing complexity. • At worst, it can cripple the environment and degrade the live services.
44 Policies, principles and basic concepts • Release Unit − CIs that are normally released together − Typically includes sufficient components to perform a useful function. For example: • Fully configured desktop PC, payroll application − Considerations include • Ease and amount of change needed to deploy • Resources needed to build, test and deploy • Complexity of interfaces
45 Release and Deployment – Basic Concepts • Big bang versus phased approach − Phased approach can be by users, locations, functionality… • Push versus Pull deployment • Automated versus manual deployment • Release Package − Single release or many related releases − Can include hardware, software, utility, warranty, documentation, training…
46 Big Bang vs. Phased • ‘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. • 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 rollout plan. This will be the case in many scenarios such as in retail organizations for new services being introduced into the stores’ environment in manageable phases.
47 Push and Pull Approach • 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.
48 Automated vs. Manual • Whether by automation or other means, the mechanisms to release and deploy the correctly configured service components should be established in the release design phase and tested 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 manual mechanism is used it is important to monitor and measure the impact of many repeated manual activities as they are likely to be inefficient and error-prone. • Too many manual activities will slow down the release team and create resource or capacity issues that affect the service levels.
49 Release and Deployment – Basic Concepts • Release and deployment models − Standard approach for a release − Overall structure for building the release − Exit and entry criteria for each stage − Build and test environments to use − Roles and responsibilities − Configuration baseline model − Template schedules − Release and deployment steps − Supporting systems − Handover activities
50 Release and Deployment – Roles • Release package and build manager − Establishes final release configuration − Builds final release − Test final delivery prior to independent testing − Establishes and reports known errors and workarounds − Provides input to final implementation sign-off
51 Release and Deployment – Roles • Deployment Manager − Final physical delivery of the service implementation − Co-ordinates documentation and communications • Including training and customer, service management and technical release notes − Plans deployment with Change, SKMS and SACM − Technical and application guidance and support • Including known errors and workarounds − Feedback on effectiveness of the release − Records metrics for deployment • To ensure within agreed SLAs
© 2008 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Service Validation and Testing
53 Purpose/Goals/Objectives The purpose of the Service Validation and Testing process is to: − Plan and implement a structured validation and test process that provides objective evidence that the new or changed service will support the customer’s business and stakeholder requirements, including the agreed service levels − Quality assure a release, its constituent service components, the resultant service and service capability delivered by a release − Identify, assess and address issues, errors and risks throughout Service Transition. The goal of Service Validation and Testing is − To assure that a service will provide value to customers and their business. The objectives of Service Validation and Testing are to: − Provide confidence that a release will create a new or changed service or service offerings that deliver the expected outcomes and value for the customers within the projected costs, capacity and constraints − Validate that a service is ‘fit for purpose’ – it will deliver the required performance with desired constraints removed − Assure a service is ‘fit for use’ – it meets certain specifications under the specified terms and conditions of use − Confirm that the customer and stakeholder requirements for the new or changed service are correctly defined and remedy any errors or variances early in the service lifecycle as this is considerably cheaper than fixing errors in production.
54 Scope • The service provider takes responsibility for delivering, operating and/or maintaining customer or service assets at specified levels of warranty, under a service agreement. • Service Validation and Testing can be applied throughout the service lifecycle to quality assure any aspect of a service and the service providers’ capability, resources and capacity to deliver a service and/or service release successfully. • Testing is equally applicable to in-house or developed services, hardware, software or knowledge-based services. • Testing directly supports the release and deployment process by ensuring that appropriate levels of testing are performed during the release, build and deployment activities. • It evaluates the detailed service models to ensure that they are fit for purpose and fit for use before being authorized to enter Service Operations, through the service catalogue. • The output from testing is used by the evaluation process to provide the information on whether the service is independently judged to be delivering the service performance with an acceptable risk profile.
55 Value to business • Service failures can harm the service provider’s business and the customer’s assets and result in outcomes such as loss of reputation, loss of money, loss of time, injury and death. • The key value to the business and customers from Service Testing and Validation is in terms of the established degree of confidence that a new or changed service will deliver the value and outcomes required of it and understanding the risks. • Successful testing depends on all parties understanding that it cannot give, indeed should not give, any guarantees but provides a measured degree of confidence. The required degree of confidence varies depending on the customer’s business requirements and pressures of an organization.
56 Policies, principles and basic concepts • Service Transition V-Model • Entry Criteria and Exit Criteria • User Acceptance Test
57 Service Transition V Model
58 Entry Criteria and Exit Criteria • Effective validation and testing focuses on whether the service will deliver as required. • This is based on the perspective of those who will use, deliver, deploy, manage and operate the service. • The test entry and exit criteria are developed as the Service Design Package is developed. • These will cover all aspects of the service provision from different perspectives including: − Service Design – functional, management and operational − Technology design − Process design − Measurement design − Documentation − Skills and knowledge.
59 User Acceptance Test Use r te sting – applicatio n, syste m , se rvice • Testing is comprised of tests to determine whether the service meets the functional and quality requirements of the end users (customers) by executing defined business processes in an environment that, as closely as possible, simulates the live operational environment. This will include changes to the system or business process. • Full details of the scope and coverage will be defined in the user test and user acceptance test (UAT) plans. • The end users will test the functional requirements, establishing to the customer’s agreed degree of confidence that the service will deliver as they require. • They will also perform tests of the Service Management activities that they are involved with, e.g. ability to contact and use the service desk, response to diagnostics scripts, incident management, request fulfillment, change request management.
© 2008 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Evaluation
61 Purpose/Goals/Objectives The purpose of evaluation is − To provide a consistent and standardized means of determining the performance of a service change in the context of existing and proposed services and IT infrastructure. The actual performance of a change is assessed against its predicted performance and any deviations between the two are understood and managed. The goal of evaluation is − To set stakeholder expectations correctly and provide effective and accurate information to Change Management to make sure changes that adversely affect service capability and introduce risk are not transitioned unchecked. The objective are to: − Evaluate the intended effects of a service change and as much of the unintended effects as is reasonably practical given capacity, resource and organizational constraints − Provide good quality outputs from the evaluation process so that Change Management can expedite an effective decision about whether a service change is to be approved or not.
62 Scope • Specifically in this section we consider the evaluation of new or changed services defined by Service Design, during deployment and before final transition to service operations. • The importance of evaluating the actual performance of any service change against its anticipated performance is an important source of information to service providers to help ensure that expectations set are realistic and to identify that if there are any reasons that production performance does not meet what was expected.
63 Value to business • Evaluation is, by its very nature, concerned with value. Specifically effective evaluation will establish the use made of resources in terms of delivered benefit and this information will allow a more accurate focus on value in future service development and Change Management. • There is a great deal of intelligence that Continual Service Improvement can take from evaluation to analyze future improvements to the process of change and the predictions and measurement of service change performance.
64 Policies, principles and basic concepts • Policies − The following policies apply to the evaluation process: − Service Designs or service changes will be evaluated before being transitioned. − Any deviation between predicted and actual performance will be managed by the customer or customer representative by accepting the change even though actual performance is different to what was predicted; rejecting the change; or requiring a new change to be implemented with revised predicted performance agreed in advance. No other outcomes of evaluation are allowed. − An evaluation shall not be performed without a customer engagement package. • Principles − The following principles shall guide the execution evaluation process: − As far as is reasonably practical, the unintended as well as the intended effects of a change need to be identified and their consequences understood and considered. − A service change will be fairly, consistently, openly and, wherever possible, objectively evaluated. • Basic Concepts − The evaluation process uses the Plan–Do–Check–Act (PDCA) model to ensure consistency across all evaluations.
65 Evaluation Process
© 2008 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Knowledge Management
67 Knowledge Management (KM) • “The process responsible for gathering, analyzing, storing and sharing knowledge and information within an organization. • The primary purpose of Knowledge Management is to improve efficiency by reducing the need to rediscover knowledge.”
68 Purpose/Goals/Objectives The purpose of Knowledge Management is: − To ensure that the right information is delivered to the appropriate place or competent person at the right time to enable informed decision. The goal of Knowledge Management is − To enable organizations to improve the quality of management decision making by ensuring that reliable and secure information and data is available throughout the service lifecycle. The objectives of Knowledge Management include: − Enabling the service provider to be more efficient and improve quality of service, increase satisfaction and reduce the cost of service − Ensuring staff have a clear and common understanding of the value that their services provide to customers and the ways in which benefits are realized from the use of those services − Ensuring that, at a given time and location, service provider staff have adequate information on: • Who is currently using their services • The current states of consumption • Service delivery constraints • Difficulties faced by the customer in fully realizing the benefits expected from the service.
69 Scope • Knowledge Management is a whole lifecycle-wide process in that it is relevant to all lifecycle sectors and hence is referenced throughout ITIL from the perspective of each publication. • It is dealt with to some degree within other ITIL publications but this chapter sets out the basic concept, from a Service Transition focus
70 Value to business • Knowledge Management is especially significant within Service Transition since relevant and appropriate knowledge is one of the key service elements being transitioned. • Examples where successful transition rests on appropriate Knowledge Management include: − User, service desk, support staff and supplier understanding of the new or changed service, including knowledge of errors signed off before deployment, to facilitate their roles within that service − Awareness of the use of the service, and the discontinuation of previous versions − Establishment of the acceptable risk and confidence levels associated with the transition, e.g. measuring, understanding and acting correctly on results of testing and other assurance results. − Effective Knowledge Management is a powerful asset for people in all roles across all stages of the service lifecycle. It is an excellent method for individuals and teams to share data, information and knowledge about all facets of an IT service. The creation of a single system for Knowledge Management is recommended.
71 Policies, principles and basic concepts • Knowledge Management is typically displayed within the Data–to– Information–to–Knowledge–to–Wisdom (DIKW) structure. The use of these terms is set out below. • Data is a set of discrete facts about events. Most organizations capture significant amounts of data in highly structured databases such as Service Management and Configuration Management tools/systems and databases. • The key Knowledge Management activities around data are the ability to: − Capture accurate data − Analyze, synthesize, and then transform the data into information − Identify relevant data and concentrate resources on its capture.
72 D-I-K-W Structure • Information comes from providing context to data. Information is typically stored in semi-structured content such as documents, e-mail, and multimedia. • The key Knowledge Management activity around information is managing the content in a way that makes it easy to capture, query, find, re-use and learn from experiences so that mistakes are not repeated and work is not duplicated. • Knowledge is composed of the tacit experiences, ideas, insights, values and judgments of individuals. People gain knowledge both from their own and from their peers’ expertise, as well as from the analysis of information (and data). Through the synthesis of these elements, new knowledge is created. • Knowledge is dynamic and context based. Knowledge puts information into an ‘ease of use’ form, which can facilitate decision making. In Service Transition this knowledge is not solely based on the transition in progress, but is gathered from experience of previous transitions, awareness of recent and anticipated changes and other areas that experienced staff will have been unconsciously collecting for some time. • Wisdom gives the ultimate discernment of the material and having the application and contextual awareness to provide a strong common sense judgment
73 Data, Information, Knowledge and Wisdom (DIKW) Context Understanding Wisdom Knowledg e Information Data
74 Relationship of CMDB, CMS & SKMS
75 Service Knowledge Management System (SKMS)

More Related Content

PDF
ITIL 4 service value chain data flows (input and outputs)
Rob Akershoek
 
PPTX
ITIL Service Design
Marvin Sirait
 
PPTX
Service Catalog Essentials: 5 Keys to Good Service Design in IT Service Catalogs
Evergreen Systems
 
PPT
Defining Services for a Service Catalog
Axios Systems
 
PDF
Digital Operating Model & IT4IT
David Favelle
 
PPTX
Introducing ITIL
Robert Thomas
 
PPTX
IT4IT Overview (A new standard for IT management)
Charles Betz
 
PPT
Change Management ITIL
dkmorgan51
 
ITIL 4 service value chain data flows (input and outputs)
Rob Akershoek
 
ITIL Service Design
Marvin Sirait
 
Service Catalog Essentials: 5 Keys to Good Service Design in IT Service Catalogs
Evergreen Systems
 
Defining Services for a Service Catalog
Axios Systems
 
Digital Operating Model & IT4IT
David Favelle
 
Introducing ITIL
Robert Thomas
 
IT4IT Overview (A new standard for IT management)
Charles Betz
 
Change Management ITIL
dkmorgan51
 

What's hot (20)

PPTX
ITIL PPT
Vikas Aryan
 
PPTX
ITSM and Service Catalog Overview
Christopher Glennon
 
PDF
The IT Chargeback Journey
Pete Hidalgo
 
PPT
It Service Management Implementation Overview
Alan McSweeney
 
PDF
IT Operating Model - Fundamental
Eryk Budi Pratama
 
PPTX
Service Transition Overview
sivashankar Balasubramanian
 
PDF
Future Proofing Your IT Operating Model for Digital
David Favelle
 
PDF
ITIL,COBIT and IT4IT Mapping
Rob Akershoek
 
PDF
Review of Information Technology Function Critical Capability Models
Alan McSweeney
 
PPTX
ITIL Continual Service Improvement
Marvin Sirait
 
PDF
Service Integration and Management (SIAM)
NUS-ISS
 
PDF
How to implement ITSM as a program in the real world
Pink Elephant EMEA
 
PDF
Integrating ITSM Frameworks, Standards and Processes - ITSM Academy Webinar
ITSM Academy, Inc.
 
PPTX
A new IT Operating Model Emerges
David Favelle
 
PPTX
ITIL Service Transition
Marvin Sirait
 
PDF
IT4IT™ - Managing the Business of IT
The Open Group SA
 
PPTX
Implementing Effective Enterprise Architecture
Leo Shuster
 
PPTX
ITIL Service Transition 2011
Marvin Sirait
 
PPTX
IT4IT - The Full Story for Digital Transformation - Part 1
Mohamed Zakarya Abdelgawad
 
PPT
ITSM Presentation
itsm_at_hanover
 
ITIL PPT
Vikas Aryan
 
ITSM and Service Catalog Overview
Christopher Glennon
 
The IT Chargeback Journey
Pete Hidalgo
 
It Service Management Implementation Overview
Alan McSweeney
 
IT Operating Model - Fundamental
Eryk Budi Pratama
 
Service Transition Overview
sivashankar Balasubramanian
 
Future Proofing Your IT Operating Model for Digital
David Favelle
 
ITIL,COBIT and IT4IT Mapping
Rob Akershoek
 
Review of Information Technology Function Critical Capability Models
Alan McSweeney
 
ITIL Continual Service Improvement
Marvin Sirait
 
Service Integration and Management (SIAM)
NUS-ISS
 
How to implement ITSM as a program in the real world
Pink Elephant EMEA
 
Integrating ITSM Frameworks, Standards and Processes - ITSM Academy Webinar
ITSM Academy, Inc.
 
A new IT Operating Model Emerges
David Favelle
 
ITIL Service Transition
Marvin Sirait
 
IT4IT™ - Managing the Business of IT
The Open Group SA
 
Implementing Effective Enterprise Architecture
Leo Shuster
 
ITIL Service Transition 2011
Marvin Sirait
 
IT4IT - The Full Story for Digital Transformation - Part 1
Mohamed Zakarya Abdelgawad
 
ITSM Presentation
itsm_at_hanover
 
Ad

Viewers also liked (20)

PPT
ITIL Practical Guide - Service Transition
Axios Systems
 
PDF
It transition management an operational perspective
Pankaj Sharma, PMP, ITIL Expert, COP
 
PPTX
Service Transition
Peleg
 
PDF
ITIL V3 And Service Transition - ITSM Academy Webinar
ITSM Academy, Inc.
 
PPT
Transition Management basics
DRIFT - Erasmus University Rotterdam
 
PDF
Managing Successful Business Process Transition
Information Services Group (ISG)
 
PPTX
Transition and Planning
AIESEC
 
PPT
5 itil v3 service transition 5 v1.8
Karthik Arumugham
 
PPT
Managing transitions (1)
Charlene Ehll
 
PDF
ITIL Foundation Training
stefanhenry
 
PDF
ITIL V3 New Process Maps
cityfan
 
PPT
ITIL v3 Foundation Overview
adabbas
 
PPTX
Transition management
barnesmanagementgroup
 
PPT
Service transition
trainer_omarali
 
PPTX
Sl
Eugenia S. Lee
 
DOC
Transition out-plan
Murugan Paramasivan
 
PPT
Wake up and get back to work
K S Ahluwalia
 
PPT
Managed Services Support
jdivalerio
 
PPTX
Doddi Priyambodo - Scrum Day Asia 20121123 - AGILE SOFTWARE DEVELOPMENT LIFE ...
Doddi Priyambodo
 
PPTX
Asset Management vs. Configuration Management: Who's Winning?
Cireson
 
ITIL Practical Guide - Service Transition
Axios Systems
 
It transition management an operational perspective
Pankaj Sharma, PMP, ITIL Expert, COP
 
Service Transition
Peleg
 
ITIL V3 And Service Transition - ITSM Academy Webinar
ITSM Academy, Inc.
 
Transition Management basics
DRIFT - Erasmus University Rotterdam
 
Managing Successful Business Process Transition
Information Services Group (ISG)
 
Transition and Planning
AIESEC
 
5 itil v3 service transition 5 v1.8
Karthik Arumugham
 
Managing transitions (1)
Charlene Ehll
 
ITIL Foundation Training
stefanhenry
 
ITIL V3 New Process Maps
cityfan
 
ITIL v3 Foundation Overview
adabbas
 
Transition management
barnesmanagementgroup
 
Service transition
trainer_omarali
 
Sl
Eugenia S. Lee
 
Transition out-plan
Murugan Paramasivan
 
Wake up and get back to work
K S Ahluwalia
 
Managed Services Support
jdivalerio
 
Doddi Priyambodo - Scrum Day Asia 20121123 - AGILE SOFTWARE DEVELOPMENT LIFE ...
Doddi Priyambodo
 
Asset Management vs. Configuration Management: Who's Winning?
Cireson
 
Ad

Similar to 5 service transition (20)

PPT
4 service design
sagaroceanic11
 
PPT
4 service design
sagaroceanic11
 
PPT
Tatakelola TI Menggunakan Framework ITIL V3
ssuser89dc1c
 
PPT
ITIL - introduction to ITIL
Vibrant Technologies & Computers
 
PPT
Itilv3
ahmet durak
 
PPT
Itilv3
Markus Yaldu
 
PPT
ITIL Foundation for Information technology begineers
wnilo
 
PPT
ITIL V3 by Jisu Dasgupta
Jisu Dasgupta
 
PPTX
The five core processes: Service transition
Rhy Carloy Basalo
 
PDF
Itilservicetransition 161212153303
BhagyashriJadhav16
 
DOCX
Robert Latest cv
Robert Cordock
 
PPT
ITIL
Mohammed El Rafie Tarabay
 
PPTX
ITIL Best Practice for Software Companies
Daniel Brody
 
PPT
2 the service lifecycle
sagaroceanic11
 
PPT
2 the service lifecycle
sagaroceanic11
 
PPTX
ITIL Intermediate Service Transition Course Preview
Invensis Learning
 
PDF
U2 chap1 itsm service design
MusTufa Nullwala
 
PPSX
ITIL v3 at COMPUTERLAND : presentation to the team - Sept 2014
Patricia NENZI
 
PPSX
ITIL v3 at COMPUTERLAND : presentation to the team - Sept 2014
Patricia NENZI
 
PPT
3 service strategy
sagaroceanic11
 
4 service design
sagaroceanic11
 
4 service design
sagaroceanic11
 
Tatakelola TI Menggunakan Framework ITIL V3
ssuser89dc1c
 
ITIL - introduction to ITIL
Vibrant Technologies & Computers
 
Itilv3
ahmet durak
 
Itilv3
Markus Yaldu
 
ITIL Foundation for Information technology begineers
wnilo
 
ITIL V3 by Jisu Dasgupta
Jisu Dasgupta
 
The five core processes: Service transition
Rhy Carloy Basalo
 
Itilservicetransition 161212153303
BhagyashriJadhav16
 
Robert Latest cv
Robert Cordock
 
ITIL
Mohammed El Rafie Tarabay
 
ITIL Best Practice for Software Companies
Daniel Brody
 
2 the service lifecycle
sagaroceanic11
 
2 the service lifecycle
sagaroceanic11
 
ITIL Intermediate Service Transition Course Preview
Invensis Learning
 
U2 chap1 itsm service design
MusTufa Nullwala
 
ITIL v3 at COMPUTERLAND : presentation to the team - Sept 2014
Patricia NENZI
 
ITIL v3 at COMPUTERLAND : presentation to the team - Sept 2014
Patricia NENZI
 
3 service strategy
sagaroceanic11
 

More from sagaroceanic11 (20)

PPTX
Module 21 investigative reports
sagaroceanic11
 
PPTX
Module 20 mobile forensics
sagaroceanic11
 
PPTX
Module 19 tracking emails and investigating email crimes
sagaroceanic11
 
PPTX
Module 18 investigating web attacks
sagaroceanic11
 
PPTX
Module 17 investigating wireless attacks
sagaroceanic11
 
PPTX
Module 04 digital evidence
sagaroceanic11
 
PPTX
Module 03 searching and seizing computers
sagaroceanic11
 
PPTX
Module 01 computer forensics in todays world
sagaroceanic11
 
PPT
Virtualisation with v mware
sagaroceanic11
 
PPT
Virtualisation overview
sagaroceanic11
 
PPT
Virtualisation basics
sagaroceanic11
 
PPT
Introduction to virtualisation
sagaroceanic11
 
PPT
6 service operation
sagaroceanic11
 
PPT
5 service transition
sagaroceanic11
 
PPT
1 introduction to itil v[1].3
sagaroceanic11
 
PPTX
Visual studio 2008 overview
sagaroceanic11
 
PPT
Vb introduction.
sagaroceanic11
 
PPTX
Vb essentials
sagaroceanic11
 
PPT
Vb basics
sagaroceanic11
 
PPT
Rubyforjavaprogrammers 1210167973516759-9
sagaroceanic11
 
Module 21 investigative reports
sagaroceanic11
 
Module 20 mobile forensics
sagaroceanic11
 
Module 19 tracking emails and investigating email crimes
sagaroceanic11
 
Module 18 investigating web attacks
sagaroceanic11
 
Module 17 investigating wireless attacks
sagaroceanic11
 
Module 04 digital evidence
sagaroceanic11
 
Module 03 searching and seizing computers
sagaroceanic11
 
Module 01 computer forensics in todays world
sagaroceanic11
 
Virtualisation with v mware
sagaroceanic11
 
Virtualisation overview
sagaroceanic11
 
Virtualisation basics
sagaroceanic11
 
Introduction to virtualisation
sagaroceanic11
 
6 service operation
sagaroceanic11
 
5 service transition
sagaroceanic11
 
1 introduction to itil v[1].3
sagaroceanic11
 
Visual studio 2008 overview
sagaroceanic11
 
Vb introduction.
sagaroceanic11
 
Vb essentials
sagaroceanic11
 
Vb basics
sagaroceanic11
 
Rubyforjavaprogrammers 1210167973516759-9
sagaroceanic11
 

Recently uploaded (20)

PPT
340036916-American-Literature-Literary-Period-Overview.ppt
carinaherdiles611
 
PDF
Business model innovation report 2022.pdf
pradvapal
 
PDF
Laughter Yoga Basic Learning Workshop Manual
yeechensee
 
PPTX
Belch_12e_PPT_Ch18_Accessible_university.pptx
Haitham327103
 
PDF
Outsourced Audit & Assurance in USA Why Globus Finanza is Your Trusted Choice
Globus finanza
 
PPTX
ICG2025_ICG 6th steering committee 30-8-24.pptx
AtiarRahaman5
 
PDF
How to Get Business Funding for Small Business Fast
Jake Thornhill
 
PPTX
The Marketing Journey - Tracey Phillips - Marketing Matters 7-2025.pptx
shannonzipoy2
 
PDF
Chapter 5_Foreign Exchange Market in .pdf
sophatphoniu
 
PDF
Stem Cell Market Report | Trends, Growth & Forecast 2025-2034
Claight Corporation
 
PDF
Solara Labs: Empowering Health through Innovative Nutraceutical Solutions
The lifescience magaizne
 
DOCX
Business Management - unit 1 and 2
anithak410
 
PPTX
HR Introduction Slide (1).pptx on hr intro
suhanidwivedi227
 
PDF
Training And Development of Employee .pdf
nivethavm864
 
DOCX
unit 2 cost accounting- Tender and Quotation & Reconciliation Statement
MANJU N
 
PPTX
Principles of Marketing, Industrial, Consumers,
efranciscaantoinette
 
PPTX
Dragon_Fruit_Cultivation_in Nepal ppt.pptx
UmeshTimilsina1
 
PDF
Nidhal Samdaie CV - International Business Consultant
Nidhal Samdaie
 
PDF
Reconciliation AND MEMORANDUM RECONCILATION
MANJU N
 
PDF
COST SHEET- Tender and Quotation unit 2.pdf
MANJU N
 
340036916-American-Literature-Literary-Period-Overview.ppt
carinaherdiles611
 
Business model innovation report 2022.pdf
pradvapal
 
Laughter Yoga Basic Learning Workshop Manual
yeechensee
 
Belch_12e_PPT_Ch18_Accessible_university.pptx
Haitham327103
 
Outsourced Audit & Assurance in USA Why Globus Finanza is Your Trusted Choice
Globus finanza
 
ICG2025_ICG 6th steering committee 30-8-24.pptx
AtiarRahaman5
 
How to Get Business Funding for Small Business Fast
Jake Thornhill
 
The Marketing Journey - Tracey Phillips - Marketing Matters 7-2025.pptx
shannonzipoy2
 
Chapter 5_Foreign Exchange Market in .pdf
sophatphoniu
 
Stem Cell Market Report | Trends, Growth & Forecast 2025-2034
Claight Corporation
 
Solara Labs: Empowering Health through Innovative Nutraceutical Solutions
The lifescience magaizne
 
Business Management - unit 1 and 2
anithak410
 
HR Introduction Slide (1).pptx on hr intro
suhanidwivedi227
 
Training And Development of Employee .pdf
nivethavm864
 
unit 2 cost accounting- Tender and Quotation & Reconciliation Statement
MANJU N
 
Principles of Marketing, Industrial, Consumers,
efranciscaantoinette
 
Dragon_Fruit_Cultivation_in Nepal ppt.pptx
UmeshTimilsina1
 
Nidhal Samdaie CV - International Business Consultant
Nidhal Samdaie
 
Reconciliation AND MEMORANDUM RECONCILATION
MANJU N
 
COST SHEET- Tender and Quotation unit 2.pdf
MANJU N
 

5 service transition

  • 1. © 2008 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Service Transition
  • 2. 2 Service Transition • Concepts − V Model − Configuration Item − Configuration Management System − Knowledge Management − Data Information Knowledge Wisdom − Service Knowledge Management System − Definitive Media Library • Processes − Change Management − Service Asset and Configuration Management − Release and Deployment Management
  • 4. 4 Configuration Item (CI) • Anything that needs to be managed in order to deliver an IT Service • CI information is recorded in the Configuration Management System • CI information is maintained throughout its Lifecycle by Configuration Management • ALL CIs are controlled by Change Management • CIs typically include − IT Services, hardware, software, buildings, people, and formal documentation such as Process documentation and SLAs
  • 5. 5 Configuration Management System (CMS) • Information about all Configuration Items − CI may be entire service, or any component − Stored in 1 or more databases (CMDBs) • CMS stores attributes − Any information about the CI that might be needed • CMS stores relationships − Between CIs − With incident, problem, change records etc. • CMS has multiple layers − Data sources and tools, information integration, knowledge processing, presentation
  • 7. © 2008 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Transition Planning and Support
  • 8. 8 Purpose/Goal/Objective The purpose of the Transition Planning and Support activities is to: − Plan appropriate capacity and resources to package a release, build, release, test, deploy and establish the new or changed service into production − Provide support for the Service Transition teams and people − Plan the changes required in a manner that ensures the integrity of all identified customer assets, service assets and configurations can be maintained as they evolve through Service Transition − Ensure that Service Transition issues, risks and deviations are reported to the appropriate stakeholders and decision makers − Coordinate activities across projects, suppliers and service teams where required. 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. The objective of Transition Planning and Support is to: − Plan and coordinate the resources to establish successfully a new or changed service into production within the predicted cost, quality and time estimates − Ensure that all parties adopt the common framework of standard re-usable processes and supporting systems in order to improve the effectiveness and efficiency of the integrated planning and coordination activities − Provide clear and comprehensive plans that enable the customer and business change projects to align their activities with the Service Transition plans.
  • 9. 9 Scope • The scope of the Service Transition Planning and Support activities includes: − Incorporating design and operation requirements into the transition plans − Managing and operating Transition Planning and Support activities − Maintaining and integrating Service Transition plans across the customer, service and contract portfolios − Managing Service Transition progress, changes, issues, risks and deviations − Quality review of all Service Transition, release and deployment plans − Managing and operating the transition processes, supporting systems and tools − Communications with customers, users and stakeholders − Monitoring and improving Service Transition performance
  • 10. 10 Value to Business • Effective Transition Planning and Support can significantly improve a service provider’s ability to handle high volumes of change and releases across its customer base. • An integrated approach to planning improves the alignment of the Service Transition plans with the customer, supplier and business change Project Plans.
  • 11. 11 Policies, principles and basic concepts • Service Design will – in collaboration with customers, external and internal suppliers and other relevant stakeholders – develop the Service Design and document it in a Service Design Package (SDP). • The SDP includes the following information that is required by the Service Transition team: − The applicable service packages (e.g. Core Service Package, Service Level Package) − The service specifications − The service models − The architectural design required to deliver the new or changed Service including constraints − The definition and design of each release package − The detailed design of how the service components will be assembled and integrated into a release package − Release and deployment plans − The Service Acceptance Criteria.
  • 12. © 2008 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Change Management
  • 13. 13 Purpose/Goals/Objectives The purpose of the Change Management process is to ensure that: − Standardized methods and procedures are used for efficient and prompt handling of all changes − All changes to service assets and configuration items are recorded in the Configuration Management System − Overall business risk is optimized. The goals of Change Management are to: − Respond to the customer’s changing business requirements while maximizing 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. The objective of the Change Management process is: − To ensure that changes are recorded and then evaluated, authorized, prioritized, planned, tested, implemented, documented and reviewed in a controlled manner.
  • 14. 14 Scope • Addition, Modification or Removal of − Any Service or Configuration Item or associated documentation • Including − Strategic, Tactical and Operational changes • Excluding − Business strategy and process − Anything documented as out of scope
  • 15. 15 Scope of Change and Release Management
  • 16. 16 Value to the business • Prioritizing and responding to requests • Implementing changes in required times • Meet agreed service requirements while optimizing costs • Reducing failed changes and rework • Correctly estimating quality, time and cost • Assessing and managing risks • Managing staff time
  • 17. 17 Policies, principles and basic concepts • Change Types − Normal Changes • Types are specific to the organization • Type determines what assessment is required − Standard Changes • Pre-authorized with an established procedure − Emergency Changes • Insufficient time for normal handling • Should use normal process as far as possible
  • 19. 19 Some things to consider The top five risk indicators of poor Change Management are: 1. Unauthorized changes (above zero is unacceptable) 2. Unplanned outages 3. A low change success rate 4. A high number of emergency changes 5. Delayed project implementations.
  • 20. 20 Remember • Change, configuration, release and deployment − Should be planned together − Should have coordinated implementation • Remediation Plans − Every change should have a back-out plan − Sometimes a change can’t be backed out • Must still have a plan for what to do
  • 21. 21 7 Rs of Change Management • Who RAISED the change? • What is the REASON for the change? • What is the RETURN required from the change? • What are the RISKS involved in the change? • What RESOURCES are required to deliver the change? • Who is RESPONSIBLE for the build, test and implementation of the change? • What is the RELATIONSHIP between this change and other changes?
  • 22. 22 Roles: Change Manager • Usually authorizes minor changes • Coordinates and runs CAB meetings • Produces change schedule • Coordinates change/build/test/implementation • Reviews/Closes Changes
  • 23. 23 Roles: CAB and ECAB • Change Advisory Board (CAB) − Supports the change manager − Consulted on significant changes − Business, users, application/technical support, operations, service desk, capacity, service continuity, third parties… • Emergency CAB (ECAB) − Subset of the standard CAB − Membership depends on the specific change
  • 24. 24 Key Metrics • Compliance − Reduction in unauthorized changes − Reduction in emergency changes • Effectiveness − Percentage of changes which met requirements − Reduction in disruptions, defects and re-work − Reduction in changes failed / backed out − Number of incidents attributable to changes • Efficiency − Benefits (value compared to cost) − Average time to implement (by urgency/priority/type) − Percentage accuracy in change estimates
  • 25. 25 Change – Challenges • People who ignore the process • Inadequate Configuration Management • Business pressure to “just do it” • Lack of “Standard Changes” • Scalability across large organizations
  • 26. © 2008 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Service Asset and Configuration Management (SACM)
  • 27. 27 Purpose/Goals/Objectives The purpose are to: − Identify, control, record, report, audit and verify service assets and configuration items, including versions, baselines, constituent components, their attributes, and relationships − Account for, manage and protect the integrity of service assets and configuration items (and, where appropriate, those of its customers) through the service lifecycle by ensuring that only authorized components are used and only authorized changes are made − Protect the integrity of service assets and configuration items (and, where appropriate, those of its customers) through the service lifecycle − Ensure the integrity of the assets and configurations required to control the services and IT infrastructure by establishing and maintaining an accurate and complete Configuration Management System. The goals are to: − Support the business and customer’s control objectives and requirements − Support efficient and effective Service Management processes by providing accurate configuration information to enable people to make decisions at the right time, e.g. to authorize change and releases, resolve incidents and problems faster. − Minimize the number of quality and compliance issues caused by improper configuration of services and assets − Optimize the service assets, IT configurations, capabilities and resources. The objective of is: − To define and control the components of services and infrastructure and maintain accurate configuration information on the historical, planned and current state of the services and infrastructure.
  • 28. 28 Scope • Asset Management covers service assets across the whole service lifecycle. It provides a complete inventory of assets and who is responsible for their control. • It includes: − Full lifecycle management of IT and service assets, from the point of acquisition through to disposal − Maintenance of the asset inventory. • Configuration Management ensures that selected components of a complete service, system or product (the configuration) are identified, baselined and maintained and that changes to them are controlled. It also ensures that releases into controlled environments and operational use are done on the basis of formal approvals. It provides a configuration model of the services, assets and infrastructure by recording the relationships between service assets and configuration items. SACM may cover non-IT assets, work products used to develop the services and configuration items required to support the service that are not formally classified as assets. • The scope covers interfaces to internal and external service providers where there are assets and configuration items that need to be controlled, e.g. shared assets.
  • 29. 29 Value to Business • 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. • SACM provides visibility of accurate representations of a service, release, or environment that enables: − 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 (less non- conformances) − More business opportunities as able to demonstrate control of assets and services − Changes to be traceable from requirements − The ability to identify the costs for a service.
  • 30. 30 Policies, principles and basic concepts • Service Lifecycle CIs − Business case, plan, design package… • Service CIs − Service package, acceptance criteria,… − Service assets • Management, organization, process, knowledge, people, information, applications, infrastructure, financial capital • Organization CIs • Internal and External CIs
  • 31. 31 Policies, principles and basic concepts
  • 32. 32 Configuration Baseline • A configuration baseline is the configuration of a service, product or infrastructure that has been formally reviewed and agreed on, that thereafter serves as the basis for further activities and that can be changed only through formal change procedures. • It captures the structure, contents and details of a configuration 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.
  • 33. 33 Snapshot • A snapshot of 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 referred to a footprint. • A snapshot is not necessarily formally reviewed and agreed on – it is just a documentation of a state, which may contain faults and unauthorized CIs. • One example is where a snapshot is established after an installation, perhaps using a discovery tool, and later compared to the original configuration baseline. • The snapshot: − Enables problem management to analyse evidence about a situation pertaining at the time incidents actually occurred − Facilitates system restore to support security scanning software.
  • 34. 34 Definitive Media Library (DML) • The Definitive Media Library (DML) is the secure library in which the definitive authorized versions of all media CIs are stored and protected. It stores master copies of versions that have passed quality assurance checks. • Master copies of all software assets − In house, external software house, COTS… − Scripts as well as code − Management tools as well as applications − Including licenses • Quality checked − Complete, correct, virus scanned… • The only source for build and distribution
  • 36. 36 Definitive Spares • An area should be set aside for the secure storage of definitive hardware spares. • These are spare components and assemblies that are maintained at the same level as the comparative systems within the controlled test or live environment. • Details of these components, their locations and their respective builds and contents should be comprehensively recorded in the CMS. • These can then be used in a controlled manner when needed for additional systems or in the recovery from incidents. Once their (temporary) use has ended, they are returned to the spares store or replacements are obtained.
  • 37. 37 SACM – Roles • Service Asset Manager • Configuration Manager • Each of these is the process owner for their area − Implement policy and standards − Procure and manage finances − Agree scope, processes, and procedures − Define and procure tools − Recruit and train staff − Oversee collection and management of data − Manage audits − Provide management reports
  • 38. © 2008 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Release and Deployment Management
  • 39. 39 Purpose/Goals/Objectives The purpose of Release and Deployment Management is to: − Define and agree release and deployment plans with customers and stakeholders − Ensure that each release package consists of a set of related assets and service components that are compatible with each other − Ensure that integrity of a release package and its constituent components is maintained throughout the transition activities and recorded accurately in the CMS − Ensure that all release and deployment packages can be tracked, installed, tested, verified, and/or uninstalled or backed out if appropriate − Ensure that organization and stakeholder change is managed during the release and deployment activities − Record and manage deviations, risks, 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 operations and support staff to enable them to effectively and efficiently deliver, support and maintain the service according to required warranties and service levels. The goal of Release and Deployment Management is: − To deploy releases into production and establish effective use of the service in order to deliver value to the customer and be able to handover to service operations.
  • 40. 40 Purpose/Goals/Objectives The objective of Release and Deployment Management is to ensure that: − There are clear and comprehensive release and deployment plans that enable the customer and business change projects to align their activities with these plans − A release package can be built, installed, tested and deployed efficiently to a deployment group or target environment successfully and on schedule − A new or changed service and its enabling systems, technology and organization are capable of delivering the agreed service requirements, i.e. utilities, 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.
  • 41. 41 Release and Deployment – Objectives • Clear, comprehensive release and deployment plans − Supporting customer and business change projects • Release packages can be built, installed, tested and deployed − Efficiently, successfully and on schedule − With minimal impact on production services, operations, and support teams − Enabling new or changed services to deliver agreed service requirements • Skills and knowledge transfer to enable − Customers and users to optimize use of the service − Operations and support staff to run and support the service
  • 42. 42 Scope • The scope of Release and Deployment Management includes the processes, systems and functions to package, build, test and deploy a release into production and establish the service specified in the Service Design package before final handover to service operations.
  • 43. 43 Value to business • Effective Release and Deployment Management enables the service provider to add value to the business 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 will make a significant difference to an organization’s service costs. • A poorly designed release or deployment will, at best, force IT personnel to spend significant amounts of time troubleshooting problems and managing complexity. • At worst, it can cripple the environment and degrade the live services.
  • 44. 44 Policies, principles and basic concepts • Release Unit − CIs that are normally released together − Typically includes sufficient components to perform a useful function. For example: • Fully configured desktop PC, payroll application − Considerations include • Ease and amount of change needed to deploy • Resources needed to build, test and deploy • Complexity of interfaces
  • 45. 45 Release and Deployment – Basic Concepts • Big bang versus phased approach − Phased approach can be by users, locations, functionality… • Push versus Pull deployment • Automated versus manual deployment • Release Package − Single release or many related releases − Can include hardware, software, utility, warranty, documentation, training…
  • 46. 46 Big Bang vs. Phased • ‘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. • 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 rollout plan. This will be the case in many scenarios such as in retail organizations for new services being introduced into the stores’ environment in manageable phases.
  • 47. 47 Push and Pull Approach • 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.
  • 48. 48 Automated vs. Manual • Whether by automation or other means, the mechanisms to release and deploy the correctly configured service components should be established in the release design phase and tested 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 manual mechanism is used it is important to monitor and measure the impact of many repeated manual activities as they are likely to be inefficient and error-prone. • Too many manual activities will slow down the release team and create resource or capacity issues that affect the service levels.
  • 49. 49 Release and Deployment – Basic Concepts • Release and deployment models − Standard approach for a release − Overall structure for building the release − Exit and entry criteria for each stage − Build and test environments to use − Roles and responsibilities − Configuration baseline model − Template schedules − Release and deployment steps − Supporting systems − Handover activities
  • 50. 50 Release and Deployment – Roles • Release package and build manager − Establishes final release configuration − Builds final release − Test final delivery prior to independent testing − Establishes and reports known errors and workarounds − Provides input to final implementation sign-off
  • 51. 51 Release and Deployment – Roles • Deployment Manager − Final physical delivery of the service implementation − Co-ordinates documentation and communications • Including training and customer, service management and technical release notes − Plans deployment with Change, SKMS and SACM − Technical and application guidance and support • Including known errors and workarounds − Feedback on effectiveness of the release − Records metrics for deployment • To ensure within agreed SLAs
  • 52. © 2008 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Service Validation and Testing
  • 53. 53 Purpose/Goals/Objectives The purpose of the Service Validation and Testing process is to: − Plan and implement a structured validation and test process that provides objective evidence that the new or changed service will support the customer’s business and stakeholder requirements, including the agreed service levels − Quality assure a release, its constituent service components, the resultant service and service capability delivered by a release − Identify, assess and address issues, errors and risks throughout Service Transition. The goal of Service Validation and Testing is − To assure that a service will provide value to customers and their business. The objectives of Service Validation and Testing are to: − Provide confidence that a release will create a new or changed service or service offerings that deliver the expected outcomes and value for the customers within the projected costs, capacity and constraints − Validate that a service is ‘fit for purpose’ – it will deliver the required performance with desired constraints removed − Assure a service is ‘fit for use’ – it meets certain specifications under the specified terms and conditions of use − Confirm that the customer and stakeholder requirements for the new or changed service are correctly defined and remedy any errors or variances early in the service lifecycle as this is considerably cheaper than fixing errors in production.
  • 54. 54 Scope • The service provider takes responsibility for delivering, operating and/or maintaining customer or service assets at specified levels of warranty, under a service agreement. • Service Validation and Testing can be applied throughout the service lifecycle to quality assure any aspect of a service and the service providers’ capability, resources and capacity to deliver a service and/or service release successfully. • Testing is equally applicable to in-house or developed services, hardware, software or knowledge-based services. • Testing directly supports the release and deployment process by ensuring that appropriate levels of testing are performed during the release, build and deployment activities. • It evaluates the detailed service models to ensure that they are fit for purpose and fit for use before being authorized to enter Service Operations, through the service catalogue. • The output from testing is used by the evaluation process to provide the information on whether the service is independently judged to be delivering the service performance with an acceptable risk profile.
  • 55. 55 Value to business • Service failures can harm the service provider’s business and the customer’s assets and result in outcomes such as loss of reputation, loss of money, loss of time, injury and death. • The key value to the business and customers from Service Testing and Validation is in terms of the established degree of confidence that a new or changed service will deliver the value and outcomes required of it and understanding the risks. • Successful testing depends on all parties understanding that it cannot give, indeed should not give, any guarantees but provides a measured degree of confidence. The required degree of confidence varies depending on the customer’s business requirements and pressures of an organization.
  • 56. 56 Policies, principles and basic concepts • Service Transition V-Model • Entry Criteria and Exit Criteria • User Acceptance Test
  • 58. 58 Entry Criteria and Exit Criteria • Effective validation and testing focuses on whether the service will deliver as required. • This is based on the perspective of those who will use, deliver, deploy, manage and operate the service. • The test entry and exit criteria are developed as the Service Design Package is developed. • These will cover all aspects of the service provision from different perspectives including: − Service Design – functional, management and operational − Technology design − Process design − Measurement design − Documentation − Skills and knowledge.
  • 59. 59 User Acceptance Test Use r te sting – applicatio n, syste m , se rvice • Testing is comprised of tests to determine whether the service meets the functional and quality requirements of the end users (customers) by executing defined business processes in an environment that, as closely as possible, simulates the live operational environment. This will include changes to the system or business process. • Full details of the scope and coverage will be defined in the user test and user acceptance test (UAT) plans. • The end users will test the functional requirements, establishing to the customer’s agreed degree of confidence that the service will deliver as they require. • They will also perform tests of the Service Management activities that they are involved with, e.g. ability to contact and use the service desk, response to diagnostics scripts, incident management, request fulfillment, change request management.
  • 60. © 2008 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Evaluation
  • 61. 61 Purpose/Goals/Objectives The purpose of evaluation is − To provide a consistent and standardized means of determining the performance of a service change in the context of existing and proposed services and IT infrastructure. The actual performance of a change is assessed against its predicted performance and any deviations between the two are understood and managed. The goal of evaluation is − To set stakeholder expectations correctly and provide effective and accurate information to Change Management to make sure changes that adversely affect service capability and introduce risk are not transitioned unchecked. The objective are to: − Evaluate the intended effects of a service change and as much of the unintended effects as is reasonably practical given capacity, resource and organizational constraints − Provide good quality outputs from the evaluation process so that Change Management can expedite an effective decision about whether a service change is to be approved or not.
  • 62. 62 Scope • Specifically in this section we consider the evaluation of new or changed services defined by Service Design, during deployment and before final transition to service operations. • The importance of evaluating the actual performance of any service change against its anticipated performance is an important source of information to service providers to help ensure that expectations set are realistic and to identify that if there are any reasons that production performance does not meet what was expected.
  • 63. 63 Value to business • Evaluation is, by its very nature, concerned with value. Specifically effective evaluation will establish the use made of resources in terms of delivered benefit and this information will allow a more accurate focus on value in future service development and Change Management. • There is a great deal of intelligence that Continual Service Improvement can take from evaluation to analyze future improvements to the process of change and the predictions and measurement of service change performance.
  • 64. 64 Policies, principles and basic concepts • Policies − The following policies apply to the evaluation process: − Service Designs or service changes will be evaluated before being transitioned. − Any deviation between predicted and actual performance will be managed by the customer or customer representative by accepting the change even though actual performance is different to what was predicted; rejecting the change; or requiring a new change to be implemented with revised predicted performance agreed in advance. No other outcomes of evaluation are allowed. − An evaluation shall not be performed without a customer engagement package. • Principles − The following principles shall guide the execution evaluation process: − As far as is reasonably practical, the unintended as well as the intended effects of a change need to be identified and their consequences understood and considered. − A service change will be fairly, consistently, openly and, wherever possible, objectively evaluated. • Basic Concepts − The evaluation process uses the Plan–Do–Check–Act (PDCA) model to ensure consistency across all evaluations.
  • 66. © 2008 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Knowledge Management
  • 67. 67 Knowledge Management (KM) • “The process responsible for gathering, analyzing, storing and sharing knowledge and information within an organization. • The primary purpose of Knowledge Management is to improve efficiency by reducing the need to rediscover knowledge.”
  • 68. 68 Purpose/Goals/Objectives The purpose of Knowledge Management is: − To ensure that the right information is delivered to the appropriate place or competent person at the right time to enable informed decision. The goal of Knowledge Management is − To enable organizations to improve the quality of management decision making by ensuring that reliable and secure information and data is available throughout the service lifecycle. The objectives of Knowledge Management include: − Enabling the service provider to be more efficient and improve quality of service, increase satisfaction and reduce the cost of service − Ensuring staff have a clear and common understanding of the value that their services provide to customers and the ways in which benefits are realized from the use of those services − Ensuring that, at a given time and location, service provider staff have adequate information on: • Who is currently using their services • The current states of consumption • Service delivery constraints • Difficulties faced by the customer in fully realizing the benefits expected from the service.
  • 69. 69 Scope • Knowledge Management is a whole lifecycle-wide process in that it is relevant to all lifecycle sectors and hence is referenced throughout ITIL from the perspective of each publication. • It is dealt with to some degree within other ITIL publications but this chapter sets out the basic concept, from a Service Transition focus
  • 70. 70 Value to business • Knowledge Management is especially significant within Service Transition since relevant and appropriate knowledge is one of the key service elements being transitioned. • Examples where successful transition rests on appropriate Knowledge Management include: − User, service desk, support staff and supplier understanding of the new or changed service, including knowledge of errors signed off before deployment, to facilitate their roles within that service − Awareness of the use of the service, and the discontinuation of previous versions − Establishment of the acceptable risk and confidence levels associated with the transition, e.g. measuring, understanding and acting correctly on results of testing and other assurance results. − Effective Knowledge Management is a powerful asset for people in all roles across all stages of the service lifecycle. It is an excellent method for individuals and teams to share data, information and knowledge about all facets of an IT service. The creation of a single system for Knowledge Management is recommended.
  • 71. 71 Policies, principles and basic concepts • Knowledge Management is typically displayed within the Data–to– Information–to–Knowledge–to–Wisdom (DIKW) structure. The use of these terms is set out below. • Data is a set of discrete facts about events. Most organizations capture significant amounts of data in highly structured databases such as Service Management and Configuration Management tools/systems and databases. • The key Knowledge Management activities around data are the ability to: − Capture accurate data − Analyze, synthesize, and then transform the data into information − Identify relevant data and concentrate resources on its capture.
  • 72. 72 D-I-K-W Structure • Information comes from providing context to data. Information is typically stored in semi-structured content such as documents, e-mail, and multimedia. • The key Knowledge Management activity around information is managing the content in a way that makes it easy to capture, query, find, re-use and learn from experiences so that mistakes are not repeated and work is not duplicated. • Knowledge is composed of the tacit experiences, ideas, insights, values and judgments of individuals. People gain knowledge both from their own and from their peers’ expertise, as well as from the analysis of information (and data). Through the synthesis of these elements, new knowledge is created. • Knowledge is dynamic and context based. Knowledge puts information into an ‘ease of use’ form, which can facilitate decision making. In Service Transition this knowledge is not solely based on the transition in progress, but is gathered from experience of previous transitions, awareness of recent and anticipated changes and other areas that experienced staff will have been unconsciously collecting for some time. • Wisdom gives the ultimate discernment of the material and having the application and contextual awareness to provide a strong common sense judgment
  • 73. 73 Data, Information, Knowledge and Wisdom (DIKW) Context Understanding Wisdom Knowledg e Information Data

Editor's Notes

  • #3: Purpose: Key Message: Additional Information: N/A Transition to Next Slide:
  • #4: Purpose: Key Message: Using a model such as the V-Model builds in service validation and testing early in the service life cycle. It provides a framework to organize the levels of configuration items to be managed through the life cycle and the associated validation and testing activities both within and across stages. The level of test is derived from the way a system is designed and built up. This is known as a “V” model, which maps the types of test to each stage of development. The V-model provides one example of how the service transition levels of testing can be matched to corresponding stages of service requirements and design. The left-hand side represents the specification of the service requirements down to the detailed service design. The right-hand side focuses on the validation activities that are performed against the specifications defined on the left-hand side. At each stage on the left hand side, there is direct involvement by the equivalent party on the right hand side. It shows that service validation and acceptance test planning should start with the definition of the service requirements. For example, customers who sign off the agreed service requirements will also sign off the service acceptance criteria and test plan. Additional Information: N/A Transition to Next Slide:
  • #5: Purpose: Key Message: A configuration item (CI) is an asset, service component or other item that is, or will be, under the control of Configuration Management. Configuration items may vary widely in complexity, size and type, ranging from an entire service or system including all hardware, software, documentation and support staff to a single software module or a minor hardware component. Configuration items may be grouped and managed together, e.g. a set of components may be grouped into a release. Configuration items should be selected using established selection criteria, grouped, classified and identified in such a way that they are manageable and traceable throughout the service lifecycle. Additional Information: N/A Transition to Next Slide:
  • #6: Purpose: Key Message: To manage large and complex IT services and infrastructures, Service Asset and Configuration Management 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 a for 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 processes reporting outside of 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. Many organizations are already using some elements of SACM, often maintaining records in documents, spreadsheets or local databases, and some of these may be used in the overall CMS. Automated processes to load and update the Configuration Management database should be developed where possible so as to reduce errors and optimize costs. Discovery tools, inventory and audit tools, enterprise systems and network management tools can be interfaced to the CMS. These tools can be used initially to populate a CMDB, and subsequently to compare the actual ‘live’ configuration with the information and records stored in the CMS. Additional Information: N/A Transition to Next Slide:
  • #14: Purpose: There is a big difference between V2 and V3. In Version 2, we used to say minimize risk but in ITIL V3 we consider the cost to the business and the value to the business of risk treatments and we optimize these to achieve the best business outcome for the money. Key Message: The purpose of the Change Management process is to ensure that: Standardized methods and procedures are used for efficient and prompt handling of all changes All changes to service assets and configuration items are recorded in the Configuration Management System Overall business risk is optimized. The goals of Change Management are to: Respond to the customer’s changing business requirements while maximizing 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. The objective of the Change Management process is to ensure that changes are recorded and then evaluated, authorized, prioritized, planned, tested, implemented, documented and reviewed in a controlled manner. Additional Information: N/A Transition to Next Slide:
  • #15: Purpose: Change can be defined in many ways. The definition of a service change is: “ The addition, modification or removal of authorized, planned or supported service or service component and its associated documentation” Key Message: The scope of Change Management covers changes to baselined service assets and configuration items across the whole service lifecycle. Each organization should define the changes that lie outside the scope of their service change process. Typically these might include: Changes with significantly wider impacts than service changes, e.g. departmental organization, policies and business operations – these changes would produce RFCs to generate consequential service changes Changes at an operational level such as repair to printers or other routine service components. Additional Information: N/A Transition to Next Slide:
  • #16: Purpose: Key Message: The figure shows a typical scope for the service Change Management process for an IT department and how it interfaces with the business and suppliers at strategic, tactical and operational levels. It covers interfaces to internal and external service providers where there are shared assets and configuration items that need to be under Change Management. Service Change Management must interface with business Change Management (to the left in the figure), and with the supplier’s Change Management (to the right in the figure). This may be an external supplier with a formal Change Management system, or with the project change mechanisms within an internal development project. The Service Portfolio provides a clear definition of all current, planned and retired services. Understanding the Service Portfolio helps all parties involved in the Service Transition to understand the potential impact of the new or changed service on current services and other new or changed services. Strategic changes are brought in via Service Strategy and the business relationship management processes. Changes to a service will be brought in via Service Design, Continual Service Improvement and the service level management process. Corrective change, resolving errors detected in services, will be initiated from Service Operations, and may route via support or external suppliers into a formal RFC. Exclusions This chapter does not cover strategic planning for business transformation or organizational change although the interfaces to these processes do need to be managed. Additional Information: N/A Transition to Next Slide:
  • #17: Purpose: Key Message: 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 maximizing service availability Reducing the Mean Time to Restore Service (MTRS), via quicker and more successful implementations of corrective changes Liaising with the business change process to identify opportunities for business improvement. Additional Information: N/A Transition to Next Slide:
  • #18: Purpose: Key Message: A change request is a formal communication seeking an alteration to one or more configuration items. This could take several forms, e.g. ‘Request for Change’ document, service desk call, Project Initiation Document. Different types of change may require different types of change request. An organization needs to ensure that appropriate procedures and forms are available to cover the anticipated requests. Avoiding a bureaucratic approach to documenting a minor change removes some of the cultural barriers to adopting the Change Management process. STANDARD CHANGE A standard change is a change to a service or infrastructure for which the approach is pre-authorized by Change Management that has an accepted and established procedure to provide a specific change requirement. Examples might include an upgrade of a PC in order to make use of specific standard and pre-budgeted software, new starters within an organization, or a desktop move for a single user. Other examples include low impact, routine application change to handle seasonal variation. Approval of each occurrence of a standard change will be granted by the delegated authority for that standard change, e.g. by the budget holding customer for installation of software from an approved list on a PC registered to their organizational unit or by the third party engineer for replacement of a faulty desktop printer. The crucial elements of a standard change are that: There is a defined trigger to initiate the RFC The tasks are well known, documented and proven Authority is effectively given in advance Budgetary approval will typically be preordained or within the control of the change requester The risk is usually low and always well understood. Once the approach to manage standard changes has been agreed, standard change processes and associated change workflows should be developed and communicated. A change model would normally be associated with each standard change to ensure consistency of approach. Standard changes should be identified early on when building the Change Management process to promote efficiency. Otherwise, a Change Management implementation can create unnecessarily high levels of administration and resistance to the Change Management process. All changes, including standard changes, will have details of the change recorded. For some standard changes this may be different in nature from normal change records. Some standard changes to configuration items may be tracked on the asset or configuration item lifecycle, particularly where there is a comprehensive CMS that provides reports of changes, their current status, the related configuration items and the status of the related CI versions. In these cases the Change and Configuration Management reporting is integrated and Change Management can have ‘oversight’ of all changes to service CIs and release CIs. Some standard changes will be triggered by the request fulfillment process and be directly recorded and passed for action by the service desk. EMERGENCY CHANGES Emergency changes are sometimes required and should be designed carefully and tested before use or the impact of the emergency change may be greater than the original incident. Emergency changes may document some details retrospectively. The number of emergency changes proposed should be kept to an absolute minimum, because they are generally more disruptive and prone to failure. All changes likely to be required should, in general, be foreseen and planned, bearing in mind the availability of resources to build and test the changes. Nevertheless, occasions will occur when emergency changes are essential and so procedures should be devised to deal with them quickly, without sacrificing normal management controls. Emergency change is reserved for changes intended to repair an error in an IT service that is negatively impacting the business to a high degree. Changes intended to introduce immediately required business improvements are handled as normal changes, assessed as having the highest urgency. Defined authorization levels will exist for an emergency change, and the levels of delegated authority must be clearly documented and understood. In an emergency situation it may not be possible to convene a full CAB meeting. Where CAB approval is required, this will be provided by the Emergency CAB (ECAB). Not all emergency changes will require the ECAB involvement; many may be predictable both in occurrence and resolution and well understood changes available, with authority delegated, e.g. to Operations teams who will action, document and report on the emergency change. Additional Information: N/A Transition to Next Slide:
  • #19: Purpose: Key Message: Additional Information: N/A Transition to Next Slide:
  • #21: Purpose: Key Message: Additional Information: N/A Transition to Next Slide:
  • #22: Purpose: Key Message: Additional Information: N/A Transition to Next Slide:
  • #23: Purpose: Key Message: Additional Information: N/A Transition to Next Slide:
  • #24: Purpose: Key Message: Additional Information: N/A Transition to Next Slide:
  • #25: Purpose: Key Message: Additional Information: N/A Transition to Next Slide:
  • #26: Purpose: Key Message: Additional Information: N/A Transition to Next Slide:
  • #28: Purpose: The objective is to define and control the components of services and infrastructure and maintain accurate configuration records. This enables an organization to comply with corporate governance requirements, control its asset base, optimize its costs, manage change and releases effectively, and resolve incidents and problems faster. Key Message: Additional Information: N/A Transition to Next Slide:
  • #29: Purpose: Key Message: Additional Information: N/A Transition to Next Slide:
  • #31: Purpose: Key Message: There will be a variety of CIs; the following categories may help to identify them. Service lifecycle CIs such as the Business Case, Service Management Plans, service lifecycle plans, Service Design Package, release and change plans, and test plans. They provide a picture of the service provider’s services, how these services will be delivered, what benefits are expected, at what cost, and when they will be realized. Service CIs such as: Service capability assets: management, organization, processes, knowledge, people Service resource assets: financial capital, systems, applications, information, data, infrastructure and facilities, financial capital, people Service model Service package Release package Service acceptance criteria. Organization CIs – Some documentation will define the characteristics of a CI whereas other documentation will be a CI in its own right and need to be controlled, e.g. the organization’s business strategy or other policies that are internal to the organization but independent of the service provider. Regulatory or statutory requirements also form external products that need to be tracked, as do products shared between more than one group. 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 sub-contractors and external services. Interface CIs that are required to deliver the end-toend service across a service provider interface (SPI). Additional Information: N/A Transition to Next Slide:
  • #32: Purpose: Key Message: Additional Information: N/A Transition to Next Slide:
  • #35: Purpose: Key Message: This library may in reality consist of one or more software libraries or file-storage areas, separate from development, test or live file-store areas. It contains the master copies of all controlled 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 of controlled documentation for a system are also stored in the DML in electronic form. The DML will also include a physical store to hold master copies, e.g. a fireproof safe. Only authorized media should be accepted into the DML, strictly controlled by SACM. The DML is a foundation for Release and Deployment Management Additional Information: N/A Transition to Next Slide:
  • #38: Purpose: Key Message: Additional Information: N/A Transition to Next Slide:
  • #40: Purpose: Key Message: Additional Information: N/A Transition to Next Slide:
  • #41: Purpose: Key Message: Additional Information: N/A Transition to Next Slide:
  • #42: Purpose: Key Message: Additional Information: N/A Transition to Next Slide:
  • #45: Purpose: Key Message: Additional Information: N/A Transition to Next Slide:
  • #46: Purpose: Key Message: Additional Information: N/A Transition to Next Slide:
  • #48: Purpose: Key Message: In order to deploy via ‘push’ approach, the data on all user locations must be available. Pull approaches do not rest so heavily on accurate configuration data and they can trigger an update to user records. This may be through new users appearing and requesting downloads or expected users not doing so, triggering investigation into their continued existence. As some users will never ‘pull’ a release it may be appropriate to allow a ‘pull’ within a specified time limit and if this is exceeded a push will be forced, e.g. for an anti-virus update. Additional Information: N/A Transition to Next Slide:
  • #50: Purpose: Key Message: Additional Information: N/A Transition to Next Slide:
  • #51: Purpose: Key Message: Additional Information: N/A Transition to Next Slide:
  • #52: Purpose: Key Message: Additional Information: N/A Transition to Next Slide:
  • #55: Purpose: Key Message: The service provider takes responsibility for delivering, operating and/or maintaining customer or service assets at specified levels of warranty, under a service agreement. Service Validation and Testing can be applied throughout the service lifecycle to quality assure any aspect of a service and the service providers’ capability, resources and capacity to deliver a service and/or service release successfully. In order to validate and test an end-to-end service the interfaces to suppliers, customers and partners are important. Service provider interface definitions define the boundaries of the service to be tested, e.g. process interfaces and organizational interfaces. Testing is equally applicable to in-house or developed services, hardware, software or knowledge-based services. It includes the testing of new or changed services or service components and examines the behavior of these in the target business unit, service unit, deployment group or environment. This environment could have aspects outside the control of the service provider, e.g. public networks, user skill levels or customer assets. Testing directly supports the release and deployment process by ensuring that appropriate levels of testing are performed during the release, build and deployment activities. It evaluates the detailed service models to ensure that they are fit for purpose and fit for use before being authorized to enter Service Operations, through the service catalogue. The output from testing is used by the evaluation process to provide the information on whether the service is independently judged to be delivering the service performance with an acceptable risk profile. Additional Information: N/A Transition to Next Slide:
  • #58: Purpose: Key Message: Using a model such as the V-Model builds in service validation and testing early in the service life cycle. It provides a framework to organize the levels of configuration items to be managed through the life cycle and the associated validation and testing activities both within and across stages. The level of test is derived from the way a system is designed and built up. This is known as a “V” model, which maps the types of test to each stage of development. The V-model provides one example of how the service transition levels of testing can be matched to corresponding stages of service requirements and design. The left-hand side represents the specification of the service requirements down to the detailed service design. The right-hand side focuses on the validation activities that are performed against the specifications defined on the left-hand side. At each stage on the left hand side, there is direct involvement by the equivalent party on the right hand side. It shows that service validation and acceptance test planning should start with the definition of the service requirements. For example, customers who sign off the agreed service requirements will also sign off the service acceptance criteria and test plan. Additional Information: N/A Transition to Next Slide:
  • #68: Purpose: Key Message: Additional Information: N/A Transition to Next Slide:
  • #74: Purpose: Key Message: Additional Information: N/A Transition to Next Slide:
  • #76: Purpose: Key Message: Additional Information: N/A Transition to Next Slide: