Multiple Data Touch Points

March 17, 2011 by
Filed under: Business Impacts, Data Governance, Data Quality 

Coincidentally, similar issues came up with different clients over the last week or so, focusing on ensuring the quality of elements of a specific data domain. In both environments information flowed from a number of source systems in the organization, usually starting with some customer-facing process, and in other cases, with data feeds coming from external sources. But what was obvious was that as these different systems have come on line, there had been little documentation of how the processes acquired, read, or modified the data. As a result, when an error occurred, it manifested itself in a downstream application, and it took a long time to figure out where the error occurred and how it was related to the negative impact(s).

It was great to hear that their approaches were also very similar: they decided to map out the end to end information flows and identify where in the organization the specific data elements were touched. At the same time, a process was put in place to assess the data quality requirements from the end users to determine what their expectations were. Once they knew the expectations and the locations of the data element touch points, they planned to first take some measures to assess the quality of the data at the different touch points, then institute inspection and “evasive maneuvers” so that when an error occurred at the intake locations, some method could be applied (either automatically or manually) to correct the data at the point of entry.

Here are some ideas to think about: has your organization documented the information flows for your critical data elements? Has anyone solicited the data quality requirements for downstream uses? Do you have a plan for flagging issues early in the process, and do you have alternatives for correcting errors when they occur?

Comments

Tell me what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!