In contrast to addressing the management and process issues, we might say that the technical issues are actually quite straightforward to address. In my original enumeration from a few posts back, I ordered the data issue categories in the reverse order of the complexity of their solution. Model and information architecture problems are the most challenging, because of the depth to which business applications are inherently dependent on their underlying models. Even simple changes require significant review to make sure that no expected capability is inadvertently broken.
Next are the synchronization and timing issues: often discrepancies exist across different systems and data stores because there are few controls on ensuring timely and coherent communication of updates that need to be shared. In one of our engagements, customer addresses are changed in a number of systems, but rarely are there discrete process steps to publish the change to any other system that is managing customer address. And even if you think that creating a master data repository for customer address will fix the problem, you still need to make sure that the master version is updated in a synchronized way.
Last are the tool configuration and business rules. There should be formal ways of representing the rules (at least you want to believe so ), and once you have addressed the need for standardized processes for solicitation and documentation of business rules, the technical challenge is to verify that the rule was properly transcribed, and in the many cases where the rule needs to be implemented in multiple environments, make sure those are done in a consistent way as well.
Hmm, did you notice that even though I was talking about addressing the technical data management issues, we still came back to policy and process? It just goes to show you that you can’t escape good data management practices as defined within a data governance operating model. Basically, data governance remains the foundation for ensuring data usability.