Change Management

Change Management Objective

Primary goal of the Change Management Process is to maintain the integrity of the production environment. Change management provides a gateway through which every change must pass on its way to the production environment. The Change Management Process ensures the implementation of changes with minimum risk to the business.

The objectives of Change Management Process are:

• Ensure efficient and prompt handling of changes.
• Provide accurate and regular information about all planned changes.
• Ensure consistent change implementation procedures
• Ensure adequate control measures are in place to minimize failure of change implementation.
• Ensure risk and impact analysis to assess and minimize the risk of implementing changes.
• Monitor and track the lifecycle of all changes.
• Ensure proper categorization of changes and that proper procedures are followed for each type of change.
• Ensure that changes are consistent with business and technical plans.
• Eliminate bureaucracy without compromising change implementation controls.
• Ensure that the Change Management Process complies with statutory requirements.

High Level Process Workflow

Key Definitions

1. Change: A Change is defined as the addition, modification, or removal of an authorized, planned, or supported service or CI.
2. Normal Change: Normal Change is a change to a service for which the approach is pre-authorised by the Change Management and has an accepted and established procedure to provide a specific change requirement.
3. Emergency Change: These are the changes that are required to restore service due to an incident or a change that needs to be implemented immediately to avoid impact. An ECAB is triggered in case of an emergency change which supervises on the approvals, prioritization etc.
4. Standard Change: Standard Change (a pre-approved Change) is a Change to a service or infrastructure for which the approach is pre-authorized by Change Management, that has an accepted and established procedure to provide a specific Change requirement. A Standard Change is of low risk, low impact, relatively common and follows a SOP (Standard Operating Procedure) or Work Instruction.
5. Change Work Item: It contains all the details of a Change. It carries a formal request for a Change to be implemented.
6. Task: Tasks are designed to perform specific level of work with a specific output. Many changes are divided into group of tasks to achieve desired results.
7. Impact: Impact is a measure of the effect of an Incident, Problem, or Change on business processes. Impact is often based on how service levels will be affected.
8. Request For Change (RFC): A change request is a formal proposal for an alteration to a product or system or an environment.
9. Configuration Item (CI): CIs are the components or service assets that need to be managed to deliver an IT service. Information about each configuration item is recorded in a configuration record within the configuration management system and is maintained throughout its lifecycle by service assets and configuration management.
10. Post Implementation Review (PIR): Purpose of PIR is to analyse the success of the Change and to make sure the Change is implemented as expected. PIR also contributes to the knowledge base for the team to learn from the experience.
11. Downtime: It is the span of time during which Services will be interrupted or unavailable.
12. Risk: It is an uncertain event that can either have a positive or negative impact on the business process.
13. Rollback (Back Out Plan): It is the process of restoring Services or Business Operations to a previously defined workable state or to design a new Implementation plan to bring Services back to normal.
14. Change Advisory Board (CAB): CAB delivers support to a Change Management team by approving requested Changes and assisting in the assessment and prioritization of Changes. This body is generally made up of IT and Business representatives that typically includes - a Change Manager, Technical Experts and Third-Party representatives & Customers (if required). As and when a CAB is convened, members should be chosen who can ensure that all Changes within the scope of the CAB are adequately assessed from both a business and a technical viewpoint.
15. Emergency Change Advisory Board (E-CAB): E-CAB is responsible for assessing, authorizing and implementing an Emergency Change as quickly as possible. This process is invoked if normal Change Management procedures cannot be applied because an emergency requires immediate action.
16. Lead Time: The Time between Change submission to Change implementation.
17. Change Freeze/Blackout Window: Time interval during which an organization wants to avoid Changes in the production environment. Changes during this freeze need to have a special approval and will be approved by the members of the ECAB.

3-Tier Structure

HCL BigFix Service Management has a 3-Tier structure for any ticket:

1. Service Request: Service requests are placed by Consumers for purchasing new Services. Service requests have prefix REQ#
2. Work Item: Work Items are created for Service Providers for fulfilment of Service requests. Work Items such as Incident, Problem, Change and Fulfilment Work Item are associated with Service Request followed by work item number. For example:
   • For Incident -> REQ# - INC#
   • For Fulfilment -> REQ# - ITM#
   • For Change -> REQ# - RFC#
   • For Problem -> REQ# - PRB#
3. Task: Each Work Item can have one or more tasks allocated to individual Service Provider groups. Task Numbers have prefix TSK. Tasks are optional and can be created manually if needed.

Process Input and Output

Classification of Change Types

Following types of changes are available in HCL BigFix Service Management

1. Standard Change: Frequently performed changes with documented implementation procedures. Their implementation is tested and proven, and their success can be determined and reported quickly. Standard Changes will have predefined workflows and tasks created in HCL BigFix Service Management in the form of templatized catalog items.
2. Normal Change: Normal Changes are planned regular changes. These changes will require a formal review and approval by the Change Advisory Board. The risk of this change may vary from low to high, depending on the criticality of the affected CI, the complexity of the change, and the impact on the business. It includes project or service improvement opportunities. Normal Changes will follow a defined lead time for testing, implementation and validation. Lead times can be configured for Normal Changes based on recommended policies of Customer Organization.
3. Emergency Change: Emergency Change refers to RFCs that circumvent the normal RFC process to resolve critical incidents, security patches or services that need an RFC for immediate repair. Emergency Changes do not have any lead times and will require Emergency CAB approval process for implementation.

RFC Submission Policy

All members of a support group (Service Provider/Service Supporter) who have the change user or change manager role are authorized to initiate RFCs. Consumers have the option to raise Standard Change Requests.

Anyone may identify the need for a change. However, creation of an RFC can only be initiated when proper justification exists. If the requester is not an authorized change initiator, they must contact the authorized change initiator to initiate an RFC.

All mandatory information related to an RFC must be complete.

An RFC can be submitted at any time.

Risk Assessment Policy

1. The risk involved in a Change is determined by assessing the following parameters and based on two criteria which is Technical Risk & Business Risk.
2. The risk assessment must be performed by the Change Initiator at the time of Change submission. Overall risk on a Change is automatically computed based on the values selected for ‘Risk Occurrence Probability’, ‘Impact if risk is realized’ and ‘Control Effectiveness’, respectively.
3. Risk assessment will be based on one or more of the following factors:
   • Criticality of the affected application.
   • Change schedule (maintenance window, business or non-business hours).
   • Adequacy of release testing.
   • Skill requirements.
   • Conflicts with other change(s).
   • Compatibility of components.
   • Change complexity.
   • Availability and adequacy of back-out and implementation plans.
   • Downtime or outage in the case of a back-out.
4. The risk will be assessed by the Change Initiator (an internal IT Operations person) but reviewed by the Change Manager for that change and verified and validated by the Approver.
5. An Approver can change the risk level or advise the Change Manager of the risk level.
6. Additional controls, such as those in the following checklist, should be enforced before execution of high-risk changes.
   • All affected users and the IT service desk have been informed and information posted on the bulletin board.
   • The change has been fully tested, and the reports have been documented.
   • The back-out plan has been documented and understood.
   • The appropriate business owner has been informed.

RFC Acceptance Policy

Change acceptance criteria in the initial review include, but are not limited to:

• Is it within the scope of IT service?
• Is it within IT Governance policy?
• Are there any conflicts with security policies?
• Are there any conflicts with IT strategy (such as deviations from standards or the IT roadmap)?
• Is it technically feasible?
• Is the information in the RFC complete and accurate?
• Are the effects on DR, if any, accounted for and required action plans included in the RFC?

If the information in the RFC is not adequate, it can be referred-back – a notification email is triggered to the Change Initiator or the concerned user requesting further details.

Change Approval Policy

1. No Change, even an Emergency Change, can be implemented without approvals.
2. By default, HCL BigFix Service Management allows to configure 4 level of approvals, however for Normal Change minimum two level of change approvals should be configured:
   • Level 1 RFC Approval (Change Manager)
   • Level 2 RFC Approval (CAB Approver)
3. RFC Approvals are configured against each CI at the time of CI creation. Additional approvals can be configured as & when needed.
4. An Emergency RFC that requires fixing a high-priority outage can be executed after appropriate approval from an authorized person. Written approval (e-mail) is preferred.
5. The Change Approver may reject scheduled or unscheduled changes due to inadequate planning, inadequate back-out plans or a negative impact of the timing of the Change on a key business process.
6. When RFC is rejected, the reason for rejection must be mentioned.
7. If the Change Initiator and the Approver are same, the change ticket is auto approved and moves to next approval.
8. Besides granting approval, the Change Approver can also perform the following actions on an RFC:
   • Change the risk assessments
   • Change the planned dates and
   • Provide additional instructions

Conflict or Collision Detection Policy

• Collision Detection is a procedure to identify the conflict between various changes scheduled during the same window
• Collision Detection is useful to identify other changes that are scheduled at the same time or impact the same configuration items (CIs) as a change request.
• Collision or conflict detection happens for normal and emergency changes. The tool will identify a conflict if the start and end time of the new change is falling between the start and end time of a change that is in Scheduled status.
• Conflict information will be visible as a pop-up window before the new change can be submitted. Conflict can be resolved by either changing the planned start and end time or by ignoring the conflict by providing a justification.

Multi Supplier Change

• Changes involving multiple suppliers would require active participation from all the suppliers involved, which will include:
  • Day-to-day change coordination activities, which will be performed by the Supplier Change Manager.
  • Sharing the required details as part of the change implementation activity and deployment plan.
  • Representing the Supplier and enabling successful implementation of the overall change.
  • Working with the Change Manager to execute the CAB discussions and approval.
  • Providing timely approvals for the tasks assigned to each supplier to achieve the estimated change implementation date.
  • Providing detailed justification for the tasks rejected or referred-back to the Change Initiator.

  • Active participation in identifying improvement opportunities as part of PIRs conducted for the changes.

Emergency Changes

• An Emergency RFC will only be created under the following situations:
  • To fix a high-priority incident or problem.
  • To avoid an imminent outage.
• Emergency is the highest RFC urgency level. An Emergency RFC must be responded to immediately because it may relate to a service interruption that is classified as high impact, either because it affects a large number of users or involves systems or services critical to the organization.
• The process, workflow and approval levels for an emergency change are the same as those for a normal change. However, in the case of Emergency changes, all activities, including approval, must be conducted as soon as possible.

Post Implementation Review

• All types of changes to production CIs must go through Post Implementation Review.
• Details will be recorded within the RFC ticket and Change Manager will review this.
• In the event of failed or backed out change, a detailed PIR report is created to document lessons learnt, deviation from solution and follow- up action. Change Manager ensures this is tracked and all follow-up actions are addressed, documented and brought to closure. Change Manager organizes a PIR meeting for each with all stakeholders including Change Initiator, Implementation team and Change Manager.
• PIR is conducted by Change Manager in HCL BigFix Service Management by completing the online form Post Change Implementation.

Change Completion

• RFC can be marked as completed only after the Change Initiator has agreed that the change achieved its purpose or the CAB has conducted a Post-Implementation Review.
• If CMDB update is required, it must take place before the RFC can be considered as “Completed”.
• Configuration Manager will update the CMDB and notify the change manager who would then perform the PIR and mark the change as Completed.

Change Cancellation

• The Change Initiator can cancel an RFC any time during its lifecycle. A request for cancellation is governed by the following policies:
  • If it is cancelled before approval, the RFC will move to cancelled stage
  • If it is cancelled after approval then Change Manager will check the implementation status, if it’s in ‘Scheduled’ and the implementation is not yet started, then it will be cancelled immediately by Change Manager.
• If the change is under implementation and roll back is possible, then the implementer will roll back the Change. For these RFCs also, standard closure process will be applicable after back-out.
• In case the change cannot be rolled back, then they will go through the implementation and closure process. The records will state that the cancellation did not occur, and the implementation was successful.

Preventing Unauthorized Changes

• An Unauthorized Change is a change implemented without approval(s) as defined by the Change Management Process. Unauthorized changes can be of two types:
  • Changes implemented without submission of an RFC. The Change Management Process is not designed to prevent, detect, or report unauthorized changes. These changes can be detected only during configuration audits.
  • An RFC is submitted but not approved and yet the change is implemented. The Change Management Process can facilitate detection of these unauthorized changes through an audit of RFCs submitted during a specific period.
• Any unauthorized change identified in the environment must be investigated to determine the reason the change was implemented.
• Reviews of unauthorized changes may be an additional CAB agenda to identify controls necessary to prevent unauthorized changes.

Change Process Workflow

Change – Request and Submission

1. Projects can undergo change at any stage. To ensure change flows smoothly, the change lifecycle should be governed end to end.
2. As soon as the need for change is identified via Investigation work Item or any other source, RFC must be created immediately. However, creation of RFC can only be initiated when proper justification exists.
3. If the requester is not an authorized change initiator, they must contact the authorized change initiator to initiate an RFC. All mandatory information related to RFC must be complete.
4. An RFC can be submitted at any time but with valid reasons and Business Justification.
5. Change Initiator needs to do provide Change Implementation, Test and Backout Plan before change submission.

Change – Approval, Implementation and Closure

1. Once a Change is submitted, notification is sent to the designated Level 1 Approver. This could be a technical approval. Technical approvers validate its risks and make an impact assessment. Then approver will approve or reject a change.
2. If the change is approved, it will move ahead for Level 2 Approval. This could be a CAB approval.
3. Once both the approvals are granted change will move ahead with its lifecycle. The change implementer(s) will initiate the implementation of the change. If the implementation is successful, the change implementer(s) provide the CMDB update information. All RFCs do not necessarily lead to a CMDB update.
4. If a change is unsuccessful and a correction is possible, then the change implementer(s) will perform an appropriate correction step and provide the CMDB with updated information.
5. If the change is unsuccessful and correction is not possible, then the back-out is performed to restore the system to its previous working state.
6. If the RFC is rejected at any of the Levels of approval (Level 1 & 2), the approvers will specify the reasons for rejection and the Change will move to Rejected stage, where implementer can Re-plan the change.
7. Downtime and Start and End date can be modified at Re-plan stage.
8. After a change is re-planned, it will again undergo process of review and approval, and the same cycle will follow.
9. After a successful implementation, the CMDB is updated, and the RFC status is updated as Completed. Configuration Manager shall be informed via email notification or by creating a manual ad hoc task for making the necessary changes in CMDB.

Change – Post Implementation Review (PIR) and Closure

1. The Change Manager for that change prepares a PIR report and initiates the review with the CAB and the Change Initiator before closing of the RFC.
2. The report includes review outputs containing any lessons learned and devised action plans.
3. If the change is rejected, or the change fails during testing and is determined not feasible, the RFC is closed without review.
4. PIR will be conducted by the Change Manager in HCL BigFix Service Management.
5. PIR Form will be available on the change form in Related Links which needs to be filled in by Change Manager before closure.

RFC Status Transition

Change Task Status Transition

Change Management – RASIC Matrix

Task Lifecycle

1. For Standard Changes, the tasks can be pre-defined along with auto-routing rules at the time of standard change template creation. This can be enabled in the Fulfillment Plan on the Service Board.
2. Tasks can also be pre-defined for a normal change or Emergency change from the Asset/Config board which can be auto routed to relevant groups based on CIs.
3. Ad-hoc parallel and sequential tasks can also be created for a change from the ‘Work item board’. The lifecycle of the tasks is same.
4. It is mandatory to close the tasks before the PIR is performed by the change manager.
5. If a change is cancelled, all underlying tasks will be cancelled automatically.

Change Module Roles Configured in HCL BigFix Service Management

Logging into HCL BigFix Service Management

To login, the user should:

• Open internet browser (Edge, Chrome) and enter the URL: https://support.dryice.ai
• Provide login credentials to authenticate and login to HCL BigFix Service Management

Landing page of Work Item Board

From the Application Menu, click on the Work Item Board. The User will be presented with the current Work Item Board.

Support users have a capability to sort Work Items based on various filters available on the landing page.

Alternatively, the change request can be searched from the global search at the top of the page.

Creating a Change Work Item

To create a Change (Normal, Emergency or Latent) Work Item, click on the icon on the landing page of Work Item Board. It will open a form that needs to be filled to create a Change Work Item.

Once all the Change request related details are filled, on the same page, click to Save or Cancel the form.

Lifecycle of a Change Work Item

Lifecycle of a Change Work Item is divided into several phases:

1. Draft: As soon as the Change Work Item is created, the first stage is ‘Draft’. In this stage Support User will assess and examine the Change. Change User/Implementer will draft an Implementation Plan with the course of action that are required to execute a change.

   A support user can perform the following actions at this stage.

   • Cancel a Work Item
   • Submit a Change Work item for review
   • Draft a detailed Implementation Plan.
   • Upload Attachments
   • Notify Intended Audience
2. Under Review: Once an Implementation plan is submitted for review to a Change Manager or an accredited Approving Authority, lifecycle moves to ‘Under Review’ stage. A change Work Item has to undergo two levels of approvals. Change Manager or any other accredited Approving Authority will be responsible for reviewing the Implementation Plan and subsequently Approving or Rejecting it.

   A support user can perform the following actions at this stage.

   • Cancel a Work Item
   • View the Implementation Plan
   • Approve/Reject a Work Item
   • Upload Attachments
   • Notify Intended Audience
3. Under Approval: As soon as the Level 1 approval is granted, lifecycle moves to its next stage based on levels of approval set up. Appropriate approvers will Approve/Reject the Work Item after review and ticket moves to next stage.

   A support user can perform the following actions at this stage.

   • Re-Plan an Implementation Plan
   • Cancel a Work Item
   • View Implementation Plan
   • Approve/Reject a Work Item
   • Upload Attachments
   • Notify Intended Audience
4. Scheduled: After Level 1 and 2 approvals are granted, Change lifecycle moves to ‘Scheduled’ stage.

   A support user can perform the following actions at this stage.

   • Re-Plan an Implementation Plan
   • Cancel a Work Item
   • Start Implementation
   • View Approvals
   • Upload Attachments
   • Notify Intended Audience
5. Under Implementation: As soon as the change User/Implementer starts executing the Implementation Plan, the lifecycle of the Change Work Item moves to ‘Under Implementation’ stage. If the Change Implementation review policy is enabled, then it is required for the

   change assignee to select a reviewer on the implementation task. The reviewer will then change the implementation task status to “Reviewed”.

   A support user can perform the following actions at this stage.

   • End Implementation
   • View Approvals
   • Upload Attachments
   • Send Notifications
6. Implemented: Once the Implementation plan is executed and Support user clicks on End Implementation lifecycle of a Change Work Item moves to ‘Implemented’.
7. Under PIR: After Implemented stage, lifecycle of a Change Work Item moves to ‘Under PIR’. Purpose of PIR is to analyses the success of the Change and to make sure the Change is implemented as expected.
   A support user can perform the following actions at this stage:

   • Document PIR
   • View Approvals
   • Upload Attachments
   • Send Notifications
   • CMDB Update (If CMDB Update Needed=Yes)
8. Completed: Once the PIR is documented and saved, Lifecycle of a Change Work Item moves to final stage which is ‘Completed’.

Updating Activity Journal

Relating other Work Items with Change Work Item

Support users can relate existing Change Work Items with Other Work Item if required based on following attributes:

Relating other Work Items with Change Work Item

Support user can relate existing Change Work Items with Other Work Item if required based on work item Type such as Change, Incident, Fulfilment and Problem.

Relationship can be removed using Delete icon

Search by – Item ID, Same Requester and Same Impacted CI. Click on Relate button to relate the work item.

Relating Configuration Items with Change Work Item

Support users can relate Configuration Item with Change Work Item whenever required by selecting Related CI from side panel.

User needs to click on + icon to search the Cis.

Configuration Items can be searched based on two parameters – CI Name and Class Name. Once the CI list is visible, users can select the CI and click on relate.

Identifying Applicable Approvals associated with a Work item

• Support user can check the Approving authority name’s applicable to a specific Work Item by the options explained in the snapshot below.
• Approval Audit log contains the history of approvals executed on the change request

Audit Log

Activity Details capture the details of the change ticket lifecycle:

• Comments contain the comments posted by support users.

  

• Audit log captures the changes in various fields throughout the lifecycle of a Change Work Item.

  

• Notifications contains the notifications sent for the change ticket.

  

Drafting an Implementation Plan/ Back out Plan

Change User/Change Manager are required to draft an Implementation plan explaining how the change will be implemented.

Submitting the change for review

Implementation Plan needs to be reviewed by the Change Manager or any authorized Approving Authority before its being executed by the

Change implementer. Once it's sent for review the lifecycle stage of Change Work Item changes to ‘Under Review’

Replan or cancel the change under review

Implementation Plan needs to be reviewed by the Change Manager or any authorized Approving Authority before its being executed by the Change implementer. Once it’s sent for review the lifecycle stage of Change Work Item changes to ‘Under Review’.

Approving/ Rejecting/ Referring back a Change Request from ‘My Approvals’ page

There is one more option to Approve/ Reject and Refer Back to the changes and that is from ‘My Approvals’ page:

• As any Approving Authority clicks Approve, a window will popup asking for confirmation. Click Yes if you want to Approve.
• In case Approving Authority is not satisfied with the documented Implementation Plan and needs modifications to be done to it, Click Reject, a window will popup asking for Reason of Rejection. Enter the same and click Submit.
• If the approving authority feels that if anything is missing and needs to be updated/modified, ‘Refer Back’ option should be used, and the Change Initiator must update the required details. The approvals in this case will start from Level 1 again.

Implementing a change

• Implementation Plan must go through two Levels of Approval- Level 1 and Level 2.
• Change Manager or any other Approving Authority will be able to view the submitted RFC in their bin for approval. They need to
• review the Implementation Plan before it gets implemented and suggest amendments/correction if required before approval.

  

Re-planning an Implementation

• In case a support user wants to Re-Plan an Implementation for a valid reason, they can do so by selecting Re-Plan option from the list below as shown in the snapshot.

  

• Re-planning an Implementation provides user with options to amend Start and End Date of Implementation along with alterations in Downtime.

Creating and Assigning Tasks to other support Groups

Support users can create and assign tasks for multiple support group if needed to work on same Change Work Item.

Tasks can be created and assigned based on following attributes:

• Sequence Number – 1,2,3 and 4.
• Sequence Type – Sequential and Parallel.
• Status – Assigned, In Progress, Completed and Cancelled.
• Assignment Group – This tab will include all the available groups (available in the dropdown list).

  

• Assignment to – Individual to whom Work Item will be assigned (available in the dropdown list).

  

Implementing an assigned Change Task

• Once a Task has been assigned to the Support User, it will be visible in the Task List View page of that User.

  

• Support User can view Task from the Task List View page by clicking the ‘Edit’ or ‘Pencil’ icon.

Assigning/Viewing the Task

On Clicking Edit, the form will appear, and changes can be made.

Implementing/Completing assigned Change Task

After implementing the task, the Support User must update the Task Status to ‘Completed’

Performing a Post Implementation Review (PIR)

Select ‘PIR’ is selected from the drop down list.

A template will open on the right which needs to be filled by the Change user to document PIR.

Support User needs to enter remarks in all the fields and Click Save. As soon as user clicks on it, PIR will be saved, and a message will pop up confirming the save.

Once PIR is completed, status of Change Work Item Lifecycle moves to ‘Completed’.

Notifying intended audience about the Work Item

• Support User can Notify the intended audience by sending emails to the respective recipients through the Notify option.
• Emails can be sent to a ‘Requester’ or a ‘Group’. Support User also has a provision to mention the email id of any intended individual/ group by selecting the ‘Specify’ option under ‘Send To’ field.

  

Cancelling a Change Work Item

• A Change Work Item can be cancelled, in various stages of a Lifecycle by selecting the ‘Cancel’ option.
• Support user can ‘Cancel’ the Change in following 3 Stages : Draft, Under Review, Scheduled stage.

  

How to raise Standard Change Request?

• In HCL BigFix Service Management, catalog manager exposes “Standard Change” catalog item in the Home page of “Shopping Catalog”.
• From where requestor can raise Standard Change Request.

  

Raise a Standard Change Request

The below form will be displayed on the screen. User needs to fill in the details to move ahead.

Once requestor submits the request, a RFC Number will generate from the system. The workflow of standard change will be same as Normal/Emergency which has described in above slides.