- 1. Page 1 Se rvice De sig n Se rvice ITIL Service Strategy
Service Operation Service Design Continual Service Improvement
SERVICE TRANSITION ITIL V3 Core Framework Service Transition
Validates the service design against service requirements
2. Page 2 Service Transition (ST) ST will ensure that the design
will deliver the intended strategy and that it can be operated and
maintained effectively. ST is concerned with managing change, risk
& quality assurance and has an objective to implement service
designs so that service operations can manage the services and
infrastructure in a controlled manner. Main Target Audience: IT
Service Managers, Service Owners, operational staff. Main
Influencers: Customers, Service owners, support staff. 3. Page 3 ST
The Real World The majority of IT projects do not yield desired
results / outputs Near 80% of incidents are caused by failed
changes and activities within IT Most IT organization need:
Stability Improved Quality Increased Efficiency & Effectiveness
Reduced IT Costs 4. Page 4 ST Key Terms Change : The addition,
modification or removal of anything that could have an effect on IT
Service; scope should include all IT services, Configuration Items,
Processes, documentation, etc Configuration Item (CI) : Any
component that needs to be managed in order to deliver an IT
service Build : The activity of assembling a number of
Configuration Items to create part of an IT service. It may also
refer to a Release Configuration Management DataBase (CMDB):
Configuration Management identifies the various components of IT
infrastructure as Configuration Items (CIs). All the information
regarding CIs are help within the Configuration Management Database
(CMDB) Configuration Management System (CMS) : A set of tools and
databases that are used to manage an It Service Providers
configuration data Definitive Media Library (DML) : One or more
locations in which the definite and approved versions of all
software Configuration Items are securely stored 5. Page 5 ST Key
Terms Release : A collection of hardware, software, documentation,
process or other components required to implement one or more
approved Changes to IT Services Release Unit : Components of an IT
service that are normally released together. Service Knowledge
Management System (SKMS) : A set of tools and databases that are
used to manage knowledge and information which includes the
Configuration Management System. Transition : A change in state,
corresponding to a movement of an IT service or other Configuration
Item from one Lifecycle status to the next. Validation : An
activity that ensures a new or changed IT service, process, plan or
other deliverable meets the needs of the business. 6. Page 6 ST
Purpose, Goals & Objectives How to introduce new services ( or
change the existing services) with appropriate balance of : Speed
Cost Safety Focus on customer expectations and requirements 7. Page
7 ST - Activities Two specific activities that are important to
Service Transition: Organizational and stakeholder Change:
Reflecting the holistic nature of change that Service Transition
must be based on, organizations do not transform their IT service
by only changing the IT services. Communications: Service
Transition must take on communication piece to ensure that the
business, the end user community and the IT staff are all aware of
the services available, why they are important, how they
interrelate with and impact other services, and how they are
supported. 8. Page 8 ST - Processes Transition Planning &
Support Change Management Service Asset & Configuration
Management Release & Deployment Service Validation &
Testing Evaluation Knowledge Management 9. Page 9 Transition
Planning & Support Management Purpose : Plans and coordinates
the resources to move a new or changed service into production
within the predicted cost, quality and time estimates. Goal :
Manage the planning & coordination of resource to meet
requirements. Objectives : Ensure adoption of a common framework
for making changes. 10. Page 10 KPIs - Transition Planning &
Support Management Key performance Indicator (KPI) Definition
Number of Projects Number of major release rollouts under the
control of Project Management Percentage of Projects with Project
Charters Percentage of projects which are started with a signed
Project Charter in place Number of Changes to Project Charter
Number of changes to the Project Charter after project start
Adherence to Project Budget Actual vs. planned consumption of
financial and personnel resources Project Delays Actual vs. planned
project completion dates 11. Page 11 Change Management Goal To
ensure that standardized methods and procedures are used for
efficient and prompt handling of all Changes, in order to minimize
the impact of Change-related Incidents Benefits Reduction in
incidents and problems caused by unplanned change Communication
with appropriate parties before change occurs Approval received
from appropriate parties before change occurs Time spent on
preparation and prevention rather than fire fighting and downtime
12. Page 12 Change Management Key Concepts Change : Addition,
modification or removal of anything that could have an effect on IT
Services Request for Change (RFC) : A formal proposal for a change
to be made. Change Window : A regular, agreed time when changes may
be implemented with minimal impact on services. Change Advisory
Board (CAB) : A group of people that advices the Change Manager in
the assessment, prioritization and scheduling of changes. 13. Page
13 Type of Requests and Changes An organization needs to ensure
that appropriate procedures and forms are available to cover the
anticipated requests. Different types of changes may require
different types of change requests. Normal Changes Changes to :
Service Portfolios, Service definitions Project changes, User
accesses, Operational Changes Standard Changes Change to a service
or infrastructure for which the approach is pre- authorized by
Change Management. Has an accepted and established procedure.
Emergency Changes Changes that will have a high negative impact on
the business. 14. Page 14 Standard Change The crucial elements of a
Standard Change are that: Pre-authorized Changes. The tasks are
well-known, documented and low-risk tasks. Authority has been in
advance. Budgetary approval is already set or is controller by the
requestor Example Installing workstation software from an proved
list. 15. Page 15 Change Management - Activities Create &
Record Assess & Evaluate Authorize Changes Coordinate Changes
Review & Closure 16. Page 16 Change Create & Record Accept
Change Validate Initiator Validate Change Record Register Request
for Change Full History of Change Logging Unique Identification
Registered via CMS Control Access Editing Viewing 17. Page 17
Change Access & Evalute Impact Business Operations
Infrastructure Services Effect on Change If NOT implemented IT,
Business & Other Resources Schedule Change Schedule (CS)
Projected Service Outage (PSO) Plans Continuity, Capacity,
Availability & Security 18. Page 18 Change Authorize Change
Formalized Acceptance Accountability, Responsibility Levels of
Authorization Considers Type, Size & Risk Organizational
Approach Hierarchical Flattened Acceptance Criteria Anticipated
Business Risk Financial Implications Scope of Change 19. Page 19
Change Management Authorizing Change IT Manageme nt Board Change
Advisory Board Local Authorization Decisions,Directio
Escalations,RFCs,Is Level 1 Level 2 Level 3 Level 4 High Cost/Risk
Impact on Multiple service or divisions Impact only on Local or
service group Standard Changes Business Executives 20. Page 20
Change Advisory Board (CAB) The Change Advisory Board (CAB)
delivers support to the Change Management team by approving
requested changes and assisting in the assessment and
prioritization of changes. Generally made up of IT and Business
representatives that include Change Manager User managers and
groups Technical experts Possible third parties and customers (if
required) CAB is responsible for oversight of all changes in the
production environment CAB is tasked with reviewing and
prioritizing requested changes, monitoring the change process and
providing managerial feedback Emergency Change Advisory Board
(ECAB): It is a subset of the CAB that considers a RFC tagged as an
Emergency Change. 21. Page 21 Change Coordinate Change Handoff to
Change Builder(s) Formal Tracking Work Orders Coordination
Responsibility For Scheduled Delivery of Change Remediation
Procedure development Quality Assurance Conformance 22. Page 22
Change Review & Closure Post Implementation Review Technical
Incident Problems Known Errors Business Requirements Desired
Outcome No Undesirable Effects Time & Cost of Delivery Follow
Up if Required Closure if Successful 23. Page 23 Change Management
The 7 Rs Who RAISED the change? What is the REASON for the change?
What is the RETURN required from the Change? What are the RISKS
involved with the change? What RESOURCES are required to deliver
the change? Who is RESPONSIBLE for build, test &
implementations of the change? What is the RELATIONSHIP between
this change and other changes? 24. Page 24 Change Management
Measures & Outcomes Measures link to business goals, cost,
service availability, and reliability Percentage reduction in
unauthorized changes Volume of change Frequency of change by
service By business area Ratio of accepted to rejected change
requests Time to execute a change. 25. Page 25 Change Management -
Challenges Major IT Cultural Shift Perceived as Bureaucratic Siloed
Technical Functional Areas Organizational Behavioral Change
Establishment of the New Normal Attempts to Bypass Changes Only
Made via Change Management Vendor/Contractor Compliance 26. Page 26
Review and Close Change Changer Review Meets objectives Users,
Customers are happy Side effects Resources consumption Time and
Cost 27. Page 27 Service Asset & Configuration Management
(SACM) Purpose: Establish control over the physical IT
infrastructure Goal : Document the content and the context of the
IT infrastructure Objective : Ensure all of the CIs are authorized
and under a single processes. 28. Page 28 SACM Key Concepts Asset
Any component of a business process Process (Change Management)
Organization (Experience, Reports) People, Infomration,
Applications, Infrastructure Financial Capital Configuration Item
Any asset being a service component, or other item under control of
Configuration Management 29. Page 29 SACM Configuration Management
System (CMS) System used to manage the information under SACM
Details of all the component of IT Infrastructure Maintain
relationships Configuration Management Database (CMDB) Automated
tools 30. Page 30 Configuration Management System (CMS) The CMS is
the heart of Service Asset and Configuration Management The CMS
maintains one or more CMDBs, and each CMDB stores attributes of
CIs, and relationships with other CIs. The CMS also maintains
several physical libraries, such as the Definite Media Library
(DML) for the secure storage of CIs. Although this is a physical
library, the CMS logically represent its content. 31. Page 31
Configuration Management DataBase (CMDB) Details about CIs are
stored in the Configuration Management DataBase (CMDB) from which
queries about the IT Infrastructure can be answered The details of
a CI that are mentioned in a CMDB include : Unique Identifier
(service tag) Attributes (supplier, price) Status (ordered,
testing, production, archived) History (past incidents, applied
changes) Category (hardware, software) Relationship (is connected
to, is a part of) The scope of the Configuration Management
database is defined by the area of responsibility of the IT
organization The level of detail is defined by the need for
information of the IT management processes, the control of the
information and the costs and benefits of a CMDB 32. Page 32 CMDB
& CMS CMDB is a database only, while the CMS also includes
tools CMS maintains one or more CMDBs CMS is used by all IT Service
Management processes CMS Components Secure Libraries and Secure
Stores Definitive Media Library (DML) Configuration baseline
Snapshot 33. Page 33 Release & Deployment Management Purpose :
Ensure the structured release and deployment of IT Services Goal :
Deploy release into production & establish the effective use of
the service. Objective : Project the line environment through the
use of formal procedures. 34. Page 34 Release & Deployment
Management Release & Deployment Management ensures
well-planned, cost-effective and properly implemented IT Service.
It helps balance the customers demand for change and IT stability.
Release and Deployment Management, deploys change into the live
environment, along with responsibility for quality control during
development and implementation. It provides a clear plan that
guides release activities with minimal unpredicted impact to live
services. 35. Page 35 Release and Deployment - Concepts Release A
collection of hardware, software, documentation, processes or other
components required to implement one or more approved changes to IT
services. Release Unit Components of an IT Service that are
normally released together Release Package / release Design One or
more release units to upgrade from as-is situation to to-be
situation 36. Page 36 Release and Deployment Releases Approaches
Big Bang versus Phased approach Big Bang: 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 : 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 scheduled rollout plan. Push versus Pull
deployment A push approach is used where the service component is
deployed from the centre and pushed out to the target locations. 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 locations at a time of their choosing or
when user workstation restarts. Automation versus Manual
deployments Automation will help to ensure repeatability and
consistency 37. Page 37 Release And Deployment Management - Roles
Release and Deployment Manager Responsible for planning, design,
build, configuration and testing of all software and hardware to
create the release package for the designated service Other roles
Release Packaging and Build Manager Deployment Staff Early Life
Support Staff 38. Page 38 Definite Media Library The Definite Media
Library (DML), maintained by Configuration Management, provides a
secure repository for the definitive versions of the software the
Release & Deployment Activities will use to complete its
activities. It stores master copies of versions that have passed
quality assurance checks. Only authorized media should be accepted
into DML, strictly controlled by SACM. 39. Page 39 Release &
Deployment Measures & Outcomes Maintain integrity of release
package through transition activities and ensure recording in CMS
Comprehensive and clear release deployment plans with minimal
unpredicted impact. Reduction in number of discrepancies Reduced
resources and cost Reduced incidents against the service. 40. Page
40 Definite Media Library 41. Page 41 Service Validation Management
Purpose: Provide for the Structured validation & testing of IT
Service Goal : Assure IT Service value is achieved for the benefit
of the customer. Objectives Ensure the IT Service delivers the
expected outcomes & value. 42. Page 42 Service Validation
Management Service Testing and Validation establishes confidence
that a new or changes service will deliver the value and outcomes
expected. Service Testing and Validation provides a structured
validation and testing process that delivers quality assurance that
the Service Design and release is fit for purpose and fit for use.
43. Page 43 The Service V Model The Service V model represent the
different configuration levels to be built and tested to deliver a
service capability. 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 designed on the left-hand
side. The V model approach is traditionally associated with the
waterfall lifecycle, just as applicable to other lifecycle
including iterative lifecycle, such as prototyping, RAD approaches.
44. Page 44 The Service V Model Represents the different
configuration levels to be built and tested to deliver a service
capability 45. Page 45 The Service V Model 46. Page 46 Evaluation
Purpose: Provide consistent means of determining the performance of
a service Goal : Set stakeholder & provide accurate information
Objectives : Evaluate the indented effects of a service change. 47.
Page 47 Evaluation Model Evaluation provides an overarching view of
Service Transition. Some common evaluations are: Service Design:
Release and deployment Acceptance 48. Page 48 Knowledge Management
Purpose: Ensure the right knowledge at the right time place. Goal :
Improve quality of management decisions. Objective : Ensure a clear
and common understanding value of IT Services. 49. Page 49
Knowledge Management Knowledge Management ensures that availability
and quality of knowledge assists in the direct support of IT
Services across the entire lifecycle. 50. Page 50 DIKW Model 51.
Page 51 Service Knowledge Management System (SKMS) SKMS is a
broader concept that covers a much wider base of knowledge, for
example : The experience of staff Records of peripheral matters (
e.g., weather, user numbers and behavior, organizations performance
figures) Supplier and partner requirements, abilities and
expectations Typical and anticipated users skill levels. 52. Page
52 Service Knowledge Management System (SKMS) Information, in the
form of knowledge, to base decisions on. Consists of: Staff
experiences Peripheral records Supplier / Partner information
Requirements Abilities Expectations User skill levels 53. Page 53
Service Knowledge Management System (SKMS) 54. Page 54 Questions
Questions
