"Yerli ve yabancı pazar yerlerine entegrasyonlarımızı inceleyin. "

Change Management Policy

1. Document Purpose

This document outlines the change management policy expected to be adhered to by all employees of Hamurlabs.

2. Change Management Policy Summary

The primary objective of Change Management (CM) is to enable changes to be made, with minimal or no disruption to the services we provide to our customers. Change Management will work in conjunction with other Hamurlabs policies related to ITIL and IT Service Management (ITSM). The goals of the Hamurlabs Change Management Policy include establishing a standard process for requesting, planning, communicating, approving, implementing and reporting changes to our Services. The owner of this policy is the Hamurlabs Chief Operating Officer.

3. Key Change Management Policy Steps

4. Roles

Roles Description
Change Requestor Anyone who wants to raise a request for change (RFC)
Change Owner Person who ensures the assessment, prioritization, scheduling, communication, and delivery of the change
Change Implementer Person who creates, builds, tests, and deploys the change
Change Management Process Manager Person who administers the change process, ensuring all necessary process steps are completed and improvements are raised, when necessary
Change Approver The person/group who approves the change(s)
CAB (Change Advisory Board) / ECAB (Emergency Change Advisory Board) The group/body who exists to support the authorization of change and to assist Change Management in the assessment, prioritization, and scheduling of change, resolving priority conflicts.

5. Change Types

Change Type Definition Technical Approval prior to CAB CAB Submission Deadline
Standard A routine change that is low risk, relatively common, and follows a pre-defined procedure. Customer approval is still required.
For a Normal change to be upgraded to a standard change, it must have been completed successfully three times as a normal change and the procedure documented. The creation of the standard template requires approval by the change manager.
No No
Normal A change to an existing service, system, application, or infrastructure component with potential impact which may require CAB approval before being implemented. Yes 3 hours before CAB for high risk changes only
Emergency A change that must be implemented as soon as possible, for example, to resolve a major Incident, implement a security patch or to prevent an imminent failure. Yes Emergency CAB required

6. Change Risks and Impact

Change Risks

When assessing a change, a risk assessment is undertaken using the following criteria:

High:

  • Previous change has been made and was not successful
  • Complex implementation or back-out plans
  • Novel technology, not previously implemented

Medium:

  • Previous similar changes have occasionally been problematic
  • Some complexity to implementation or back-out plans
  • Standard technology utilized in a non-standard application

Low:

  • Previous similar changes have always been successful
  • Simple implementation or back-out plans
  • Standard technology used in a BAU context

Customer Impact Analysis

When assessing a change, an impact assessment is undertaken using the following criteria:

High:

  • The proposed change poses significant impact to the customer(s) or internal systems in the form of loss of service or serious performance degradation for an extended period
  • Multiple customers or internal departments suffer loss or degraded service during the change window

Medium:

  • The proposed change poses an impact to the customer(s) or internal systems in the form of reduced resiliency, redundancy or capacity
  • A single customer or internal department suffers loss or degraded service during the change window

Low:

  • The proposed change has no impact to the customer(s) or internal systems

7. Change Approval

For each change type, the following approval matrix needs to be adhered to:

Change Type Technical Approval Customer CAB / ECAB
Standard No Yes No
Normal Yes Yes Risk related
Emergency Yes Yes Yes

Technical Approval

Technical approval must be given by a higher skilled engineer or peer (of the technology/technologies related to the change) of the engineer implementing the change. If the engineer planning and implementing the change has no reviewer of an equivalent or higher skillset, then the change must be set as a high risk and assessed by the CAB / ECAB.

Customer Approval

Individual customer approval (for changes related to one customer only) must only be accepted from an authorized customer representative.

CAB / ECAB Approval

All Emergency changes are to be reviewed by the CAB / ECAB, where they will be approved or rejected. This is in addition to technical and customer approval.

Emergency

A change in response to a major incident where the remedy requires immediate action and will be approved by the Major Incident Manager with evidence of retrospective approval from the customer being requested as soon as reasonably practicable.

8. Implementation and Testing

Change Implementation

All changes should be carried out as described in the RFC and within the designated planned times. If a variation is identified during the change, then this must be presented to either a member of the Change Management team or the Duty Manager to approve the variation. This variation must then be documented in the change notes. If the variation is not approved, this will result in the change being backed out. This change will then need to be re-planned and re-raised.

Testing and Validation

Following the implementation of the change, tests in line with the testing plan set out in the change must be carried out to ensure that the desired result has been verified. If a change has not met the acceptance criteria, then the back-out plan must be invoked, as detailed in the RFC.

Change Completion

Once the change has been tested and validated, the change status is changed to completed.

Post Implementation Review (PIR)

A change review should be carried out to confirm that the change has met its objectives, that the change initiator and stakeholders are happy with the objectives, and that there have been no unexpected side effects (e.g., no P1 incidents after implementation). Spot checking of changes rather than large scale PIRs is acceptable for successful changes, however, a PIR is mandated for changes that have been rolled back, led to unexpected service impact, or changes where there was a variation during implementation.

Change Closure

Once the change owner has satisfied themselves that all stages of the change life cycle have been completed, the change can be closed.

9. Customer Notification

For planned changes which may cause outage or serious performance degradation for multiple customers, notifications must be issued at least 14 days in advance. In emergency situations, the 14-day notice period may be waived.

10. Expected Change Inputs and Outputs

Inputs

  • Request of the change recorded
  • Change window
  • Impact duration
  • Resourcing
  • Acceptance criteria
  • Testing plan
  • Back out plan
  • Impact assessment
  • Risk assessment
  • Services on system monitoring
  • Method statement for high risk or high impact changes
  • Configuration items identified

Outputs

  • Technical approval recorded prior to CAB
  • Customer approval recorded
  • CAB approval
  • Customer confirmation of successful implementation (if available)
  • CMDB updated
  • Documentation updated
  • Reporting
    • Successful changes
    • Unsuccessful changes
    • Reporting by change type
    • Trend analysis
    • Changes promoted from Normal to Standard
  • Internal forward schedule of change
  • Customer forward schedule of change
  • Customer notifications