Service Transition
Change Management
Introduction
A Change must be implemented efficiently
to ensure that it provides a permanent
solution to a problem, with minimum
disruption
to services.
Changes include
new
services as well as current services
that need to be changed.
Purpose
The purpose of Change
Management is to ensure that standardized methods and procedures are used for controlled, efficient and prompt
handling of all Changes, in order to minimize the impact of change-related incidents upon service quality.
Change Management
responds to the business and IT
Requests for Change that will align the services with the business needs.
The Change Management
process
aims at providing the
managed and controlled
environment that the current
business requires.
Objectives
The objectives of change management are to:
• Respond to the customer’s changing business requirements
while maximizing value and reducing incidents, disruption and re-work.
• Respond
to
the
business and
IT
requests for change that will align the services with the business needs.
• Ensure
that
changes
are
recorded and evaluated, and that authorized changes are prioritized, planned,
tested, implemented, documented
and reviewed in a controlled manner.
• Ensure that all
changes to
configuration items
are
recorded in the configuration management system.
• Optimize overall business risk, it is often correct to minimize business risk, but sometimes
it
is appropriate
to
knowingly
accept
a
risk
because
of
the potential benefit.
Scope
Change can be defined in many ways. The ITIL definition of a
change is ‘the addition,
modification or removal
of anything that
could have an effect on IT services’. The scope of change management covers changes to all configuration items across the whole service lifecycle
Furthermore, the scope of the change management process also includes:
• Service solutions for new or changed services, including all of the functional
requirements, resources and capabilities needed and agreed
• Management information systems and tools, especially the service portfolio, for the management and control of services through their lifecycle
• Technology architectures and management architectures required to provide
the services
• Processes needed to design,
transition, operate
and improve the services
• Measurement
systems,
methods and
metrics
for
the services, the architectures, their constituent components and the processes.
Concept (Service
Change)
Change Management applies some of the most critical concepts in ITIL® that needs to be well-understood.
Service Change
is
defined as “The addition,
modification and removal
of an authorized, planned or supported
service or service component
and its associated documentation.”
Reasons for changes
to arise:
• Proactively: as a means of seeking business benefits
• Reactively: as a means of resolving errors and adapting to changing circumstances
Other Concepts
Other vital concepts in Change Management are as follows:
• Request for Change
(RFC): It is the formal
request
for a change
made
by those involved
in the service, end-users, IT staff or management from business
or IT. All RFCs should be documented
and logged
for traceability
purposes.
• Change Proposal: This
applies
for cases
where
changes
have
significant implications to the organization as a
whole or financially. A Change Proposal requires full details of the proposed change, reasons justified and approved by appropriate levels of business management.
Scope of Service Change
The scope of Change
Management covers changes to baseline Service Asset and
Configuration Items.
It covers interfaces
to internal and external
service providers where there are shared assets and Configuration Items which need to be governed by Change Management. Understanding the
Service Portfolio will
allow all parties to assess the impact of changes to current and new services.
There are three types of changes in the scope of a Service Change:
• Strategic
Changes: Changes
brought by Service Strategy and business
management
• Tactical Changes: Changes
brought
by Service Design,
Continual Service
Improvement and the service
level management process.
• Operational
Changes: Changes brought
by
Service Operations,
involving corrective changes
ore resolving errors
Change Proposal
A change proposal
is used to communicate a high level description of the change. The
change
proposal is
normally created by the service
portfolio management process and is passed to change management for authorization.
In some organizations, change proposals may be created by a program
management office or by individual projects.
The change proposal should include:
• A high-level description of the new,
changed
or
retired service,
including business outcomes to be supported, and utility and warranty to be provided
• A full business case including risks, issues and alternatives, as well as a budget and financial expectations
• An outline
schedule for design and implementation of the change.
Types of Requests and Changes
Different types of changes may require different types of change requests.
The different types of change requests
are:
• Normal Change: Follows the Normal change management process
and can be categorized as Minor, Major
or Significant in
nature. Some
Normal Changes are standard
changes which require simple processes.
• Standard Change: A change
to
a
service or infrastructure whereby the change has been pre-authorized
by Change Management. These are often handled by the Request Fulfillment process.
• Emergency Change: A change
with substantial impact on the business, that needs
to be attended to immediately due to service failure without
sacrificing normal management controls.
Activities
Change management
ensures that there is a standard process to handle all changes, of which the activities are as follows:
• Create and record RFCs
• Review RFC and change proposal
ƒ Filtering changes
• Assess and evaluate
the change
ƒ Establish appropriate level of change authority
ƒ Establish relevant areas of interest
• Authorize the change
ƒ Obtaining authorization/rejection
ƒ Communicating the decision with stakeholders and initiator of RFC
• Plan updates
• Coordinate Change implementation
ƒ Where the change is actually built, tested and implemented
• Review and close the Change
ƒ Collating the change documentation
ƒ Review the change(s) and change documentation
ƒ Closing the change document when all actions are completed
Depending on the type of change, the exact procedures
to execute the activities may be different.
“Seven Rs” of Change Management
All Requests for Change (RFCs) must be evaluated before approval.
The 7 Rs of Change Management
state seven questions that must be answered to properly
evaluate a change:
• Who raised the change?
• What is the reason for the change?
• What is the return required from this 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?
Planning and Scheduling
Changes need to be carefully
planned to ensure tasks and processes are carried out accordingly and without
ambiguity. When planning a
change, Change Management
should carefully
consider
the impact on the business of the implementation
rather than
focusing entirely on IT needs.
Change Management
coordinates the
production
and
distribution of the follwoing
deliverables:
• Schedule of Change (SC): Contains details of all authorized changes ready for
implementation
as well as the implementation dates.
• Projected Service Outage (PSO): Contains
details of changes to agreed SLAs and service availability as well as planned downtime.
Organizations may find it helpful to predefine change process models
and apply them to appropriate changes
when
they occur. This set of predefined steps
should be taken when dealing with specific types of changes in an agreed upon way.
No change should be approved without taking into consideration of solutions, if the change is unsuccessful. Ideally, a back-out
plan or remedial
plan will
restore the organization to its initial situation. However, it is important to note that not all changes are reversible, in which case an alternative approach to remediation is required.
Authorising Change
Formal authorization
for a change is obtained from a change authority that may be a role, person or a group of people.
If for any reason, the assigned change authority discovers the change possesses a higher level of risk,
the authorization
request is escalated to the appropriate higher level of authorization.
While the responsibility
for change authorization
lies with the Change Manager, he still must gain Financial Approval, Business Approval and Technology Approval.
The following must also be taken into consideration:
• The implications of performing the
change, as well as the impacts
of NOT
implementing the change.
• The importance of empowering the change
manager as its primary role is to protect the integrity of the IT infrastructure.
Change
Advisory Board
• Change Advisory Board (CAB)
ƒ This is a very important
part of Change Management, which
constitutes
a group of people selected for their capabilities and expertise in various
areas of IT.
ƒ The CAB members advise the Change Manager in taking
decisions on the RFCs. The Change Manager normally
chairs the CAB.
ƒ Potential CAB members include:
¾ Customer
¾ User Manager
¾ User Group
¾ Application Developers
¾ Specialist/Technical Consultants
¾ Services and Operations
¾ Third Parties (if outsourcing)
• Emergency Change Advisory Board (ECAB)
ƒ For emergency cases when immediate decisions need to be made, an
Emergency Change Advisory Board (ECAB) is formed.
ƒ The members of ECAB may be different from members of CAB and a smaller group of people.
Review and Close Change
The purpose of Review and Close
Change is to ensure that all changes are carried out
and that every change has met its objectives. It is also important to see what can be improved in
future (similar) changes. Change review is also known as Post- Implementation Review.
There are two types of review:
• Review of service change: immediately visible to the customer, at the service level
• Review of infrastructure change: is concerned
with how IT delivers rather than what it delivers,
which is usually
not visible to the customers
Roles
Only individuals with appropriate skills and authority should hold the post of Change
Manager.
The main duties of a Change Manager are:
• Responsible for main activities of the process
• Control RFC
• Coordinate and chair the CAB
• Authorize changes
based on input and advice from CAB
Detailed duties of a Change Manager
are:
• Accept, process, log and reject RFCs based on their practicality (depending on the impact of the change, this can be delegated to Change Coordinators).
• Issue agenda and circulate RFCs for CAB members
• Decide on the suitable expertise
to handle RFCs
• Convene urgent CAB or ECAB meetings for all urgent RFCs.
• Chair all CAB and ECAB meetings
• Authorize acceptable Changes adviced by CAB and ECAB
• Issue Change Schedules via the Service Desk
• Liaise
with
appropriate
parties to coordinate Change building,
testing
and implementation
• Update the Change log on a regular basis
• Review all Changes that have been implemented.
• Review all outstanding RFCs
• Analyze
Change records for trends
or
problems and rectify
with relevant
parties
• Close RFCs
It is the Change Manager, not the CAB or ECAB, that authorizes or rejects changes. The CAB is strictly an advisory body.
Metrics
It is essential to measure and count the number of Incidents that generates Changes as well as identify the causes of the Changes. Measures link to
business goals, cost, service availability and reliability.
The Key Performance Indicators for Change
Management are:
• Reduction in the number of changes
where remediation is invoked
• Reduction in the number of failed changes
• Average time to implement based on urgency, priority, or change type
• Incidents attributable to changes
• Accuracy percentage
in change estimate
• Number of RFCs accepted
or rejected
• Number of emergency changes
as a percentage of the total
Challenges
Challenges affecting Change Management are as follows:
• Change in
culture: A central
process
comes
into place that influences everyone’s activities
• Bypassing: Projects dodging the Change Management process
• Close relationship
with
Service Asset and Configuration Management: To execute a
controlled change, all data must be reliable. Change Management
relies on configuration
data, whereas Service Asset and Configuration
Management relies on Change Management for the information on changes
• Commitment of the supplier(s) to the process
• Commitment of management
ITIL, ITIL Foundation Course, ITIL V3, ITIL Course, ITIL - Course, online itil, itil certification, online material for itil course
