SP5: Assess and coordinate changes

 

Process name: Assess and coordinate changes - Part of: Supporting processes

Previous process: Manage configuration information

Next process: Manage projects

 

Process description

The change management process in YaSM (fig. 1) acts as a gate-keeper, ensuring that modifications to the service provider's range of services and its underlying components are made only after risks and potential side-effects have been carefully considered.

Fig. 1: 'Assess and coordinate changes':
YaSM change management process SP5.

To this end, other YaSM processes requiring a change will submit a request for change (RFC) to the change manager. The RFC will then be assessed by the change manager or the CAB, depending on the required level of authority for approval.

A special procedure is called upon for assessing emergency changes, for example if the resolution of a major incident requires the implementation of a non-standard change on an urgent basis.

In this context, change models are an important tool for reducing the workload of the change manager and the CAB. Change models are used to define "standard changes" - types of well-known, low-risk changes which may be implemented without the involvement of the formal change assessment process.

 

Compatibility: The YaSM change management process is aligned with ISO 20000, the international standard for service management (see ISO/IEC 20000-1:2018, sections 8.1 and 8.5), and it corresponds to the practice of 'ITIL 4 change enablement'.

Sub-processes

YaSM change management has the following sub-processes:

SP5.1: Support the assessment of changes

Process objective: To set up and maintain the tools for an effective and efficient management of changes.

SP5.2: Log and review RFCs

Process objective: To filter out requests for change (RFCs) which do not contain all information required for assessment or which are deemed impractical.

SP5.3: Assess emergency changes

Process objective: To assess and authorize emergency changes as quickly as possible. This process is invoked if normal change assessment procedures cannot be applied, for example because an emergency requires immediate action.

SP5.4: Assess changes (change manager)

Process objective: To determine the required level of authorization for the assessment of a proposed change. Significant changes are passed on to the CAB for assessment, while minor changes are immediately assessed and authorized by the change manager.

SP5.5: Assess changes (CAB)

Process objective: To assess and authorize a proposed change through the change advisory board (CAB). If required, higher levels of authority (e.g. the management board) are involved in the authorization process.

SP5.6: Monitor open changes

Process objective: To constantly monitor outstanding changes with regards to their implementation status, and to take corrective action as appropriate.

SP5.7: Review and close changes

Process objective: To assess the course of the change implementation and the achieved results, in order to verify that a complete history of activities is present for future reference, and to make sure that any mistakes are analyzed and lessons learned.

Process outputs

This section lists the documents and records produced by 'change management'. YaSM data objects [*] are marked with an asterisk, while other objects are displayed in gray.

CAB meeting minutes

The CAB meeting minutes document the topics discussed in a change advisory board (CAB) meeting and any decisions taken. A draft of this document can be circulated in preparation of the CAB meeting to inform the CAB members of agenda items to be dealt with. [*]

Change assessment report

The results of a change assessment are documented in a change assessment report. Every non-standard change requires formal assessment before being authorized. Particular changes may require more extensive assessments than others, so the contents of the assessment report will depend on the nature and scope of the proposed change. [*]

Change authorization notice

Information related to the authorization status of a change. This information is sent to the initiator of a change to communicate that a change has been authorized or rejected. In case a change has been rejected, the notice may include recommendations on how the change must be modified before it can be authorized.

Change model

Change models describe procedures for the handling of recurring changes. While change models can be created for changes of any scale, they are often used to define standard changes (low-risk, pre-authorized changes like installing additional hardware on a client PC). Change models are an important tool to reduce the workload of the change manager and the CAB. [*]

Change record

A change record contains all details of a change, documenting the lifecycle of a single change. In its initial state, a change record describes a request for change (RFC) which is to be assessed and authorized prior to implementing the change. Further information is added as the change progresses through its lifecycle. [*]

Change schedule

The change schedule lists all proposed and authorized changes, including their planned and actual implementation dates. It is sometimes called a forward schedule of change, even though it also contains information about changes that have already been implemented. [*]

Post-implementation review report

The results of a post-implementation review are documented in a post-implementation review report. Post-implementation reviews (PIR) take place after a change has been implemented. Their aim is to determine if the change was successful and to identify improvement opportunities for future changes. [*]

Suggested process modification

A suggestion for modifying one or several service management processes. Suggestions for process modifications or improvements may originate from anywhere within the organization.

 

---

Notes:

[*] "YaSM data objects" are those documents or records for which the YaSM model provides detailed recommendations: Every YaSM object has an associated checklist (see example) describing its typical contents, and an associated lifecycle diagram depicting how the status of the object changes as it is created, updated, read and archived by various YaSM processes (see example).

"Other objects" are mostly informal data or information where YaSM has less strong views about their contents. There are no associated lifecycle diagrams or checklists.

Process metrics

Process metrics are used, for example, to assess if the service management processes are running according to expectations.

For suggestions of suitable metrics, please refer to the list of metrics for YaSM's change assessment process.

Roles and responsibilities

Process owner: Change manager

• The Change manager controls all changes across their lifecycle. His primary objective is to enable beneficial changes to be made, with minimum disruption to services. For important changes, the change manager will refer the authorization of changes to the change advisory board (CAB).

 

Responsibility matrix: "SP5: Assess and coordinate changes"

YaSM role / sub-process		CAB	Change mgr.	Change owner	Config. mgr.	ECAB
SP5.1	Support the assessment of changes	R	AR	-	-	-
SP5.2	Log and review RFCs	-	AR	R	-	-
SP5.3	Assess emergency changes	-	AR	-	-	R
SP5.4	Assess changes (change manager)	-	AR	-	R	-
SP5.5	Assess changes (CAB)	R	AR	-	R	-
SP5.6	Monitor open changes	-	AR	-	-	-
SP5.7	Review and close changes	R	AR	R	-	-

 

Notes

Is based on: The Change assessment process from the YaSM Process Map.

By:  Stefan Kempter   and  Andrea Kempter , IT Process Maps.

 

Process description  › Sub-processes  › Process outputs  › Metrics  › Roles