V3 Service Transition Finbarr Callan Lecturer, Best Practice
V3 Service Transition : Agenda Key Elements of Transition Processes –  Service Asset & Configuration Management Change Management Release and Deployment Management Knowledge Management Evaluation & Testing Questions
Service Lifecycle Components
Purpose and Goals Provide  guidance on the development and improvement of capabilities  for transitioning new and changed services into operations Set customer  expectations Enable  integration Reduce  performance variation Reduce  known errors  and minimize risk Ensure proper use of services Service Transition
Service Transition Scope Management and co-ordination of the processes, systems and functions to package, build, test and deploy a release into production, and  establish the service specified in the customer and stakeholder requirements Objectives Provide clear and comprehensive plans Plan and manage the resources Increase satisfaction Increase use of services
Service Transition : Scope © Crown Copyright 2007.  Reproduced with permission from OGC
It enables the service provider to: Handle  high volumes  of change and releases across its customer base Align  the new or changed service with the customer’s business requirements and business operations Ensure that customers and users can use the new or changed service in a way that  maximizes value  to the business operations Value to the Business
Business Value   Adaptability Mergers & Acquisitions Successful Change Service  Predictability Compliance Productivity Contract  Management Risk  Management
Define Transition Policy All changes  made through Change/Service Transition Common  process framework Align with organization  process/re-use Align with  business requirements Relationship and  expectation management Effective  knowledge transfer Planning and  design Manage  resources Handle  corrections Meet  quality  needs Fundamental Principles
Fundamental Principles Define Release Policy Roles and Responsibilities Naming/numbering/identification for release types Frequency of release Grouping changes into releases Automation Baselining Acceptance criteria ELS – end/handover to operations
Common Operations Communications Strategy and planning Methods Organizational Change DRAC  ( D enial/ R ejection/ A cceptance/ C ommitment) curve – how do you overcome it? Necessity/Vision/Plan/Resources/Competence Culture Stakeholder Management
Shock Rejection Experiment Commitment Time The Denial Curve & Cultural Change
Service Transition : Processes Transition Strategy, Planning and Support  Knowledge Management Change Management Service Asset and Configuration Management Release and Deployment Management Service Testing and Verification Evaluation
Transition Planning Scope Value to the business Basic concepts Activities/techniques Challenges
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 decisions . Knowledge Management
DIKW Model © Crown Copyright 2007.  Reproduced with permission from OGC
Managing Knowledge © Crown Copyright 2007.  Reproduced with permission from OGC
Knowledge Management
Knowledge Management
Service Asset and Configuration Management
Managing Knowledge © Crown Copyright 2007.  Reproduced with permission from OGC
Service Asset & Configuration Management Objectives  To  define and control  the components of services and infrastructure, and  maintain accurate configuration records  allowing: Compliance with corporate  governance Control of  asset base Cost  optimization Effective change and release management Faster incident and problem  resolution
Key Concepts Configuration items (CIs) Categories Levels Naming Labels Attributes Configuration Management System (CMS) Baselines Service Asset & Configuration Management
Service Asset & Configuration Management A Configuration Item (CI) is an asset, service component or other item which is, or will be, under the control of configuration management. Configuration Items CI Categories: Service lifecycle CIs, e.g. plans, business case, SDP Service CIs - Capability assets, e.g. people, knowledge resource assets, e.g. systems, data models and packages Organization CIs Internal CIs External CIs
Asset and Configuration Management
Asset and Configuration Management
Asset and Configuration Management
Change Management
Change Management Objective and Scope To ensure that changes are: Recorded, evaluated, authorized, prioritized, planned, tested, implemented, documented and reviewed  in a controlled manner Changes to base-lined service assets and configuration items  across the service lifecycle
Change types : Normal  – requires full assessment and authorization Standard  – pre-authorized by change management  Emergency  – rapid response to a business affecting situation Service Change Definition The addition, modification or removal of any authorized, planned or supported service or service component and its associated documentation Change Management : Concepts
Change Management : Normal Change Process © Crown Copyright 2007.  Reproduced with permission from OGC
Change Management Standard Change Elements  Defined trigger Tasks are well-known, documented and proven Authority  is effectively given in advance Budgetary  approval pre-ordained or within control of requestor Risk  – usually low; always well understood
Change Management : Assessing Impact The 7 “Rs” Who  RAISED  the change? What is the  REASON  for it? What is  RETURN   required? What are the  RISKS  involved? What  RESOURCES   are required to deliver it? Who is  RESPONSIBLE  for build, test and implementation? What is the  RELATIONSHIP  with other changes?
Change Management : Challenges The spread of those affected  Balancing risk  and  need Stability vs responsiveness Balancing  control  and  bureaucracy Culture Using the right  measurements
Change Management
Change Management
Change Management
Release and Deployment Management
Release and Deployment : Objectives Clear and comprehensive plans  enabling change projects to align their activities Release packages  can be built, installed, tested and deployed efficiently New or changed services meet the  utility, warranty and service levels Ensure  knowledge transfer  enabling full utilization by the consumer Ensure knowledge and skills transfer to  support staff  enabling full delivery and support of the service Minimize unpredicted impact Satisfied customers and users
Release and Deployment  Management Scope Value to the business Basic concepts  Release Unit :  a portion of a service or infrastructure that is normally released together Release Package:  a single release unit or a structured set of release units Activities/techniques Challenges
Release and Deployment Management © Crown Copyright 2007.  Reproduced with permission from OGC
CMS and Deployment © Crown Copyright 2007.  Reproduced with permission from OGC
Release Options Big-bang  – to all users at once Phased  – partial then scheduled roll-out - Incremental changes to all users - Unit by unit - Element by element - Combinations of these Push  versus  pull Automation  versus  manual Release and Deployment Management
Release and Deployment Management
The V Model   © Crown Copyright 2007.  Reproduced with permission from OGC
Validation and Testing Scope Value to the business Basic concepts Activities/techniques Challenges Evaluation Scope Value to the business Basic concepts Activities/techniques Challenges Validation and Testing / Evaluation
Evaluation and Testing
Roles and Responsibilities Service Owner Service Transition Manager Service Asset Manager Configuration Manager/Analyst Change Authority Change Manager CAB/ECAB
Service Lifecycle Components
Any Questions [email_address] www.axiossystems.com Further Resources V3 Service Strategy and Service Design Webinars  – now available onDemand. V2 versus V3 White Paper and Webinar -  on  Axios website. ITIL V3 Quick Reference Guide  – pocket guide & poster ITSM: IT Transforms Itself into a Service .   Aberdeen Group Research. Available to download, along with a complementary onDemand  Webinar  on the Axios website.  ITIL V3: The Future is Here White Paper,  authored by Sharon Taylor, Chief Architect of ITIL V3. A  Webinar  by Sharon Taylor is also available onDemand. Both are available for download from the Axios website.

ITIL Practical Guide - Service Transition

  • 1.
    V3 Service TransitionFinbarr Callan Lecturer, Best Practice
  • 2.
    V3 Service Transition: Agenda Key Elements of Transition Processes – Service Asset & Configuration Management Change Management Release and Deployment Management Knowledge Management Evaluation & Testing Questions
  • 3.
  • 4.
    Purpose and GoalsProvide guidance on the development and improvement of capabilities for transitioning new and changed services into operations Set customer expectations Enable integration Reduce performance variation Reduce known errors and minimize risk Ensure proper use of services Service Transition
  • 5.
    Service Transition ScopeManagement and co-ordination of the processes, systems and functions to package, build, test and deploy a release into production, and establish the service specified in the customer and stakeholder requirements Objectives Provide clear and comprehensive plans Plan and manage the resources Increase satisfaction Increase use of services
  • 6.
    Service Transition :Scope © Crown Copyright 2007. Reproduced with permission from OGC
  • 7.
    It enables theservice provider to: Handle high volumes of change and releases across its customer base Align the new or changed service with the customer’s business requirements and business operations Ensure that customers and users can use the new or changed service in a way that maximizes value to the business operations Value to the Business
  • 8.
    Business Value Adaptability Mergers & Acquisitions Successful Change Service Predictability Compliance Productivity Contract Management Risk Management
  • 9.
    Define Transition PolicyAll changes made through Change/Service Transition Common process framework Align with organization process/re-use Align with business requirements Relationship and expectation management Effective knowledge transfer Planning and design Manage resources Handle corrections Meet quality needs Fundamental Principles
  • 10.
    Fundamental Principles DefineRelease Policy Roles and Responsibilities Naming/numbering/identification for release types Frequency of release Grouping changes into releases Automation Baselining Acceptance criteria ELS – end/handover to operations
  • 11.
    Common Operations CommunicationsStrategy and planning Methods Organizational Change DRAC ( D enial/ R ejection/ A cceptance/ C ommitment) curve – how do you overcome it? Necessity/Vision/Plan/Resources/Competence Culture Stakeholder Management
  • 12.
    Shock Rejection ExperimentCommitment Time The Denial Curve & Cultural Change
  • 13.
    Service Transition :Processes Transition Strategy, Planning and Support Knowledge Management Change Management Service Asset and Configuration Management Release and Deployment Management Service Testing and Verification Evaluation
  • 14.
    Transition Planning ScopeValue to the business Basic concepts Activities/techniques Challenges
  • 15.
    The purpose ofKnowledge Management is to ensure that the right information is delivered to the appropriate place or competent person at the right time to enable informed decisions . Knowledge Management
  • 16.
    DIKW Model ©Crown Copyright 2007. Reproduced with permission from OGC
  • 17.
    Managing Knowledge ©Crown Copyright 2007. Reproduced with permission from OGC
  • 18.
  • 19.
  • 20.
    Service Asset andConfiguration Management
  • 21.
    Managing Knowledge ©Crown Copyright 2007. Reproduced with permission from OGC
  • 22.
    Service Asset &Configuration Management Objectives To define and control the components of services and infrastructure, and maintain accurate configuration records allowing: Compliance with corporate governance Control of asset base Cost optimization Effective change and release management Faster incident and problem resolution
  • 23.
    Key Concepts Configurationitems (CIs) Categories Levels Naming Labels Attributes Configuration Management System (CMS) Baselines Service Asset & Configuration Management
  • 24.
    Service Asset &Configuration Management A Configuration Item (CI) is an asset, service component or other item which is, or will be, under the control of configuration management. Configuration Items CI Categories: Service lifecycle CIs, e.g. plans, business case, SDP Service CIs - Capability assets, e.g. people, knowledge resource assets, e.g. systems, data models and packages Organization CIs Internal CIs External CIs
  • 25.
  • 26.
  • 27.
  • 28.
  • 29.
    Change Management Objectiveand Scope To ensure that changes are: Recorded, evaluated, authorized, prioritized, planned, tested, implemented, documented and reviewed in a controlled manner Changes to base-lined service assets and configuration items across the service lifecycle
  • 30.
    Change types :Normal – requires full assessment and authorization Standard – pre-authorized by change management Emergency – rapid response to a business affecting situation Service Change Definition The addition, modification or removal of any authorized, planned or supported service or service component and its associated documentation Change Management : Concepts
  • 31.
    Change Management :Normal Change Process © Crown Copyright 2007. Reproduced with permission from OGC
  • 32.
    Change Management StandardChange Elements Defined trigger Tasks are well-known, documented and proven Authority is effectively given in advance Budgetary approval pre-ordained or within control of requestor Risk – usually low; always well understood
  • 33.
    Change Management :Assessing Impact The 7 “Rs” Who RAISED the change? What is the REASON for it? What is RETURN required? What are the RISKS involved? What RESOURCES are required to deliver it? Who is RESPONSIBLE for build, test and implementation? What is the RELATIONSHIP with other changes?
  • 34.
    Change Management :Challenges The spread of those affected Balancing risk and need Stability vs responsiveness Balancing control and bureaucracy Culture Using the right measurements
  • 35.
  • 36.
  • 37.
  • 38.
  • 39.
    Release and Deployment: Objectives Clear and comprehensive plans enabling change projects to align their activities Release packages can be built, installed, tested and deployed efficiently New or changed services meet the utility, warranty and service levels Ensure knowledge transfer enabling full utilization by the consumer Ensure knowledge and skills transfer to support staff enabling full delivery and support of the service Minimize unpredicted impact Satisfied customers and users
  • 40.
    Release and Deployment Management Scope Value to the business Basic concepts Release Unit : a portion of a service or infrastructure that is normally released together Release Package: a single release unit or a structured set of release units Activities/techniques Challenges
  • 41.
    Release and DeploymentManagement © Crown Copyright 2007. Reproduced with permission from OGC
  • 42.
    CMS and Deployment© Crown Copyright 2007. Reproduced with permission from OGC
  • 43.
    Release Options Big-bang – to all users at once Phased – partial then scheduled roll-out - Incremental changes to all users - Unit by unit - Element by element - Combinations of these Push versus pull Automation versus manual Release and Deployment Management
  • 44.
  • 45.
    The V Model © Crown Copyright 2007. Reproduced with permission from OGC
  • 46.
    Validation and TestingScope Value to the business Basic concepts Activities/techniques Challenges Evaluation Scope Value to the business Basic concepts Activities/techniques Challenges Validation and Testing / Evaluation
  • 47.
  • 48.
    Roles and ResponsibilitiesService Owner Service Transition Manager Service Asset Manager Configuration Manager/Analyst Change Authority Change Manager CAB/ECAB
  • 49.
  • 50.
    Any Questions [email_address]www.axiossystems.com Further Resources V3 Service Strategy and Service Design Webinars – now available onDemand. V2 versus V3 White Paper and Webinar - on Axios website. ITIL V3 Quick Reference Guide – pocket guide & poster ITSM: IT Transforms Itself into a Service . Aberdeen Group Research. Available to download, along with a complementary onDemand Webinar on the Axios website. ITIL V3: The Future is Here White Paper, authored by Sharon Taylor, Chief Architect of ITIL V3. A Webinar by Sharon Taylor is also available onDemand. Both are available for download from the Axios website.

Editor's Notes

  • #4 The Service Portfolio acts as “the spine” of the service lifecycle. It is the single integrated source of information on the status of each service together with other service details and the interfaces and dependencies between services. The information within the Service Portfolio is used by the activities within each stage of the service lifecycle. SERVICE STRATEGY – Looks at the Capabilities and Constraints This slide demonstrates the SPINE of all this is the SERVICE PORTFOLIO
  • #5 Intentionally blank page to be completed by Training Provider with additional information if desired
  • #6 ST: Objectives Provide clear and comprehensive plans that enable the customer and business change projects to align their activities with the Service Transition plans. Plan and manage the resources to establish successfully a new or changed service into production within the predicted cost, quality and time estimates Ensure there is minimal unpredicted impact on the production services, operations and support organisation Increase the customer, user and service management staff satisfaction with the Service Transition practices including deployment of the new or changed service, communications, release documentation, training and knowledge transfer Increase proper use of the services and underlying applications and technology solutions
  • #7 Intentionally blank page to be completed by Training Provider with additional information if desired
  • #8 And it therefore adds value to the business by improving the: Competitive edge – Ability to adapt quickly to new requirements and market developments Management of mergers, de-mergers, acquisitions, transfer of services Success rate of changes and releases for the business Predictions of service levels and warranties for new / changed services Confidence in the degree of compliance with business and governance requirements during change Variation of actual against estimated and approved resource plans and budgets Productivity of business and customer staff because of better planning and use of new and changed services Timely cancellation or changes to maintenance contracts for hardware and software when components are disposed or de-commissioned Understanding of the level of risk during and after change, e.g. service outage, disruption and re-work
  • #10 P25-31/ST
  • #11 P36 - ST
  • #14 Transition Strategy – see word doc. P38/39 in book.
  • #15 P.35+/ST book. Para 4.1 +
  • #16 The ability of an organisation (or individuals within it) to respond properly and effectively depends upon information being available in the right place, format and at the right time to enable it to be used for making relevant decisions. In the past much information was locked away within individuals. By recording more data and providing engines for searching, manipulating and presenting that data, the individual’s personal knowledge can be enhanced. The next slide illustrates a common model used for expressing the progression from Data to Wisdom
  • #17 The Data–Information–Knowledge–Wisdom structure Knowledge management is typically displayed within the Data–Information–Knowledge–Wisdom (DIKW) structure. The use of these terms is set out below. Data is a set of discrete facts about events. Most organisations 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 Analyse, synthesize, and then transform the data into information Identify relevant data and concentrate resources on its capture. 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, reuse 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 judgements 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 judgement. Data – quantitative collection of details e.g. number of Incidents Information – derives additional facts by processing data e.g. number of priority 1 Incidents occurring after year end processing Knowledge – uses information but includes an extra dimension from experience Wisdom – making correct decisions and judgements
  • #18 Diag. 4.39; p. 151 ST – spot the difference! This slide illustrates (in a simplified manner) how we can hold, manipulate and present information in a Knowledge Management system. The value of an SKMS depends to a large degree on the quantity and quality of data held in the various repositories that together represent the data and information sources. They will include structured and unstructured data. The Configuration Management System (CMS) will hold details of all the components of the IT Infrastructure and the relationships between them. In many cases it is the relationship information that will assist us most, since it will enable many of the other service management processes. Key components of the CMS are the Configuration Management Database (CMDB) of which there may be more than one physical instance that is linked with others to provide a Federated CMDB. The CMDB holds information about the logical components. The Definitive Media Libraries (DML) hold physical copies of items such as software, licences, etc. As the name implies, these are the master copies. Organisations may choose to link any other data/information to the CMS if it is decided that it will provide value. In such cases, the data is not normally replicated but linked to the CMS. Let us now look in more detail at the CMS and CMDB and the process of Service Asset and Configuration Management.
  • #19 Knowledge Base (Suggestions at point of logging)
  • #20 Knowledge Search
  • #21 Header slide
  • #22 Diag 4.8 ST. P68 This slide illustrates (in a simplified manner) how we can hold, manipulate and present information in a Knowledge Management system. The value of an SKMS depends to a large degree on the quantity and quality of data held in the various repositories that together represent the data and information sources. They will include structured and unstructured data. The Configuration Management System (CMS) will hold details of all the components of the IT Infrastructure and the relationships between them. In many cases it is the relationship information that will assist us most, since it will enable many of the other service management processes. Key components of the CMS are the Configuration Management Database (CMDB) of which there may be more than one physical instance that is linked with others to provide a Federated CMDB. The CMDB holds information about the logical components. The Definitive Media Libraries (DML) hold physical copies of items such as software, licences, etc. As the name implies, these are the master copies. Organisations may choose to link any other data/information to the CMS if it is decided that it will provide value. In such cases, the data is not normally replicated but linked to the CMS. Let us now look in more detail at the CMS and CMDB and the process of Service Asset and Configuration Management.
  • #23 The slide describes the objectives of Service Asset and Configuration Management The purpose of SAandCM is to: Protect the integrity of service assets and configuration items (CI) Place IT assets and designated CIs under configuration management Ensure the integrity of assets and configurations by maintaining a complete Configuration Management System (CMS) Support processes through accurate information The goal of SAandCM is to provide a logical model of the IT infrastructure correlating IT services and IT components (physical, logical, etc) needed to deliver these services.
  • #24 Intentionally blank page to be completed by Training Provider with additional information if desired
  • #25 Included in the Lifecycle CIs are: Service management plans, release and change plans, test plans, Organisation CIs include strategy and internal policies Internal CIs include tangible and intangible assets such as software for individual projects External CIs include external customer agreements, releases for suppliers or sub-contractors.
  • #26 Server Asset details
  • #27 Sage Payroll Service To show what other assets could be effected if sage is down (if there are any other open incidents against the assets, etc.)
  • #28 Detail all / specific assets within service catalog Item Selection – Service Catalog – Technical Services
  • #29 Header slide
  • #30 Some changes will lie outside the scope of Change Management. These may be wider organisational and/or business changes, that would give rise to RFCs that relate to services. At the opposite end of the scale, operational changes, such as printer repairs, may be deemed outside the scope.
  • #31 Normal changes include requests such as: change to service portfolios Change to a service or service definition Project change proposal User access request Operational activity Standard changes are those where the approach is pre-authorised by change management since it has an accepted and established procedure that can be followed to satisfy a specific change requirement. They will usually be associated with Change Models. Key aspects of standard changes are: Defined trigger Tasks are well-known, proven and documented Advance authority is effectively given Budgetary approval is either preauthorised or within the requestor’s control Usually low risk – but certainly well-understood
  • #32 Within the system, a record must be kept of all the changes proposed, the decisions made in relation to them and the current status of the change. Some of the information in a change record will be created when an RFC is raised; the remainder will be added as the change progresses through its life. In many ways, therefore, the RFC can be considered as a subset of the Change record. Change record Request for Change (RFC) Business case Related CMS information RFC Content Unique number Trigger Description Id of items to be changed Reasons Effect of not doing CIs and baselines affected Proposer details Date/time raised Category Timescales, resources, etc Priority Risk assessment Back-out plan Impact assessment Knock-on effect Decision body Decision Authorised Date
  • #33 Intentionally blank page to be completed by Training Provider with additional information if desired
  • #34 Intentionally blank page to be completed by Training Provider with additional information if desired
  • #35 Change impacts so many different people and groups across the enterprise that is difficult to ensure common levels of understanding about the importance of change management and the correct procedures to be followed. Change is inevitable; in many cases essential. But the organisation needs to define its appetite for risk. Is it always necessary to be first to market? – which might call for less rigorous testing and speedy decision making – or is it more important to ensure that nothing upsets the live services. All humans like stability, but change management needs to be seen as responsive and being an enabler of the right changes. The process must allow change not stifle it – but under control There will be resistance Measure the right things and use the results to seek improvement
  • #36 Process Design Manager – Software Release Process
  • #37 Same process – Change Calendar
  • #38 Change Conflict Detection
  • #39 Header slide
  • #40 Intentionally blank page to be completed by Training Provider with additional information if desired
  • #41 P.84/SD book Para 4.4
  • #42 Intentionally blank page to be completed by Training Provider with additional information if desired
  • #43 DML – same as V2. scope/content need to be defined during SACM planning.
  • #44 Intentionally blank page to be completed by Training Provider with additional information if desired
  • #45 Software Release affecting three servers (upgrading SQL Server 2003)
  • #46 Criteria – pass/fail. P.91/P.123 ST book. Using a model such as the V-Model (Figures 4.12, 4.21, 4.30) builds in service validation and testing early in the service lifecycle. It provides a framework to organize the levels of configuration items to be managed through the lifecycle 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.
  • #47 ST book – p.115+
  • #48 Test and Evaluation (Typical Back-out Process)
  • #50 The Service Portfolio acts as “the spine” of the service lifecycle. It is the single integrated source of information on the status of each service together with other service details and the interfaces and dependencies between services. The information within the Service Portfolio is used by the activities within each stage of the service lifecycle. SERVICE STRATEGY – Looks at the Capabilities and Constraints This slide demonstrates the SPINE of all this is the SERVICE PORTFOLIO