The ITIL 4 body of service management best practice guidance offers a clear purpose statement:
… to maximize the number of successful service and product changes by ensuring that risks have been properly assessed, authorizing changes to proceed, and managing the change schedule.
Source: AXELOS, Change Enablement ITIL 4 Practice Guide (2020)
Where a change is “The addition, modification, or removal of anything that could have a direct or indirect effect on services.”
There are four common reasons why change happens:
Importantly, change enablement, provides a formalized way to consistently handle the changes required to improve IT services, IT and business operations and outcomes, and ultimately customer experiences and outcomes.
In the case of change enablement or change management there are two similar, but different, ITSM capabilities that need to be seen, and treated, differently to change:
Change enablement in ITIL 4 is far less complicated than change management was in ITIL v3/2011. The differences are covered in a later section.
The new ITIL 4 change enablement guidance includes the following two change processes:
Change lifecycle management includes the following activities:
The change optimization process is concerned with continually improving the change enablement practice, change models, and standard change procedures.
Modern business needs change, and there are many drivers of change. Some are internal such as new products and services, revised ways of working, mergers and acquisitions, or correcting technology issues. Some are external such as legal or regulatory changes. Organizations need formal change capabilities that balance speed, risks, costs, and business value to deal with this constant flow of change.
The benefits of change enablement/management reflect these needs:
ITIL 4 also includes some changes specific to change management
By renaming change management to change enablement, ITIL 4 avoids the confusion with people-related change practices and better positions the guidance to enable better business outcomes.
ITIL 4 also blends in key DevOps concepts, including:
ITIL 4 change guidance also includes how different levels of complexity affect change needs. The diagram below is taken from the AXELOS Change Enablement ITIL 4 Practice Guide:
Another key difference with the ITIL 4 change enablement guidance is with change-related roles. A new change authority role has replaced the change advisory board (CAB) model previously espoused by ITIL. Where changes can be assessed and authorized by peer reviewers and automation.
When starting with change enablement - or change management if this term is preferred - there are many necessary, “common sense” steps to take. These include:
Change management capabilities have long been a staple of ITSM tools. It’s not uncommon for ITSM tool vendors to demo their solution using an IPC approach - where:
There are separate change management tools available, but most organizations prefer to use the native change capabilities of the corporate ITSM tool that’s already employed to deliver against a variety of service management needs.
This approach benefits from the ability to move incident data into a problem record seamlessly and then into an RFC. Plus, this gives change enablement access to workflow automation, notification and reporting to assist in process execution. This can assist with classification of changes, change-model routes, approvals and facilitating other procedural needs.
In addition to these capabilities, there are some key change -management -specific capabilities required of fit-for-purpose ITSM tools, including:
More recently, ITSM tools have been introducing artificial intelligence (AI)-enabled capabilities - leveraging machine learning and natural language understanding (NLU) - to improve their change enablement/management capabilities. These technologies can assist with things like change categorization or the assessment of risk.