The primary goal of any BI solution is to provide decision makers with the information they need to make better decisions, leading to higher profits, lower costs and improved service levels. Successful BI solutions enable this by automating the extraction and transformation of data into a shape that facilitates agile reporting and analysis.
When working with organizations looking to build their first BI solution, I've found that building them a prototype is a great way to show them the types of things that are possible with BI solutions. This process assists them in answering the questions used to document the formal business requirements upon which their real BI solution will be built.
It's interesting to observe their reactions during the demonstration of the prototype. For organizations that are used to manually collating figures and producing canned reports, the speed with which a BI solution can slice and dice the numbers often blows them away, which is nice, but it can also have a side effect of alienating the very people who are critical to the success of the project.
It's very easy to build a slick looking prototype and present it under controlled conditions. It's much harder to build a real solution that consumes real data, much of which is unstructured, inconsistent, and, in some cases, plain wrong.
One of the primary reasons BI projects fail is poor data quality, leading to inconsistent results and errors during data loads. Such outcomes chip away at the confidence in the system, and in some cases, precipitates the cancelation of the project itself. I wrote about this in more detail in my blog post titled Top 5 reasons why your Business Intelligence project will fail.
Avoiding data quality issues requires a good working relationship with the custodians of the source data. These people are often the same people that produce the existing reports that the BI system will ultimately replace, and therein lies the paradox; why would they help you to build a system that makes them redundant?
Human beings, rightly or wrongly, are resistant to change, particularly when the change has a perceived impact on their livelihood or professional value. In the context of a new BI solution, data custodians often view the solution as a threat to their value in the organization. They’re used to being in charge of large amounts of data, and making sense of it by producing reports. They feel threatened by a new system which promises to automate large parts of their work and produce much more flexible reports.
Successful BI projects acknowledge this threat/perception early. They engage data custodians and report writers in the early stages, and involve them throughout the solution lifecycle. They make them stakeholders in the solution, and value their organizational knowledge as a crucial ingredient in the overall success of the project. Perhaps most importantly, they address the value they will continue to play in the future. They map out how their role will evolve from basic data collation/reporting to more advanced analysis, and therefore provide increased value to the organization.
Some would argue that this is a mere ego stroking political exercise to be indulged on an as-needed basis. I argue that it’s a real challenge to be met early, and one that has measurable and ongoing impacts, and may just save the project from being undermined by those with a vested interest in its failure.
Cheers, and happy holidays :-)
Rod.
Subscribe to this blog!
