Professional Documents
Culture Documents
Overview
Reduce costs
Reduce errors
Purpose
o
Make sure that standardized methods and procedures are used to
efficiently and promptly handle all Changes.
o
Make sure that all Changes to Services Assets and CIs are
recorded in the Change Management System (CMS)
o
Make sure that overall business Risk is optimized
Goals
o
Respond to the customer's changing business requirements while
maximizing value and reducing Incidents, disruption and rework
o
Respond to the Requests for Change (RFCs) of the business and IT
that will align Services with business needs
Objectives
o
Make sure that Changes are recorded and then evaluated,
authorized, prioritized, planned coordinated, documented and
reviewed in a controlled manner
2.2. Scope
A Service Change:
Organizations must define the Changes that are within the scope of their
Service Change process. Those outside the scope might include Changes such
as at the department, organization, policy and business levels and routine
operational Changes, for example, repairs to printers or other routine Service
components.
Types of Changes
Predefined Change scope usually includes the following three types of Changes
Reduce the Mean Time to Restore Service (MTRS) through quicker and
more successful implementations of corrective Changes
Each organization counts on having reliable IT Services to perform its day-today functions. In fact, reliability and business continuity are two cornerstones
of the success and survival of any organization. Services and infrastructure
Changes can have an adverse Impact on the business by causing Service
disruptions.
Ensuring that the Service Change Management process aligns with the
business, project and stakeholder Change Management processes
Defining the performance and risk evaluation of all Changes that impact
Service capability
Basic Principles
A Change Request is a formal communication seeking an alteration to alter one
or more CIs.
Types of Change Requests
It is crucial to define the approach to manage Standard Changes and define all
related Change processes and workflows. These should become part of the
Change Process Model.
No Change should be approved without explicitly addressing the steps to take if
the Change fails. This includes back-out plans for reversible Changes and
alternative remediation approaches for irreversible Changes.
Change Process Models
Change Process Models are a way of predefining the steps that should be taken
to handle a process in an agreed way
Defined workflows
Has defined steps that seek help from other Service Management
processes to evaluate the Impact of Change
Scope of a Change Process Model
Change Process Models are designed with tasks specific to the level of control
desired by the organization. They are predefined by Change Management and
agreed with the organization. The model may be specific to type, for example,
network or PC; to severity of Impact, or to whatever is specific to the
organization.
It includes:
Escalation procedures
Standard Change
Is a low-impact Change implemented in the usual way. This includes fully
defined and preapproved Change Models that are individually recorded but not
individually assessed by Change Management. Examples include low-impact,
routine application Changes to handle seasonal variation.
A delegated authority grants approval for each standard Change.
Elements of Standard Change
The crucial elements of a Standard Change are:
Authorized in advance
Low risk
Communicating Standard Changes
After you have decided on the approach to manage all Standard Changes, you
must develop the following and communicate them to all concerned personnel
to ensure the effective application of Standard Changes:
Manage reporting
Through e-mail
5
6
The
1
2
3
4
5
6
7
Return the rejected Requests to the initiator along with reasons for the
rejection. The initiator can request for the Change again through the
correct management channels.
Assess change Requests to identify their Impact on other Services, Cis,
business operations, current Change schedules, resource requirements,
continuity plans, security plans and Service Operation practices.
Seven Rs of Change Management
Who Raised the Change?
What is the Reason for the Change?
What is the Return required from the Change?
What are the Risks involved in the Change?
What Resources are required to deliver the Change?
Who is Responsible for the build, test and implementation of the Change?
What is the Relationship between this Change and other Changes?
Additional resources
o
Impact on
Continuity plan
Capacity plan
Security plan
Service Operations
Impact
Urgency
Risk
Benefits
Costs
Risk Categorization
The organization should also assess and categorize the associated Risks to
prevent disruptions to the business or to the delivery of Services. Many
organizations use a simple matrix to categorize Risks.
2.5.3 Authorizing Changes
Before implementing a Change:
Make sure that the organization has defined the Change authorization
hierarchy.
Different types of Change will have different authorization levels. In addition,
each authorization level might include a delegated authority based on some
predefined parameters of assessment, such as the type, size, cost or Risk of
the Change.
The culture of the organization will also dictate the levels of Change
authorization.
2.5.4 Coordinating, reviewing and closing Changes
Coordinating Change Requests
Change Management is responsible for ensuring that Changes are
implemented as scheduled. This is largely a coordination role. After change
authorization, you need to coordinate the Change implementation.
Coordinating Change Requests includes tracking and coordinating them. It is
good practice to track the building of Changes in a formal way, for example,
through work orders. Change Management coordinates the Change
implementation while technical specialists build, test and implement the
Change.
Change Management has a supervisory role to ensure that all Changes that can
be tested are thoroughly tested. While testing the Change before
RFC completed
Strategic Changes
o
These Changes aim to achieve specific objectives with respect to
predefined parameters, such as organization Change, sourcing model
Change and legal or regulatory Change.
Operational changes
o
These Changes aim to affect operations. Examples are access
requests or requests to move an IT asset across locations.
Change proposals
Plans for
Change
Transition
Release
Deployment
Test
Evaluation
Remediation
Current Change schedule
Current asset or configuration Changes
Planned Configuration Baseline
Test results
Reports such as
o
Test reports
o
Evaluation reports
o
o
o
o
o
o
o
Outputs
The outputs of a Change Management are:
Rejected RFCs
Approved RFCs
Change schedule
Revised PSO
Problem Management
o
Problem Management interfaces with Change Management by
raising RFCs to implement Workarounds and to fix Known Errors.
Many RFCs originate from Problem Management. They plan an
important role in CAB meetings.
IT Service Continuity
o
You can update many procedures and plans in ITSCM through
Change Management. This is necessary to ensure accuracy and to
inform stakeholders of all the Changes.
Security Management
o
RFCs also originate from Security Management. You need to follow
Change Management to implement these Changes. Security is also a
key contributor to the CAB (to discuss security issues).
Program and Project Management must work together to align all the processes
and people involved in Service Change initiatives. The Change effort also
improves based on how closely you align the processes. The Change
Management team is allowed to attend project-related meetings.
The partnership agreement between the entities involved in the Change
process should clearly define the roles and responsibilities of each entity and
how much influence each of them can have on the Change process. You must
also check how well you align the Change processes and the tools in the
organization. If the supplier is responsible for the operational Services, conflicts
may arise.
The different entities involved in the Change process may include internal or
external vendors and suppliers that provide new or changed Services. To
manage the Change process efficiently, ensure that:
In Change Management, KPIs help analyze patterns and reasons for requested
Changes. When implemented correctly, KPIs and metrics help you measure the
Impact of Changes on the organization.
Let us now understand how the KPIs implemented in your organization help you
analyze Change Requests to spot trends.
Change Management KPIs
The KPIs applicable for Change Management are:
Change Authority
o
May be a role, person or group of people that provides formal
authorization for each Change
Change Manager
o
Receives, logs and allocates a priority level to all RFCs and rejects
the impractical ones
o
Prepares all RFCs for a CAB meeting, issues the agenda and
circulates all RFCs to CAB members before meetings to allow priori
consideration
o
Determines the participants of meetings, who receive specific
RFCs based on the nature of the RFCs, the required Changes and
their areas of expertise
o
Convenes urgent CAB or ECAB meetings for all urgent RFCs
o
Chairs all CAB and ECAB meetings
o
Authorizes acceptable Changes after considering the advice of the
CAB or ECAB
Customer(s)
User manager(s)
Application developers/maintainers
Specialists/technical consultants
To ensure that you consider all operational issues while processing an RFC,
involve the Service Operation staff in the process, right from the initial stages
(not just at the CAB or ECAB). You must also make sure that the staff is
involved in the actual Change implementation if it is in the Operations area.
This will ensure that the various scheduled tasks do not raise any conflicts.