SERVICE MANAGEMENT
How to Effectively
Optimize Change Management?
A Unisys ITSM Best Practices Guide
White Paper
According to Wikipedia, Change Management is an IT Service
Management (ITSM) discipline. The objective of Change
Managemen...
3
Table of Contents
Best Practice Recommendations 	 4
Define a Single Change Management Support Group	 4
Permit Change Coo...
Best Practice Recommendations
Clearly Define Your Change Processes
Change Processes are basically the sequence steps or
ac...
•	 Feedback to the Change Advisory Board is NOT Centralized.
The Change Advisory Board needs to have a central leader
who ...
Clearly Define all Service Catalog Offerings
Supporting Each Change Process
Change Requests are initially driven by the ty...
Utilize the Class Options Effectively
The Class field defines the urgency of the Change Request.
Every option should be ut...
Utilize the Change Type Options Effectively
The Change Type field defines the type of service that the
change is associate...
Utilize Work Info Type Options to Track and
Enforce Documentation Requirements
The Work Detail section records the history...
Define Effective Approval Stage Processing
Approvals are an important part of the Change Management
Application, ensuring ...
Train Authorities on the use of Approval
Central Console
The Change Request can only be modified by the associated
Coordin...
Edge Service Management by Unisys
Turn insight into action with Edge Service Management by
Unisys. Drive increased value t...
Upcoming SlideShare
Loading in...5
×

How to Effectively Optimize Change Management?

335

Published on

To learn more visit: http://www.unisys.com/edge

Change Management is a mission critical IT Service Management (ITSM) discipline, whose objective is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes to manage IT infrastructure. This paper describes how you can effectively optimize Change Management for your enterprise by following Unisys best practice recommendations to minimize the number and impact of any related incidents upon service.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
335
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
13
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

How to Effectively Optimize Change Management?

  1. 1. SERVICE MANAGEMENT How to Effectively Optimize Change Management? A Unisys ITSM Best Practices Guide White Paper
  2. 2. According to Wikipedia, Change Management is an IT Service Management (ITSM) discipline. The objective of Change Management in this context is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes to control IT infrastructure, in order to minimize the number and impact of any related incidents upon service. Changes in the IT infrastructure may arise in response to problems or externally imposed requirements or from programs, projects or service improvement initiatives. Change Management can ensure standardized methods, processes and procedures which are used for all changes, facilitate efficient and prompt handling of all changes, and maintain the proper balance between the need for change and the potential detrimental impact of changes. Think of Change Management as an “effective means” to in-line all organizations and departmental changes under a central location, following a pre-defined process to incorporate changes within the company. Prerequisite This document supports the recommendations of implementing an effective Change Management environment through the utilization of the BMC Remedy Change Management application. 2
  3. 3. 3 Table of Contents Best Practice Recommendations 4 Define a Single Change Management Support Group 4 Permit Change Coordinators and Change Managers Only to Submit Directly into the Change Request Form 5 Clearly Define all Service Catalog Offerings Supporting Each Change Process 6 Minimize the Number of Change Coordinators 6 Utilize the Class Options Effectively 7 Utilize the Change Type Options Effectively 8 Establish Operational Categorizations Associated to Changes 8 Basing Risk Level Questions of Operational Categorizations 8 Utilize Work Info Type Options to Track and Enforce Documentation Requirements 9 Define Task and Task Group Templates 9 Established Configuration Assignment Rules for Each Change Process 9 Define Effective Approval Stage Processing 10 Train Authorities on the Approval Central Console 11 Provide a Step-by-Step Guide to Generate a Change Request 11 Utilize the Email System for Communication References to the Change Request 11 Edge Service Management by Unisys 12
  4. 4. Best Practice Recommendations Clearly Define Your Change Processes Change Processes are basically the sequence steps or activities that a Change Management Team or Project Leader would follow when applying changes to any associated application, project, product, process, resource, person etc. Every organization or department within a company should identify the processes that are to be incorporated into the Change Management application. This is done in 5 stages: • Request Stage • Preparation Stage • Management Stage • Implementation Stage • Reinforcement Stage Request Stage: This stage defines how a Request for Change (RFC) should be incorporated into the Change Management application. The recording of an RFC within the BMC Remedy Change Management application can be very complex for any end user to utilize without some type of basic training. Therefore, the initial recording of an RFC should be made as easy as possible for those who require the service that will be managed and implemented by another organization or department. Preparation Stage: Once the Change Request has been defined as valid, sufficient time is needed: to establish the appropriate steps to use; to ensure the change is implemented correctly and effectively; to identify all affected configuration items (CI); to identify all the necessary resources required to complete the request; to ensure there are no conflicting schedules; to make sure the appropriate approving authorities are aware of the upcoming request. Management Stage: The Change Management Team ensures: that the Change Request is in line with company policies and procedures; the approving authorities respond to the request appropriately and within the scheduled time frame; any issues that may arise in association with the recording and processing of the Change are resolved. Implementation Stage: At this stage, all the Change Requests should have at least one task to indicate when the request was actually implemented and another task to ensure the implementation process was effectively verified. NOTE - Utilizing tasks will help: define the Sequence Order of what needs to be performed; identify who should perform the tasks; define how long it took to perform the task. Additionally, another task should be considered to notify the Asset Management Team to ensure CIs have been generated, updated or terminated according to the request. Reinforcement Stage: The Change Manager and Change Coordinator should review the entire process to determine if changes are to be made in the implementation plan processing, approval authority requirements, risk assessment, impact areas affected, and more. Define a Single Change Management Support Group It is recommended that each company within the BMC Remedy Change Management application have a “single” Change Manager Team comprising of anywhere between three to five people. Having too many Change Managers can result in the following issues: • Change Managers are Likely to Follow Their Own Rules. Each Change Manager Team would end up defining their respective policies, procedures and process requirements. This will result in each organization or department doing its own thing to process a change and/or requiring a multitude of customizations to be incorporated into the Change form. • Change Managers are Too Close to Change Coordinators. The Change Manager Team needs to enforce the business policies and procedures defined for all departments and organizations to follow. Keeping this group to a single set and ensuring the appropriate people are trained to enforce these rules will help in effective maintenance of the change processes. • Change Managers are Too Busy - In the Real World of Events, people are tasked with a multitude of responsibilities. Limiting the Change Manager’s role to a small number will help one focus on their respective roles and responsibilities, ensuring the Change Requests are processed accordingly. 4
  5. 5. • Feedback to the Change Advisory Board is NOT Centralized. The Change Advisory Board needs to have a central leader who can provide feedback on all Change Requests that were submitted, processed, rejected, cancelled, etc. Therefore, it is best to have the Chairman of the Change Advisory Board come from the Change Manager Team, as this individual will be better informed of what is happening within the company. Furthermore, they will be better suited to avoid scheduling conflicts, overloading of a single support team, illegal changes, missed approval requirements, and more. • Difficulty in Adapting to Change. As technology and processes change, so do the roles and responsibilities of the Change Manager. This makes it challenging to retrain all the Change Managers as it is crucial to ensure they know and understand the new procedures and tools. Having a single support team that functions as the Change Manager for all the Change Requests submitted provides the Change Requester with a central point of contact to reach out to when issues arise with the Change Coordinators or if the Requester feels that delays in implementing their requests are unacceptable. It provides balance within the Change Management processes by having a central point to oversee and enforce company policies and procedures to everyone involved. Permit Change Coordinators and Change Managers Only to Submit Directly into the Change Request Form Like any Change Reporting application, the BMC Remedy Change Request form is not without its primary requirements and multitude of enhancement features that could make it too complicated for end users to understand. As training is generally overlooked, it is best to limit access to the creation of an RFC into the BMC Remedy Change Request form to a minimum, thus lowering the training costs for new and updated process changes. It is recommended that for end users the BMC Service Request Management module be used to define service requests that automatically create the change request. Change Coordinators understand the correct documentation requirements (implementation plan, back out plan, verification plan, resources required, scheduling of changes and more) needed for a Change Requester. This makes them perfectly suited to submit the Change Requests as they are well equipped with the necessary information, which increases their chances of obtaining approval. Change Managers should be limited in their submission of Change Requests. While their understanding of business needs and procedures may be good, they are not fully knowledgeable of all of the processes and procedures that are performed within the overall company. Hence, the Change Manager should only submit a Change Request directly into the system when a Change Requester has contacted them as a result of not knowing the front-entrance means of submitting an RFC via the BMC Remedy Service Request Management application To assist the Change Manager or anyone else unfamiliar with submitting an RFC, a series of templates should be created for common change requests. This will aid the requester in properly creating the RFC. 5
  6. 6. Clearly Define all Service Catalog Offerings Supporting Each Change Process Change Requests are initially driven by the type of service required by the Change Requester. Accordingly, defining the appropriate service catalog by defining Service CIs that will be used to support the Change Requester’s requirement would help determine the following: • Type of Service Being Requested. The Service Catalog defines the types of services being offered to the End User. This includes: -- Decommissioning or Commissioning of Servers. -- Employee Service Support – End User Profile Support. -- Employee On-Boarding. -- Software Service Support - Patch installations, customization requirements, configuration requirements, etc. -- Hardware Service Support – Memory upgrades, hardware additions or removals, etc. -- Scheduled Maintenance Support. • Assigning the Appropriate Product Categorization Requirements. The Product Catalog is the hardest to determine based on the number of CIs that can be associated with a single Change Request. The Service Catalog will provide an overall product categorization setting to support the service request and to assign the request to the appropriate Change Coordinators. NOTE: If the service is handled by different Support Groups based on a specialty, then it is recommended to breakdown the service catalog into smaller offerings to support the respective specialties. For example: Support Group A handles all patch installations for BMC Remedy Products, while Support Group B handles all patch installations for Microsoft Products. Thus, the two services should be defined as BMC Software Service Support and Microsoft Software Support, respectively. • Enhances the Business Need to Support the Service. Every Change Request associated with a Business Service will help Business Managers understand what types of services are requested the most frequently. This helps them determine which services need more resources, money, and management. • Satisfies the Requirement to Always Have CIs Associated with a Change Request. In some cases, companies will require a CI to be associated with every Change Request before it is approved. This can be difficult if the request necessitates a “new” product or requires something that is not being tracked within the underlying Configuration Management Database (CMDB). When selecting the Service Catalog (Service CI option), the “save” action will generate the relationship between the Change Request and the Business Service CI. It does take time to define the Business Services needed to support the Service CI process; however, in the long term, the time taken by a company to define its service catalog offerings within the Business Service process will help improve its capabilities to provide effective and sufficient support to its customers/end users. Minimize the Number of Change Coordinators Similar to Change Manager Support Groups, it is advisable to minimize the number of Change Coordinators to the appropriate number needed to “oversee” the Change Request process. The Coordinator Group within the BMC Remedy Change Management application is the “owner” of the Change Request, who has the overall responsibility of processing the Change. The Change Coordinator is the “Point of Contact” from the Coordinator Group, elected to communicate with the Change Requester, Change Manager, Approving Authorities, Task Implementers and everyone else about the Change Request. However, the Change Coordinator is not entirely responsible for the Change – this belongs to the Coordinator Group. The tasks associated with the Change Request define who performs the work. In this case, the number of Support Groups can be extensive as the tasks represent the specialty of the individuals, where the Coordinator Group is identifying the team that’s coordinating the work, plan, schedules, etc. 6
  7. 7. Utilize the Class Options Effectively The Class field defines the urgency of the Change Request. Every option should be utilized in order to best process the associated Change Request. Here is a list of the Class options and how they can be utilized effectively: • Normal – Use this setting for changes that need to take place sometime after the Change Advisory Board (CAB) has an implementation plan that has NOT been tested with multiple previous implementations of the same change. This type of change will require the Standard Process Flow. It is reviewed through the four out-of-the-box approval stages (Review, Business Approval, Implementation and Close Down), as the implementation plan (associated tasks, risk assessment, impacted areas, back-out plan, verification plan, etc.) has to be reviewed, approved, tested, implemented and re-tested. • Standard – Use this setting for changes that have been processed through the Normal Change method a sufficient number of times to know that it is consistently repeatable. It only requires a review by the Change Manager. These are reported to the CAB after implementation. This change can be done on the same day; however, the Change Request should at least be related to an existing Change Template to assure consistency with the previously implemented like changes. -- The Change Manager Group reviews the change to verify that it is a true Standard Change and to assign a Change Manager to the request. -- The Change Manager reports the overall process of the Change Request at the next CAB meeting and takes necessary actions based on the decisions of the CAB. This is generally done by setting up a Close Down approval for the Change Manager and having them only approve the request after it has been reported and signed off by the CAB. • Expedited – Use this setting for changes that have to be done prior to the subsequent CAB meeting; however, these changes are not classified as an emergency and don’t have a supporting Change Template/Standard Change to use. Expedited changes should follow the same path as the Normal process; but, the Change Coordinator must contact the necessary approving authorities for faster approval requests and must notify the Task Implementers of the impending importance of the Change Request. • Emergency – Use this setting for changes that have an Incident Request that requires IMMEDIATE action. Approvals are generally extended at the Review Stage, to obtain technical and business approvals through ad hoc or email approval requests before the work is completed. -- The Change Manager Group reviews the Change Request to ensure that it is assigned to the appropriate Change Manager, an incident request has been associated, and the process is being adhered to in order to support the reason for an emergency setting. The incident is required to justify the emergency. It is the driver of the urgency and is usually an outage. -- The Coordinator Group is responsible for obtaining the appropriate approval requirements and supplying the necessary information to support the Emergency change. In addition, they oversee the implementation of the change and follow up the process by ensuring the Change Request helped resolve the Incident. • Latent – This setting should be used when it is discovered that an undocumented change was done that have been tracked. This sometimes occurs when someone is implementing one change on a system and sees an additional smaller change is necessary at the same time. When a Latent change is selected, the status goes directly to “Completed”; however, an approval from the CAB or other appropriate authorities is required at the Close Down procedure to ensure the additional changes are acceptable or if the change has to be rolled back the pre-change configuration. • No Impact – This setting is generally used for those Business Services that do not require an approval and do not impact the company or a business service. These types of requests should be defined within Change Templates so the End User will have a better understanding of what does and does not impact the business or company. 7
  8. 8. Utilize the Change Type Options Effectively The Change Type field defines the type of service that the change is associated with. Here is a list of the Change Type options and how each can be utilized effectively: • Change – Use this setting for changes that are associated with a stand-alone change. This type of change can be part of another service request (Release or Project) or can be an individual request that does not have an implementation on anything other than the items associated within the Change. • Project – Use this setting for changes that indicate a project that is to be implemented where Release Management is not being defined or is not being utilized. For example: Commissioning a New Database would begin with a Project Change Request to initiate the approval process for incorporating a new database. With the approval, the implementation plan would require more extensive and timely actions, while the Project remains in the Implementation in Progress Status throughout life cycle of the new database. Following this, Change (Change Type) requests will be generated off the Project Change to support patch updates, memory increases, application installations, etc. • Release – Use this setting for changes that are associated with a Release Management Request. • Asset Maintenance – Use this setting for changes that are associated with routine maintenance requests. This is generally set up through the use of a Change Template and is triggered through the scheduling of CIs to be fired at a pre-defined time. Establish Operational Categorizations Associated to Changes • With any of the BMC Remedy ITSM Applications, one of the primary articles in a Change Request form is the Operational Categorization field. The following points highlight the importance of establishing Operational Categorization values: • Defines the specific service request that can be used in assigning the Change Request to the appropriate Coordinator Group. • Used by the Collision Detector feature to ensure that the Change Request is not overlapping with other Changes of the same type. • Used for reporting on the different types of specific services provided. • Used for searching capabilities to locate previous Change Requests that could be used as Templates through the Copy Change feature. • Defines the specific number and types of risk assessment questions that need to be asked in order to establish the appropriate Risk Level assessment. Basing Risk Level Questions off Operational Categorizations Without the use of the Operational Categorizations, the Risk Level Assessment would be defined either by the End User/ Change Template or the Change Coordinator, based on past experience or guessing. Another option would be to use a set of questions, suitable for all types of changes. These questions may not have a meaning against the request, thus resulting in inaccurate risk assessment. The operational categorizations correlating to the appropriate risk questions can provide the most accurate risk assessment, consequently affecting the overall reaction to the Change Request and/or Service Level Agreements associated with the change. 8
  9. 9. Utilize Work Info Type Options to Track and Enforce Documentation Requirements The Work Detail section records the history of what took place on the Change Request, from the time of generation to the time of closure. Within the Work Info Type field, a number of documented activities can be recorded using this option. This includes recording of the back-out plan, test results, rejection of a change, and more. Instead of utilizing an external document to track the plan requirements, it is simpler to utilize the Work Info Type options to keep the documentation requirements together and easier for individuals to access/review/approve. Define Task and Task Group Templates All Change Requests are required to have at least two tasks – one for implementing the change and one for verifying the changes made. However, there are other task requirements based on the type of request and what the request is going against that could best utilize the support of independent tasks and in some cases, grouping of tasks. When creating tasks, establish the Name of the task as the overall requirement, but ensure the Summary field can be interchanged for those requests that use a single task for multiple actions. For example: Addition or removal of memory from a server box could utilize a single task – TASK NAME: Add or Remove Resources Associated to Servers, while the Summary would be SUMMARY: Add 2 Gigs of Memory to Server GBS8383. The association of the Task would be handled by the same or different groups. When defining Task Group Templates, ensure the sequence is established with the correct order of when the tasks should be performed. If incorporating the option of having a task act as an approval requirement, that it is on its own sequence number setting, permitting the ability to bypass the remaining process for those tasks that are being rejected. Established Configuration Assignment Rules for Each Change Process The decision to determine what Change Coordinator Group should be responsible for the Change Request should not rest with the Change Manager Group. The Change Manager Group membership changes like any other Support Group; new members are learning the processes and procedures, which may result in them incorrectly assigning a Change Coordinator group to the Change Request. Establishing the Configuration Assignment settings would remove control of the training process from the Change Manager and assign it to the Change Management Board (not the CAB). The assignment processes are pre-defined. When changes are needed, the CAB can approve the same for the Change Management Board to update within the Foundation Data settings of the BMC ITSM Applications. 9
  10. 10. Define Effective Approval Stage Processing Approvals are an important part of the Change Management Application, ensuring the Change Requests are beneficial and necessary to support a business service, process or need for the company. Inability to establish the appropriate approving authorities for each of the Change Processes is the primary reason why Change Management fails. Approving authorities must understand their roles as far as the Change Management Application is concerned. They must ensure that the changes are reviewed in a timely manner, while making certain that the implementation process is on the right track to execute the change. Depending on the Change Type, the Class settings should drive what type of approval stages should be utilized by the team. You can utilize the four out-of-the-box stages provided, based on the following scenarios (This will only focus on the Change Type being used): Class = Normal and Change Type = Change • Review -- Change Manager Approval – Level 0 • Business Approval -- Business CAB Chairman Approval – Level 0 • Implementation Approval -- Change Manager Approval – Level 1 -- Technical CAB Approval – Level 5 for each Support Group -- Ad hoc Approval Requirements Defined here at life of Change • Close Down Approval -- Asset Management for CI changes – Level 1 -- Change Manager for CAB Reporting and final review – Level 5 Class = Standard and Change Type = Change • Review -- Change Manager Approval – Level 0 • Business Approval -- NOT REQUIRED • Implementation Approval -- NOT REQUIRED • Close Down Approval -- Asset Management for CI changes – Level 1 -- Change Manager for CAB Reporting and final review – Level 5 Class = Expedited and Change Type = Change • Review -- Change Manager Approval – Level 0 • Business Approval -- Business CAB Chairman Approval – Level 0 • Implementation Approval -- Change Manager Approval – Level 1 -- Technical CAB Approval – Level 5 for each Support Group -- Ad hoc Approval Requirements Defined here at life of Change • Close Down Approval -- Asset Management for CI changes – Level 1 -- Change Manager for CAB Reporting and final review – Level 5 Class = Emergency and Change Type = Change • Review -- Change Manager Approval – Level 0 -- Technical CAB Approval – Level 5 for each Support Group -- Ad hoc Approval Requirements Defined here at life of Change • Close Down Approval -- Asset Management for CI changes – Level 1 -- Change Manager for CAB Reporting and final review – Level 5 Class = Latent and Change Type = Change • Close Down Approval -- Asset Management for CI changes – Level 1 -- Change Manager for CAB Reporting and final review – Level 5 Class = No Impact and Change Type = Change • Review -- Change Manager Approval – Level 0 • Close Down Approval -- Change Manager for CAB Reporting and final review – Level 5 10
  11. 11. Train Authorities on the use of Approval Central Console The Change Request can only be modified by the associated Coordinator Group and Change Manager Group members. When an approving authority is requested to sign off on a Change Request, they can only review the Change Request and add a Work Detail entry (primarily the Rejection Information reason for rejecting a change) directly within the request. Training the approving authorities on how to use the Approval Central Console helps save time and enables them to understand how the approval or rejection requirements work. Additionally, when rejecting a request, the approver needs to understand that the Change Requester, Change Coordinator and Change Manager are unaware why the Change was rejected, if it is done through the Approval Central Console. Therefore, the approver needs to enter this information into the Change Request’s Work Detail section. For holding a Change Request, the approver should utilize the Email System feature on the Change Request to submit their questions to whomever, as this option will record their questions and make the responses added to the Work Detail visible to all. Provide a Step-by-Step Guide to Generate a Change Request Always establish a checklist guide for the Change Coordinators and Change Managers to follow when generating a Change Request through the Change Request form. This will ensure that everyone follows the same processing procedures while utilizing the Change Management application. For example: • Key in your primary Change Support Group and your name into the Coordinator Group and Change Coordinator fields, respectively. • Identify the Change Requester if you are not using the Requested for URL. • Select a Change Template or complete the Summary/ Notes fields, detailing the type of request being made. • Select the Type of Service (Service CI field) being requested. • Select the appropriate Class setting if not using Normal or not selecting a Change Template. • Determine the Impact and Urgency of the Change Request. • Fill in the Operational Categorization requirements (if not already provided by the Change Template). • Answer the Risk Level Assessment questions (select the Risk Weight Scale button). • Add the Implementation Plan Document to the Work Detail – Technical Design option, along with the Back-Out Plan, Verification Plan, etc. (This can be done now or at the Planning In Progress Status). • Associate the affected CIs. • Associate the Task Template or Task Group Templates (or build your own tasks – ad hoc) to support the implementation process. • Establish the Scheduled Start Date and Scheduled End Date requirements. • Save the change request. Utilize the Email System for Communication References to the Change Request When communicating about the Change Request, it is recommended to utilize the Email System feature to exchange information via email. Anyone with access to the Change Request can use the Email System to set up the initial communication thread. Upon saving the email (selecting the Send Email option), a record is generated in the Word Detail section with the information provided in the outgoing message. However, if you are expecting a response to your email, you must include the responding email address within the body of the text. This option is highly beneficial for approving authorities who need answers to their questions from the Change Requester or anyone associated with the overall Change Request. 11
  12. 12. Edge Service Management by Unisys Turn insight into action with Edge Service Management by Unisys. Drive increased value through a cloud-based pre-built, proven, and business ready solution powered by BMC and advanced by Unisys. Use real-time analytics to accelerate problem resolution, proactively improve and gain competitive advantage through enhanced support for people, operations, and business. For more information visit www.unisys.com/itsm © 2014 Unisys Corporation. All rights reserved. Unisys, the Unisys logo, and Edge Service Management by Unisys are registered trademarks or trademarks of Unisys Corporation. All other brands and products referenced herein are acknowledged to be trademarks or registered trademarks of their respective holders Printed in the United States of America 03/14 14-0146

×