Data Fix Changes

In order to satisfy audit requirements for data integrity it is necessary to track all changes to data. The primary method to manage all data changes is through the programmatic interface to the systems of record – Novus, ReloAccess, etc.. There are times when this is not possible and in those instances the Change Management process needs to capture and approve the add/delete/modify changes to data.

There are two main types of changes made to data outside the systems of record.

• Incidents, an unplanned incident where an existing application function is broken and may have incorrect or corrupted data
• Administrative, these could be bulk data entry where a programmatic interface is missing

Incidents – Break/Fix

Incidents need to be reported to the Service Desk and the severity of the Incident determines the SLA for resolution. Multiple teams are responsible for troubleshooting the incident to find a resolution, primarily Infrastructure and Operations teams – Application Support, Database Administrators and Systems Engineering. If it is determined that the Incident has caused a problem in the database that cannot be fixed by the application process the I&O teams, sometimes in consultation with Development, will prepare a data fix change as part of the resolution. This break/fix change is managed by the Change Management process.

If it is determined that the incident was caused by a bug in the system of record then a Bug Report will also be submitted to the Development teams for priority resolution.

Administrative

There are a number of other reasons for a data change (add/modify/delete) to be requested that are not break/fix related.

• The application function is missing either because the request is new or because the function was not determined necessary during the original development
• The application function exists but is not designed for bulk changes causing excessive work by business teams or risking missing a deadline

Each data change needs to be evaluated for its frequency and impact, as well as the availability of workarounds, to determine if development work is warranted to build the application interface. Manual effort for a workaround, by any IT team, needs to be agreed by the associated IT Management.

A temporary workaround will need to be submitted by the original Requestor(Business or Development) as a Data Fix in ChangeGear. The Data Fix needs to reference the script and be implemented by the DBA team. All RFCs require approval.