Implement Change Management through Process Workflows

IT-related change requests have cost and performance-related impacts. You must carefully plan and then exercise the IT services requests in a controlled manner. Poorly planned change can result into loss in terms of time and money. A competent authority must study the change and its impacts, before actually implementing it. The reviewers analyze the change proposal and post comments. An approval group is a group of users, which after considering all the information, approves, rejects, or asks for modifications. Currently, the functionality of approvals is limited to only Change Tickets. Understand the concept of change management, before configuring approval groups.

Change Management

Change management is the process of managing a change ticket through its lifecycle. Change management involves setting a process to handle changes so that they are well-planned and have no negative impact. The change management aims to ensure that the following processes are implemented:

• Change is classified using an appropriate change type and processed through an appropriate workflow. For example, hardware change or software change.
• Change is submitted through an appropriate change approval process that is specific to the change type. For example, the data security team must approve any change requests with security impacts.
• Change is implemented according to a defined process and includes tasks to verify that all aspects of the change are implemented. For example, moving a server location needs prior notification, physical movement, and a notification when it starts from the location.
• Implementation is reviewed to ensure that lessons are learned from failures and overall business risk is minimized.
• Change is recorded in all related systems before closure.

Change Types

The change requests are classified into the following types, which are based on the nature of change, impact, and urgency:

• Standard Change: Standard change is the change type that is suggested for common IT systems and services-related requests. For example, an employee requests to install a software or a database. Standard change requests do not require a change approval process and the manager of the requester generally approves these requests.
• Normal Change: Normal change is the change type that is suggested for proactive and planned changes to IT systems and services. These changes require thorough investigation, detailed implementation plans, multiple level review and approvals, and post-implementation reviews. For example, implementing a new security system which impacts how users access the IT resources over a VPN.
• Emergency Change: Emergency change type is the change type that is suggested for reactive situations where implementing a change is required. The change can either correct or avert a major problem with existing systems or services. These changes require quicker approval and implementation process. For example, replacing a faulty database server leading to downtime for several users.
• Break-fix Change: Break-fix change is the change type that is suggested to report a change after it has been implemented without an approval process. For example, security of a server is compromised and it is removed from the network to prevent further security breech. These changes do not go through an approval process and only saved for record keeping. Each of these change types can have a change management workflow with relevant approval groups, ticket templates, workflow actions, and auto routes.

Change Reviewers and Change Approvers

The change reviewers are specialized users having expertise with a system or service to which a change is related. The change reviewers analyze the proposed change and advice the approvers by commenting on it. The change reviewers cannot hold or reject a change. The change approvers are specialized users having authority to approve or reject a ticket or defer the decision and ask for more information. As an administrator, you can configure the workflow for the change approval process. You can ensure that a change ticket goes to a particular approval group for approval. If you configure an Approval Group without setting any Matching Conditions, the Approvers and Reviewers from that group feature as Approvers/Reviewers for ALL changes. You can select an Approval Type from the following options:

• All Approvers: The change is approved only if all approvers of the approval group approve the ticket. If any approver rejects the ticket, the change is rejected.
• Any One Approver: A change is approved as soon as any one approver of the approval group approves the ticket. The change approval process does not wait for the inputs from the remaining approvers. However, the approval is rejected only when all of the approvers reject the change.
• Any One Approval or Rejection: A single approver from the approval group either approves or rejects the change. The decision of the first approver to approve or reject is applied to the change request.

Named and Contextual Approvers

The Named Approvers and reviewers are the known approvers for a particular change. If you know a person or a group with the authority to approve the change, you can select them as named approver. The named approvers are selected for the change requests requiring complex approval process. For example, you can select a finance manager, who approves the change requests having financial impact, as a named approver.

Note: To use a support group as a named approver, enable the Used for Approval option for that group.

The Contextual approvers and reviewers are the contacts who become a part of the change approval process. The process is based on the context of the ticket. For example, a change request to change particular software does not impact any other user. The request requires only the approval from the immediate manager of the requester. The name of the manager depends on the name of the requester. In such cases, you can select Manager of Requester as the contextual approver and the actual approver is selected based on the requester. The contextual approvers and reviewers are:

• Manager of Requestor
• Manager of Requested For
• Manager of Assigned Individual
• Group Lead of Assigned Group
• Assigned Individual
• Assigned Group
• Requestor
• Requested For
• Approver of Affected Service
• Approver of Related Service CI
• Approver of Related Non-Service CI

Note: Proper configuration of support groups, contacts, and configuration items class categorization is required to exploit the contextual approver feature. For example, you can assign Group Lead of Assigned Group as the contextual approver only if you have defined a group lead for the selected support group.