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
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.
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
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 Provider’s 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
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.
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
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.
Page 8
ST - Processes
 Transition Planning & Support
 Change Management
 Service Asset & Configuration Management
 Release & Deployment
 Service Validation & Testing
 Evaluation
 Knowledge Management
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.
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
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
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.
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.
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.
Page 15
Change Management - Activities
– Create & Record
– Assess & Evaluate
– Authorize Changes
– Coordinate Changes
– Review & Closure
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
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
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
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
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.
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
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
Page 23
Change Management – The 7 R’s
 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?
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.
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
Page 26
Review and Close Change
 Changer Review
– Meets objectives
– Users, Customers are happy
– Side effects
– Resources consumption
– Time and Cost
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.
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”
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
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.
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
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
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.
Page 34
Release & Deployment Management
 Release & Deployment Management ensures well-planned, cost-effective and
properly implemented IT Service. It helps balance the customer’s 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.
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”
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
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
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.
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.
Page 40
Definite Media Library
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.
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.
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.
Page 44
The Service “V” Model
Represents the different configuration levels to be built and tested to
deliver a service capability
Page 45
The Service “V” Model
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.
Page 47
Evaluation Model
 Evaluation provides an overarching view of Service Transition.
 Some common evaluations are:
– Service Design:
– Release and deployment
– Acceptance
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.
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.
Page 50
DIKW Model
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,
organization’s performance figures)
– Supplier and partner requirements, abilities and expectations
– Typical and anticipated users skill levels.
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
Page 53
Service Knowledge Management System (SKMS)
Page 54
Questions
 Questions

5 itil v3 service transition 5 v1.8

  • 1.
    Page 1 Se rvice Desig 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 Provider’s 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 ofRequests 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 AdvisoryBoard (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 R’s  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 andClose 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 ManagementSystem (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 ManagementDataBase (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 customer’s 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 andDeployment - 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 andDeployment – 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 AndDeployment 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 MediaLibrary  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.
  • 41.
    Page 41 Service ValidationManagement  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 ValidationManagement  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.
  • 51.
    Page 51 Service KnowledgeManagement 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, organization’s performance figures) – Supplier and partner requirements, abilities and expectations – Typical and anticipated users skill levels.
  • 52.
    Page 52 Service KnowledgeManagement 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 KnowledgeManagement System (SKMS)
  • 54.