Building Making It Happen
Building Making It Happen
  Sign-in         Register
    
BiPM Practice Tool Listing Page
Data Correction Checklist
The Data Correction Checklist enables a discipline, control and consistency in conducting 'back-end' data corrections. As the back-end data corrections are risky, they have to be well-planned and tested, before executing them in production environment.
 
This page of 'BiPM Practice Tool' is linked to:  Data Quality,


Overall usage Guide

Purpose of this checklist

This checklist is used through the stages of analysis, design, testing and execution of a data correction activity.

Who uses this checklist?

The business analyst and IT specialist involved in the data correction, fill-up this checklist and it is reviewed by the CIO and the business owner.

When is this checklist used?

This checklist is used from the point the data correction request is raised.

Help Guide-

Data Correction Script

As a principle, one should do data correction from the front-end. This ensures that all the controls and checks associated with the data are followed. Sometimes, due to urgency and high volume of data, one has to do the data correction from the back-end, which means that one bypasses the application layer. This generates a risk, which needs to be managed.

  • Data Correction Script will completely fix the target data: One needs to ensure that the data correction script does the complete job. If there are multiple problems with the same data, it should be preferably be done all at once.
  • The referential integrity of the corrected data is accounted for?: If you are inserting or deleting a set of records or changing the value of primary key, the referential integrity needs to be maintained. This means that other tables which are linked to the table being corrected also need to be touched. For example, if you are updating the location_code in location master, the same code should be changed in other master tables (changing location_code in customer_master) and transaction tables (changing the location in the sales transaction record)
  • For correction of the values, has the calculation impact on other data is accounted for?: If you are correcting values from the back-end, one will need to understand that the counter transactions are also taken care of. For example, tax calculation for 10000 transactions is corrected; the GL transactions for the same also need to be corrected.
  • Does the data correction script considers the data which is already committed from regulatory point of view?: if the data which you need to be corrected has already been reported in compliance and regulatory report, it cannot be changed. You will need to put the countervailing transactions in place.
  • Does the Data Correction Script maintains the audit of what was changed?: The data correction script needs to be designed in such a way that it created a temporary table of all the transactions which have undergone a change with before and after image along with the time stamp.
  • Data Correction Script has been reviewed by DBA and IT Design Specialist: This is imply a matter of sign-off an assurance that the script has been reviewed.

Data Correction Script Testing:

One cannot over-emphasize the need to be first time right for running data correction script on the production, through the back-end. The extensive testing can minimize the risk.

  • Data Correction Script Test Plan is created: The test plan will consider sample and full production testing.
  • Data Correction Script is tested in Development Environment: This is part of standard IT processes, whereby first test will happen in the environment, where you have created the script.
  • Data Correction Script has been tested in test environment on sample data: This testing will be in stand-alone and sanitized test environment, which will be the closest simulation to production. The first step in testing in the test environment is to do it on a sample data. One has to consider the sample data to test all the test scenarios for data correction.
  • Data Correction script has been tested in the test environment on copy of production data: The next step is to replicate the target production data (or preferably the whole production data), and test your script. The output of testing is not only to check the data from the back-end but also from the front-end screens and the enterprise reports.
  • Test Results are signed off by IT owners and Business Owner: The stakeholders have to be satisfied with the results.

Data Correction Script Productionization

  • Data Correction Scrip is checked into the version control system: One needs to ensure that the same script, which is tested, is also run on the production system.
  • Has the back-up of production data taken?: This is sometimes needed for audit and also for a back-out plan. Back-out means that we go back to the original production data, if the correction script does not work.
  • Are we clear about the backing out procedure, if the productionization does not works-out?: this is to see that, we know what will we do if the correction script does not work. One of the back-out option is to restore the original production data.
  • Do you know the reporting which you have to re-run and redistribute post data correction?: Once the data is corrected, one may need to re-run enterprise reports as well some other processes (like refresh of data warehouse), to ensure that data correction has cascaded to all points.
  • Have you planned the manual activities, which we need to do post correction: like re-sending the statements or renewal letters to the customers? Data correction is not only an IT activity. Once you have done the correction, you will need to contact the impacted stakeholders. This means that when you do the data correction, the manual tasks, which need to be done, should also be planned.
   Access more details on this page   

Download Attachment

Data Correction Checklist.xls  

Quick Feedback- Was this information helpful ?
 
Back
Featured Pages
Using Synonyms and Views
Single & Stable system for Data Marts
Conformed dimensions for cross-drilling
OLAP what if Analysis

Make 'Executable' Strategy
Maximize Results
Maximize People
Manage Execution

Featured Pages
Data Warehouse Project Initiation Phase
Metadata standards
Data Warehouse Purpose and Objective
Audit dimensions in the Fact table