itil foundation
description
Transcript of itil foundation
Page 1
ServiceDesign
Service
ITIL
ServiceStrategy
ServiceOperation
ServiceDesign
Continual ServiceImprovement
SERVICETRANSITION
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
Dec
isio
ns,
Dire
ctio
ns
Esc
alat
ions
, R
FC
s,
Issu
esLevel 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 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 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 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