OK, then, so is it a data quality rule or a business rule? Perhaps we can look at this from the impact perspective. Table 2 characterizes the impact.
Table 2: Impact Matrix
If the rule is triggered as a result of a data error, that is certainly not good, but catching the error and fixing the process will prevent any further issues. If the problem is a business problem, that it worse, requiring a business analyst to take some action. The worst scenario is when there is a data problem that actually masks the business problem, in which the process of finding and fixing the data error does not alleviate the business issue.
Next, let’s consider the analysis effort, as is shown in Table 3.
Table 3: Effort Matrix
If it is solely a data error, then the expended effort is solely a technical assessment to find the source of the error and then fix it. If it is determined that it is not a data error, then it might require more effort to figure out where the business problem is, and then change the process. When it is both a data issue and a business issue, the data problem will be evaluated and fixed, but the business problem remains, requiring the additional review to find the process failure as well. The sequence of events for each of the scenarios is shown in Table 4.
Table 4: Sequence Matrix
Reviewing this last table shows an interesting phenomenon: In any of the three cases in which there is any issue, the first action taken is to look for a data problem,
even when there is not a problem with the data! Triggering the rule always means data quality root cause analysis, leading one to suggest that the primary intent of the rule is to flag a data issue and that the rule exists secondarily as a business policy compliance rule. Or, perhaps to answer the question more succinctly, the rule is a data quality rule unless no data error exists, in which case it reverts to being both a data quality rule
and a business rule.
There are certainly more things to consider. We could adjust this analysis by considering additional variables associated with the four scenarios, such as frequency of occurrence, probability of occurrence, or whether there is conditional probability (such as whether the probability of the incidence of a business problem is increased when a data problem exists – hey, it could happen!).
Special Alert: Business problems are directly related to missed data quality expectations. Flawed information production processes introduce risks preventing the successful achievement of critical business objectives. However, these flaws are mitigated through data quality management and control: controlling the quality of the information production process from beginning to end to ensure that any imperfections are identified early, prioritized, and remediated before material impacts can be incurred. My new book,
The Practitioner's Guide to Data Quality Improvement, shares the fundamentals for understanding the impacts of poor data quality, and guides practitioners and managers alike in socializing, gaining sponsorship for, planning, and establishing a data quality program. For more information, visit the book website at
http://dataqualitybook.com for more information and special tips and tricks from me!
Comments
Want to post a comment? Login or become a member today!
Be the first to comment!