According to ITIL (Information Technology Infrastructure Library) best practice, change management divides the requests into three different types: Standard Changes, Non-Standard Changes, and Emergency Changes. Each type applies to a different entry point into the configurable life-cycle (statuses, reasons) of change requests. Workflows are used to describe and automate the various different change management processes, depending on the classification of tickets or any other related information. With the provided workflow activities, even complex change workflows can be easily configured, mixing approvals with manual tasks or even technical automation tasks. Default workflows support a quick start and allow simple modification of standard processes.
Classification of Change Requests
Standard changes are changes of infrastructure or service components. Standard changes have a well-known and repeatable implementation pattern. The risks, costs and required implementation tasks are known and the Change Advisory Board (CAB) approval is not required.
Typical examples are software installations on client computers, granting access privileges to users or adding peripheral components to computers.
Standard changes can therefore be used as provisioning actions for services that are ordered from the Matrix42 Service Catalog.
For non-standard changes, the costs, risks and required activities for implementation and review are usually not clearly known at the time the change is requested. Therefore, they need to pass all change processing phases including analysis, approval and review. It is possible to add additional tasks manually to the change during the process runtime to deliver the desired results.
Typical examples are modifications in server, network or security infrastructure of the data center, which mostly bear higher costs and risks and therefore should be properly planned.
Non-standard changes can be requested by email, through the Matrix42 Self Service Portal, or created directly in the application. As the final costs and tasks are not known at the time of the request, they should never be used as provision actions for services.
Emergency changes have a very special nature. They are usually created in the system after the implementation and are used only for documenting the changed settings and coordinating a proper review.
The analysis and approval phases are skipped – approval is usually given verbally by the ECAB (Emergency Change Advisory Board) – and the implementation phase is usually finished.
A typical example for an emergency change might be reconfiguration of a system due to a critical problem.
Emergency changes can be created only by change management directly in Matrix42 Service Desk.