itil foundation

54
Page 1 Service Design Service 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

description

itil foundation ppt

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 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