NOTE- This template is part of the paid Data Quality Package- the most comprehensive online data quality management tool-Kit. This page provides a sample view of the usage of this template. For Buying this template and the entire Data Quality Package, please Click Here

Usage Guide

Purpose of Data Monitoring Checklist-

Data Monitoring checklist is a conscience keeper at various stages of Data Monitoring. Data Monitoring Checklist is not a formal document, requiring approvals or sign-off. Data Monitoring needs to be well-balanced in terms of scope, as it can place some level of processing load on the systems and also placed the demand for analyzing these reports.

When is Data Monitoring Checklist used?-

Data Monitoring checklist is used for planning, specifications, design, test and results management phases. In other words, it is used through out the data monitoring lifecycle.

Who uses Data Monitoring Checklist?

This checklist is used by the IT specialist and business analyst linked with Data Monitoring. Occasionally it may also be referred by the Data Custodian and Data Steward.

Which are the linked work-tools?

• Data Monitoring Request Form- This form is the initiator of the Data Monitoring Request..

Help Guide

Data Monitoring Plan and Specifications

• Data Entities, Attributes and Tables have been identified: One needs to ensure that the target data in terms of its location and range is identified. One cannot monitor each and every aspect of your IT systems. Therefore, one needs to ensure that we have listed out the targets. Secondly, there is also an element of feasibility.

• Data Monitoring benefits and reasons are identified: The business-case for data monitoring needs to be specified. Every DM can place a processing load on the systems. However, at the same time, business case need not be given for every DM. If DM is not of significant nuisance in terms of systems load and not much effort is needed to design and configure the data monitoring scripts + parameters, one may skip the business case. Many a times, the data monitoring is to do a root cause analysis of a production issue. Business case may not be needed in that scenario as well.

• The Level of Monitoring has been identified: One can do Data Monitoring at various levels. It can range from summary level (for example matching the trial balance data) to detailed level (The sales done by a sales agent, as stored in sales compensation system should be in synch with the sales figure in core ERP system)

• The channel and method for publishing and distribution of Data Monitoring results has been identified: Data Monitoring reports can be in various forms. For example, CIO could get just a flash, in case of an exception, whereas the IT specialist linked to the DM could get a 50 page report. Therefore, one needs to define on who, when and how will get what kind of report. Report can be detailed exception report, summary exception report or detailed data monitoring log.

• Roles and responsibilities to view and analyze the results has been identified: Next question is on who will do what, once the DM report is received. Every Data Monitoring report can have sections, each of which needs to be reviewed by different people in stand-alone or collaborative method.

• The actions related to the exceptions have been identified: One needs to firm-up on how the exceptions thrown-up by the DM report will be handled. One also needs to define on what the exceptions are, and what their criticality is. For example if the Location data of the customer is not in synch, it may wait for some time, but if the exception is around the account balance of the customer, it is a high criticality item. The actions related to the exceptions can be:
  • Escalation
  • Assignment of criticality and priority
  • Root cause analysis
  • More detailed data monitoring
  • Suspension of transactions, before the issue is resolved.
  • Initiate Data Correction etc...

• Data Monitoring hierarchy has been identified: This is essentially the level at which you want to do data monitoring. Hierarchy essentially means the drill down you would do, if an exception is found. For example, your DM scripts could define the hierarchy as:
  • Trial Balance
  • Account Group Level (Account Payable)
  • Master Account level (Vendor Account Payable)
  • Expanded chart of account level (Vendor Account payable for a location)
Data Monitoring Frequency has been defined: Data Monitoring frequency could be starting from real-time to monthly to ad-hoc.

• Data Monitoring time-span is identified: The next question is on for how long a given set of data monitoring needs to be done. There are some DM routines, which are done business as usual. For example monitoring related to GL balances, Customer balances etc... is required and sometime mandated by the internal control and audit function.

• The system load due to data monitoring has been estimated and signed-off: Data Monitoring places a processing load on the production systems. Therefore one needs to be conscious of that as one defines the scope.

• Stakeholders have signed-off on Data-Monitoring plan: Finally, the stakeholders should be signing off on the data monitoring plan.

Data Monitoring Scripts and Configuration Development and Testing

When you do data monitoring, you may create scripts, which run on your databases or you may configure a data monitoring tool (like BDQ Monitor) or Both.

• Data Monitoring scripts or configuration of data monitoring tool is done: Self Explanatory

• Data Monitoring scripts or configuration testing in the test environment is done: One needs to test the DM scripts in the development environment on the sample data, and in a sanitized test environment on sample data or on copy of production data depending upon the design.

• Data consistency and exchange online vs. end of day batches has been accounted for: As you create the scripts one needs to be careful that we are aware on when do we need to do

• Data Monitoring dashboard is created:

• Time span for retention of Data Monitoring results is specified:

Data Monitoring Results management

Apart from the areas, where the DM is done to manage a key production issue or managing critical financial data, DM results management may not find high priority. This checklist acts as a conscious keeper for ensuring that DM results are given due priority.

• Data Monitoring results are published as per plan: This is to check on if the DM results are getting published and broadcasted as per plan. Sometimes, due to other priorities, the DM results may be generated but they are not sent.
• Data Monitoring results analysis is being done and reported: This is to check, if people are actually looking at the results and analyzing them. If not, you may like to bring it to stakeholders’ attention. The outcome may be to either do it or stop the DM.
• Data Monitoring results issues are being escalated as per the agreed plan: After the analysis is done, the expectation is that the analysis is responded to. You may also be escalating the DM observations to higher level, but it may not be able to find the right priority with the audience. Therefore, one needs to bring it to the attention of the stakeholders.
• Data Monitoring results are cross linked to Data Quality Gaps for tracking: As you complete the data monitoring and Gaps are identified, these Gaps should be able to find way into the overall list of data quality gaps. We assume here that there is a central tracking around the gaps

 FAQs

What happens when one needs to do data monitoring across wide-set of systems and databases? It becomes a challenge to get everyone involved.

One may need to involve wide-set of stakeholders. The best person to drive the DM is CIO, as CIO has the ownership of the enterprise wide IT. Data Monitoring is not changing the data in these systems, but only reading it. Therefore the business decision is needed mainly from the business owner, who is getting impacted due to data quality issues. You need to involved wider set of stakeholders if the DM will slow down their systems etc.

TIPs

TIP- One does not need to get through the entire cycle of DM for every DM activity that you do. Many a times, IT runs its own DM to ensure the data integrity, without involving business. Extensive Data Monitoring is also needed post launch of a new system or release. DM also needs to be invoked as one goes through the root-cause analysis or simulation of a production issue. One needs to be careful on being optimal on the management load for doing DM.

TIP- Some times it is possible that you may not be able to holistically test your data monitoring due to lack of availability of test environments. For example, if your data monitoring required to be done across three systems, all of them may not be available in test-environment. Other reason you may not be able to find a good test environment is because, the data in the test environment may not be representing real-life data. In that scenario one needs to take a conscious call, on how much you want to test, and get it agreed with the stakeholders.

TIP- One easy and less intrusive way to do data monitoring is to create a production replica, where you can replicate the production data, and you can do offline monitoring. This is done when you do not need real-time view, but need to do some extensive monitoring.