Beruflich Dokumente
Kultur Dokumente
© 9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved. Reproduction of this publication in any form without prior
written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable.
Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no
liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The reader
assumes sole responsibility for the selection of these materials to achieve its intended results. The opinions expressed
herein are subject to change without notice.
TABLE OF CONTENTS
Analysis...........................................................................................................................................4
1.0Governance Introduction...............................................................................................4
1.1Mission.............................................................................................................4
1.2Strategy and Objectives...................................................................................4
1.3Scope...............................................................................................................5
2.0Change Management Definitions, Roles, Classifications and Procedures....................5
2.1Change Definition.............................................................................................5
2.2Change Policy Document Management...........................................................5
2.3Change Management Guiding Principles.........................................................5
2.3.1Change Agility Principle....................................................................6
2.3.2Common Change Management Principle.........................................6
2.4Define Individual Roles and Responsibilities....................................................7
2.4.1Change Process Owner...................................................................7
2.4.2Change Process Manager................................................................7
2.4.3Change Owner/Requestor................................................................7
2.4.4Change Implementer........................................................................7
2.4.5Change Coordinator/Administrator...................................................8
2.4.6CAB Member....................................................................................8
2.5Define CAB and E-CAB Roles and Responsibilities.........................................8
2.5.1CAB Guiding Principles....................................................................8
2.6Define RFCs, Types, Categories and Classifications.......................................8
2.6.1Change Types..................................................................................9
2.6.2Priority..............................................................................................9
2.6.3Risk................................................................................................10
2.6.4Impact.............................................................................................10
2.6.5Additional Categorization and Classification...................................11
2.6.6Documenting RFCs........................................................................12
2.6.7RFC Documentation Principles......................................................13
2.7Process Workflows.........................................................................................13
3.0Integrative Process Partners.......................................................................................18
3.1Business Continuity Management and Disaster Recovery.............................19
3.2Configuration Management............................................................................20
3.3Incident and Problem Management................................................................20
3.4Project Management......................................................................................20
3.5Release Management....................................................................................20
3.6Examples of Key Policy Integration................................................................20
4.0Schedule/Calendar......................................................................................................20
4.1Scheduling Key Policy Attributes....................................................................21
4.2Change Measurement....................................................................................21
4.3Critical Success Factors.................................................................................21
4.4Quality and Efficiency Metrics........................................................................21
4.5Compliance and Control.................................................................................21
5.0Communications, Coordination and Education Methods.............................................22
5.1Key Meetings..................................................................................................22
5.2Cross-Departmental Collaboration and Coordination.....................................22
5.3Training Programs..........................................................................................22
LIST OF FIGURES
•Identify and apply best practices in defining common processes for change throughout
an organization.
•Determine whether the amount of lead time affects the success or failure of
nondisruptive changes.
•When lead time is important, identify sensitive types and volumes of changes to reduce
disruptions.
•Determine a better method of identifying and categorizing changes into levels of risk.
•Display the number of and types of changes planned in the short and long term.
•Ensure that every record has technical and management accountability to provide a
compliance audit trail.
•Establish a process to ensure that records are consistently reviewed for technical merit
and business readiness, while allowing for flexibility based on business needs.
•Audit change activity and understand the reasons for failing to comply with processes.
Revision History
Version Status Date Author/ Changes/
Reviser Justifications
1.00
1.01
• Implications: How does this principle affect behavior through the process?
• Rationale:
• To expedite change for emergency situations, the change must follow documented
processes.
• Implications:
• Policies:
• Rationale:
• To ensure complete adherence by all staff to change processes and activities, all
changes will be tracked, trended, monitored and analyzed for compliance, success
and efficiency.
• Implications:
• Change management must be a global policy that is adhered to by all groups and
resources.
• Develops and delivers senior leadership of change management strategies and IT-wide
communication plans
• Executes, manages and reviews change management process activities on a daily basis
• Chairs the change advisory board (CAB) and the emergency change advisory board (E-
CAB)
• The CAB is comprised of at least one representative and alternate from each IT
functional area and appropriate non-IT functional areas, including line-of-business
representatives. The enterprise system management group maintains member listings
on the change intranet site. The change specialist and CAB decide whether more or
fewer groups are represented.
• The change manager will schedule regular meetings of the CAB to be attended by the
designated representative or alternate from each identified functional area.
• If the owner or a designated substitute does not represent a change that requires
representation at a CAB meeting, then the change is postponed and the change
specialist informs the owner.
• The CAB is not allowed to stop a change because of disagreement with the technical
methods proposed by subject-matter experts assigned to a specific change request.
• The CAB or change coordinator can postpone a change if it is determined that the
change does not follow change policy or is logistically unworkable. The change
specialist informs the owner.
• Unplanned: A change request not compliant with policy for documentation, review
and lead time
To assess the impact of an RFC on an IT service, a matrix evaluation is executed via a set of
categories (impact, risk and priority). There is a relationship among impact, risk and priority —
from philosophical and mechanical perspectives.
2.6.2 Priority
Based on an ITIL definition, this classification identifies the relative importance of an RFC. The
RFC priority status is based on RFC classification variables, with input from the change manager.
Typically, this assignment is used to sequence an RFC to address an incident or problem that
needs to be resolved, based on impact and urgency. This can also be used to meet business
demands, such as the implementation of an enhancement to an application. Typical priority level
descriptions include:
• High: The RFC addresses a severe problem that affects production systems and
demands immediate attention. Customer or IT service has been partially disrupted.
Business risk is high to medium (for example, slowed business operations).
2.6.3 Risk
Risk defines the potential disruption of business operation associated with a given change
request. A risk is measured by the probability of a threat or the vulnerability of the IT service to
that threat. Typical risk definitions are:
2.6.4 Impact
Impact measures the pain caused by a defective IT service. In most cases, variables such as
geography, users and so on help identify the scale. Typical impact classification definitions are:
• Affects a few CIs (for example, one to 10 desktops and one server)
• Medium:
• Affects CIs
• High:
• Affects multiple and/or a variety of CIs (for example, desktops and servers, multiple
services and/or a mission-critical service, such as three mission-critical applications,
50 servers and 250 desktops)
• Infrastructure: This typically covers network devices and other WAN "plumbing,"
including:
• Major: Major changes potentially affect the department or entire company. They may
affect multiple CIs. Multiple IT departments and multiple business sites need to be
notified.
• Significant: These changes may affect a group or department and multiple CIs.
Notification is needed for a few IT departments and business departments.
• Minor: These changes affect a few users and CIs (for example, one to 10 desktops or
one server). Notification is needed for one IT department.
• Standard: A pre-approved change that is low risk and adheres to an approved, typically
well-tested procedure or work instruction, is relatively common and is the accepted
solution for a specific requirement.
• Class, category, priority, risk and impact as defined in the policy document.
• CIs: The requesting group should provide a list of items to the remote group for input
into the inventory or configuration management database on a regular basis.
• Approver: Key groups and individuals required to provide approval prior to the
implementation.
• Closure: The requestor closes request. If the person makes the request on behalf of a
business unit, then he or she must receive acknowledgement from that unit once the
issue is closed.
• Maximum use of templates must occur for standard and repetitive changes.
• Use established change priorities as guidelines in the decision. The change manager is
the neutral arbiter for assignment review. If an agreement cannot be reached with the
change manager, then appeal to the next-most-senior level of management.
• For specified change types, such as high risk/high impact, changes require documented
plans for testing, implementation, backout, notification and verification of success.
Operating or support procedures, such as rerun instructions, problem resolution scripts
and other information, may also be required, and support staff must be involved.
• Emergency changes are usually the result of a problem and require a problem ticket.
Document
Document
Change
Change
Assess
Assess
Change
Change
Authorize/Reject
Authorize/Reject
Change
Change
Schedule/Implement
Schedule/Implement
Change
Change
Review
Review
Change
Change
Close
Close
Change
Change
Change Requestor
Reports and
RFC Document Audit
Yes Go to emergency
Emergency? workflow
No
Identify
Assess Change
CIs
Release
Management
Test Change
Change Mgr.
Yes No
Working? Backout Change
Review
Change
Audit CIs
No
Success? To Start Review
Yes Updated
Records
Close Change
The macrostages can be decomposed to specific activity or task flows. Figure 4 represents an
example of an approval stage and the established tasks required to complete it. Note the task
level integration with configuration management that acknowledges the update to configuration
management based on the RFC approval.
Yes
Evaluate RFC
and Impact
Assessment
Collect
Individual
Approvers
CAB Review
and Approval
if Needed
Return to
Approved? No Requestor
Yes
Scheduling
For some change management policies, workflows can be very detailed and cover processes,
tools and individual roles. These tend to be presented in a "swimlane" structure (see Figure 5).
Minor
Change RFC "Not
Change Approved"
Status: Document Status: Classify Status: Assess
Requestor Close
Create Minor Determine RFC Complete RFC and Status: Document RFC
Request for Implementation Forward to Mgr. for Yes
Meet With
Change Date/Time Approval
Requestor/
Owner to Resolve Can Issue Be
Issues Resolved? No
Status: Approve No
Change
Authorization Mgr. Receives and Approve
Approver Reviews RFC RFC?
for Approval
Yes
Status: Schedule
Status: Implement
Change Place RFC as Assign Submitted RFC to
Coordinator Submitted in RFC to Change Implem.
Calendar Coordinator
Tools/Data
Change Management Tool
© 9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved. Reproduction of this publication in any form without prior written permission is forbidden. The information contained herein
has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no
liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The reader assumes sole responsibility for the selection of these materials
to achieve its intended results. The opinions expressed herein are subject to change without notice.
Research
Publication Date: ID Number:
© 9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved. Reproduction of this publication in any form without prior
written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable.
Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no
liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The reader
assumes sole responsibility for the selection of these materials to achieve its intended results. The opinions expressed
herein are subject to change without notice.
Figure 6. Linking Key Processes to IT Change Management
Incident Service-Level
Management Management
• Disaster recovery
• Business recovery
• Business resumption
• Contingency planning
• Crisis management
Disaster recovery management restores access to production applications and data following a
partial or complete interruption of data center operations. It is fundamental to successful BCM,
4.0 Schedule/Calendar
IT change management should coordinate the production and distribution of a change schedule
and a projected service impact or availability. A change schedule, formerly referred to as a
• Changes must adhere to the approval lead times published in this process guide.
• Cost of change
• Changes must be submitted in a change control tool by day and time, in compliance
with policy lead times, to be considered for review in the weekly CAB meeting.
• RFC closure requires verification that an approved RFC was executed according to
documentation. This can be done via various change management roles in concert
with auditing or configuration management tools.
• Coordination with support groups that perform changes must be done with adequate
lead time for the support group to schedule resources. When resources are not available
to implement all requested changes in the desired time frames, the support group
manager and change owner decide on resource allocation.
• Prior to review by the change review team, project teams, support groups, business
partners and the change specialist plan and coordinate changes.
• Key IT change management meeting led by the IT division attending ITIL certification