Create and record Requests for change

The change is raised by a request from the initiator – 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 from many other sources.

For a major change with significant organizational and/or financial implications, a change proposal may be required, which will contain a full description of the change together with a business and financial justification for the proposed change. The change proposal will include sign-off by appropriate levels of business management.

Table 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. Business Case, impact assessment report.

Attribute on the change record	RFC	Change proposal (if appropriate)	Related assets/CIs
Unique number
Trigger (e.g. to purchase order, problem report number, error record s, business need, legislation)
Description	Summary	Full description
Identity of item(s) to be changed – description of the desired change	Summary	Full description	Service (for enhancement) or CI with errors (corrective changes)
Reason for change, e.g. Business Case	Summary	Full justification
Effect of not implementing the change (business, technical, financial etc.)
Configuration item s and baseline version s 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
Predicted timeframe, resource s, costs and quality of service	Summary/reference	Full
Change priority	Proposed
Risk assessment and risk management plan	Summary/reference	Full
Back-out or remediation plan	Possibly	Full
Impact assessment and evaluation – resources and capacity, cost, benefits	Provisional	Initial impact
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
Target change plan(s) for change to be incorporated into
Scheduled implementation time (change window, release window or date and time)
Location/reference to release/implementation plan
Details of change implementer
Change implementation details (success/fail/ remediation)
Actual implementation date and time
Review date(s)
Review results (including cross-reference to new RFC where necessary)	Summary
Closure	Summary

Table 4.4 Example of contents of change documentation

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 attribute s to be updated through the lifecycle. This may depend on various factors such as the change process model and change category but it is recommended that the attributes are standardized wherever possible to aid reporting.

Some system s 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 an RFC proceeds through its lifecycle, the change document, related records (such as work orders) and related configuration item s are updated in the CMS, so that there is visibility of its status. Estimates and actual resource s, costs and outcome (success or failure) are recorded to enable management reporting.

Дата добавления: 2015-10-29