7.1 itsm chg best practice process 85894

8/9/2019 7.1 ITSM CHG Best Practice Process 85894

1/24

www.bmc.com

White Paper

BMC Best Practice Process

Flow for ChangeManagement

October 2007


2/24

If you have comments or suggestions about this documentation, contact Information Design and Development by email at

doc_ f eedback@bmc. com.

Contacting BMC Software

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

United States and Canada

Address BMC SOFTWARE INC2101 CITYWEST BLVDHOUSTON TX 77042-2827USA

Telephone 713 918 8800 or800 841 2031

Fax 713 918 8000

Outside United States and Canada

Telephone (01) 713 918 8800 Fax (01) 713 918 8000

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, andlogos may be registered or pending registration in the U.S. or in other countries. All other trademarks or registered trademarks are theproperty 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 issubject to the terms and conditions of the applicable End User License Agreement for the product and the proprietary and restrictedrights notices included in this documentation.

Restricted rights legend

U.S. Government Restricted Rights to Computer Software. UNPUBLISHED -- RIGHTS RESERVED UNDER THE COPYRIGHT LAWS OFTHE UNITED STATES. Use, duplication, or disclosure of any data and computer software by the U.S. Government is subject torestrictions, 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, TX77042-2827, USA. Any contract notices should be sent to this address.
mailto:[email protected]://www.bmc.com/mailto:[email protected]://www.bmc.com/


3/24

Customer Support

You can obtain technical support by using the Support page on the BMC Software website or by contacting CustomerSupport 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 atht t p: / / www. bmc. com/ suppor t _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 orsend an email message to cust omer _suppor t @bmc. com. (In the Subject line, enterSupI D: , such as SupI D: 12345.) Outside the United States and Canada, contact your localsupport 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 f i l e syst em f ul l Messages from related software
http://www.bmc.com/support_homemailto:[email protected]:[email protected]://www.bmc.com/support_home


4/24

License key and password information

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

E-mail cust omer _suppor t @bmc. com. (In the Subject line, enter SupI D: , such asSupI D: 12345.)

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

Submit a new issue at ht t p: / / www. bmc. com/ suppor t _home.
mailto:[email protected]://www.bmc.com/support_homehttp://www.bmc.com/support_homemailto:[email protected]


5/24

Document : Change Management Creation date : December 02, 2004

Author : BMC Software, Inc. Last edited : October 08, 2007Version : 7.0 Page : 1 of 20

Copyright 2004 - 2007 BMC Software, Inc.

1. Process Description

The Change Management process consists of eight procedures; six for implementing plannedchanges, and two for implementing emergency changes.

The first procedure is called "Request for Change Review". This procedure is used by changesupervisors when they are dealing with requests for change.

The second procedure is called "Change Planning". It is used by change supervisors andspecialists to prepare the implementation plans for changes.

The third procedure is called "Change Approval". It is used by the change manager andapprovers (i.e. customer representatives and service providers) to approve planned changes.

The fourth procedure is called "Infrastructure Change Implementation". It is used by specialists toimplement infrastructure changes.

The fifth procedure is called "Application Change Implementation". It is used by specialists,release administrators, customer representatives and change supervisors to implementapplication changes.

The sixth procedure is called "Planned Change Closure". It is used by specialists when theyperform production tests after changes have been implemented and by change supervisors whenthey close out changes.

The seventh procedure is called "Emergency Change Implementation". This procedure is usedby specialists and release administrators to implement changes to resolve incidents.

The eighth and last procedure is called "Emergency Change Closure". This procedure is used byspecialists and change supervisors to complete and close out emergency changes.

A graphical representation of the process is provided on the next page. Each procedure isdescribed in more detail in the sections that follow this diagram.


6/24

Document : Change Management

Author : BMC Software, Inc. Version : 7.0


Change Management Process


7/24




1.1 Request for Change Review

The change supervisor receives the requests for change for the service(s) that he/shecoordinates the change for. The requests for change can originate from the following fivesources:

Incident Management, in the form of incident requests which resolutions need to beimplemented by Change Management,

Incident Management, in the form of changes that were generated upon the submission ofthe 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 newrequest for change to the existing change to optimize efficiency.

If the request for change asks for the implementation of a standard change, the changesupervisor 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 checksthe 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 policythat the request for change conflicts with.

If there is no conflict, the change supervisor determines whether the change implementationreally 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 changesupervisor rejects the request for change and informs the requester that Change Management isnot required.

If it has been determined that Change Management is required for the implementation of therequested change, the change supervisor determines whether the request for change should bepassed on to Release Management. Release Management is not required if the request forchange 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 orContinuity Management, the change supervisor selects the most appropriate change templateand/or task (group) template(s) to prepare the change. All other requests for change areassigned to Release Management.


8/24




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


9/24




Procedure 1, Request for Change Review


10/24




1.2 Change Planning

After having registered a new change, the change supervisor starts the risk & impact analysisphase by gathering the necessary information so that a change implementation plan can becreated 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 newservice infrastructure is to be built, or if an existing service infrastructure is likely to require amodification in order to satisfy the change requirements, the change supervisor also requests theassistance from the availability manager for the creation of a new, or the modification of anexisting, service infrastructure design.

Having gathered all the risk & impact information, the change supervisor finalizes the planning forthe change implementation ensuring that the risk of failure and the impact on the user(s) isminimized.

If the change is a standard change for which the approval phase can be skipped, the changesupervisor 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 necessaryapprovals.

The Change Planningprocedure diagram is presented on the next page.


11/24




Procedure 2, Change Planning


12/24




1.3 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 inconflict with internal standards or policies, he/she informs the change supervisor that the changecannot be implemented.

If the change is not in conflict with any internal standards or policies, the change managerreviews the risk assessment and the implementation plan. The change manager checks the planto ensure that appropriate precautions have been planned to minimize both the risk of failure andthe impact on the user(s), and that the timing of the implementation does not conflict with otherplanned changes or planned events.

If the risk & impact analysis is found to be insufficient, the change manager requests additionalanalysis 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 changesor events, the change manager requests an adjustment of the implementation plan from thechange supervisor.

On the other hand, if the risk & impact analysis and the planning of the implementation appear tobe in order, the change manager ensures that the necessary approvals will be collected for thechange.

Approval is required from the representatives of customers who will be affected by the changeimplementation, 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 plannedimplementation.

If the change is rejected by an approver, the change manager finds out why. The changemanager asks the change supervisor to perform additional risk & impact analysis or to adjust theplanning if that was the reason why the change was rejected.

If the change was rejected for any other reason, the change manager informs the changesupervisor that the change cannot be implemented.

The Change Approvalprocedure diagram is presented on the next page.


13/24




Procedure 3, Change Approval


14/24




1.4 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, areassigned to the specialist(s) for the preparation of the implementation (i.e. to ensure operationalreadiness). 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 actualimplementation of the change.

The Infrastructure Change Implementationprocedure diagram is presented on the next page.


15/24




Procedure 4, Infrastructure Change Implementation


16/24




1.5 Application Change Implementation

After the first implementation task(s) of the application change have been assigned, one or morespecialists develop the new release in the development environment. The new release is testedby the specialist(s) to ensure that the change requirements have been met. This is done in aseparate test environment if one has been made available for this purpose. Otherwise, the testsare performed in the development environment. The (automated) scripts for regression testingare also updated and run by the specialist(s) if such scripts are available for the application. Thespecialist(s) fix any errors that were encountered during the tests in the developmentenvironment.

Once the specialist(s) have confirmed that the change requirements have been met and that nonew bugs have been introduced, the release administrator transfers the new release to the testenvironment where the customer representative(s) ensure that it gets tested.

The change supervisor creates and assigns additional tasks if the new release did not passcustomer testing, so that the new release can be corrected. If these additional tasks caused thetransfer 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 isready to take the new release into production (i.e. ensure operational readiness). This couldinvolve user training, the addition of storage capacity to the production and continuityenvironments, ordering additional software licenses, etc.

Finally, the release administrator transfers the new release into production.

TheApplication Change Implementationprocedure diagram is presented on the next page.


17/24




Procedure 5, Appl ication Change Implementation


18/24




1.6 Planned Change Closure

After the change has been put into production, a specialist (with the help of a user if the specialistdoes not have sufficient access rights) performs the production test to verify the success of theimplementation.

The CMDB, the Capacity Management and the Continuity Management information is updated asneeded after the specialist has determined that all the requirements of the change have beenmet. If all change requirements have not been fulfilled, however, the specialist who performed theproduction test determines if the change implementation should be backed out. The change isbacked out if its implementation does not provide an improvement over the previous situation, orcauses a security or data integrity risk.

If the unsuccessful change implementation can still be made into a success, the changesupervisor 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 areinformed. If the change implementation was found to be successful, the requester of the changewill receive a notification that the change has been completed. The requester then checkswhether his/her requirements have been fulfilled. If the requester has verified that therequirements have been met, he/she does not need to take any action. If the change did not fulfillthe requester's requirements, the requester reopens the change.

The Planned Change Closureprocedure diagram is presented on the next page.


19/24




Procedure 6, Planned Change Closure


20/24




1.7 Emergency Change Implementation

After the service provider (or on-duty manager if the service provider was not available) hasasked a specialist to resolve an incident by implementing an emergency change, the specialiststarts to work on the implementation. If the emergency change concerns an infrastructurechange, 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 newrelease in the development environment and makes sure that it will fix the incident withoutintroducing new bugs. The specialist subsequently asks a release administrator to transfer thenew 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 environmentto correct it. On the other hand, if the new release passed the tests, the specialist asks therelease administrator to transfer it to the production environment.

The Emergency Change Implementationprocedure diagram is presented on the next page.


21/24




Procedure 7, Emergency Change Implementation


22/24




1.8 Emergency Change Closure

The specialist performs the production test (with the help of a user if the specialist does not havesufficient access rights) after the implementation has been completed. If the implementation turnsout to be unsuccessful, the specialist informs the service provider (or on-duty manager if theservice provider is not available) to discuss the situation.

Conversely, if the specialist has determined that the implementation is successful, he/shecompletes the incident request. In addition, the specialist asks the change supervisor of theaffected service to register a change in the service management application for the emergencychange that he/she just implemented.

The change supervisor registers the change and, if required, ensures that the CMDB and theCapacity Management information is updated. Before closing the change, the change supervisorinforms 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 Closureprocedure diagram is presented on the next page.


23/24




Procedure 8, Emergency Change Closure


24/24

!"#"$%!!"#"$%!!"#"$%!!"#"$%!

*85894*

7.1 itsm chg best practice process 85894

Documents