POLICY PURPOSE

• The main purpose of IT change management policy is to have a formal process for making changes to IT Systems.
• To ensure all changes are authorized, planned, implemented and to ensure minimum disruption to the IT services and business users.
• To record and track all changes in IT Systems.
• To exercise effective change management for services which are critical to the business, especially those which use a complex technical environment.
• To minimize the risk and impact in the IT Systems by standardizing IT change management process.

POLICY STATEMENT

Purpose of Change Request Form (CRF) is to record, track, schedule and implement changes in the IT production environment.

Activities associated with change requests are:

a. Recording change details. b. Assigning change manager responsible for the change. c. Ensuring technical capability. d. Assessing the risk and impact on the business. e. Ensuring appropriate authorization. f. Resolving conflicts (resources, costs) and deciding methods to be used. g. Scheduling the change and notifying relevant affected parties. h. Communicating details of change status. i. Management reporting.

A change in production environment may be initiated in response to many events: to resolve a problem; to improve the efficiency of the current system; to introduce new capabilities; to prevent the occurrence of a problem. Many groups, like IT Service users, Business Managers, Information Security, Audit Department Managers, IT staff in operations, system software, network & communications, and applications sections, can request the changes.

The Change Request Forms is used to capture change details and to seek required approvals. It also serves as control mechanism to ensure that all the documentation is delivered, user acceptance testing is done, and change is scheduled before the change is transported to the production system, as well as the post implementation review.

Categories and types of change:

This process recognises different categories of change and uses a common framework to apply an appropriate level of control to each category.

The following categories of change are recognised:

1. Install/upgrade/decommission of hardware.
2. Install/upgrade/decommission of OS, Patches, Firmware, RDBMS, Software packages.
3. Install/upgrade/decommission of IT Services.
4. Configuration changes of IT Applications, OS, Network, Security framework, Desktop footprint
5. Software movement from testing (development) into production.
6. Emergency changes to production environment, and
7. Any other type of change.

The following types of change risks recognised:

High risk: High risk changes may cause major disruption to applications or infrastructure services and adversely effects all business operations and processes of different department(s)

Medium risk: Medium risk changes may cause moderate disruption to applications or infrastructure services and adversely impact some of the important business operations / processes of a Different department(s).

Low risk: low risk changes may cause a minor disruption to applications or infrastructure services and adversely impact limited or one business operation / process of a different departments.

Scope

Change management is not an optional process, but is a compulsory and routine part of normal functioning, and applies to all areas which affect the production environment, including:

• Applications programs and data (new or revised programs, data fixes)
• Operational support applications (command procedures, backup procedures);
• System software (operating systems, office systems, desktop products, databases);
• Hardware (Servers, Appliances);
• Network hardware (WAN, LAN, Wireless);
• Facility (buildings, power, environmental);
• Security controls.

Responsibilities

• End Users / Change requestor: to request the changes, describe the change, justify, and highlight added value to their operations.
• Head of Department requesting the change: To review the requested change, discuss with requestor the value and provide approval.
• Respective IT Team: To analyse the change requirements on IT resources, and efforts required (licenses, Manpower) as well as the impact on cost, process and risk on IT systems and business operations, document the implementation steps, rollback plan and affected parties. For changes pertaining to HIS/CORE, the HIS/CORE System vendor must also approve the change and provide cost /time estimate. IT Governance Committee and TMO approval must be secured before proceeding with the needed change.
• IT Change Manager (IT Applications / Infrastructure Manager): To review the change, change priority and type, assessment, impact and risk, implementation and rollback plan and provide decision.
• Change Control Board: Is to review and provide decision on critical change requests with high impact, naturally the change board will be comprised from IT Director, IT Change manager, relevant chief of department requesting the change and COO.
• IT Quality Assurance: Relevant IT Team member or Manager to conduct post implementation review and ensure that the change has been implemented successfully with no / minimum impact and with desired outcome.
• IT Director: to review changes and ensure change management process are followed and is adhered to.

Procedure

The process is used to control each change through the following activities:

1. Receive and record.
2. Assess the impact on scope, risk and cost of proposed change.
3. Approve, Reject or Hold.
4. Implementation planning.
5. Pre-implementation steps (testing environment, taking backup, setup configuration)
6. Implement.
7. Verification of change (accept or roll back).
8. Post implementation review
9. Notify all stakeholders of the change.
10. Closure

Change Situations:

Normal changes:

All changes necessitated by routine operational reasons, business process change and technology changes which can be planned and executed are called normal changes and this process applies to all normal changes.

Emergency changes:

In cases where an urgent action is required, a change may be actioned as an Emergency Change. The occurrence of an emergency change must be communicated to all affected areas at the earliest possible moment, and the change request must be completed as soon as possible after the change is made, specifically identifying the change as an emergency. All emergency change requests require approvals and documentation like normal change requests.

Implementation:

The change request is passed to the appropriate person to perform the change. The implementer reviews the change request to ensure that all actions for implementation, verification, and roll back are clearly and correctly defined.

The change is actioned according to the implementation plan. Should it be necessary to amend the implementation plan, the amendments are noted on the change request. In all cases a full record of the actions which take place for implementation is made.

Verification and accept or roll-back:

When the change has been implemented, it should be tested and verified. If the verification is not completed successfully, the change has failed, and the roll back plan should be followed. A full record of the actions that take place for testing, verification, and roll back should be made on the change request, together with the identity of who performed each action.

Post implementation review and close request.

When the approved change action is completed successfully, the implementer notes the status on the change request, notifies the affected areas, and returns the change request to the Change Manager.

The Change Manager confirms the change status and required documentation and files the change request in the change folder.

1. Change Process General Flow:

REFERENCES AND CROSS REFERENCES:

Information Technology Infrastructure Library (ITIL) framework V 3.0

DEFINITIONS AND ABBREVIATIONS:

Change : an interruption to normal operations of an IT system (software/hardware) that have a positive or negative impact on live operations.

Change Request Form (CRF) : is used to capture change details and to seek required approvals. It also serves as control mechanism to ensure that all the documentation is delivered, user acceptance testing is done, and change is scheduled before the change is transported to the production system, as well as the post implementation review.|

Production Environment : is the live IT systems / services that the end users are using to run their departments business operations (IT Applications, Databases, Operating systems, Network, Servers, etc.).

Testing Environment : is a system that is used for development and training and not connected live to end users to be used for their business operations.

Change Manager : Is a logical role for the respective IT manager responsible about the change.

Affected parties : Any end user or department that can be positively or negatively affect by implanting the change.

OS : Operating systems is a system software that runs computers, Servers and other equipment

Patches : is a software programs that are used to improve the operations, security or resolve of an Application, OS, Database, and other IT Services

FortiOS : is the Operating systems of network equipment’s like Switches and Routers.

Database : Database Management Systems is collection of information that is organized so that it can be easily accessed, managed, and updated.

Software packages : Ready/custom made software programs developed to run certain operations like (Microsoft Office) or even and enterprise application used to automate business operations like (ERP)

WAN/LAN : Wide Area Network and Local Area Network.

Apendicies

1. Network Change Request Form
2. Security Change Request Form
3. System Change Request Form
4. Applications Change Request Form