White Paper

BMC Best Practice Process

Flow for Change
Management

October 2007

www.bmc.com

Contacting BMC Software

You can access the BMC Software website at http://www.bmc.com. From this website, you can obtain information
about the company, its products, corporate offices, special events, and career opportunities.

United States and Canada

Address

BMC SOFTWARE INC

2101 CITYWEST BLVD
HOUSTON TX 77042-2827
USA

Telephone

713 918 8800 or

800 841 2031

Fax

(01) 713 918 8000

Fax

713 918 8000

Outside United States and Canada

Telephone

(01) 713 918 8800

If you have comments or suggestions about this documentation, contact Information Design and Development by email at
doc_feedback@bmc.com.

Copyright 19912007 BMC Software, Inc.

BMC, BMC Software, and the BMC Software logo are the exclusive properties of BMC Software, Inc., are registered with the U.S. Patent
and Trademark Office, and may be registered or pending registration in other countries. All other BMC trademarks, service marks, and
logos may be registered or pending registration in the U.S. or in other countries. All other trademarks or registered trademarks are the
property of their respective owners.
DB2 is a registered trademark of International Business Machines Corporation.
IBM is a registered trademark of International Business Machines Corporation.
ITIL is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the
U.S. Patent and Trademark Office.
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.
Oracle is a registered trademark of Oracle Corporation.
UNIX is a registered trademark of The Open Group.
BMC Software considers information included in this documentation to be proprietary and confidential. Your use of this information is
subject to the terms and conditions of the applicable End User License Agreement for the product and the proprietary and restricted
rights notices included in this documentation.

Restricted rights legend

U.S. Government Restricted Rights to Computer Software. UNPUBLISHED -- RIGHTS RESERVED UNDER THE COPYRIGHT LAWS OF
THE UNITED STATES. Use, duplication, or disclosure of any data and computer software by the U.S. Government is subject to
restrictions, as applicable, set forth in FAR Section 52.227-14, DFARS 252.227-7013, DFARS 252.227-7014, DFARS 252.227-7015, and
DFARS 252.227-7025, as amended from time to time. Contractor/Manufacturer is BMC Software, Inc., 2101 CityWest Blvd., Houston, TX
77042-2827, USA. Any contract notices should be sent to this address.

Customer Support
You can obtain technical support by using the Support page on the BMC Software website or by contacting Customer
Support by telephone or email. To expedite your inquiry, please see Before Contacting BMC Software.

Support website
You can obtain technical support from BMC Software 24 hours a day, 7 days a week at
http://www.bmc.com/support_home. From this website, you can:

Read overviews about support services and programs that BMC Software offers.
Find the most current information about BMC Software products.
Search a database for problems similar to yours and possible solutions.
Order or download product documentation.
Report a problem or ask a question.
Subscribe to receive email notices when new product versions are released.
Find worldwide BMC Software support center locations and contact information, including email addresses, fax
numbers, and telephone numbers.

Support by telephone or email

In the United States and Canada, if you need technical support and do not have access to the Web, call 800 537 1813 or
send an email message to customer_support@bmc.com. (In the Subject line, enter
SupID:<yourSupportContractID>, such as SupID:12345.) Outside the United States and Canada, contact your local
support center for assistance.

Before contacting BMC Software

Have the following information available so that Customer Support can begin working on your issue immediately:

Product information

Product name
Product version (release number)
License number and password (trial or permanent)

Operating system and environment information

Machine type
Operating system type, version, and service pack
System hardware configuration
Serial numbers
Related software (database, application, and communication) including type, version, and service pack or
maintenance level

Sequence of events leading to the problem

Commands and options that you used

Messages received (and the time and date that you received them)

Product error messages

Messages from the operating system, such as file system full
Messages from related software

License key and password information

If you have a question about your license key or password, contact Customer Support through one of the following
methods:

E-mail customer_support@bmc.com. (In the Subject line, enter SupID:<yourSupportContractID>, such as

SupID:12345.)

In the United States and Canada, call 800 537 1813. Outside the United States and Canada, contact your local support
center for assistance.

Submit a new issue at http://www.bmc.com/support_home.

Document
Author
Version

: Change Management
: BMC Software, Inc.
: 7.0

Creation date
Last edited
Page

: December 02, 2004

: October 08, 2007
: 1 of 20

1. Process Description
The Change Management process consists of eight procedures; six for implementing planned
changes, and two for implementing emergency changes.
The first procedure is called "Request for Change Review". This procedure is used by change
supervisors when they are dealing with requests for change.
The second procedure is called "Change Planning". It is used by change supervisors and
specialists to prepare the implementation plans for changes.
The third procedure is called "Change Approval". It is used by the change manager and
approvers (i.e. customer representatives and service providers) to approve planned changes.
The fourth procedure is called "Infrastructure Change Implementation". It is used by specialists to
implement infrastructure changes.
The fifth procedure is called "Application Change Implementation". It is used by specialists,
release administrators, customer representatives and change supervisors to implement
application changes.
The sixth procedure is called "Planned Change Closure". It is used by specialists when they
perform production tests after changes have been implemented and by change supervisors when
they close out changes.
The seventh procedure is called "Emergency Change Implementation". This procedure is used
by specialists and release administrators to implement changes to resolve incidents.
The eighth and last procedure is called "Emergency Change Closure". This procedure is used by
specialists and change supervisors to complete and close out emergency changes.
A graphical representation of the process is provided on the next page. Each procedure is
described in more detail in the sections that follow this diagram.

Copyright 2004 - 2007 BMC Software, Inc.

Document
Author
Version

Creation date
Last edited
Page

: Change Management
: BMC Software, Inc.
: 7.0

Change Management Process

Copyright 2004 - 2007 BMC Software, Inc.

: December 02, 2004

: October 08, 2007
: 2 of 20

Document
Author
Version

1.1

: Change Management
: BMC Software, Inc.
: 7.0

Creation date
Last edited
Page

: December 02, 2004

: October 08, 2007
: 3 of 20

Request for Change Review

The change supervisor receives the requests for change for the service(s) that he/she
coordinates the change for. The requests for change can originate from the following five
sources:

Incident Management, in the form of incident requests which resolutions need to be

implemented by Change Management,
Incident Management, in the form of changes that were generated upon the submission of
the Request form,
Problem Management, in the form of known errors,
Release Management, in the form of documents that detail the change requirements, and
Continuity Management, in the form of return-to-production requests from service providers
following the recovery of service infrastructures at their continuity sites.

Upon receiving a request for change, the change supervisor determines if it can be added to a
change that was already prepared earlier. If this is the case, the change supervisor links the new
request for change to the existing change to optimize efficiency.
If the request for change asks for the implementation of a standard change, the change
supervisor uses the appropriate change template to prepare the change.
If the request for change is not a request for a standard change, the change supervisor checks
the request to ensure that it does not conflict with internal standards or policies. If it does conflict,
the request for change is rejected and the requester is informed of the internal standard or policy
that the request for change conflicts with.
If there is no conflict, the change supervisor determines whether the change implementation
really needs to be coordinated by Change Management. This is only necessary when the
implementation will cause:

a service to become unavailable or degraded during service hours,

the functionality of a service to become different, or
the CMDB to require an update.

If the change can be implemented without the involvement of Change Management, the change
supervisor rejects the request for change and informs the requester that Change Management is
not required.
If it has been determined that Change Management is required for the implementation of the
requested change, the change supervisor determines whether the request for change should be
passed on to Release Management. Release Management is not required if the request for
change asks for the prevention or fix of a problem, provided that:

the change implementation can be coordinated by a single change supervisor,

the implementation will not cause the functionality of the service to become different, and
no additional funding is required to complete the implementation.

If Release Management is not required, or if the request for change originated from Release or
Continuity Management, the change supervisor selects the most appropriate change template
and/or task (group) template(s) to prepare the change. All other requests for change are
assigned to Release Management.

Copyright 2004 - 2007 BMC Software, Inc.

Document
Author
Version

: Change Management
: BMC Software, Inc.
: 7.0

Creation date
Last edited
Page

: December 02, 2004

: October 08, 2007
: 4 of 20

The Request for Change Review procedure diagram is presented on the next page.

Copyright 2004 - 2007 BMC Software, Inc.

Document
Author
Version

Creation date
Last edited
Page

: Change Management
: BMC Software, Inc.
: 7.0

Procedure 1, Request for Change Review

Copyright 2004 - 2007 BMC Software, Inc.

: December 02, 2004

: October 08, 2007
: 5 of 20

Document
Author
Version

1.2

: Change Management
: BMC Software, Inc.
: 7.0

Creation date
Last edited
Page

: December 02, 2004

: October 08, 2007
: 6 of 20

Change Planning

After having registered a new change, the change supervisor starts the risk & impact analysis
phase by gathering the necessary information so that a change implementation plan can be
created that minimizes both the risk of failure and the impact on user(s).
The change supervisor consults other specialists as needed to obtain this information. If a new
service infrastructure is to be built, or if an existing service infrastructure is likely to require a
modification in order to satisfy the change requirements, the change supervisor also requests the
assistance from the availability manager for the creation of a new, or the modification of an
existing, service infrastructure design.
Having gathered all the risk & impact information, the change supervisor finalizes the planning for
the change implementation ensuring that the risk of failure and the impact on the user(s) is
minimized.
If the change is a standard change for which the approval phase can be skipped, the change
supervisor initiates the implementation of the change. On the other hand, if approval is required,
the change supervisor asks the change manager to initiate the collection of the necessary
approvals.
The Change Planning procedure diagram is presented on the next page.

Copyright 2004 - 2007 BMC Software, Inc.

Document
Author
Version

Creation date
Last edited
Page

: Change Management
: BMC Software, Inc.
: 7.0

Procedure 2, Change Planning

Copyright 2004 - 2007 BMC Software, Inc.

: December 02, 2004

: October 08, 2007
: 7 of 20

Document
Author
Version

1.3

: Change Management
: BMC Software, Inc.
: 7.0

Creation date
Last edited
Page

: December 02, 2004

: October 08, 2007
: 8 of 20

Change Approval

After a change supervisor has informed the change manager that a change is ready for approval,
the change manager reviews the change. If the change manager finds the change to be in
conflict with internal standards or policies, he/she informs the change supervisor that the change
cannot be implemented.
If the change is not in conflict with any internal standards or policies, the change manager
reviews the risk assessment and the implementation plan. The change manager checks the plan
to ensure that appropriate precautions have been planned to minimize both the risk of failure and
the impact on the user(s), and that the timing of the implementation does not conflict with other
planned changes or planned events.
If the risk & impact analysis is found to be insufficient, the change manager requests additional
analysis from the change supervisor. Similarly, if the planning does not adequately address the
risk of failure or the impact on the user(s), or if the planning conflicts with other planned changes
or events, the change manager requests an adjustment of the implementation plan from the
change supervisor.
On the other hand, if the risk & impact analysis and the planning of the implementation appear to
be in order, the change manager ensures that the necessary approvals will be collected for the
change.
Approval is required from the representatives of customers who will be affected by the change
implementation, if it will cause:

a service to become unavailable or degraded during service hours, or

the functionality of a service to become different.

Approval from the service provider is sufficient if these conditions do not apply to the planned
implementation.
If the change is rejected by an approver, the change manager finds out why. The change
manager asks the change supervisor to perform additional risk & impact analysis or to adjust the
planning if that was the reason why the change was rejected.
If the change was rejected for any other reason, the change manager informs the change
supervisor that the change cannot be implemented.
The Change Approval procedure diagram is presented on the next page.

Copyright 2004 - 2007 BMC Software, Inc.

Document
Author
Version

Creation date
Last edited
Page

: Change Management
: BMC Software, Inc.
: 7.0

Procedure 3, Change Approval

Copyright 2004 - 2007 BMC Software, Inc.

: December 02, 2004

: October 08, 2007
: 9 of 20

Document
Author
Version

1.4

: Change Management
: BMC Software, Inc.
: 7.0

Creation date
Last edited
Page

: December 02, 2004

: October 08, 2007
: 10 of 20

Infrastructure Change Implementation

If the change concerns an application change, the implementation continues in Procedure 5,

Application Change Implementation. The first task(s) of an infrastructure change, however, are
assigned to the specialist(s) for the preparation of the implementation (i.e. to ensure operational
readiness). This can involve ordering hardware, configuring a test environment, performing tests,
etc.
When everything is ready, the specialist(s) receive and complete the task(s) for the actual
implementation of the change.
The Infrastructure Change Implementation procedure diagram is presented on the next page.

Copyright 2004 - 2007 BMC Software, Inc.

Document
Author
Version

Creation date
Last edited
Page

: Change Management
: BMC Software, Inc.
: 7.0

Procedure 4, Infrastructure Change Implementation

Copyright 2004 - 2007 BMC Software, Inc.

: December 02, 2004

: October 08, 2007
: 11 of 20

Document
Author
Version

1.5

: Change Management
: BMC Software, Inc.
: 7.0

Creation date
Last edited
Page

: December 02, 2004

: October 08, 2007
: 12 of 20

Application Change Implementation

After the first implementation task(s) of the application change have been assigned, one or more
specialists develop the new release in the development environment. The new release is tested
by the specialist(s) to ensure that the change requirements have been met. This is done in a
separate test environment if one has been made available for this purpose. Otherwise, the tests
are performed in the development environment. The (automated) scripts for regression testing
are also updated and run by the specialist(s) if such scripts are available for the application. The
specialist(s) fix any errors that were encountered during the tests in the development
environment.
Once the specialist(s) have confirmed that the change requirements have been met and that no
new bugs have been introduced, the release administrator transfers the new release to the test
environment where the customer representative(s) ensure that it gets tested.
The change supervisor creates and assigns additional tasks if the new release did not pass
customer testing, so that the new release can be corrected. If these additional tasks caused the
transfer to production to be rescheduled, the change will need to be approved again.
Once the new release has passed customer testing, the specialist(s) ensure that everything is
ready to take the new release into production (i.e. ensure operational readiness). This could
involve user training, the addition of storage capacity to the production and continuity
environments, ordering additional software licenses, etc.
Finally, the release administrator transfers the new release into production.
The Application Change Implementation procedure diagram is presented on the next page.

Copyright 2004 - 2007 BMC Software, Inc.

Document
Author
Version

Creation date
Last edited
Page

: Change Management
: BMC Software, Inc.
: 7.0

Procedure 5, Application Change Implementation

Copyright 2004 - 2007 BMC Software, Inc.

: December 02, 2004

: October 08, 2007
: 13 of 20

Document
Author
Version

1.6

: Change Management
: BMC Software, Inc.
: 7.0

Creation date
Last edited
Page

: December 02, 2004

: October 08, 2007
: 14 of 20

Planned Change Closure

After the change has been put into production, a specialist (with the help of a user if the specialist
does not have sufficient access rights) performs the production test to verify the success of the
implementation.
The CMDB, the Capacity Management and the Continuity Management information is updated as
needed after the specialist has determined that all the requirements of the change have been
met. If all change requirements have not been fulfilled, however, the specialist who performed the
production test determines if the change implementation should be backed out. The change is
backed out if its implementation does not provide an improvement over the previous situation, or
causes a security or data integrity risk.
If the unsuccessful change implementation can still be made into a success, the change
supervisor creates and assigns the necessary additional tasks. However, if it is currently not clear
how all change requirements can be met, the change supervisor closes the change.
The change supervisor finally ensures that the requester and approvers of the change are
informed. If the change implementation was found to be successful, the requester of the change
will receive a notification that the change has been completed. The requester then checks
whether his/her requirements have been fulfilled. If the requester has verified that the
requirements have been met, he/she does not need to take any action. If the change did not fulfill
the requester's requirements, the requester reopens the change.
The Planned Change Closure procedure diagram is presented on the next page.

Copyright 2004 - 2007 BMC Software, Inc.

Document
Author
Version

Creation date
Last edited
Page

: Change Management
: BMC Software, Inc.
: 7.0

Procedure 6, Planned Change Closure

Copyright 2004 - 2007 BMC Software, Inc.

: December 02, 2004

: October 08, 2007
: 15 of 20

Document
Author
Version

1.7

: Change Management
: BMC Software, Inc.
: 7.0

Creation date
Last edited
Page

: December 02, 2004

: October 08, 2007
: 16 of 20

Emergency Change Implementation

After the service provider (or on-duty manager if the service provider was not available) has
asked a specialist to resolve an incident by implementing an emergency change, the specialist
starts to work on the implementation. If the emergency change concerns an infrastructure
change, the specialist performs the implementation as if completing a normal incident request.
Alternatively, if the emergency change is an application change, the specialist first builds a new
release in the development environment and makes sure that it will fix the incident without
introducing new bugs. The specialist subsequently asks a release administrator to transfer the
new release to the test environment. In the test environment, the specialist tests the new release.
If the new release did not pass the test, the specialist goes back to the development environment
to correct it. On the other hand, if the new release passed the tests, the specialist asks the
release administrator to transfer it to the production environment.
The Emergency Change Implementation procedure diagram is presented on the next page.

Copyright 2004 - 2007 BMC Software, Inc.

Document
Author
Version

Creation date
Last edited
Page

: Change Management
: BMC Software, Inc.
: 7.0

Procedure 7, Emergency Change Implementation

Copyright 2004 - 2007 BMC Software, Inc.

: December 02, 2004

: October 08, 2007
: 17 of 20

Document
Author
Version

1.8

: Change Management
: BMC Software, Inc.
: 7.0

Creation date
Last edited
Page

: December 02, 2004

: October 08, 2007
: 18 of 20

Emergency Change Closure

The specialist performs the production test (with the help of a user if the specialist does not have
sufficient access rights) after the implementation has been completed. If the implementation turns
out to be unsuccessful, the specialist informs the service provider (or on-duty manager if the
service provider is not available) to discuss the situation.
Conversely, if the specialist has determined that the implementation is successful, he/she
completes the incident request. In addition, the specialist asks the change supervisor of the
affected service to register a change in the service management application for the emergency
change that he/she just implemented.
The change supervisor registers the change and, if required, ensures that the CMDB and the
Capacity Management information is updated. Before closing the change, the change supervisor
informs the service provider (and the on-duty manager if he/she approved the emergency change
implementation) via email that the emergency change has been implemented successfully.
The Emergency Change Closure procedure diagram is presented on the next page.

Copyright 2004 - 2007 BMC Software, Inc.

Document
Author
Version

Creation date
Last edited
Page

: Change Management
: BMC Software, Inc.
: 7.0

Procedure 8, Emergency Change Closure

Copyright 2004 - 2007 BMC Software, Inc.

: December 02, 2004

: October 08, 2007
: 19 of 20

*85894*
*85894*
*85894*
*85894*
*85894*