Intermediate: Service Transitions (Itil)

Front 1

Service

Back 1

A means of delivering value to customers by facilitating outcomes that customers want to achieve without the ownership of specific costs and risks.

Front 2

Service Management

Back 2

A set of specialized operational capabilities for providing value to customers in the form of services

Front 3

Processes

Back 3

Structured sets of activities designed to accomplish a specific objective. Take one or more defined inputs and turns them into defined outputs.

Front 4

Procedure

Back 4

A document containing steps that specify how to achieve an activity. Procedures are defined as part of processes

Front 5

Function

Back 5

A team or group of people and the tools (or other resources) they use to carry out one or more processes or activities (e.g. the Service Desk)

Front 6

Role

Back 6

A set of responsibilities, activities and authorities assigned to a person or team. A role is defined in a process or function.

Front 7

Utility

Back 7

The functionality offered by a product or service to meet a particular need. Utility can be summarized as "what the service does" and whether it's fit for purpose.

Front 8

Warranty

Back 8

Assurance that a product or service will meet agreed requirements. Warranty refers to the ability of a service to be available when needed, to provide the required capacity and to provide the required reliability in terms of continuity and security. Warranty is "how the service is delivered."

Front 9

Service Asset

Back 9

Any resource or capability of a service provider

Front 10

Resource

Back 10

IT infrastructure, people, money, or anything else that helps to deliver an IT service. Resources are considered assets of an organization

Front 11

Capability

Back 11

The ability of an organization, person, process, application, IT service, or other CI to carry out an activity

Front 12

Risk

Back 12

A possible event that could cause harm or loss, or affect the ability to achieve objectives.

Risk is measured by the probability of a threat, the vulnerability of the asset to the threat, and the impact if it occurred

Front 13

Purpose of Service Transition

Back 13

To ensure that new, modified or retired services meet the expectations of the business as documented in the Service Strategy and Service Design lifecycle stages

Front 14

Service Transition Objectives

Back 14

-Plan and manage service changes efficiently & effectively.

-Manage risks related to new, changed or retired services.

-Successfully deploy new releases into supported environments.

-Set correct expectations on the performance and use of a new or changed service.

-Ensure that service changes create the expected business value.

-Provide good-quality knowledge and information about services and service assets.

Front 15

Service Transition Scope

Back 15

-Development & improvement of capabilities for transitioning new and changed services into supported environments, including release planning, building, testing, evaluation & deployment

-Service retirement and transfer of services between service providers

-Ensuring that the requirements from service strategy, developed in service design, are effectively realized in service operation while controlling the risks of failure and subsequent disruption.

Front 16

ST Processes Through the Service Lifecycle:

Back 16

1) ChM

2) SACM

3) KM

Front 17

Processes Functioning Primarily in ST

Back 17

1) Transition Planning & Support

2) R&DM

3) SV&T

4) ChE

Front 18

Optimizing Service Transition

Back 18

Key: Focus on delivering what the business requires as a priority within financial and other resource constraints

Front 19

ST Inputs

Back 19

- Vision & Mission

-Strategies, strategic plans & policies

-Financial info & budgets

-Svc. Portfolio

-Ch Proposals

-RFCs

-SDPs (utility, warranty, acceptance criteria, service models, designs, interface specs, transition plans, ops plans & procedures, input to ChE & CAB meetings.)

-Knowledge & info in the SKMS

Front 20

ST Outputs

Back 20

-New/Changed Svcs

-Responses to ChProposals, RFCs

-Ch Schedule

-Known Errors

-Standard Changes for Req. Fulfillment

-Knowledge/Info in SKMS

-Financial reports

-Achievements against metrics, KPIs, CSFs

-Feedback to other lifecycle stages

-Improvement opportunities

Front 21

Service Strategy Inputs to ST

Back 21

Vision, mission, policies; Strategies, strategic plans & priorities (based in business cases); Dynamic Svc portfolios; ChProposals & requirements w/ utility, warranty & timescales; Financial info & budgets; Mgt input to ChE, CAB, & ECAB

Front 22

Service Operation Inputs to ST

Back 22

RFCs for operational Changes & resolutions; Metrics of actual performance of ST Improvement for ST Processes; Operational requirements (as Svc Acceptance Criteria); Quality Reports, User and Operations feedback on transitions; Input to ChE, CAB & ECAB

Front 23

Service Design

Back 23

SDP (Details of utility, warranty; acceptance criteria; service models; design & interface specs

Front 24

7 ST Processes

Back 24

Transition Planning & Support, ChM, SACM, R&DM, SV&T, ChE, KM

Front 25

What goes into an SDP?

Back 25

Service packages (core svc. pkg, svc level pkg)

Service specs

Details of utility & warranty

Acceptance criteria

Service models

Release pkg definition & design, how components will be assembled & integrated into release pkg.

Architectural design to deliver new/changed svc

Designs & interface specs

Transition plans

Operations plans & procedures

Input to ChEval & CAB mtgs

Front 26

What has to be measured for ST?

Back 26

-Alignment with business and IT plans

-Metrics for overall ST process performance

Front 27

What are Svc Acceptance Criteria?

Back 27

A set of criteria used to ensure that an IT service meets its functionality (utility) and quality (warranty) requirements and that the IT svc provider is ready to operate it when deployed.

Front 28

Change

Back 28

The addition, removal, or modification of anything that could have an effect on IT services. The scope includes changes to all architectures, processes, tools, metrics and documentation, as well as changes to IT services and other CIs

Front 29

Releases

Back 29

One or more changes that are built, tested and deployed together. One release may include changes to hardware, software documentation, processes and other components

Front 30

Release Pkg

Back 30

A set of CIs that will be built, tested, and deployed together as a single release. Each release usually includes one or more release units

Front 31

Release Unit

Back 31

Components of an IT service that are normally released together. A release unit typically includes sufficient components to perform a useful function: one release unit could be a desktop PC--HW, SW, licenses, documentation, etc.

Front 32

Transition Planning & Support Purpose

Back 32

Provides overall planning for Service Transitions, including resource coordination

Front 33

Transition Planning & Support Objectives

Back 33

Plan & coordinate resources

Coordinate activities across projects, suppliers & service teams

Establish new or changed services into supported environments

Establish new or modified management information systems and tools, technology, and management architectures, service management processes, measurements and metrics

Ensure that all parties adopt a common framework of standard, re-usable processes and supporting systems

Provide clear and comprehensive plans

Identify, manage and control risks

Monitor and improve performance

Front 34

Transition Planning and Support performs the following:

Back 34

Maintains policies, standards and models

Guides major changes or new services

Coordinates the efforts needed to enable multiple transitions

Prioritizes conflicting requirements

Plans the required budget and resources

Reviews and improves performance

Ensures that ST is coordinated with program and project mgt.

Front 35

Value of TPS:

Back 35

Significantly improves the service provider's ability to handle high volumes of changes and releases

Improves the alignment of ST plans with customer, supplier and business change project plans

Front 36

Service Transition Policy

Back 36

-Implement all changes through ST

-Adopt common framework & standards

-Align ST with business needs

-Establish effective controls & disciplines

-Ensure early involvement in the lifecycle

Front 37

Release Policy

Back 37

Defined for one or more services:

-unique ID, numbering and naming conventions

-roles & responsibilities

-requirement for SW to come from DML

-expected release frequency by type

-approach for accepting and grouping changes into a release

-mechanism to automate build, installation, and release distro process

-how the config baseline is captured and verified against actual release

-entry and exit criteria

-criteria and authorization to exit early life support and handover to Service Ops

Front 38

Major Release:

Back 38

-Normally contains large areas of new functionality

-Usu. supersedes all preceding minor upgrades, releases and emergency fixes

-Must have a unique ID

-Must be tracked in alignment to RFC

Front 39

Minor Release:

Back 39

-Normally contains small enhancements and fixes

-Usually supersedes all prior emergency fixes

-Must have a unique ID

-Must be tracked in alignment to RFC

Front 40

Emergency Release:

Back 40

-Normally contains corrections to a small number of KE

-Enhancements are to meet a high-priority business requirement

-Must have a unique ID

-Must be tracked in alignment to RFC

Front 41

Transition Planning & Support Activities

Back 41

Define transition strategy

Prepare for service transition

Plan and coordinate service transition

Provide transition process support

Front 42

Transition Planning & Support: Define Transition Strategy

Back 42

Defines the overall approach to organizing ST & allocating resources:

-Purpose & Objectives

-Context & Scope

-Applicable standards (legal, contractual, etc.)

-Organizations & stakeholders

-Svc Transition framework

-Criteria (entry, exit, success and failure)

-Roles & responsibilities

-Approach: Transition model, ChM plans, etc.

-Deliverables from transition activities

Front 43

Transition Planning & Support: Prepare for Service Transition

Back 43

-Review and acceptance of inputs from other Service Lifecycle phases (SvcDesign, SvcStrategy)

-Review and check the input deliverables (SDP, Svc. Acceptance criteria, evaluation report)

-ID'ing, raising & scheduling RFCs

-Check Config Baselines are recorded in CMS prior to Service Transition start

-Check transition readiness

Front 44

Transition Planning & Support: Svc. Transition Plan & Coordinate

Back 44

Plan:

Describes the tasks and activities required to release and deploy a release into the test environments and into production. It also describes:

-Work environment & infrastructure

-Schedule of milestones

-Activities & tasks

-Staffing, resource requirements, budgets & timescales at each stage

-Issues & risks to be managed

-Lead times and contingency plans

Front 45

Transition Planning & Support: Provide Transition Process Support Activities

Back 45

-Providing advice to all relevant stakeholders

-Administration

-Communication

-Progress monitoring and reporting

Front 46

Transition Support Roles:

Back 46

-Service Transition Manager

-Transition Planning & Support Process Owner

-Transition Planning & Support Process Mgr

-Transition Planning & Support Practitioner

Front 47

Transition Planning & Support Triggers

Back 47

-Authorized RFC

-Change Proposal

-Budgetary Planning Cycle

Front 48

Transition Planning & Support Inputs

Back 48

Change Proposal

Authorized Change

Service Design Package

Front 49

Transition Planning & Support Outputs

Back 49

Transition Strategy & Budget

Integrated set of Service Transition Plans

Front 50

Transition Planning & Support Process Interfaces

Back 50

-Demand Management

-Service Portfolio Management

-Business Relationship Management

-Service Design Processes

-Supplier Mgt

-All other SvcTransition Processes

-Service Operations functions

Front 51

Transition Planning & Support CSFs:

Understanding and managing the trade-offs between cost, quality and time--KPIs

Back 51

-Increase in the number of releases implemented that meet the customer's agreed requirements in terms of cost, quality, scope and release schedule

-Reduced variation of actual versus predicted scope, quality, cost and time

Front 52

Transition Planning & Support CSFs:

Identifying and managing risks of failure and disruption--KPIs

Back 52

-Reduction in number of issues, risks and delays

-Improved service transition success rates

Front 53

Transition Planning & Support CSFs:

Coordinating activities of multiple processes involved in each transition--KPIs

Back 53

-Improved efficiency and effectiveness of the processes and supporting systems

-Reduction in time and resources to develop and maintain integrated plans and coordination activities

Front 54

Transition Planning & Support CSFs: Managing conflicting demands for shared resources--KPIs

Back 54

-Increased project and service team satisfaction with the Service Transition Processes

-Reduced number of issues caused by conflicting demands for shared resources

Front 55

Service Transition Planning & Support Challenges

Back 55

-Building relationships needed to manage and coordinate stakeholders

-Coordinating and prioritizing many new or changed services

-Proactively managing resource planning

Front 56

Service Transition Planning & Support Risks:

Back 56

-Lack of information from Demand Management and Service Portfolio Management

-Poor relationships with project and program teams

-Delays to one transition impacting future transitions

-Insufficient information to prioritize conflicting requirements

Front 57

Change Management: Purpose

Back 57

To control the lifecycle of all changes, enabling beneficial changes to be made with minimal disruption to IT services

Front 58

Change Management: Objectives

Back 58

-Respond to customer's changing business requirements while maximizing value & reducing incidents, disruption & rework

-Respond to business & IT RFCs that will align services with business needs

-Ensure that Changes are recorded & evaluated, & that authorized changes are prioritized, planned, tested, implemented, documented and reviewed in a controlled manner

-Ensure that all Changes to CIs are recorded in the CMS

-Optimize overall business risk

Front 59

ChM Value to Business

Back 59

-Protect business and other services while making required changes

-Implement changes to meet customer's agreed service requirements while optimizing costs

-Contributing to meet legal/governance/contractual/regulatory requirements

-Reduce failed changes

-Reduce unauthorized changes

-Deliver changes to meet business timescales

-Track changes

-Contribute to more accurate estimates of time, cost and quality of changes

-Assess risks associated with Svc Transition

-Improve staff productivity by reducing disruptions

-Reduced MTTRS

-Liase with business change process to identify business improvement opportunities

Front 60

ChM Policies

Back 60

-Create culture of ChM w/0 tolerance for unauthorized Ch

-Align ChM Process with business, project & stakeholder ChM Processes

-Prioritization of Ch (innovation vs. prevention, detection vs. correction)

-Establish accountability and responsibility for Ch through Svc. lifecycle

-Segregation of duty controls

-Single focal point for Ch. to minimize probability of conflicting changes & disruption to production environment

-Prevent unauthorized people from changing production environment

-Integrate with other Svc Mgt processes for traceabilityof Ch, detection of unauthorized Ch, and identification of Ch related incidents

-Ch windows--enforcement and authorization for exceptions

-Performance and risk evaluation of all Ch impacting service capability

-Process performance measures-efficiency & effectiveness

Front 61

Change Proposal

Back 61

Provides a high-level description of major changes that involve significant cost, risk or organizational impact--usually initiated by Service Portfolio Mgt.

Front 62

Change Model

Back 62

A predefined set of steps to handle a particular type of change

Front 63

Overall Change Activity Responsibilities

Back 63

1) Change Planning & Control

2) Change & Release Scheduling

3) Communication

4) Change decision making & authorization

5) Ensuring that there are remediation plans

6) Measurement & control

7) Management reporting

8) Understanding impact

9) Continual improvement

Front 64

ChM Process Flow

Back 64

0) Ch Proposal (large-scale Ch.)

1) Create RFC

2) Record RFC

3) Review RFC

4) Assess & Evaluate Ch

5) Authorize Ch Build & Test

6) Coordinate Ch Build & Test

7) Authorize Ch Deployment

8) Coordinate Ch Deployment

9) Review & Close Ch Record

Front 65

ChM: Create & Record RFC

Back 65

-Ch raised by request from initiator

-Ch logged in the Svc Mgt tool

-Triggers for Ch (e.g. Problem Record) should be referenced in the RFC/tool

Front 66

ChM Review RFC

Back 66

Verification by ChM: Ch is not completely impractical, redundant to other RFCs, incomplete

Ex: Insufficient description, no budgetary approval, contrary to organizational strategy, unauthorized requestor

Front 67

ChM Assess & Evaluate Ch

Back 67

- Ch must be evaluated by Ch Authority

-Significant Ch can be formally handled by Ch Evaluation Process

-Considerations:

**Impact

**Risk

**Priority

**Remediation

Front 68

7 R's of Impact Assessment

Back 68

-Raised by who?

-Reason for the Ch

-Risks of the Ch (including those if it's not made)

-Returns required to justify resources and risks?

-Resources required?

-Responsibility for building, testing, implementation?

-Relationships to other changes?

Front 69

ChM: Authorize Ch Build & Test

Back 69

-Every Ch must be authorized by ChAuthority for build & test

-Authority level required depends on type, size, risk and potential business impact

-Multiple-stage Ch may require multiple approvals at "stage gates" of Ch implementation

Front 70

ChM: Coordinate Ch Build & Test

Back 70

-Ch schedule & projected service outage plans are produced

-Authorized RFCs should be passed to technical groups for building the changes

-Changes must be tested, along with remediation and implementation methods

-Other processes, including R&DM, ChE, and SV&T will be involved

Front 71

ChM: Considerations: Authorize Ch Deployment

Back 71

-Release Deployments may require multiple steps & various test/acceptance criteria being met

-Deployments may be carried out in stages

-Deployments may be multi-system

-Deployment may have to adhere to Approved Release windows

-Vendor and SME involvement may be required

-ChE Process may be used by ChM as required

-Evaluation results are considered by Ch Authority for formal authorization for Ch deployment.

Front 72

ChM: Considerations: Coordinate Ch Deployment

Back 72

Deployment will involve resources from R&DM

Ensure that remediation procedures are prepared and documented

Alignment of deployed releases to svc requirements defined in RFC is essential

Front 73

ChM: Review & close Ch Record

Back 73

-Every Ch must be evaluated to ensure that *actual* performance is acceptable, and that there are no unacceptable risks

-CAB Ch Review

-CMS & CMDB updated

-PIR: where required, report produced prior to closure

Front 74

CAB Review Meeting following Change must cover:

Back 74

-Ch has had desired effect & met objectives

-Users, customers & stakeholders are okay w/results

-No unexpected/negative side-effects to functionality, svc levels, warranties

-Resources within parameters

-Deployment plan worked

-Ch implemented on time and within costs

-Remediation plan worked if deployment was rolled back

Front 75

ChM Process Roles

Back 75

-ChM Process Owner

-ChM Process Mgr

-Ch Initiator

-ChM Practitioner

-Ch Authority

-CAB Member

-CAB Chair

Front 76

ChM Process Triggers

Back 76

Strategic Ch: Legal or regulatory Ch, Organizational Ch.

Service Ch: Service Catalog, Svc. Pkg

Operational Svc Ch: Approved Std. Changes; Approved Svc Request; Corrective/Preventive Actions to manage svcs

Svc/Process Improvements: CSI initiated Changes (Strategic & Svc Changes)

Front 77

ChM Inputs

Back 77

-Ch & Release policies & strategies

-RFCs

-Ch Proposals

-Ch Schedule & Projected svc outages

-Evaluation reports

-Assets & CI data

-Test results, test reports, evaluation reports

Front 78

ChM Outputs

Back 78

-Rejected/Cancelled RFCs

-Authorized Changes/Change Proposals

-New or changed services/CIs/assets

-CMS/CMDB updated

-Adjusted PSO

-Updated Change Schedules

-Change decisions, actions, documents, records & reports

Front 79

ChM Interfaces

Back 79

-Business Change process

-Program & Project Mgt

-Organizational & Stakeholder Mgt

-Sourcing & Partnering

-Other ITSM Processes, including:

**SACM

**Problem

**Continuity Mgt

**InfoSec Mgt

**Capacity & Demand Mgt

**Svc Portfolio Mgt

Front 80

ChM CSFs

Back 80

1) Responding to business & IT RFCs that will align the services with the business needs while maximizing value

2) Optimizing overall business risk

3) Ensuring that all Changes to CIs are managed and recorded in the CMS

Front 81

ChM CSFs- KPIs: Responding to business and IT RFCs that will ensure the alignment of services with business needs while maximizing value

Back 81

1) Increase in the percentage of Changes that meet the customer's agreed requirements (e.g. quality, cost, time)

2) Benefits of Ch exceed costs of Ch

Front 82

ChM CSFs: KPIs: Optimizing overall business risk

Back 82

1) Reduction in number of disruptions to services, defects and re-work caused by inaccurate specification, poor or incomplete impact assessment

2) Increase in change-success rate

Front 83

ChM CSFs: KPIs: Ensuring that all changes to CIs are managed and recorded in CMS

Back 83

1) Reduction in the number of audit compliance issues for ChM Process

2) Reduction in # and percentage of discrepancies found by SACM verification & audit activity

Front 84

ChM Challenges

Back 84

-Ensuring that every Ch is recorded & managed

-Gaining support from customers, users and IT staff

-ChM viewed as just operational Ch Authorization process

-Agreeing & Documenting the many levels of Ch Authority

Front 85

ChM Risks

Back 85

-Lack of commitment to ChM process by business, IT staff, IT mgt.

-Implementation of changes without ChM Process

-ChAssessment being reduced to box-ticking

-Introduction of delays without adding value

-Insufficient time for proper assessment of Ch, and implementation of Changes

-Insufficient resources

-Lack of clarity on how ChM should interact with other ITSM processes and project mgt

-Excessive bureaucracy creating excessive delay

Front 86

SACM Purpose

Back 86

To ensure that the assets required to deliver services are properly controlled and that accurate and reliable information about those assets is available when and where it is needed

Front 87

SACM Objectives

Back 87

1) Ensure that assets under the control of the IT organization are identified, controlled and properly managed

2) ID, control, record, report, audit and verify services and other CIs

3) Account for, manage, and protect the integrity of CIs through the service lifecycle

4) Ensure integrity of CIs and configurations required to control the services through CMS

5) Maintain accurate configuration information on the historical, planned and current state of services and other CIs

6) Support efficient and effective ITSM processes

Front 88

SACM Scope

Back 88

1) ID, baseline and maintain CIs, and ensure that all changes to CIs are controlled

2) Ensure that releases into controlled environments and operational use are done on the basis of formal authorization

3) Provide configuration model of services and service assets by recording the relationships between CIs

4) Interfaces with internal and external svc providers

Front 89

SACM Value to Business

Back 89

1) Understanding of config & relationships between services & the CIs that enable them

2) Improved planning & forecasting of Ch

3) Successful assessment, planning & delivery of Ch & Releases

4) Resolution of incidents & problems w/in svc targets

5) Delivery to service levels & warranties

6) Improved adherence to standards, legal & regulatory obligations

7) Improved business opportunities through demonstrable control of assets & services

8) Traceability of Changes from requirements

9) Identifiability of service costs

10) Reduced time and costs to discover config info when needed

11) Proper stewardship of fixed assets under the control of the service provider

Front 90

SACM Principles (1-7)

Back 90

1) SACM operational costs & resources are commensurate with risks to the service

2) Delivery of governance requirements

3) Deliver capability, resources & warranties as defined by SLAs & contracts

4) Support available, reliable, & costeffective svcs

5) Clear economic & performance criteria for interventions that reduce costs or optimize service delivery

6) Application of whole-life cost appraisal methods

7) Transform from reactive to proactive mgt

Front 91

SACM Principles (8-14)

Back 91

8) Maintain adequate config info for stakeholders

9) Maintain control and requirements for traceability & auditability

10) Apply continual improvement methods to optimize service levels, assets & configuraitons

11) Integrate SACM with other processes

12) Migration to common CMS architecture

13) Increased automation to reduce errors & costs

Front 92

SACM: Service Asset

Back 92

Any resource or capability that could contribute to service delivery

Front 93

SACM: CI

Back 93

Any service asset that must be managed to deliver an IT service

Front 94

SACM: CMS

Back 94

A set of tools, data and information used to support SACM

Front 95

SACM: Configuration Record

Back 95

A record containing the details of a CI throughout its lifecycle

Front 96

SACM: CMDB

Back 96

A database used to store configuration records throughout their lifecycle

Front 97

SACM: Configuration Model

Back 97

A representation of the services, assets, and infrastructure along with the relationships between CIs

Front 98

SACM: DML

Back 98

One or more locations (a single logical location) in which definitive and authorized versions of SW CIs (as well as licenses & documentation) are stored

Front 99

SACM: Definitive Spares

Back 99

HW components and assemblies that are maintained at the same revision level as the systems within as the systems within the controlled test or live environment

Front 100

SACM: Configuration Baseline

Back 100

A configuration of a service, product or infrastructure that has been formally reviewed and agreed, and any further change can be made only through ChM

Front 101

SACM: Snapshot

Back 101

The most recent status of a CI or environment

Front 102

SACM Activities

Back 102

1) Mgt & Planning

2) Configuration ID

3) Configuration Control

4) Status Accounting & Reporting

5) Verification & Audit

Front 103

SACM: Mgt & Planning

Back 103

1) Svc Mgt team decides what level of SACM is required, and how this level will be achieved, documents it in SACM Plan

2) Level of SACM will depend on organizational requirement.

3) ITSM tool must support CMDB-related automation and integration to other processes, to ensure accuracy in CMS & allow beneficial info sharing

Front 104

SACM: Configuration ID

Back 104

Focuses on determining and maintaining the naming and version numbering of assets & CIs, relationships & attributes

1) Define & document CI selection criteria, including CI components

2) Select CIs based on defined criteria

3) Apply unique CI IDs

4) Indicate when each CI will be placed under CfM

5) ID CI owner

Front 105

SACM: Configuration Control

Back 105

1) Ensures adequate control mechanisms over CIs while maintaining change record for CIs, versions, locations and ownership

2) No CIs can be added, modified, replaced or removed without following agreed procedures

3) Policies & procedures must be in place to manage svc assets & CIs

Front 106

SACM: Status Accounting & Reporting

Back 106

1) Ensures that all config data and documentation is recorded as each CI progresses through its lifecycle

2) Provides the status of a service and its environment as the configuration evolves through the service lifecycle

3) Status reporting provides the current and historical data concerned with each CI, which in turn enables tracking of changes to CIs and CI records

Front 107

SACM: Verification & Audit

Back 107

A series of reviews and audits are planned and conducted to:

** Ensure that there is conformity between the documented baselines and the actual business environment to which they refer

** Verify the physical existence of CIs and check that the records in the CMS match the physical infrastructure

** Check that release and configuration documentation is present before making a release

Front 108

SACM Roles

Back 108

1) SACM Process Owner

2) SACM Process Mgr

3) Configuration Analyst

4) Configuration Librarian

Front 109

SACM Inputs

Back 109

1) Designs, plans and configurations from SDPS

2) RFCs and work orders from ChM

3) Actual configuration info collected by tools & audits

4) Information in the organization's fixed asset register

Front 110

SACM Outputs

Back 110

1) New & updated Configuration records

2) Updated asset info

3) Info about attributes & relationships of CIs

4) Config baselines & snapshots

5) Status reports and other consolidated configuration info

6) Audit reports

Front 111

SACM Triggers

Back 111

1) Updates from ChM

2) Updates from R&DM

3) Purchase orders

4) Acquisitions

5) Service requests

Front 112

SACM Interfaces

Back 112

1) ChM (ID impact of proposed changes)

2) Financial Mgt (capturing key financial info on cost, depreciation methods, owner and user [for cost and budgeting allocation], maintenance and repair costs)

3) IT Svc Continuity Mgt: Awareness of assets that business services depend on, control of spares and SW

4) Incident/problem/error: Provide & maintain key diagnostic info; maintenance & provision of data to Svc Desk

5) Availability Mgt: Detection of points of failure

Front 113

SACM CSFs

Back 113

1) Accounting for, managing and protecting the integrity of CIs throughout the service lifecycle

2) Supporting efficient and effective ITSM processes by providing accurate configuration info at the right time

3) Establishing and maintaining an accurate and complete CMS

Front 114

SACM CSF: Accounting for, managing and protecting the integrity of CIs throughout the service lifecycle KPIs

Back 114

1) Improved accuracy in budgets and charges for the assets used by each customer or business unit

2) Reduction in the use of unauthorized HW and SW, non-standard and variant builds that increase complexity, support costs, and risk to the business services

3) Reduced number of exceptions reported during configuration audits

Front 115

SACM CSF: Supporting efficient and effective ITSM processes by providing accurate configuration information at the right time

Back 115

1) Improved speed for Incident mgt. to ID faulty CIs and restore services

2) Improved ratio of used licenses against paid-for licenses

3) Reduction in risks due to early ID of unauthorized change

Front 116

SACM CSF: Establishing and maintaining an accurate and complete CMS

Back 116

1) Reduction in business impact of outages and incidents caused by poor SACM

2) Increased quality and accuracy of Configuration info

3) Improved audit compliance

Front 117

SACM Challenges

Back 117

1) Persuading technical support staff to adopt a "checking in/checking out" policy

2) Attracting and justifying funding for SACM

3) An attitude of collecting data "because we can"

4) Lack of commitment and support from mgt.

Front 118

SACM Risks

Back 118

1) Temptation to consider SACM as "technically focused"

2) Degradation of configuration information accuracy over time

3) Setting the scope too wide or too narrow

4) CMS out of date/inaccurate due to HW movement by unauthorized staff

Front 119

R&DMgt Purpose

Back 119

To plan, schedule and control the build, test and deployment of releases, and to deliver new functionality required by the business while protecting the integrity of existing services

Front 120

R&DMgt Objectives

Back 120

1) Define and agree R&DM Plans with customers and stakeholders

2) Create and test release pkgs consisting of related CIs that are compatible with one another

3) Ensure the integrity of a release pkg & constituent components is maintained throughout transition activities

4) Deploy release pkgs from the DML to the live environment following agreed plan & schedule

5) Ensure that all release pkgs can be tracked, installed, tested, verified and/or uninstalled or backed out as appropriate

6) Ensure that organization & stakeholder change is managed during R&D

7) Ensure that new/changed services & enabling systems, technology, and organization are capable of delivering agreed warranty & utility

8) Record & manage deviations, risks & issues related to new or changed service & take necessary corrective actions

9) Ensure that there is knowledge transfer to enable customers and users to optimize their use of the service to support their business activities

10) Record & manage deviations, risks and issues related to new or changed service, and take necessary corrective actions

11) Ensure that skills and knowledge are transferred to service operation functions to enable them to effectively and efficiently deliver, support and maintain the service according to required warranties and service levels

Front 121

R&DMgt Scope

Back 121

1) Processes, systems, and functions to package, build, test and deploy a release into production and establish the service specified in the SDP before final handover to service operations

2) All CIs required to implement a release

Front 122

R&DMgt Value to Business

Back 122

1)Deliver change faster and at optimum cost and minimized risk

2) Assure that customers and users can use the new or changed service in a way that supports business goals

3) Improve consistency in implementation approach across the business change, service teams, suppliers and customers

4) Contribute to meeting auditable requirements for traceability through Service Transition

5) Reduce Change/Release related failures in operations

Front 123

R&DM Policies

Back 123

1) All Changes & releases must be fully tested under a realistic load before they are deployed

2) All Changes to a service will be packaged into annual Releases, and the only Changes permitted between these Releases will only be to resolve problems that have a major impact on the business

Front 124

R&DM: Release

Back 124

One or more changes to an IT service that are built, tested and deployed together

Front 125

R&DM: Release Unit

Back 125

Components of an IT service that are normally released together (sufficient components to perform a useful function)

Front 126

R&DM: Release Package

Back 126

Set of CIs that will be built, tested and deployed together as a single release. Each release package will normally include one or more release units

Front 127

R&DM: Deployment

Back 127

The movement of new or changed hardware, software, documentation, process, etc. to the live environment

Front 128

R&DM: Early Life Support

Back 128

A stage in the service lifecycle that occurs at the end of deployment and before the service is fully accepted into operation

Front 129

R&DM: Release Approaches

Back 129

1) Big Bang vs. Phased (all at once, versus phased implementation)

2) Push vs. Pull (admins install release versus users "pull" release)

3) Automated vs. Manual (deployment carried out via automated tools versus installation carried out by technicians)

Front 130

R&DM: Release Design Options & Considerations: Service Design defines the approach to transitioning from a current service to a new or changed service or service offering. What does R&D select?

Back 130

Differing approaches to deployment of the releases (manual vs. automated, push vs. pull, big-bang vs. phased)

Front 131

R&DM: R&D Models define:

Back 131

1) Release structure

2) Entry and exit criteria

3) Controlled environments required to build and test the release for each release level

4) Roles & responsibilities for each CI at each release level

5) Release promotion and config baseline model

6) Template R&D schedules

7) Supporting systems, tools and procedures

8) Handover activities and responsibilities

Front 132

R&DM Process Activities:

Back 132

1) R&D Planning

2) Release Build & Test

3) Deployment

4) Review & Close

Front 133

R&DM Activity: R&D Planning

Back 133

1) Prepare R&D Plans

2) Establish pass/fail criteria

3) Develop Build & Test Plans

4) Financial/Commercial Planning

Front 134

R&DM Activity: Release Build & Test

Back 134

1) Create Release & Build documentation

2) Acquire and test input CIs and components

3) Build and package Release

4) Build and manage test environments

5) Service testing and pilots

6) Service rehearsals

Front 135

R&DM Activity: Deployment

Back 135

1) Plan and Prepare for Deployment (Assess target-groups readiness, Develop plans)

2) Perform transfer, deployment and retirement (Change/Transfer financial assets; Transfer/Transition business and organization; Deploy processes and materials; Deploy Service Mgt Capability; Transfer Service; Deploy Service; Decommissioning and Service retirement; Remove redundant assets; Verify deployment; Remediate/Back-Out Release; Early Life Support)

Front 136

R&DM Activity: Review & Close

Back 136

1) Review and close deployment

2) Review and close Service Transition

Front 137

R&DM Roles:

Back 137

1) R&DM Process Owner

2) R&DM Process Manager

3) Release Packaging and Build Practitioner

4) Deployment Practitioner

5) Early Life Support Practitioner

6) Build & Test Environment Mgr

Front 138

R&DM Triggers

Back 138

1) An authorized Change to plan, build and test a production-ready release

2) An authorized Change to deploy a release package to a target deployment group or environment

Front 139

R&DM Inputs

Back 139

1) Authorized RFC

2) Service package, SLP, SDP, and SAC

3) IT SCP and BCP

4) Service Mgt, Technology, procurement and operations plans and standards

5) Acquired service assets and components and their documentation

6) Build/Release and deployment models, including template plans

7) Environment requirements and specifications for build, test, release, training, disaster/recovery, pilot and deployment

8) Entry and exit criteria for each stage of R&D

Front 140

R&DM Outputs:

Back 140

1) New, changed or retired services

2) Release & Deployment Plan

3) Completed RFCs for Release & Deployment activities

4) Service notification

5) Updated service catalog with the relevant information about the new or changed service

6) New tested service capability and environment

7) Service Transition Report

Front 141

R&DM Interfaces

Back 141

1) Service Design Coordination

2) Transition Planning & Support

3) ChM

4) SACM
5) SV&T

Front 142

R&DM CSFs:

Back 142

1) Defining and agreeing release plans with customers and stakeholders

2) Ensuring integrity of a release package and its constituent components throughout the transition activities

3) Ensuring that the new or changed service is capable of delivering the agreed utility and warranty

Front 143

R&DM CSF: Defining and agreeing release plans with customers and stakeholders: KPIs:

Back 143

1) Increased number and percentage of releases that use a common framework of standards, reusable processes, and supporting documentation

2) Increased number and percentage of releases that meet customer expectations for cost, time and quality.

Front 144

R&DM CSF: Ensuring integrity of a release package and its constituent components throughout the transition activities

Back 144

1) Reduced number of CMS and DML audit failures related to releases

2) Reduced number of deployments from sources other than the DML

3) Reduced number of incidents due to incorrect components being deployed

Front 145

R&DM CSF: Ensuring that the new or changed service is capable of delivering the agreed utility and warranty

Back 145

1) Reduced variance from service performance required by customers

2) Number of incidents against the service (low and reducing)

3) Increased customer and user satisfaction with the services delivered

Front 146

R&DM Challenges

Back 146

1) Developing standard performance measures and measurement methods across projects and suppliers

2) Dealing with projects and suppliers where estimated delivery dates are inaccurate and there are delays in scheduling service transition activities

3) Understanding the different stakeholder perspectives that underpin effective risk management for the change impact assessment and test activities

4) Building a thorough understanding of risks that have impacted or may impact successful service transition of services and releases

5) Encouraging a risk-management culture where people share information and take a pragmatic and measured approach to risk

Front 147

R&DM Risks:

Back 147

1) Poorly defined scope and understanding of dependencies in early life support

2) Using staff who are not dedicated to R&DM activities

3) Failing to use the R&DM Process to manage service retirement

4) Inadequate finances

5) Inadequate controls

6) Risks relating to management of organizational and stakeholder change

Front 148

SV&T Purpose

Back 148

Service validation is the Quality Assurance portion of the service solution.

The purpose is to ensure that a new or changed IT service matches its design specifications and will meet the needs of the business

Front 149

SV&T Objectives

Back 149

1) Provide confidence that a Release will create a new or changed service that delivers the expected outcomes and value

2) Quality-assure a release, its constituent service components, the resultant service and service capability

3) Validate that a service is fit for purpose (utility)

4) Provide assurance that a service is fit for use (warranty)

5) Confirm that the customer and stakeholder requirements for the new or changed service are correctly defined

6) Plan and implement a structured validation and testing process

7) Identify, assess and address issues, errors and risks throughout service transition

Front 150

SV&T Scope

Back 150

1) All services throughout the service lifecycle

2) Interfaces with suppliers, customers and partners

3) Testing of new or changed services or service components

4) Support to R&D Process

5) Evaluation of detailed service models to ensure that they are fit for use and purpose

Front 151

SV&T Value to Business

Back 151

1) Provides a measured degree of confidence that a new or changed service will deliver the value and the required outcomes

2) Enables customers and the service provider organization to understand the associated risks

Front 152

SV&T Policies in General

Back 152

Policies for SV&T reflect requirements for service strategy & service design, and should meet business expectations

Front 153

SV&T Policy Considerations

Back 153

1) Independent testing (no conflicts of interest!)

2) SDP should include test pass/fail criteria and every test environment

3) Creation of test library and re-use policy

4) Integrate testing into project and service lifecycle

5) Risk-based testing to reduce risk

6) Engage stakeholders, including customers, users and service teams

7) Establish test measurement and monitoring system

8) Automate complex systems and services which require critical changes in shorter timeframe

Front 154

SV&T Policies:

Back 154

1) Service Quality Policy

2) Risk Policy

3) Release Policy

4) ChM Policy

5) Service Transition Policy

Front 155

SV&T Policies: Service Quality Policy

Back 155

1) Service Quality Policy: Defines the meaning of service quality. Svc Strategy discusses quality perspectives that must be considered:

a. Level of excellence

b. Value for money

c. Conformance to specs

d. Meeting or exceeding expectations

Front 156

SV&T Principles: Define a Service

Back 156

A service is defined by a service packages that comprises one or more service level packages and reusable components, many of which are services (e.g. supporting services). The service package defines the service utilities and warranties that are delivered through the correct functioning of the particular set of identified service assets.

Front 157

SV&T: Design a Service

Back 157

Related to the context in which a service will be used (categories of customer asset). Attributes of a service characterize the form and function of the service from a use perspective

Front 158

SV&T: Service Design Package

Back 158

Defines the agreed requirements of the service, expressed in terms of the service model and Service Operations plan that provide key input to test planning and design

Front 159

SV&T: Service Models

Back 159

Show how service assets interact with customer assets to create value. Service models describe the structure of a service (how the CIs fit together) and the dynamics of the service (activities, flow of resources and interactions). A service model can be used as a template or blueprint for multiple services

Front 160

SV&T Key Concepts

Back 160

Service Quality & Assurance: Delivered through verification and validation, which in turn are delivered through testing.

Front 161

SV&T Key Concepts: Validation

Back 161

Confirms that the requirements for a specific intended use or application have been fulfilled. Provides confidence that a system or service is able to accomplish its intended goals and objectives (e.g. Capacity and demand)

Front 162

SV&T Key Concepts: Verification

Back 162

Confirmation through objective evidence that specified requirements have been fulfilled (e.g. service asset meets its specs)

Front 163

SV&T Key Concepts: Test Strategy

Back 163

Overall approach to organizing testing and allocating testing resources

Front 164

SV&T Test Strategy Activities

Back 164

1) Translate service requirements and service design to test requirements and test models

2) Establishing best-approach to optimize test coverage

3) Translating service acceptance criteria into entry and exit criteria at each level of testing

4) Translating risks and issues from the impact, resource and risk assessments into test requirements

5) ID skills, people and defining roles and responsibilities

6) Understanding mandatory and optional deliverables

7) Defining, managing, monitoring and controlling the test activities

Front 165

SV&T: Service Acceptance Testing

Back 165

Starts with verification of service requirements. Stakeholders signing off include business customers, users suppliers and service providers

Front 166

SV&T: Test Models include:

Back 166

Test plan, what is to be tested, and the test scripts that define how each element will be tested

Front 167

SV&T: Purpose of Test Models

Back 167

1) Provide traceability back to requirements

2) Enable auditing through test execution, evaluation & reporting

3) Ensure that test elements can be managed and changed

Front 168

SV&T: Focus and Perspective

Back 168

Focus is on delivery per requirements based on users, deployment and operational perspectives

Perspectives can include: Service Design (functional, management and operational), Technology design, Process design, Measurement design, Documentation, Skills and Knowledge

Front 169

SV&T: Levels of Testing and Test Models

Back 169

Building each level of testing to be performed so as to meet the entry and exit criteria using different test models. (e.g. "V" Model)

Front 170

SV&T: Testing approaches and techniques to meet different types of service, service model, risk profile, skill levels, test objectives and levels of testing. Identify examples:

Back 170

1) Document Review

2) Simulation

3) Scenario testing

4) Prototyping

5) Regression testing (identifying issues/non-functionality post-enhancement/patch/configuration change)

Front 171

SV&T: Types of testing

Back 171

1) Service requirements and structure testing (Service provider users and customers)

2) Service Level testing (Service Level Managers, operational managers and customers)

3) Warranty and assurance tests-fit-for-use testing (Availability, Capacity, Continuity and Security)

4) Usability (Users and maintainers)

5) Contract and regulation testing (audits)

6) Compliance testing (fraud check)

7) Service Management testing

8) Operational test--Systems and services

9) Regression testing

Front 172

SV&T:Activities

Back 172

1) Validation & Test Management

2) Plan and Design Tests

3) Verify test plans and test designs

4) Prepare test environment

5) Perform tests

6) Evaluate exit criteria and report

7) Test clean up and closure

Front 173

SV&T: Define entry criteria

Back 173

The criteria that must be achieved before testing can begin

Front 174

SV&T: Define exit criteria

Back 174

The criteria that must be achieved to end testing (without exit criteria, this would be running out of time or resources...)

May be: Main functionality available/unavailble; important faults cleared; other faults recorded; documentation updated, etc.

Front 175

SV&T: Validation & Test Management

Back 175

Planning, control and reporting of activities through the test stages of Service Transition:

-Planning test resources

-Prioritizing and scheduling what's to be tested, and when

-Checking incoming Known Errors and documentation are processed

-Monitoring progress and collating feedback from validation and test activities

-Management of incidents, problems, errors, non-conformances, risks and issues discovered during transition

-Consequential changes, to reduce errors going into production

-Capturing configuration baseline

-Test metrics collection, analysis, reporting and management

Front 176

SV&T: Plan and Design Tests

Back 176

1) Resourcing

**HW, infrastructure, staff/skills, capacity, etc.

**Business/customer resources required (e.g. components or raw materials for production control services, cash for ATM services, etc.)

**Supporting services, including access, security, communications, catering, etc.

2) Schedule of milestones, handover and delivery dates

3) Agreed time for consideration of reports and other deliverables

4) Point and time of delivery and acceptance

5) Financial requirements--budgeting and funding

Front 177

SV&T: Verify test plans and test design

Back 177

Ensure:

1) Test model delivers adequate and appropriate test coverage for the risk profile of the service

2) The test model covers the key integration aspects and interfaces

3) That the test scripts are accurate and complete

Front 178

SV&T: Prepare test environment

Back 178

1) Prepare the test environment by using the services of the build and test environment resources, and also use the Release and Deployment processes to prepare the test environment where possible

2) Capture a configuration baseline of the initial test environment

Front 179

SV&T: Perform Tests

Back 179

1) Carry out the tests using manual or automated techniques and procedures. Testers must record their findings during the tests. If a test fails, the reasons for failure must be fully documented. Testing should continue according to the test scripts and test plans if possible.

2) When part of a test fails, the incident or issues should be resolved or documented (e.g. a known error) and the appropriate re-tests should be performed by the same tester

Front 180

SV&T: Evaluate exit criteria and report

Back 180

1) Actual results compared to expected results

2) Results interpreted in terms of "pass/fail"; risk to the business/service provider; or, if there is a change in a projected value

3) Produce the report: Gather the test metrics and summarize the results

Front 181

SV&T: Test Clean Up & Closure

Back 181

1) Ensure that test environments are cleaned up or initialized

2) Review the testing approach and identify improvements to input to the design/build, buy/build decision parameters and future testing policy/procedure

Front 182

SV&T Roles

Back 182

SV&T Process Owner

SV&T Process Manager

SV&T Process Practitioner

Front 183

SV&T Triggers

Back 183

Scheduled activity on the:
1) Release Plan

2) Test Plan

3) Quality Assurance Plan

Front 184

SV&T Inputs

Back 184

SDP (including Service Charter; Service Provider interface definitions; Operation models; Capacity/resource models; Financial/economic/cost models; Test conditions and expected results; Design and interface specifications; R&D Plans; Acceptance criteria

Front 185

SV&T Outputs

Back 185

1) Configuration baseline of the testing environment

2) Testing carried out

3) Results and analysis of tests (comparison of expected with actual, risks identified)

Front 186

SV&T Interfaces

Back 186

SV&T supports all of the R&D steps within Service Transition. Test strategy helps ensure that the testing process works within all stages of the service lifecycle:

Service Design Coordination (to ensure that designs are testable)

CSI (to feed failure information and improvement ideas resulting from testing)

Service Operations (Use maintenance tests to ensure efficiency of services and to be adaptable to changes)

Service Strategy (Accommodate testing by adequate funding, resources, etc.)

Front 187

SV&T: CSFs

Back 187

1) Understanding the different stakeholder perspectives that underpin effective risk management for the Change Impact Assessment and test activities

2) Provide evidence that the service assets and configurations have been built and implemented correctly in addition to delivering what the customer needs

3) Achieving a balance between the cost of testing and effectiveness of testing

Front 188

SV&T KPIs for CSF Understanding the different stakeholder perspectives that underpin effective risk management for the change impact assessment and test activities

Back 188

1) Roles and responsibilities for impact assessment and test activities have been agreed and documented

2) Increase in satisfaction ratings in stakeholder survey of the service validation and testing process

Front 189

SV&T KPIs for CSF:
Providing evidence that the service assets and configuration have been built and implemented correctly in addition to the service delivering what the customer needs

Back 189

1) Increased percentage of service acceptability criteria that have been tested for new and changed services

2) Increased percentage of services for which build and implementation have been tested, separately from any tests of utility or warranty

Front 190

SV&T KPIs for CSF: Achieving a balance between cost of testing and effectiveness of testing

Back 190

1) Reduced variance between cost of testing and effectiveness of testing

2) Reduction in business impact due to delays in testing

Front 191

SV&T Challenges

Back 191

1) Inability to maintain a test environment and test data that match the live environment

2) Insufficient staff, skills and testing tools to deliver adequate testing coverage

3) Projects overrunning and allocated testing time-frames being squeezed to restore project go-live dates--but at the cost of quality

4) Development of standard performance measures and measurement methods across projects and suppliers

5) Projects and suppliers estimating delivery dates inaccurately and causing delays in scheduling service transition activities

Front 192

SV&T Risks

Back 192

1) Unclear expectations/objectives

2) Lack of understanding of the risks

3) Resource shortages

Front 193

Change Evaluation Purpose

Back 193

Provide a consistent and standardized means of determining the performance of a service change in the context of likely impacts on business outcomes, and on existing and proposed services and IT infrastructure

Front 194

Change Evaluation Objectives

Back 194

1) Set stakeholder expectations correctly and provide effective and accurate information to ChM

2) Evaluate the intended effects of a service change and as much of the unintended effects as is reasonably practical

3) Provide good quality outputs so that ChM can expedite an effective decision on Change Authorization

Front 195

Change Evaluation Scope

Back 195

All significant changes requiring a formal evaluation to provide the Change Authority with advice and guidance on authorization decisions

Front 196

Change Evaluation Value to Business

Back 196

1) Establish the use made of resources in terms of delivered benefit and this information will allow a more accurate focus on value

2) Ability to analyze future improvements to the process of Change and the predictions and measurement of service change performance

Front 197

ChEvaluation Policies

Back 197

1) Service designs or service changes will be evaluated before being transitioned

2) Every change must be evaluated, but only significant changes will use the formal ChE process; criteria must be defined to establish which changes are within the scope of this process

3) ChE will identify risks and issues related to the service that is being changed and to any other services or shared infrastructure

4) Any deviation from predicted to actual performance will be managed by the customer or customer representative by:

** Accepting the change, even though the actual performance is different from the predicted performance

**Rejecting the change

**Requiring a new change to be implemented with revised predicted performance agreed in advance

Front 198

ChEvaluation Principles

Back 198

1) As far as practical, the unintended as well as the intended effects of a change need to be identified, and their consequences understood and considered

2) A service change will be fairly, consistently, openly, and wherever possible, objectively evaluated

3) An evaluation report or interim evaluation report will be provided to ChM to facilitate decisionmaking at each point where authorization is required

Front 199

ChEvaluation Key Concepts: PDCA

Back 199

PDCA: Plan, Do, Check, Act: Ensures consistency across all evaluations

Front 200

ChEvaluation Key Concepts:

Performance

Back 200

The warranties and utilities of a service

Front 201

ChEvaluation Key Concepts:

Performance Model

Back 201

A representation of a service that is used to help predict performance

Front 202

ChEvaluation Key Concepts:

Predicted Performance

Back 202

The expected performance of a service following a service change

Front 203

ChEvaluation Key Concepts:

Actual Performance

Back 203

The performance achieved following a service change

Front 204

ChEvaluation Key Concepts:

Evaluation Report

Back 204

A report generated by the ChEvaluation process, which is passed to ChM and consists of:

** A risk profile

** A deviations report

** A recommendation

** A qualification statement

Front 205

ChEvaluation Process Activities

Back 205

1) Plan evaluation

2) Understand the intended effects of a change

3) Understand the unintended effects of a change

4) Evaluation of predicted performance

5) Evaluation of actual peformance

6) Manage risk

7) Produce evaluation report

Front 206

ChEvaluation Roles

Back 206

ChEvaluation Process Owner

ChEvaluation Process Manager

ChEvaluation Process Practitioner

Front 207

ChEvaluation Triggers

Back 207

Request for evaluation from ChM

Front 208

ChEvaluation Inputs

Back 208

1) SDP

2) Ch Proposal

3) RFC, change record, and detailed documentation

4) Discussions with stakeholders

5) Test results and report

Front 209

ChEvaluation Outputs

Back 209

1) Interim evaluation reports for ChM

2) Evaluation report for ChM

Front 210

ChEvaluation Interfaces

Back 210

1) Transition planning and control

2) ChM

3) Service Design Coordination

4) SLM & BRM

5) SV&T

Front 211

ChEvaluation CSFs

Back 211

1) Stakeholders have a good understanding of the expected performance of new and changed services

2) ChM has good quality evaluations to help them make correct decisions

Front 212

ChEvaluation KPIs: CSF "Stakeholders have a good understanding of the expected performance of new and changed services"

Back 212

1) Reduced number of incidents for new or changed services due to failure to deliver to expected utility or warranty

2) Increased stakeholder satisfaction with new or changed services as measured in customer surveys

Front 213

ChEvaluation KPIs: CSF "ChM has good quality evaluations to help them make correct decisions"

Back 213

1) Increased percentage of evaluations delivered by agreed times

2) Reduced number of changes that have to be backed out due to unexpected errors or failures

3) Reduced number of failed changes

Front 214

ChEvaluation Challenges

Back 214

1) Developing standard performance measures and measurement methods

2) Understanding the different stakeholder perspectives

3) Understanding and being able to assess the balance between managing and taking risks

4) Measuring and demonstrating less variation in predictions during and after transition

5) Taking a pragmatic and measured approach to risk

6) Communicating the organization's attitude to risk and approach to risk management

7) Building a thorough understanding of risks

8) Encouraging a risk-management culture

Front 215

ChEvaluation Risks

Back 215

1) Lack of clear criteria for when ChEvaluation should be used

2) Unrealistic expectations of the time required for ChEvaluation

3) ChEvaluation personnel with insufficient experience or organizational authority

4) Projects and suppliers estimating delivery dates inaccurately and causing delays

Front 216

Knowledge Management Purpose

Back 216

1) To share perspectives, ideas, experience and information

2) To ensure that these are available in the right place at the right time to enable informed decisions

3) To improve efficiency by reducing the need to rediscover knowledge

Front 217

KM Objectives

Back 217

1) Improve the quality of management decisions

2) Enable service provider to be more efficient and improve the quality of their service

3) Ensure that staff have a clear and common understanding of the value that their services provide to customers

4) Maintain a SKMS that provides controlled access to knowledge, information and data

5) Gather, analyze, store, share, use and maintain knowledge, information and data throughout the service provider organization

Front 218

KM Scope

Back 218

1) Relevant to ALL lifecycle stages

2) Scope includes oversight of the management of knowledge, information, and data from which the knowledge is derived

3) The scope excludes detailed attention to the capture, maintenance and use of configuration data

Front 219

KM Value to Business

Back 219

1) Conformance with legal and other requirements

2) Documented requirements for retention of each category of data, information and knowledge

3) Defined forms of data, knowledge and information in a fashion that is easily usable by the organization

4) Data, information and knowledge that is current, complete and valid

5) Data, information and knowledge to the right people at the right time

6) Disposal of data, information and knowledge as required

Front 220

KM Policies & Principles

Back 220

1) Knowledge and information supporting the services will be stored in a way that allows staff to access them when and where they are needed

2) All policies, plans and processes must be reviewed at least once per year

3) All knowledge and information should be created, reviewed, approved, maintained, controlled, and disposed of following a formal documented process.

Front 221

Data

Back 221

Raw numbers

Front 222

Information

Back 222

Who, what, when, where?

Front 223

Knowledge

Back 223

How?

Front 224

Wisdom

Back 224

Why?

Front 225

KM Process Activities

Back 225

1) Knowledge Management Strategy

2) Knowledge Transfer

3) Managing data, information and knowledge

4) Using the SKMS

Front 226

KM Process Activities: KM Strategy

Back 226

Strategy addresses:

1) Governance model

2) Organizational changes underway, planned and consequential changes in roles and responsbilities

3) Establishing roles and responsibilities and ongoing funding

4) Policies, processes, procedures and methods for KM

5) Technology and other resource requirements

6) Performance measures

Front 227

KM Process Activities: Knowledge Transfer (considerations)

Back 227

1) Transfer f knowledge to other people and to other parts of the organization at specific points in the lifecycle

2) Analyzing the knowledge gap

3) Techniques based on: Learning style; Knowledge visualization; Driving behavior; Seminars, webinars, advertising; Journals/Newsletters; Discussion forums and social media

4) Creating motivation to acquire and transfer knowledge

Front 228

KM Process Activities: Managing Data, Information and Knowledge`

Back 228

1) Establishing data, information and knowledge requirements

2) Define the information architecture

3) Establishing data, information and KM procedures

4) Evaluation & improvement

Front 229

KM Process Activities: Using the SKMS

Back 229

All training and knowledge material must be aligned to the business perspective. Examples:

-Business language and terminology and how IT terminology is translated

-The business processes and where IT underpins them

-Any SLAs and supporting agreements and contracts that would change as a result of the new Service Transition

Front 230

KM: Using the SKMS--Useful activities

Back 230

1) Involvement in Development, Requirement mapping or testing

2) Log analysis

3) Vendor programs/seminars

Front 231

KM: Useful materials include:

Back 231

1) Process maps to understand all integrated activities

2) Any known error logs and the workarounds--particularly important for the Service Desk

3) Business and other public calendars

Front 232

KM Roles

Back 232

1) KM Process Owner

2) KM Process Manager

3) KM Process Practitioner

Front 233

KM Triggers

Back 233

1) BRM storing the minutes of a customer meeting

2) Updates to the service catalog or service portfolio

3) Modification of an SDP

4) Creation of a new or updated capacity plan

5) Receipt of a updated user manual from a supplier

6) Creation of a customer report

7) Updates to the CSI register

Front 234

KM Inputs

Back 234

1) All knowledge, information and data used by the service provider

2) Relevant business data

Front 235

KM Outputs

Back 235

1) Knowledge required to make decisions and manage the IT services

2) Errors detected during transition along with their workarounds

3) Information captured by service operation staff (especially Incident and Problem Mgt)

4) Information captured by Svc Transition staff

Front 236

KM Interfaces

Back 236

1) Service Operations: errors in the service discovered during transition are recorded and analyzed and made available to svc ops.

2) Ops staff: service desk/incident mgt staff are points of capture for much every day svc mgt data

3) Problem mgt staff are key users, and generally responsible for normalizing data, developing and maintaining scripts for data capture in incident mgt

4) Transition staff: captures relevant data at all lifecycle phases

5) CSI and Svc Design: ST staff capture data and information relevant to adaptability and accessibility of the service as designed, to be fed back via CSI to svc. design for "course corrections" and other design adaptations, and application for future transition projects

Front 237

KM CSFs

Back 237

1) Availability of knowledge and information that helps to support management decisionmaking

2) Reduced time and effort required to support and maintain services

3) Sucessful implementation and early life operation of new and changed services with few errors related to lack of/inaccurate knowledge

4) Reduced reliance on personnel for knowledge

Front 238

KM KPIs: "Availability of knowledge and information that helps to support management decision making"

Back 238

1) Increased number of accesses to SKMS by managers

2) Increased percentage of SKMS searches by managers that receive a rating of "good"

Front 239

KM KPIs: "Reduced time and effort required to support and maintain services."

Back 239

1) Increased number of accesses to the SKMS by service ops teams

2) Increased percentage of incidents solved by use of known errors

3) Increased results in KM satisfaction survey of service ops teams

Front 240

KM KPIs: "Successful implementation and early life operation of new and changed services with few knowledge-related errors"

Back 240

1) Reduced number of incidents and problems categorized as "knowledge related"

2) Increased percentage of successful service transitions

Front 241

KM KPIs: "Reduced dependency on personnel for knowledge"

Back 241

1) Increased number of times that the SKMS is accessed

2) Increased percentage of SKMS searches that receive a rating of "good" from the user

3) Increased scores in regular customer satisfaction survey for knowledge management

Front 242

KM Challenges

Back 242

1) Justifying the effort needed for a consistent architecture for managing data, information and knowledge

2) Each group or team within the service provider may own and manage information that they use

3) To help all the stakeholders understand the added value that a more holistic approach to KM can bring

4) Continue to demonstrate the value of the SKMS

Front 243

KM Risks

Back 243

1) Focusing on tools rather than the creation of value

2) Insufficient understanding of what knowledge, information and data are needed by the organization

3) Lack of investment in the tools and people needed to support the SMKS

4) Spending too much effort on knowledge capture with insufficient attention to knowledge transfer and reuse

5) Lack of support and commitment from stakeholders

Front 244

ST Summary:

Transition Planning and Support is responsible for providing overall ___________ for service transitions and for ___________________ the resources they require.

Back 244

1) planning

2) coordinating

Front 245

ST Summary:

ChM ensures ____________ over the lifecycle of all changes, enabling ____________ changes to be made with minimum _________________ to IT Services

Back 245

1) Control

2) Beneficial

3) Disruption

Front 246

ST Summary:

SACM ensures that assets required to ___________ ___________ are properly controlled and that accurate and reliable information about those assets is available when and where it is needed

Back 246

Deliver services

Front 247

ST Summary:

RDM takes care of ____________, _____________, and controlling the ______________, _____________ and ___________ of new releases

Back 247

1) Planning

2) Scheduling

3) Build

4) Test

5) Deployment

Front 248

ST Summary:

SV&T ensures that new or changed IT services match the ________________ specifications and meet the __________________ of the ______________

Back 248

1) Design

2) Needs

3) Busines

Front 249

ST Summary:

ChEval tries to provide a consistent and standardized means of determining the ________________ of a service change, in the context of _____________ _______________ on business outcomes, and existing and proposed _______________ and infrastructure

Back 249

1) Impact

2) Likely impacts

3) IT Services

Front 250

ST Summary:

KM ensures improving efficiency of Service Mgt by reducing the need to _______________ knowledge and making the right __________________ available at the right time to enable informed __________________ _____________

Back 250

1) Rediscover

2) Information

3) Decision Making

Front 251

Managing People Through Service Transition: Three Aspects

Back 251

1) Managing communications & commitment

2) Managing organizational & stakeholder change

3) Stakeholder Management

Front 252

Managing People Through Service Transition: Communications and Commitment

Back 252

A major weakness in ST has always been the inability to deliver sufficient, prompt understanding of the implications, benefits and usage of IT services

Front 253

Managing People Through Service Transition: Managing Organization and Stakeholder Change

Back 253

As Change is holistic, the organization will also inevitably have to change to make use of the new and changed services

Front 254

Managing People Through Service Transition: Stakeholder Mgt

Back 254

Success of a change requires stakeholder involvement. All stakeholders must be identified: Those impacted must be aware of proposed changes and able to register their concerns and wishes--if they are excluded, their support will be lost

Front 255

Critical to Service Transition Communication

Back 255

1) Stakeholder analysis (who needs what information)

2) Staff managing ST understand impact to others

3) Two-way communication

4) Strategy established

Front 256

Communication Planning

Back 256

A. Plan

1) ID objective

2) Formal or informal? Robust or limited

3) Medium

4) Tone of each message

5) Actions prior to communication

6) How and when to involve groups

7) Can communications overcome barriers

8) All stakeholder needs considered?

9) How will communication success be measured?

B. Monitor

C. Collect Feedback

Front 257

Emotional Cycle of Change (yeah. Seriously...)

Back 257

1) Shock

2) Avoidance

3) Blame others

4) Blame self

5) Accept

6) Embrace/Own/Optimum performance

Front 258

Assessing Organizational Readiness for Changes: 8 Documents required

Back 258

1) Plan

2) Assessment Report

3) Vision/Strategy

4) Requirements (SOW, SLA, Statements, Business Case)

5) R&R interaction metrics

6) Risk Assessment Report

7) Performance measures by role

8) Baseline reports

Front 259

Monitoring Organizational Change: 3 Activities

Back 259

1) Regular checks and surveys, including customer and stakeholder feedback

2) Response/Feedback analysis and addressing issues

3) Improvements identified during PIR and fed into CSI

Front 260

Kotter's 8 Steps to Organizational Transformation

Back 260

1) Education & Commitment

2) Participation & Involvement

3) Facilitation & Support

4) Negotiation & Agreement

5) Manipulation & Co-Option

6) Explicit & Implicit Coercion

7) Rewarding desirable behavior, using peer-group pressure, encouraging, etc

Front 261

Reasons for Resistance:

Back 261

1) Loss of control

2) Excessive personal uncertainty

3) Avoid surprises

4) The different effect

5) Loss of Face

6) Fear around competence (exposure of incompetence)

7) Ripples

8) Increase in workload

9) Past resentments

10) Real threats

Front 262

Stakeholder Management: Potential Stakeholders

Back 262

1) Top Mgt & Gov't

2) Suppliers (services), Business Partners, Press & Media, Customers

3) Suppliers (products), Audits, Shareholders

4) Business areas, Ops staff, Trade unions, Program & Project Teams

Front 263

Plan for _______________ in Stakeholder Commitment

4 Categories

Back 263

Changes.

Not committed

No resistance

Helps it happen

Makes it happen

Front 264

Key activities with respect to managing communications & commitment:

Back 264

1) Establishing communication strategy

2) Communications Planning

3) Identifying the right communication methods

4) Motivating people through proper and timely communications

Front 265

Managing Organization & Stakeholder Change is critical, and includes:

Back 265

1) Understanding emotional cycle of change

2) Establishing org. roles & responsibilities

3) Determining ST's role in org change

4) Developing strategy & design for org. change

5) Planning & implementing org change

6) Determining & developing org change products

7) Assessing org. readiness for change products

8) Monitoring the progress of org. change

9) Dealing with organization and people in sourcing changes

Front 266

Stakeholder Mgt includes:

Back 266

1) Developing stakeholder mgt strategy, inc. identifying all potential stakeholders

2) Developing stakeholder map and performing an analysis

3) IDing changes in stakeholder commitment and developing a planning chart

Front 267

Organization Definitions: Function

Back 267

A logical concept referring to people and automated measures executing a defined activity

Front 268

Organization Definitions: Group

Back 268

Non-formal organization structure, grouping people together to perform similar activities

Front 269

Organization Definitions: Team

Back 269

Formal organizational structure containing people who work together to achieve a common objective

Front 270

Organization Definitions: Department

Back 270

A formal organizational structure existing to perform specific activities with a hierarchical structure

Front 271

Organization Definitions: Division

Back 271

A number of departments grouped together, normally self-contained

Front 272

Organization Definitions: Role

Back 272

A set of linked behaviors or actions performed by a person, team or group

Front 273

Factors influencing ST organizational structure

Back 273

1) Size & location(s) of organization

2) Complexity of technology used and vendors involved

3) Skill sets available for ST

4) Organization Culture

5) Organization finances

6) Mgt commitment to ST processes

7) Communication mechanisms, process integration and tools available within the organization

Front 274

Stages in Organizational Development

Back 274

1) Services through network (hallway taskers)

2) Services through direction

3) Services through delegation

4) Services through coordination

5) Services through collaboration

Front 275

3-Step Change Process for Organizations

Back 275

1) Unfreeze the organization from current state

2) Make the desired change to the new state

3) Freeze the organization in the new desired state

Front 276

Svc Transition Organizational hierarchy

Back 276

Svc Transition Manager over CCRM team and Evaluation & Test Team.

Manager of each team over practitioners on each team.

Front 277

Technical & Application Management: Function

Back 277

A team or group of people and the tools and other resources they use to carry out one or more processes or activities (e.g. Service Desk)

Front 278

Technical & Application Management: Application Management

Back 278

The function responsible for managing applications throughout their lifecycle

Front 279

Technical & Application Management:
Technical Management

Back 279

The function responsible for providing technical skills in support of IT services and management of the IT infrastructure. Technical management defines the roles of support groups as well as the tools, processes and procedures required

Front 280

Application Management in Svc Transition:

Back 280

1) Provides testing/deployment resources

2) Provides input for improvement

3) CMS/Relationship/Attribute inputs

4) Training, documentation resources

5) Vendor coordination

Front 281

Technical Management in Svc. Transition:

Back 281

1) Provides testing/deployment resources

2) Provides input for improvement

3) CMS/Attribute inputs

4) Training, documentation resources

5) Vendor Coordination

6) Infrastruture monitoring/Thresholds for changes

Front 282

Svc Transition Roles: Service Owner

Back 282

Holds the responsibility, to the customer, for the initiation, transition and maintenance of a service, as well as:

1) Ensuring ongoing service delivery & support meet agreed levels

2) Works with BRM to understand & translate customer requirements

3) Ensures consistent communication with customers

4) Assists in defining service models

5) Liase with process owners through lifecycle

6) Soliciting required data, statistics & reports for analysis

7) Represents the service across the organization

8) Serving as the point of escalation for major service incidents

9) Participating in internal and external service review meetings

10) Ensuring that service entry in the service catalogue is accurate and maintained

11) Participates in negotiating SLAs and OLAs

12) IDs improvement opportunities for inclusion in the CSI register

Front 283

Svc Transition Roles: Process Owner

Back 283

Ensures all process activities are carried out. Responsible for:
1) Sponsoring, designing and change-managing the process and its metrics

2) Defining the process strategy

3) Assisting with process design

4) Ensuring that appropriate process documentation is available

5) Periodically auditing the process

6) Communication process info & changes

7) Providing process resources

8) Ensuring that process technicians have the required knowledge

9) Reviewing opportunities for process enhancement

10) Addressing issues with the running of the process

11) ID improvement opportunities for inclusion in the CSI register

Front 284

KM Tools:

Back 284

Document Mgt

Records Mgt

Content Mgt (web tools, word processing, data/financial analysis, presentation tools, flow-charting, content mgt systems--codify, organize, version control, doc. architectures--publication & distro)

Front 285

Collaboration Tools:

Back 285

1) Community tools: Portals, social networking, email alias mgt, focus groups, templates/examples repository, online events & net shows)

2) Workflow Mgt: Workflow design, Routing objects, event svcs, gatekeeping at authorization checkpoints, state transition svcs

Front 286

Stages of introducing ST to an organization

Back 286

1) Justifying ST

2) Designing ST

3) ID impact of introducing ST on existing projects

4) Cultural Change

5) Risk and Value

Front 287

Justifying Introduction of ST:

Back 287

1) Impact vs. costs

2) Cost of failed Ch

3) Prevention of incidents/issues

4) Third-party reports

Front 288

Designing ST:

Back 288

1) Applicable policies & standards

2) Relationships (Program & Project Mgt, Internal dev teams & suppliers, customers & users, other stakeholders & other support services)

3) Budgets & resources (funding approach--for SKMS, test environmnet)

4) Resources (infrastructure, project resources, suppliers, training, competency)

Front 289

Impact of introducing ST to existing projects

Back 289

1) Alignment with the existing good practices

2) Conversion from old to new approach

3) Integration of tools & workflows

Front 290

Culture Change with introduction of ST

Back 290

1) must address concerns of all stakeholders

2) Long term view of sustaining and getting more out of ST through cooperation

3) Answering the question "What's in it for me?"

Front 291

Risks of introduction of ST

Back 291

1) Support staff being isolated

2) Higher costs

3) Disruption of Business-as-Usual

4) Lack of quick-wins

5) Delayed business benefits

Front 292

Value of introduction of ST

Back 292

1) Customer and user satisfaction

2) Reduced failures: Changes, incidents

3) Reduced cost of transitioning

4) Clarity for stakeholders