The point I've heard a few times is, "I'd rather have a wrong number and work out a way to improve (move forward), than spend hours arguing/debating/analyzing what the right number is."
On one occurrence, a client asked me to sit in a mgmt meeting, while I was helping with their business re-org.
They reviewed departmental financial performance reports and a dept head, my client, disagreed with the result of one measure. Swore it couldn't be that low and below target. After a couple minutes of clenched-fists-in-the-air attitude with "I'm going to find out the right answer!", his senior exec boss speaks up briefly with the quote above (or something like it).
I don't know how you feel about this but I'm sure some of you are cringing at the thought of knowing numbers could be wrong in the warehouse and that you were asked not to find the problem. I could just see the perceived value of their BI solution going straight into the crapper.
However, there is something here worth investigating. In the senior executive's eyes, the value of the "historical" performance report, specifically the poorly performing measure, wasn't the accuracy of the number but the identification of poor performance. It was agreed that the number probably wasn't inaccurate enough to make the measure a strong performer.
[I know, red flags are going up but bare with me.]
Could they be sure the measure was a poor performer? No. To confirm this, it would involve the BI group and department managers/staff to verify. I.e. time consuming.
Are they making fact based decisions? Partially. They are moving into the planning stage based on a poorly performing measure.
Is the mgmt team doing what executives do? Absolutely. They are taking the facts as they know them and making a decision (gut-feel perhaps). But they are focused on moving the company forward.
And here falls one dilemma for BI to overcome.
In this example, BI ended at the report or chart or visualization. There was no integration into the management cycle to continue into planning. I'm not talking about the financial genius building a model to show various projections. I mean the outcomes of planning... tasks, deliverables, goals/objectives, etc. BI only comes back into the picture when new reports are needed.
For me, without better integration into the business processes and mgmt cycle, BI will forever by a reporting tool on steroids.
Another dilemma for BI?
The pain to verify numbers. The time/cost to produce new numbers. Anytime you need to involve your ETL developer or cube/report developer to explain how a number was generated costs time and money. It's not their fault, it's the tools they are forced to work with.
BI needs to move more into the "configuration" space. At least needs to move up a level or two in usability to where application building is today. With all the toolboxes, components, and hosted technology available, I feel that "I" could almost write a Web 2.0 app! (okay a very simple one... maybe).
The point being is the technologist's tools need another layer of abstraction/architecture (okay not sure exactly what to call this) to allow quicker time to value.
Caveat: Now don't get me wrong. I think BI has future potential and can provide value. (now here comes the tough love speech) But BI has problems and poor results are seen repeatedly. I want BI to improve so I'm not picking it apart because I have another agenda; I truly want success. Success through learning and change.