Sie sind auf Seite 1von 22

Research

Publication Date: ID Number:

IT Change Management Policy Documentation


Guidelines

© 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

Figure 1. Revision History...............................................................................................................5

Publication Date: /ID Number: Page 2 of 22


© 9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
Figure 2. Change Management Process.......................................................................................14
Figure 3. RFC Integrative Process Workflow................................................................................15
Figure 4. Change Approval Workflow...........................................................................................16
Figure 5. Change Request Swimlane...........................................................................................17
Figure 6. Linking Key Processes to IT Change Management.......................................................19

Publication Date: /ID Number: Page 3 of 22


© 9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
Analysis

1.0 Governance Introduction


1.1 Mission
The documentation of IT change management governance should provide succinct guidance for
everyone to follow when a change is introduced that could affect client service. The change
management process is intended to manage any change that might prevent a system from
behaving as the client expects or from delivering the services stated in the service-level
agreement. Typically, the IT change management process will apply to all situations or proposed
alterations to an IT service. Any deviations require a change record that can be tracked through
the process until a successful change is installed. Because any change may have complications,
each change should be addressed in the same manner.

1.2 Strategy and Objectives


The fundamental strategy for IT change management process governance is to ensure that all
changes are implemented without any negative impact on customer service. Sample strategies
and objective statements include:

•Identify and apply best practices in defining common processes for change throughout
an organization.

•Develop common change management processes within an organization, including


roles and responsibilities by functional group and the governance group for managing
strategic direction.

•Allow change while maintaining or improving system availability.

•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.

•Reduce the number of changes requiring "backout" due to inadequate preparation.

•Provide complete change documentation to shorten problem determination risk time.

•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.

•Increase the accuracy of predications regarding the impact of change.

•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.

•Avoid conflicts by managed scheduling.

•Audit change activity and understand the reasons for failing to comply with processes.

Publication Date: /ID Number: Page 4 of 22


© 9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
1.3 Scope
The IT change management process encompasses the companywide computing environment.
This includes any alteration to any IT asset or configuration item (CI) in the production
environment, such as:

• A database administrator reorganizing a table

• A server technician rebooting a server

• An application programmer updating code to fix a bug

• A project manager scoping server hardware replacements for mission-critical


applications

• A security manager implementing a new policy for user administration


IT change management includes the tasks necessary for planning, testing and implementing
alterations to minimize effects (integrating with configuration and release management
processes).

2.0 Change Management Definitions, Roles, Classifications


and Procedures
2.1 Change Definition
Change definition governs the development of all the change policies and the execution of
changes to any aspect of the IT and communications environment. It enables controlled changes
while preserving the integrity and service quality of the production environment.

2.2 Change Policy Document Management


This section specifies the ownership and document tracking information. It is the official guide and
reference for an organization's IT change management process policy and is the definitive source
for all IT change activity or revisions to the policy document (see Figure 1).

Figure 1. Revision History

Revision History
Version Status Date Author/ Changes/
Reviser Justifications
1.00

1.01

Source: Gartner (February 2008)

2.3 Change Management Guiding Principles


The change management process policy statement provides a set of guidelines for all aspects of
the IT organization. This policy is integral to a disciplined methodology, and each IT department
must adopt it from design to implementation.

Publication Date: /ID Number: Page 5 of 22


© 9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
The use of these guiding principles can seem simplistic if not properly detailed. To help focus the
organization on what will be critical for change management policy, Gartner recommends that
guiding principles be articulated at several levels:

• Guiding Principle: What is the key point?

• Rationale: Why is it important to draw attention to this?

• Implications: How does this principle affect behavior through the process?

• Policies: What rules of engagement need to be established to ensure compliance?


The next section provides examples of some guiding principles.

2.3.1 Change Agility Principle


Change management processes and procedures must be flexible and agile enough to
accommodate emergencies.

• Rationale:

• To support problem management, emergency changes must be provided for within


the change process.

• To expedite change for emergency situations, the change must follow documented
processes.

• Implications:

• Emergency changes follow an expedited process flow.

• Emergency changes must be tracked and trended.

• Emergency changes must be a low percentage of overall change.

• Policies:

• All changes, including emergency changes, will be qualified, authorized and


reviewed.

• Emergency changes will be generated from high-priority problem tickets or have


adequate business justification and authorization.

2.3.2 Common Change Management Principle


All changes implemented in the production environment will follow the change management
process.

• Rationale:

• To ensure that all staff and changes are compliant.

• 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.

Publication Date: /ID Number: Page 6 of 22


© 9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
• Policies:

• All teams will be responsible for adhering to change management processes.

• All changes will be handled through the change management processes.

2.4 Define Individual Roles and Responsibilities


Identifying who participates, at what points in the process and their level of participation is often
referred to as RACI modeling — Responsible = participates, Accountable = owns the function,
Consulted = advisory role, Informed = notified of work.
In addition to helping organizations communicate participation, RACI models help identify
gaps/overlaps in participation that often wreak havoc with organizational performance. Over time,
the many interpretations of the IT change management process evolving to new functional roles
are who "owns" specific processes/tasks.
RACI and other personnel models can help define the new roles to support IT change
management. In the end, disciplined people are needed for the successful implementation and
execution of IT change management.
An example of basic roles are included in the next section.

2.4.1 Change Process Owner


For large organizations, this might be the management team sponsor with change process
development and organizational leadership responsibility. In small and midsize businesses, one
person can take the change owner and manager roles. The change process owner:

• Is responsible for the end-to-end success of the change process

• Drives continuous improvement for change management

• Liaises with other process owners to establish integration and collaboration

• Develops and delivers senior leadership of change management strategies and IT-wide
communication plans

2.4.2 Change Process Manager


The change process manager is the policy guardian for the change management process, and is
responsible for standards issuance and revision of procedures or forms. He or she also:

• 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)

• Communicates enhancements/modifications to the change management community

• Provides training on the change management process

2.4.3 Change Owner/Requestor


This person initiates a request for change (RFC) and may reside within the business unit or the IT
organization.

2.4.4 Change Implementer


This person is responsible for packaging and executing the RFCs.

Publication Date: /ID Number: Page 7 of 22


© 9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
2.4.5 Change Coordinator/Administrator
This person is responsible for assisting in RFC documentation review for an IT group, department
or division. He or she is sometimes referred to as a change agent, coordinator or administrator.

2.4.6 CAB Member


This person attends scheduled meetings or sends a deputy, and is empowered to make decisions
on behalf of the area he or she represents. The CAB may ask participants to take on
responsibilities such as a change technical reviewer — a CAB member who provides technical
guidance during CAB assessment and authorization stages of one or more RFCs. This role
usually requires broad technical knowledge from the overall IT service to the CI level.

2.5 Define CAB and E-CAB Roles and Responsibilities


The CAB is a cross-functional group set up to evaluate change requests for business needs,
priorities, costs/benefits, and potential effects to other systems or processes. Typically, the CAB
will make recommendations for implementation, further analysis, deferment or cancellation.
Minimal staffing for the CAB will be change owner, change manager/agent, representative from
configuration management and a change technical reviewer. The CAB generally meets weekly to
review RFCs.
The E-CAB tends to be a smaller group (sometimes a subset of personnel from the CAB) to
review and approve emergency decisions.

2.5.1 CAB Guiding Principles


Sample CAB guiding principles include:

• 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.

• CAB members, representatives or alternates will communicate to their respective IT


functional areas on a timely basis and provide any follow-up activities.

• The change manager will schedule regular meetings of the CAB to be attended by the
designated representative or alternate from each identified functional area.

• Changes may be represented at a CAB meeting by the change owner/requestor,


implementer and the change coordinator/administrator.

• 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.

2.6 Define RFCs, Types, Categories and Classifications


Business or IT personnel can initiate an RFC. This wide range of potential change initiators and
change activity requires consistent and complete guidance regarding documenting an RFC.

Publication Date: /ID Number: Page 8 of 22


© 9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
Fundamentally, the change record becomes the source of truth regarding information from the
initial documentation RFC to the subsequent recording of data as it progresses through the RFC
life cycle. Therefore, it is essential to pre-define the various attributes of an RFC. The IT change
management policy document needs to ensure that appropriate definitions and procedures are
described to cover the range of potential RFCs.
The formal change request includes a description of the change, components affected, business
needs, cost estimates, risk assessment, resource requirements and the approval status.

2.6.1 Change Types


To ensure standardized methods and procedures, a common taxonomy is required to define the
various RFC attributes. Even with IT Infrastructure Library (ITIL) recommendations, names and
definitions vary. The identification of these attributes is critical because it determines the
appropriate procedures for dealing with a particular type of RFC, such as emergency RFCs,
which may have different authorization and documentation requirements. The following examples
leverage basic ITIL concepts:

• Emergency: A change request to repair a failure or imminent failure. Typically, this is


associated with a critical priority (severe impact and urgency) problem ticket that affects
production, causes outages or significant degradation in business, or is accompanied by
sufficient business justification. In most cases, this request is executed with limited
documentation and is outside the standard change schedule time.

• Standard (pre-approved): A pre-approved change that is low risk and adheres to an


approved, typically well-tested procedure or work instruction. It is relatively common and
is the accepted solution for a specific requirement. It should be documented on a master
list of approved standard changes.

• Normal: If a change is neither standard nor emergency, then it is categorized as normal.


An RFC should be categorized as normal. Therefore, the RFC is not a repeatable,
previously documented change (standard), is not the result of a critical priority problem
management ticket and is not accompanied with sufficient justification (emergency). The
use of the term "normal" may be easily confused with "standard." Some organizations
will use the terms "planned" and "unplanned" to enhance the description of normal
RFCs.

• Planned: A change request submitted within policy requirements for documentation,


review and lead time

• 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:

Publication Date: /ID Number: Page 9 of 22


© 9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
• Low: An RFC is necessary; however, it can wait until the accepted policy release
timelines. The problem has minimal impact or the application change enhancement has
limited business impact.

• Medium: An RFC is designed to address a problem of medium-to-low impact. Customer


or IT services are not affected. Business risk is low.

• 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).

• Critical: An RFC is justified to address a problem that affects mission-critical production


systems. Customer or IT service has been disrupted. Business risk is high (for example,
immediate financial impact).

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:

• None: The RFC has no potential for disruption.

• Low: Business operations may be interrupted or delayed with little impact to


commitments.

• Requires no work outage

• Affects only one noncritical application or system

• Affects a limited number of clients

• Involves changes that are made during nonproduction hours

• Medium: Business operations may be interrupted or delayed, which affects


commitments.

• Requires a limited outage

• Affects a few applications or one mission-critical application

• Requires a business application redesign or enhancement

• Affects greater than X clients (use impact for guidance)

• High: Business operations may be interrupted or delayed, resulting in financial impact to


the business.

• Requires a widespread outage

• Affects multiple business-critical applications

• Requires a new business application or a major redesign

• Affects more than X clients (use impact for guidance)

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:

Publication Date: /ID Number: Page 10 of 22


© 9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
• Low:

• Affects one to a few end users

• Affects a few CIs (for example, one to 10 desktops and one server)

• Notification is needed for one IT department

• Medium:

• Affects multiple customers

• Affects CIs

• Notification is needed for a few IT and business departments

• High:

• Affects multiple departments and sites

• 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)

• Notification is needed for multiple IT departments and business sites

2.6.5 Additional Categorization and Classification


Accurate information regarding the IT service and CIs enables the CAB to assess the affected
and potential collision of a proposed RFC. To improve consistency from a data integrity and
workflow perspective, this section offers guidance on common IT services, assets and/or CI
groups.

• Development: Application development covering application activity from mainframe to


Web applications

• Infrastructure: This typically covers network devices and other WAN "plumbing,"
including:

• Data network circuits (WAN and LAN)

• Data network devices (routers, switches, hubs and firewall components)

• Voice components (PBXs, phone switches and mail devices)

• Specialized printers (metal tag and so forth)

• Plant/site power maintenance/outages

• Plant physical inventories

• Plant work shutdowns

• Operations: Server, database and overall production, including:

• Servers (Unix, Intel, AS/400, Linux and OS Patching/Upgrades)

• Database upgrades (Oracle, Progress, AdaBas and DB2)

• Data cleanup (dump/reloads, archival, purging, mass data loads or modifications)

Publication Date: /ID Number: Page 11 of 22


© 9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
• Mainframes

• Storage (arrays, local disks, tape/cartridge devices and firmware upgrades)

• Partners: Outsourcers or other third-party partners covering outsourced or multisourced


services

• Security: Security processes covering security policy improvements, such as


authentication

• Service: IT services from strategy to continual improvement

• Support: Service desk


Based on the various attributes documented in the RFC record, these groups define the change's
impact on the infrastructure, users or business. The change complexity and resources required,
and analysis of risk, impact and priority, are measured to determine the category. These are
aligned with specific procedure models that detail the steps needed to handle review and
authorization:

• 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.

2.6.6 Documenting RFCs


Documenting an RFC enables organizations to manage the process flow and control changes.
Also, documentation creates a record that will retain the complete history of a given change.
Different types of RFCs will require different degrees of data documentation. However, there
tends to be a baseline of required data based on type class, category and the service affected.
Typical baseline RFC record data fields include:

• Change owner and implementer as defined in the policy document.

• Class, category, priority, risk and impact as defined in the policy document.

• Change type 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.

• Brief description: A short description or title that summarizes the change.

• Business justification: A reason to perform a change, or the negative impact to the


business if a change is not performed.

• Change schedule: Includes targeted implementation.

Publication Date: /ID Number: Page 12 of 22


© 9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
• Backout plan: Included within request (specific field) or attached as an external
document.

• 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.

2.6.7 RFC Documentation Principles


• All changes have a business justification, documented resource and a defined feasible
technical solution.

• Unless previously exempted, any change to the IT production environment requires a


change request in the change system.

• 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.

• Emergency changes require appropriate prior notification. However, formal approvals


may be obtained after the fact. A post-review must be conducted for all emergency
changes.

2.7 Process Workflows


Pre-defined change process models offer the needed procedural guidance for an RFC. The
exercise of defining the various attributes of a change will dictate the established workflow path it
follows. Figure 2 provides an example of the "macrostages" of a process flow diagram that
presents the key tasks needed to be performed to successfully deploy a change.

Publication Date: /ID Number: Page 13 of 22


© 9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
Figure 2. Change Management Process

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

Source: Gartner (February 2008)

It is important to follow IT change management workflow to synchronize with release and


configuration management process workflows. The diagram in Figure 3 demonstrates key
intersection points between configuration and release management with a normal RFC workflow.
Note that it also includes defined procedure models for the RFC categories listed in Section 2.6.5.

Publication Date: /ID Number: Page 14 of 22


© 9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
Figure 3. RFC Integrative Process Workflow

Change Requestor
Reports and
RFC Document Audit
Yes Go to emergency
Emergency? workflow

No
Identify
Assess Change
CIs

No Approve/ Yes Minor Significant Major Update


Reject Change Records

Change Mgr. CAB CAB and Exec. Team


Configuration
Management
Schedule/
Change Change
Implement
Development Review
Change
Capture
Release
Build Change Baselines

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

Statistics and Reporting


Source: Gartner (February 2008)

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.

Publication Date: /ID Number: Page 15 of 22


© 9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
Figure 4. Change Approval Workflow

Assessment Correct No Modify


Approvers? Approver List

Yes

Evaluate RFC
and Impact
Assessment

Collect
Individual
Approvers

CAB Review
and Approval
if Needed

Return to
Approved? No Requestor

Yes

Update RFC Configuration


Status Management

Scheduling

Source: Gartner (February 2008)

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).

Publication Date: /ID Number: Page 16 of 22


© 9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
Research
Publication Date: ID Number:

Figure 5. Change Request Swimlane

Minor Change Workflow


External
Interface

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

Change Notify Requestor of


Implementer Submission Approval

Tools/Data
Change Management Tool

Source: Gartner (February 2008)

© 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:

3.0 Integrative Process Partners


This section identifies integration exchanges between IT change management and other core IT
processes. Although these integration points are critical for long-term IT change management
maturity and effectiveness, many supporting process partners can be at varying degrees of
maturity within the IT organization. This small list focuses on a few key processes where high
levels of integration will be required and may require IT change management re-engineering
efforts as the process integration evolves.
Figure 6 is not exhaustive and is a typical representation of ITIL-specific process integrations.
This can include facilities, manufacturing plant processes, internal audits, third-party vendors and
so on. The figure describes the typical key processes and integration points specific to inputs or
outputs to IT change management.

© 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

IT Service Support IT Service Delivery

Incident Service-Level
Management Management

Link record and historical Ensure that business costs and


knowledge with the change requirements are shared.
record. IT Change
Management
Availability
Problem
Management
Management
TBD fiscal 200X.
Link record and historical
knowledge with the change Capacity
record. Management

Configuration TBD fiscal 200X.


Management
Financial
Link CI knowledge to change Management
record. Support impact and risk
analysis. TBD fiscal 200X.
Project Management
Release
Service Continuity
Management
Management
Link project production
Link RFC to release record. deliverable to RFC. Place documented disaster
Provide test, implement and recovery workflows under
backout plan touchpoints. change control. Use ITCM for
disaster recovery test
communication.
Source: Gartner (February 2008)

3.1 Business Continuity Management and Disaster Recovery


Business continuity management (BCM) maintains and restores mission-critical business
processes, personnel and facilities, with the goal of ensuring emergency preparedness and
business resiliency. BCM includes six major components:

• Risk management and mitigation

• 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,

Publication Date: /ID Number: Page 19 of 22


© 9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
whose focus is the overall resumption of business operations following the occurrence of one or
more disruptive events.
The design of these procedures and plans should be under strict change control to ensure that
they are consistent and accurate, and that all stakeholders are aware of changes. In the case of
disaster recovery activity, testing activity can leverage IT change management for communication
and may be required to submit a change request.

3.2 Configuration Management


Configuration management maintains information about CIs from individual technical domains to
IT services. Configuration management should provide guidance regarding how to collect and
federate the wide variety of configuration information into a logical model of service by identifying,
controlling, maintaining and verifying the versions of CIs in existence. A configuration
management database maintains, federates and reconciles CI data into a single IT services view
to support RFC analysis. IT change management access to accurate configuration information
enables IT staff to assess the impact of proposed changes and to track results.

3.3 Incident and Problem Management


Incident management's purpose is to restore normal service operation as quickly as possible and
to minimize the adverse impact on business operations, thus ensuring service quality and
availability.
Problem management minimizes the adverse impact of incidents and problems on the business
that are caused by errors within the IT infrastructure, and to prevent recurrence of incidents
related to these errors. Problem management is a key process because changes are often
required to implement a fix to a known error. Thus, problem management will generate RFC
activity and contribute to CAB activity.

3.4 Project Management


Project management is a collection of processes focused on the disciplined management of IT
projects. The Project Management Body of Knowledge Guide and PRINCE2 offer industry
methodologies suitable to manage IT projects covering the organization, control and
management of a project. Integration with change management processes will provide analysis
and control of identified changes to the IT production environment from project deliverables.

3.5 Release Management


Release management coordinates the many sources involved with a significant release of
hardware, software and associated documentation across a distributed environment.

3.6 Examples of Key Policy Integration


• Release events must be reviewed, scheduled, tracked and measured. Any changes
identified as emergency, off-calendar or that have missed required lead times are
approved and negotiated by the IT change manager and executive CAB.

• All changes will be adequately tested in the acceptance environments prior to


implementation in production. If a test or acceptance environment is not available, then
the risk level of the change will be increased appropriately.

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

Publication Date: /ID Number: Page 20 of 22


© 9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
forward schedule of change in ITIL v.2, contains information about future changes, as well as
those that have already been implemented.

4.1 Scheduling Key Policy Attributes


• Changes will be implemented at predetermined times appropriate to business processes
and the functions and cycles they support. All new projects will adhere to these
schedules.

• Changes must adhere to the approval lead times published in this process guide.

• Changes that must be moved from a status of "scheduled" or "in progress" to


"postponed" revert to a status of "requested" and go through the entire CAB review
process again.

4.2 Change Measurement


Metrics are pivotal in managing and monitoring the IT change management process. They
baseline a process, determine the effect of process improvements, identify areas where the
process may be ineffectual or broken, and assess improvements.

4.3 Critical Success Factors


• All changes are tracked.

• Post-mortem changes are done consistently and reported.

• Process workflows will be integrated within IT operations and application development


tools.

4.4 Quality and Efficiency Metrics


• Number and percentage of emergency changes

• Number and percentage of successful changes

• Application performance and availability: planned/unplanned downtime associated with


changes and the mean time to repair Severity Level 1 or Level 2 problems

• Ratio of problem- and defect-associated changes

• Change volume: looking for month-to-month spikes

• Change activity: higher volume or percentage by department, type or item

• Change backouts: higher by department, type or item

• Problem/defect: higher by department, type or item

• Cost of change

4.5 Compliance and Control


• Audit key policy attributes:

• Unless a person is classified as exempted implementer or policy approver, he or she


cannot approve or implement changes.

• 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.

Publication Date: /ID Number: Page 21 of 22


© 9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.
• After implementing a change, the change implementer should set the status to "post
review," add any appropriate notes about the implementation to the change request
and execute appropriate communication regarding the status of the change.

• 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.

5.0 Communications, Coordination and Education Methods


5.1 Key Meetings
For meetings to be effective, they must occur consistently. All attendees should be aware of the
meeting's goals, objectives and expected outcomes. Attendees should be clear on their roles.
Examples of common meetings include:

• Daily change manager review

• CAB weekly significant and major RFC review

• Problems caused by change weekly review

5.2 Cross-Departmental Collaboration and Coordination


This area should cover the expected methods of collaboration and coordination among IT
departments, partners and the business. Examples of policy guidance include:

• 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.

5.3 Training Programs


The training and education of the change management process must eliminate inefficiencies and
quality gaps, and enable consistent process skills. Change management training must be
consistent across all areas of the organization. Sample training methods include:

• A semiannual IT change management workshop led by the change process owner

• Key IT change management meeting led by the IT division attending ITIL certification

• Quarterly luncheon meetings to review the IT change management policy

Publication Date: /ID Number: Page 22 of 22


© 9999 Gartner, Inc. and/or its Affiliates. All Rights Reserved.

Das könnte Ihnen auch gefallen