2012-02-01
As was alluded to in the introduction, we all know where to go when our computer breaks or when our overtime isn’t paid. But what happens when we have questions about our data? Open up the phone book and I expect most organisations don’t have a data contact. So why do we need one? Doesn’t IT deal with data?
The case for Data Governance is actually easy to make. Like buildings and people, data is an important business asset. It should therefore be owned and managed by the business. Because of the constraints of technology however, it falls to IT to manage it on behalf of the business. They are not the owners however, nor are they the users. Redressing the balance between IT and the business is important because users need to be sure of what to do when things go wrong. There needs to be clear lines of communication, clearly laid out processes, but above all a clear consensus between interested parties. IT does have an important part to play, but it is only a part.
Whilst people see Data Governance in several different ways, for me the simple explanation is that it encompasses the ways and means of managing data, such that ownership is defined, users know who to contact with requests or issues, and that changes and metrics can be implemented in a controlled way. But as we will see, whilst concepts may be easy, difficulties in implementation arise because changes in culture are required. Culture is the single most difficult change to make because it underlies everything in the organisation.
Where there is poor management of data, one could imagine several nightmare scenarios leading to chaos, and impending disaster. The following three examples demonstrate where Data Governance could have either prevented or helped to resolve the issues quickly.
Duplicated vendors
Let’s take a fictional Retail department where the CRM system is fragmented across several databases. Different accounts are managed by different people in different applications. You are not surprised when you are informed that several accounts have become muddled, such that identical customers now have a presence on the various applications. And worse, in one application you’ve been informed that the same supplier has been entered twice, so that there are now three accounts. As a sales manager you are at a loss to make sense of this, or how to resolve the issue. Having been in touch with all the clerks who were responsible for entering the data, they all claim to have entered it legitimately although they don’t know who made the original request. Unsure on how to proceed, you begin the laborious process of identifying account owners with a view to finding a consensus.
If Data Governance principles had been in force, then CRM databases would have been managed from the outset. Firstly, the question of whether various databases are needed would have been addressed. And consequently, each time a new CRM database is proposed the question would be considered by related parties to ensure that overlaps are prevented. If it was decided that several systems were needed then data and data storage could have been harmonised – i.e. the types of data (name, address, postcode), the methods of storage (character, number, date), and properly validated (dates, postcodes, VAT numbers etc). Additional checks and validations could have been adopted to ensure that, duplicate accounts are identified, that information is complete, accurate and up to date. For example, all address data is validated against PAF, or email address formats are consistent, and any similarities between accounts are highlighted for investigation. Furthermore, Data Governance would dif
Email Marketing Campaign
In a related incident, the marketing people ran an email campaign. The results indicated that more than 10% of email addresses were duplicated. What’s more, at least 60% of emails were bounced, meaning that they were wrong, or so old that the contacts no longer existed. Questions were raised about what could be done to improve this situation for future campaigns. In reality, the market group actually generated a monthly prize for the most improved data, and teams competed.
If Data Governance principles had been in force, then the issue arising with the email addresses should have been directed to the data owner who would have worked with his counterparts to issue guidance on keeping records up to date. Metrics on the age of records could have identified old accounts which needed updating, and correspondingly metrics could also have identified duplicate accounts. Of course, a prize always goes a long way toward influencing behaviour.
Slow Production Systems
Complaints about production systems being unbearably slow lead to an IT investigation. Speed issues were traced to a high incidence of ODBC links into the production applications. It appears that a number of external applications are downloading data for unknown purposes. IT are about to close down those ODBC links but you have a sneaking suspicion that this may cause more issues than it fixes. You ask IT to hold off on closing the read only access whilst you investigate.
If Data Governance principles had been in force the applications using data downstream would have been managed. Issues can be resolved quickly by talking to the people who are using data extracts, as list of users exist. Ideally, data should not be taken from production system but pooled into warehouse resources that can be utilised by the user community.
So we’ve identified what Data Governance might have done, but are we any the wiser as to what it is? The Data Governance Institute provides universal goals which should inform all successful implementations. I hope these are helpful in helping you to think about what Governance is:
Over the next few weeks, we will be making sense of Data Governance. What it is, why it is, and how it can be used to best effect.
I hope this introduction has been of interest.
