– the individual or organizational group that requires the change. For example, this may be a business unit that requires additional facilities or problem management staff instigating an error resolution.
Is a major change required?
For a major change with significant
organizational and/or financial implications, a change proposal may be required. More information about change proposals can be found in section 4.2.4.6.
70
| Service transition processesTable 4.4 shows an example of the information recorded for a change; the level of detail depends on the size and impact of the change. Some information is recorded when the document is initiated and some information may be updated as the change document progresses through its lifecycle. Some information is recorded directly on the request for change form, and details of the change and actions may be recorded in other documents and referenced from the RFC, e.g. the business case or impact assessment report.
The change record holds the full history of the change, incorporating information from the RFC and subsequently recording agreed parameters such as priority and authorization, implementation and review information. There may be many different types of change records used to record different types of change. The documentation should be defined during the process design and planning stage.
Different types of change document will have different sets of attributes to be updated through the lifecycle. This may depend on various factors
Change proposal (optional)
Review RFC Record RFC Create RFC
Assess and evaluate change
Authorize change build and test
Coordinate change build and test*
Authorize change deployment
Work flows Change
management Change management Change management Change initiator Role
Change management Change authority
Change authority
Ready for decision
Authorized
Created
Update information in CMS
Work flows Work flows
Coordinate change deployment*
Review and close change record Change
management
Change management, change authority, change initiator
Scheduled
Implemented
Closed
Ready for evaluation Requested
*Activities to plan, create and deploy releases are part of the release and deployment management process
Activities assigned to the role ‘change management’
may be carried out by a change practitioner, a change authority or the change management process owner, depending on organizational design
Rejected
Rejected
Figure 4.2 Example of a process flow for a normal change
Service transition processes |
71
such as the change model and change category, but it is recommended that the attributes are standardized wherever possible to aid reporting.
Some systems use work orders to progress the change, as this enables complete traceability of the change. For example, work orders may be issued to individuals or teams to do an impact assessment
or to complete work required for a change that is scheduled for a specific time or where the work is to be done quickly.
As a change proceeds through its lifecycle, the change document, related records (such as work orders) and related configuration items are updated in the CMS, so that there is visibility of its status and compliance to the process. Estimates and actual resources, costs and outcome (success or failure) are recorded to enable management reporting.
Change logging
The procedures for logging and documenting RFCs should be decided. RFCs could be submitted on paper forms, through email or using a web-based interface, for example. Where a computer-based support tool is used, it is possible that the tool might restrict the format.
All RFCs received should be logged and allocated an identification number (in chronological sequence). Where change requests are submitted in response to a trigger such as a resolution to a problem record (PR), it is important that the
Generic change request (from
a template)
Create and review RFC
Assess and evaluate RFC
Authorize and schedule change
Coordinate change implementation*
Review and close change record
Work orders Initiator
Role
Change management
Change authority
Change management
Requested
Ready for decision
Scheduled
Implemented
Closed
Update change and configuration information in CMS
Standard deployment request (where the deployment process is tried and tested)
*Includes build and test the change
Figure 4.3 Example of a process flow for standard deployment request
Create RFC
Implement change
Review and close change record Role
Initiator
Change management
Requested
Implemented
Closed Update change and configuration information in CMS
Figure 4.4 Example of a process flow for a standard operational change request
72
| Service transition processesTable 4.4 Example of contents of change documentation
Attribute on the change record RFC/change
record
Change proposal (if appropriate)
Related assets/CIs
Unique number ü
Trigger (e.g. to purchase order, problem report number, error records, business need, legislation)
ü
Description Detailed description Description at a
business level Identity of item(s) to be changed – description of the
desired change
Detailed description High-level description Service (for enhancement) or CI with errors (corrective changes) Reason for change, e.g. business case Full justification,
except if a change proposal exists
Full business case
Effect of not implementing the change (business, technical, financial etc.)
ü Full business case
Configuration items and baseline versions to be changed
ü Affected baseline/
release
Details of CIs in baseline/release Contact and details of person proposing the change ü ü
Date and time that the change was proposed ü
Change category, e.g. minor, significant, major Proposed category Used for major changes only
Predicted timeframe, resources, costs and quality of service
Full Full business case and summary of expected implementation dates
Change priority Proposed priority
Risk assessment and risk management plan Full High-level risk assessment for the overall proposal
Back-out or remediation plan Full High-level plan for the
overall proposal Impact assessment and evaluation – resources and
capacity, cost, benefits
Provisional Full business case ü
Would the change require consequential amendment of IT service continuity management (ITSCM) plan, capacity plan, security plan, test plan?
ü ü Plans affected
Change decision body ü ü
Decision and recommendations accompanying the decision
ü ü
Authorization signature (could be electronic) ü ü
Authorization date and time ü ü
Target baseline or release to incorporate change into ü
Template change plan(s) to be used ü
Scheduled implementation time (change window, release window or date and time)
ü Summary of expected
implementation dates Location/reference to release/implementation plan ü
Details of change implementer ü
Service transition processes |
73
reference number of the triggering document is retained to provide traceability.
It is recommended that the logging of RFCs is done by means of an integrated service management tool, capable of storing data on all assets and CIs and also, importantly, the relationships between them. This will greatly assist when assessing the likely impact of a change to one component of the system on all other components. All actions should be recorded, as they are carried out, within the change management log. If this is not possible for any reason, then they should be manually recorded for inclusion at the next possible opportunity.
Procedures will specify the levels of access and who has access to the logging system. While any authorized personnel may create a change, or add reports of progress to it (though the support tool should keep change management aware of such actions) only change management staff will have permission to close a change.