Overall Usage
Purpose and Objectives
This work-tool enables you to maintain a centralized inventory for the state of Data Quality assurance in all 'Key' objects. The reason , we are saying key elements, is that sometimes it is not humanly possible to have inventory of all the input forms and data elements, and all the data entities. From a practical perspective, an organization may select top 500 odd objects with in each business domain.
When to use this Tool?
The usage of this tool is business as usual. It is an inventory maintained at ongoing basis. This inventory gets updated as and when a new object (interface, input form..) is created, or changed.
Who uses this tool?
This work-tool is used by the business analysts and IT specialists, conducting the assessment, to fill-up the results and analysis. It is used by the business owner and the functional Data Steward to review the results and analysis.
Linked Work-tools
- System DQ Assessment Management- The object level DQ assurance inventory is feeds into the system DQ assessment management tool. If such object-level inventory is existing, your time spent in System level DQ assessment (as an initiative, being a part of DQ program initiation phase) will be greatly reduced. In other words, if you are maintain an object level inventory on an ongoing basis, you can cut and paste relevant objects from your inventory into the System DQ assessment management tool.
- Object level DQ assurance tracking for an initiative- The initiative level object level DQ assurance tracking tool has the state of DQ assurance for the objects related to that initiative. As the initiative is over, the content can be shifted to the Object Level DQ assurance inventory.
-----------------------------------------
Help Guide- STATE OF Data Quality Object Inventory
Here are the generic fields in all the sheets.
- Object+Controls list: List of the objects and the controls within that object, which need to assessed. There is one sheet for each of the following objects"
- Data Exchange Interfaces
- Input forms
- Key Data Elements (for domain value and data standards)
- Data Entities
- Business Rules
- Batch-Jobs
- Business Partner Interfaces
- Description: A brief description of the object
- Code & Reference: The code and reference to the object within the systems documentation or within the object level DQ inventory
- Change & Issue history: A high level history of the changes done to the object and past data quality issues.
- DQ Comments: The comments on the robustness of the DQ controls for that object. It will also cover 'why' aspect of the state of DQ.
- Overall Rating: One can provide the 'judgmental' rating on each of control+object combination or an overall rating for the object.
- Impact Statement: Any impact due to low rating of the object. This part will feed into the root-cause for current state of data.
--------------------------------------------------
examples for each of the sheets within object level DQ Assurance inventory
example Interface Quality
- Interface 1: Customer Master interface between field servicing and Order fulfillment System.
- Description: This interface is used to synchronize the customer master data across the Field Servicing system (used to support the field maintenance and support post sales) and the order fulfillment system. This a one way interface to create new customer, whereby the order fulfillment system is the 'system of record' for the customer master.
- Code & Reference: Interface code= INTCS0023, Document Ref- DDFS0324, Page#212
- Change & Issue history: This interface underwent a change (CC#- FDS2345) in its structure as order fulfillment changed its customer master structure. There has been 2 issues with this interface in the past. It has been missing an upload one some occasions (production issue- POD 2345TG
- DQ Comments: The interface has two controls missing- Duplicate file-Check, Duplicate Records check
- Rating on individual controls: Apart from Duplicate File Check and Duplicate records check, the other controls will be rated high.
- Impact Statement: Though there is a lack of duplicate file check and duplicate record check is missing, its not a high impact because:
- The field servicing system, is not changing any data of the uploaded customer file.
- There is DB to DB synch check done post the file upload
-----------------------------------------------------------------
example Domain Value and Data Standard
You will typically not include thousands of data-elements here. You may like to have top 200-300 data elements per system, which will make biggest impact on your data quality.
- Data Element 1: Invoice shipping rate
- Table Name and Field Name: Shipping_rate in the shipping_rate_table in the order fulfillment system.
- Description: This data element is the shipping rate applied based upon the location, product, weight and given a campaign.
- Change & Issue history: NIL
- DQ Comments: This data element has the following controls missing and not applicable:
- This data element can be optional: This means that a record may have a Null value. As per the domain standard, this value should be mandatory, with default as Zero%.
- Impact Statement: Shipping rate being optional has risk of it not being entered, which resulting in NIL shipping will cost for the applicable invoices, leading to a financial loss.
----------------------------------------
example -Input Form
- Input form 1: Shipment Details Entry Screen
- Description: This input form is used to enter the shipping details the shipment, before the goods are shipped.
- Change & Issue history: NIL
- DQ Comments: The field validation the shipping location. There is not domain value check for the PIN-Code vs. City, while the format check exists. Even if the PIN-CODE is valid, it may not be the valid PIN Code for that city
- Impact Statement: We have a risk of wrong pin code to be entered, which could mean shipping issues and delayed delivery.
---------------------------------------------------------------------------------
Data-Model Controls
- Data Entity 1: Customer Professional Details
- Description: This is a sub-entity to the customer-entity. it contains the details of the professional experience of the customer. It has many to one relationship with the customer master.
- Change & Issue history: The entity was expanded to include the Industry experience of the customer.
- DQ Comments: The Insert rules do not check the Industry with the Industry master and function with the function master.
-
- Rating: 6
- Impact Statement: The lack of check is leading to lot of uneven industries and functions.
--------------------------------------------------------------------------------
Business Rules
- Data Entity 1: Invoice-header
- Description: This Data Entity contains the header information for an invoice.
- Change & Issue history: The invoice header was expanded to PO date, over and above the PO number. This was used to help the customer to retrieve the relevant purchase order.
- DQ Comments: There is not consistency rule for shipping date vs. PO date vs. Invoice date. For example, shipping date can be before the purchase date and Invoice date can be before the shipping date. There was a production issue related to Invoice header, whereby the wrong Invoice number was being generated. The problem was fixed by building auto-increment logic.
- Impact Statement: A wrong set of dates, can spoil out reputation, impact our order fulfillment and customer service processes, and place us at a legal exposure.
------------------------------------------------------------------
Batch-Process
- Batch-Process 1: Bank Statement File Generation Process.
- Description: This batch process generates the file for account statements, for bank statement printing system.
- Change & Issue history: This batch process had issues related to mentioning wrong Text in converting the numbers into 'the balance in words'. It was a program logic issue. We also had issues, where the some transactions were missed out in the back statement, whereas the balance was correct.
- DQ Comments: The batch does not have a post completion checks, in terms of having covered all the customers and all transactions. It does not add-up the figures in the bank transaction table and in the statement files generated by this system. The batch should be doing a 3-way check between the customer account master, customer account transaction and account statement file.
- Impact Statement: While there are extensive checks on the correctness of the transaction and master table for the bank accounts, but the lack of control on the batch generating the bank statement files, can significantly impact our reputation.
|
