Do you do BI? You’re on trial every day
I was reading the news today about the Kercher murder trial and the acquittal of Amanda Knox. The reason for the acquittal was the DNA evidence that was collected, and was the foundation of the prosecution in the original trial, could not be relied upon. Over years the forensic community have defined how data should be collected and processed. In this case it doesn’t matter if the DNA evidence was correct or not, the way means by which it was collected and processed could not be relied upon and thus the information is discarded.
How does this relate to BI?
Trust
You are producing data which is going to be the foundation of decisions in your business. If your data can not be relied upon then the business wont trust that data and so the data becomes useless. I’ve seen far too many BI systems where there is no trust of the data. This results in the data being questioned at the slightest hiccup of the data. Rather than looking at what caused the hiccup in the business, the business turn back on the data and say the data is wrong. This means all the time that has been spent building the BI system has been for nothing.
What does this mean for your projects?
Some of the aspects of BI projects that I feel undermine any trust in data are,
1. Not delivering data on time
If data is not delivered on time then questions are raised as to what is wrong with the system. If you can’t deliver data on time then the key thing to do is to inform the business of the situation. Its always better to be upfront about these problems than try and hide the fact. Whats more the problems might be due to a source system, if thats the case then your BI system shouldn’t take the hit for a problem in a source system. Why not have a dashboard informing the users of the status of your BI system and its processing.
2. Changing results
Once a result is delivered to the business it shouldn’t change. Ok its a little more complex than that but in principle you shouldn’t changed something thats already been calculated. If results have to change then you and your users need to be aware of what and why. Do you have a latency problem in collecting information and so it takes 7 days to get to a final figure. If so your daily figures may change for 7 days, but after that they shouldn’t. You should have exception reporting so that if you get late facts after the 7 days you can manage the system by informing the users that a problem with another system and not the BI system, will mean the figures will change.
3. Not informing the business of a problem
If someone makes a decision based on the information in your BI system and 2 days later they are told the system hasn’t been working properly for 2 days they aren’t going to be happy. Its going to make them think twice about using your system as the foundation of their decision in the future. If you had informed them at the time then they would likely understand and whilst the system has had a problem it won’t undermine the trust in the system.
4. Providing two different values at the same time
Many BI systems have evolved over time, usually in a Lego fashion. A bit stuck on hear, a bit stuck on there. This almost always leads to information being consumed by the business from systems with different latencies and potentially different calculations. This is the worst case as the business won’t know which figure to look at and so won’t trust any of them. The single version of the truth is a core concept that I always try to adhere to. If you have to have multiple versions then the end users have to be aware of what the differences are so they can trust the data and your systems.
Information is King, if you have the information then you can do anything you want. However if its wrong then thats the worst situation to be in.
Make sure you do what you need to to make sure that your business trusts your data and doesn’t have reasons not to trust your data.