Service Transition Flashcards

1
Q

Purpose of Service Transition

A
  • Plan and manage capacity and resources required to package, build, test, and deploy a release into prod and establish service specified by customer and stakeholder reqs
  • Consistent and rigorous framework for evaluating service capability and risk before new or changed service release or deployed
  • Establish and maintain integrity of service assets and configs
  • Good-quality knowledge and info so that change, release and deploy mgmt can expedite effective decisions
  • Efficient repeatable build and installation mechanisms used to deploy releases that can be rebuilt if required to restore service
  • Ensure service can be managed, operated, and supported
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Goals fo Service Transition

A
  • Set customer expectations
  • Enable integration of release into business processes and services
  • Reduce variations in performance
  • Reduce known errors and minimize risks
  • Ensure service can be used within reqs and constraints
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

LIfecycle Process Support Service Transition

A
  • Change Management
  • Service Asset and Config Mgmt
  • Knowledge Management
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Value to Business

A
  • Align new or changed servcie with business requirements and operations
  • Ensure customers can use new or changed service in a way that maximizes value to business operations
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Measurements

A
  • Resource utilization against capacity
  • Capabilities
  • Warranties
  • Service Levels
  • Cost against budget
  • Time
  • Quality of service (satisfaction rating, breaches)
  • Value
  • Errors and incidents
  • Risks
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Inputs to Service Transition

A
  • Service Portfolio
  • Customer Port
  • Contract Port
  • Service Lifecycle model
  • Policies
  • Strategies
  • Constraints
  • Archtitectures
  • Service Transition Reqs
  • Service Mangement Plan
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Service Design Package Contents

A
  • Service definition
  • Service structure
  • Financial/cost model
  • Capacity/resource model
  • Service Management integrated process model
  • Service Operations model
  • Design and interface specs
  • Release design
  • Deployment plan
  • Acceptance criteria
  • Requests for Change to implement required changes to environment
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Outputs from Service Transition

A
  • Approved service design package and deployment packages
  • Updated service package/bundle definining end-to-end services offered
  • Updated service portfolio and catalogue
  • Updated contract portfolio
  • Documentation of transferred/decommissioned service
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Processes within Service Transition

A
  • Transition Planning and Support
  • Release and Deployment Management
  • Service Testing and Validation
  • Evaluation
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Utility of Service

A

Business outcomes that customers expect and constraints it will remove.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Warranty of Service

A

An assurance that some product or service will be fprovided for meet certain specifications.

  • Provided in terms of availability and capacity of services
  • Ensures customer assets continue to receive utility, even if at degraded service levels
  • Ensures security for potential of customer assets
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Define and Implement a Formal Policy for Service Transition

A
  • Policies should clearly state objectives and non-compliance remediated
  • Align policies with governance framework
  • Sponsors and decision makers involved in developing policy must have commitment to implement policy
  • Use processes that integrate teams
  • Deliver changes in releases
  • Address deployment early in release design and planning stages
  • Obtain formal sign off from maangement team, sponsors, and decision makers
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Implement all changes to services through Service Transition

A
  • Single focal point for changes in production
  • People without authority to make a change in prod should be prevented from having access
  • Familiarity with Service Operations organization
  • Increase knowledge and experience of prod services
  • Each release package governed by an RFC raised via change management
  • Standardized methods for handling changes
  • Updates recorded in Configuration Management System
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Adopt a Common Framework and Standards

A
  • Implement industry best practices
  • Control Service Transition under Change and Configuration Management
  • Ensure processes adopted consistently through reviews and audits
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Maximize re-use of established processes and systems

A
  • Re-use established processes and systems
  • Capture data and info from original source
  • Develop reusable standard Service Transiton models
  • Implement industry standards and best practices
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Align service transition plans with business needs

A
  • Set user expectations
  • Provide info and establish processes to enable business change projects to integrate a change into their business processes
  • Ensure service can be used within reqs and constraints
  • Communicate and transfer knowledge to customers
  • Monitor and measure use of services
  • Compare actual performance against predicted performance
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Establish and maintain relationships with stakeholders

A
  • Set stakeholder expectations on how performance will enable business change
  • Communicate changes to stakeholders
  • Provide good quality knowledge and info to stakeholders
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Establish effective controls and disciplines

A
  • Establish and maintain integrity of all service assets and configurations
  • Automate audit activities to detect unauthorized changes
  • Clearly define who is doing what, when, and where
  • Define and communicate roles and responsibilities for handover and acceptance
  • Establish transaction-based processes for configuration, change and problem management to provide audit trail
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Provide systems for knowledge transfer and decision support

A
  • Provide quality knowledge at the right time to the right people
  • Ensure adequate training and knowledge transfer to users
  • Improve quality of information to improve user satisfaction
  • Improve quality of documentation
  • Improve quality of release and deployment documentation
  • Provide easy access to quality information
  • Establish definitive source of information
  • Provide consolidated information to enable change, release and deployment management
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Plan release and deployment packages

A
  • Release policy agreed with business and all relevant parties
  • Releases are planned well in advance
  • Resource utilization optimized to reduce costs
  • Resources coordinated during release and deployment
  • Release mechanisms ensure integrity of components
  • Emergency releases managed in line with emergency change procedure
  • Risks of backing out are assessed and managed
  • Success and faliure of release packages is measured
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Anticipate and manage course corrections

A
  • Build stakeholder expectation that changes to plans are necessary and encouraged
  • Learn from previous course corrections
  • Debrief and propagate knowledge through end-of-transition sessions
  • Manage course corrections through appropriate change management procedures
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Proactively manage resources across Service Transition

A
  • Recognize resources, skills, and knowledge required for Service Transition within organization
  • Develop a team capable of successful implementation
  • Establish dedicated resources to perform critical activities
  • Establish and manage shared resources to improve effectiveness
  • Automate repetitive and error-prone processes
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Ensure early involvement in service lifecycle

A
  • Use range of techniques to maximize fault detection
  • Identify changes that will not deliver expected benefits and change reqs or stop change before resources wasted
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Assure quality of new or changed service

A
  • Proposed changes to operational services delivered according to reqs
  • Ensure ST teams understand what customers require from a service
  • Quality assurance and testing practices provide method for assuring quality and risks of new services
  • Test environments need to reflect live environment
  • Test design and execution should be managed and delivered independently of service designer and developer
  • Perform independent evaluations of service design and new or changed service to identify risk
  • Implement problem and config mgmt processes across lifecycle
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

Proactively improve quality during ST

A
  • Detect and resolve incidents and problems during transition
  • Proactively manage and reduce incidents, problems, and errors detected during Service Transition
  • Align management of incidents, problems, and errors with prod processes
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

Purpose of Transition Planning and Support

A
  • Plan appropriate capacity and resources
  • Provide support for ST teams
  • Plan the changes to ensure integrity of all assets
  • Ensure ST issues, risks, and deviations are reported to stakeholders and decision makers
  • Coordinate activities across projects, suppliers and service teams
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

Goals of Transition Planing and Support

A
  • Plan and coordinate resources to ensure reqs realized
  • Idenitfy, manage, and control risks of failure and disruption
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

Scope of Service Transition and Planning

A
  • Incorporate design and operation reqs into transition plans
  • Managing and operating Transition Planning and Support activities
  • Maintaining and integrating plans across portfolios
  • Managing progress, changes, issues, risks, and deviations
  • Quality review of all release and deployment plans
  • Managing and operating processes, supporting systems, and tools
  • Communications with stakeholders
  • Monitoring and improving ST performance
29
Q

Release Policy

A
  • Unique ID, numbering, naming conventions for different types of releases together with description
  • Roles and responsibilities at each stage of the release and deployment process
  • Expected frequency of each type of release
  • Approach for accepting and grouping changes into a release
  • Mechanism to automate build, installation, and release distribution process
  • How configuration baseline for the release is captured and verified against actual release contents
  • Exit and entry criteria and authority for acceptance of release
  • Criteria and authorization to exit early life support and handover to SO
30
Q

Types of Releases

A
  • Major releases – new functionality
  • Minor – small enhancements and fixes
  • Emergency – corrections to small number of known errors or meet a high priority business requirement
31
Q

Transition Strategy

A
  • Purpose, goals, and objectives of ST
  • Context (service customer)
  • Scope (inclusions and exclusions)
  • Applicable standards, agreements, legal, regulatory, contractual
  • Organizations and stakeholders involved in transition
  • Framework for ST (policies, roles and responsibilities, resource planning)
  • Criteria (entry and exit; stopping or re-starting activities
  • ID of requirements and content
  • People
  • Approach
  • Deliverables
  • Schedule of Milestones
  • Financial requirements
32
Q

ST Lifecycle Stages

A

SDP defines stages

  • Acquire and test CIs and components
  • Build and Test
  • Service release test
  • Service operational readiness test
  • Deployment
  • Early life support
  • Review and close service transition
33
Q

ST Preparation

A
  • Review and accept inputs from other lifecycle stages
  • Review and check input deliverables (SDP, Service Acceptance Criteria and evaluation report)
  • ID, raising, and scheduling RFCs
  • Checking configuration baselines recorded in Config Mgmt before start of ST
  • Checking transition readiness
34
Q

ST Plan

A

describes the tasks and activities required to release and deploy a release into test and prod environments

  • Integrated planning
  • Adopting program and project management best practices
  • Reviewing plans
35
Q

ST Planning & Support

A
  • Advice to stakeholders
  • Administration
  • Progress monitoring and reporting
36
Q

Triggers, Inputs, Outputs

A

Trigger is authorized RFC

Inputs –

  • Authorized RFC
  • Service Design Package
  • Release Package
  • Service Acceptance Criteria

Outputs –

  • Transition strategy
  • Integrated set of ST plans
37
Q

Change Management Purpose & Goals

A

Purpose

  • Standardized methods and procedures used for efficient and prompt handling of changes
  • All changes to service assets and CIs recorded in CMS
  • Overall business risk optimized

Goals

  • Respond to customer’s changing business reqs maximizing value and reducing incidents
  • Respond to business that align with business needs
38
Q

Change Management Scope

A

Service change – addition, modification. removal of authorized service component and documentation

39
Q

Risk Indicators of Poor Change Management

A
  • Unauthorized changes
  • Unplanned outages
  • Low change success rate
  • High number of emergency changes
  • Delayed project implementations
40
Q

Change Management Policies

A
  • Create culture of change management across organization where zero tolerance for unauthorized changes
  • Aligning CM process with business, project, and stakeholder CM processes
  • Prioritization of change
  • Establishing accountability and responsibilties for changes through service lifecycle
  • Segregation of duty controls
  • Establishing single focal point for changes
  • Preventing unauthorized people to make a change and having access to prod
  • Intergration with other service mgmt processes
  • Change windows
  • Performance and risk evaluation
  • Performance measures for the process
    *
41
Q

Change Request

A

formal communication seeking alteration to one or more CIs –

  • RFC
  • Service desk call
  • Project initiation document

Avoid bureaucratic approach for minor changes

Standard change procedure

42
Q

Change Process Models

A

Process model – way of predefining steps that should be taken to handle a process in an agreed way. Support tools can monitor process.

43
Q

Remediation Planning

A

no change shoudl be aapproved without having explicitly addressed question of what to do if it is not successful.

Back-out plan

44
Q

Assess and Evaluate Change

A
  • Risk categorization
  • Evaluation of Change
  • Allocation of Priorities
  • Change Planning and Schedule
  • Assessing Remediation
45
Q

Change Advisory Board

A

Exists to support the authorization of changes and to assist Change Management in the assessment and prioritization of changes. Changes assessed from both a business and technical viewpoint.

CAB chaired by change manager and includes stakeholder representatives

CAB convened based upon changes being considered

May vary in make-up

Should involve suppliers

Should reflect users’ and customers’ views

Likely to include problem manager, service level manager, and customer relations staff for part of time

46
Q

Types of Changes Triggering Change Management

A
  • Strategic changes
  • Change to one or more services
  • Operational change
  • Changes to deliver continuous improvement
    *
47
Q

Change Management Inputs

A

Change proposal often accompanies RFC. Change proposal is based on a change model. Inputs include:

  • Policy and strategy for change and release
  • RFC
  • change proposal
  • plans (change, transition, release, deployment, test, evaluation, remediation)
  • current change schedule and PSO
  • Current assets or CIs
  • As-planned configuration baseline
  • Test results, test report, evaluation report
48
Q

Change Management Outputs

A
  • Rejected RFCs
  • Approved RFCs
  • Change to the services resulting from approved RFC
  • New, changed, disposed of assets or CIs
  • change scheduled
  • revised PSO
  • authorized change plans
  • change decisions and actions
  • change documents and records
  • change management reports
49
Q

Change Management Interfaces

A
  • Integration with business change processes
  • Program and project management
  • Sourcing and partnering
50
Q

Change Management interfaces with Service Management

A
  • Asset and Configuration Management
  • Problem management
  • IT service continuity
  • Security management
  • Capacity and demand management
51
Q

Service Asset and Configuration Management Purpose

A
  • Identify, control… service assets and CIs
  • Account for integrity of saci
  • Protect integrity of saci
  • Ensure integrity of saci
52
Q

SACM Policies

A
  • Ensuring operations costs are resources commensurate with potential risks
  • Corporate governance requirements
  • Delivery of service in accordance with SLA
  • Available, reliable cost-effective services
  • Clear economic and performance criteria
  • Application of whole-life cost appraisal methods
  • Transform to predict and prevent proactive management
  • Maintain adequate asset and configuration information
  • Level of control and requirements for traceability and auditability
  • Continual improvement methods
  • Accurage asset and config info
  • Integration of SACM with other processes
  • Migration to a common asset and CMS architecture
  • Automation to reduce errors and costs
53
Q

Configuration Model

A
  • A logical model of the services and infrastructure that is a single common representation used by all parts of ITSM
54
Q

Configuration Item

A

An asset, service component or other tiem that is, or will be, under the control of configuration management

  • Service lifecycle CIs (business case, SDP, release and change plans)
  • Service CIs (management, organization, people)
  • Organizational CIs (organization business strategy)
  • Internel CIs (individual projects)
  • External CIs (external customer requirements)
  • Interface CIs (end-to-end service service)
55
Q

Configuration Management System

A

Holds all information for CIs. CMS maintains relationships between all service components and any related incidents, problems, known errors, change and release documentation

56
Q

Secure Libraries and Secure Stores

A
  • Secure library is a collection of software. Libraries are used for controlling and releasing components throughout service lifecycle
  • Secure store warehouses IT assets. Secure stores used for desktop deployment.
57
Q

Definitive Media Library

A

Secure library where definitive authorized versions of all media CIs are stored and protected. Stores master copies of all versions that have passed QA.

Foundation for Release and Deployment management.

58
Q

Definitive Spares

A

Secure storage of definitive hardware spares. Spare components and assemblies that are maintained at the same level as the comparative systems within the controlled test or live environment.

59
Q

Configuration Management Activity Model

A
  • Management and planning
  • Configuration identification
  • Configuration Control
  • Status Accounting and reporting
  • Verification and audit
60
Q

CI Selection

A

CIs should be selected in top down approach

61
Q

Release Unit

A

Portion of the service or infrastructure normally released together in accordance with the release policy.

62
Q

Challenges to SACM

A
  • Persuading technical support staff to adopt check in/out policy
  • Funding
  • Just collecting data because it is possible
  • Lack of management support
63
Q

Release and Deployment Management

A
  • Define and agree on release and deployment plans with stakeholders
  • Ensure release package consists of releated assets and service components compatible with each other
  • Ensure integrity of RP maintained
  • Ensure all packages tracked, tested, backed out
  • Ensure organization and stakeholder change is managed
  • Record and manage deviations
  • Ensure knowledge transfer to customers
  • Ensure skills transfer to operations
64
Q

SDP Role in Release Design

A

Service Design defines approach to transitioning from current service to new or changed service. SDP defines the service and solution design components to be transitioned.

65
Q

Big Bang v. Phased

A
  • Big Bang useful for application changes and when consistency of service across organization is important
  • Phased approach – scheduled rollouts, useful in retail organizations
66
Q

Push v. Pull

A

Push is service component deployed from central area to target locations.

Pull requires user to download

67
Q

Release and Deployment Models

A
  • Release structure
  • Exit and entry criteria
  • Controlled environments
  • Roles and responsibilities
  • Release baseline model
  • Template release and deploy schedules
  • Supporting ystems for documenting activities
  • handover activities
68
Q

Release and Deployment Plans

A

Should be authorized through change management

69
Q
A