Coincidentally, my company is involved with a number of different customers who are reviewing the quality criteria associated with addresses. Each scenario has different motivations for assessing address data quality. One use case focuses on administrative management – ensuring that things that need to happen at a particular location have an accurate and valid address. A different use case considers one aspect of regulatory compliance regarding protection of private information (since mail delivered to the wrong address is a potential exposure of the private information contained within the envelope). Another compliance use case looks at timely delivery of hard copy notifications as part of a legal process, requiring the correct address.
But another interesting coincidence is that there are two aspects to our customers’ desire to “fix” their data problems. One is their perception of the solution, and the other is the reality of the root causes.
More to the point, the way a project is envisioned from the customer’s perspective is driven by an expectation of the solution. An example might be “guidance for designing and implementing a master data management program.” Multiple applications refer to the same data concepts but don’t talk to each other; instituting MDM will make the business processes talk to each other, therefore the project is envisioned as an MDM activity.
Once we start to peel the onion we begin to see things a little bit differently. For example, the business processes are impeded because they do not talk to each other. Implementing MDM might bring the data together into a single location, but it won’t necessarily change the communications between processes. Similarly, other root causes of issues that lead one into drawing conclusions about a potential solution need to be both identified and evaluated before moving forward. As part of that, I have started to look at the issues that originally motivate the presumption of a solution, and, more interestingly, ways to categorize their root causes.