CentrexIT — Change Enablement

Mike Hicks Process · 1 min

Publishedv3

Change Enablement KB00011621 CentrexIT Process

SUMMARY

The Change Enablement Process, previously known as change control, change requests, or change management, is the process by which centrexIT will process and implement changes to critical systems, production systems, services, potential user impacting changes, or changes of which the implementation of it has the potential to increase risk, cause downtime, or change documentation, and/or support requirements.

PURPOSE

Section titled “PURPOSE”

The purpose of the Change Enablement Process is to provide general procedures for requesting, reviewing, approving, and tracking changes to centrexIT (cIT) and Customer Production Systems.

SCOPE

Section titled “SCOPE”

All centrexIT employees making changes that may affect more than one user must execute a change request.

REQUIREMENTS and PREREQUISITES

Section titled “REQUIREMENTS and PREREQUISITES”

Access to Halo
Configuration Item or Items (CIs) requiring or effected by the change have been identified and are in Halo
Team Member and or department doing the change has been identified
Financial Impact has been assessed
Impact and Risk associated with the change has been assessed
The full scope of the change including all configuration change steps are identified

DEFINITIONS

Section titled “DEFINITIONS”

Production System – any system that is in-use by a customer and not otherwise designated as a development or non-production system, this can also be known as a Primary Business Application (PBA) or potentially any of a PBA’s components or underlying network requirements. Systems include hardware, software, and process that may include people and business policy. Examples include but are not limited to: Servers, Storage, Networks, Active Directory, Backups, end user services, or any business software application, or any centrexIT primary process.
Change – A modification to a system or systems that would require an update to any controlled system documentation, diagram, procedure, process, or system availability, or cause any production system to be modified in such a way as to present new risk, changes in cost, new potential vulnerabilities, or potential loss of function to any critical network, or application systems (PBA/s) with which a customer or cIT relies on for daily operations. Examples include but are not limited to firewall configuration changes, network configuration changes, Compute and Configuration, or policy changes, service pack updates if not normally applied as part of general pre-approved maintenance of that system, security fixes, and physical configuration changes such as the movement of critical hardware from one location to another, or the addition or removal of critical hardware.
cIT SME – The cIT subject matter expert (SME) is an individual or individuals who must review and approve of a change prior to implementation. This individual is also a member of the CAB.
virtual IT Manager (vITM) – This is the client SME and must approve all changes for client systems alongside the cIT SME. For cIT systems, the vITM role is filled by the Senior IT Manager.
Change Advisory Board (CAB) – The Change Advisory Board is the review body for all Change Controls. The CAB will ensure that the change was completed successfully, that all documentation was updated, that the approved changes are followed, that all risk is accounted for and limited to the fullest extent possible under the circumstances, and that changes have completed an appropriate design review with peers.

Types of Changes

Section titled “Types of Changes”

Normal Changes or Normal Request for Change (NRFC) – This document covers the scope of a normal change including those undertaken during an approved project.
Standard Changes – These are predefined changes and must be completed per the predefined steps and the documentation required by the pre-approved change. At this time, all changes should be treated as Normal Changes, Standard Changes have not been built out in Halo
Emergency Changes – Emergency changes generally follow the same process as a Normal Change however in the event a major system is down and a change must be completed to return that system to full operability, an immediate minimal change may be made prior to approval. All normal change steps must be followed once the system is back online and service is restored and the change request must still be requested following the Normal Change instructions. No changes beyond the minimal needed to restore functionality should be made prior to authorized approval being granted.