Change support is a very critical service management practice in ITIL. Here we introduce its service improvements and other service management practices.
First, let's look at the definition of change: any addition, modification, or deletion operation that may directly or indirectly affect the production service.
This usually includes changes to IT infrastructure, applications, documents, processes, supplier relationships, and any other key components of the service. Although some IT organizations focus only on hardware and software change process enhancements, it is important to remember that other elements also play an important role in service development and delivery, and changes to them can have a negative impact on customers.
What is change support?
The purpose of change support practices is to maximize the number of successful IT changes by ensuring that risks have been properly assessed, authorizing changes, and managing change plans.
(Please note: In previous versions of ITIL, this approach was called "change management" and "change control." The term shift in ITIL 4 emphasized the latest version's acceptance of flexible, less stringent environments.)
The distinction between change support and organizational change management is important. Organizational change management The personnel aspect of managing changes to ensure that in order to successfully implement improvements and organizational change plans, change enhancements usually focus on product and service changes.
In ITIL, we usually identify three types of changes: each is managed in a different way, namely standard, regular, and emergency changes.
Change authorization refers to the individual or group that authorizes the change. It can be a team, supervisor, manager, chief executive officer, the board of directors, customer, or regulatory agency, depending on the nature of the change and organizational methods and culture.
The correct change permissions must be assigned to each type of change to ensure that change support is efficient and effective. There is no need to form a board of directors to approve those relatively low-risk changes locally.
In high-speed organizations, decentralization of change approval is a common practice, making peer review the highest predictor of performance. For example, the agile product team will decide which elements of the product backlog will be resolved in the sprint, and the agile product manager will decide which customer needs will be included in the product backlog. Organizations that adopt DevOps practices may establish system approvals based on the success of automated checks in the continuous integration/continuous deployment (CI/CD) pipeline.
No matter who the change authorizer is, they may need to communicate extensively throughout the organization and with key stakeholders. It is important to prepare all participants and all affected persons in advance to prevent accidents. For example, maintaining good communication with the service desk may be important to ensure that high call volumes do not cause uncontrollable surprises after erroneous changes.
The marketing team may wish to avoid planned activities when critical systems are unavailable.
In situations where a large number of people with professional knowledge are required, such as when assessing the risks of complex changes, good communication is also particularly important.
The change schedule is used to help plan changes, assist communication, avoid conflicts, and allocate resources. It can also be used to provide the information needed for incident management, problem management, and improvement plans after deploying changes. It is important to disclose the change schedule to all key stakeholders involved in the change through communication channels that may convey information to them in a timely manner.
The relationship between change support and service value chain
Change support practices involve all activities in the service value chain, as follows: