Sunday, December 7, 2008

Challenges in BI Implementations

All of us will have our own, unique take on this; but hey, a blog is all about opinions!

I think it is imperative to classify the challenges faced by the host company and the solution provider separately and stress that they vary based on the type of implementation and the current state of the host.

From my experience these are probably the top 3 challenges faced in larger implementations (in no particular order):

Host Organization
  1. Resistance to change: Introduction of a BI system changes the operational processes and might change business processes. Every individual prefers a status-quo and getting their buy-in (especially when we are dealing with operational BI) is critical. Moreover, embracing a BI system often requires the users to get trained on and be familiar with a new set of tools. That decision never wins the popularity sweep-stakes. The best designed and implemented BI project is a failure if user adoption is low.
  2. Master Data Management: Integrating and/or reconciling existing, disparate master data across various silos is a key challenge for most large organizations. It may be overwhelming to drive consensus on this, but it is imperative to keep moving forward in this exercise.
  3. Justifying RoI: BI business benefits are difficult to quantify. How do you prove that an increase in sales is because of the better strategy adopted from the insights your BI system provided and not because your sales personnel became “super” sales personnel? Quick wins and consistent visibility of key metrics to track project progress is a major driver of success

Solution Provider

  1. Estimating for a BI implementation: Accurately estimating a BI project is difficult because the scope is extremely difficult to nail-down and the expected output is often never known till it is actually seen. Prototyping plays a critical role in the entire exercise. There is no industry standard methodology, though the “agile” approach tends to work well and ETL is easier to estimate than reporting and analytics. I personally use a complex excel template that relies on several “weights” provided by past experience. But, on the whole, making an effort or schedule estimate for implementing a BI system running out of an EDW can be extremely hazardous. It takes a brave person to make a "fixed price" bid!
  2. Data Quality: Everyone knows about this, yet it continues to be a critical bottle-neck. Often the only solution to this is to change the way the transactional system handles data, but that is easier said than done. Anyway, garbage in is garbage out. Enough said.
  3. Contain scope, yet be flexible; deliver quick wins, but don’t lose sight of the big picture: It is necessary for the provider to wear many hats at the same time – ensuring that varying objectives are met is critical to this. The client CIO, COO and CFO may have divergent, even contradictory objectives – yet the solution provider has to meet them all! Be prepared for lots of prototyping and throwing away developed and working components

This blog has its mirror at http://www.beyeblogs.com/rajeshr/

1 comment:

Anonymous said...

Hi da! Interesting blog. Will keep visiting.

As far as ROI evaluation is concerned, what is the typical practice? For some of what we do, we conduct a pilot where we evaluate a new process (usually dependent on some BI technique) against an existing process and measure performance on a set of relevant metrics. Obviously, this approach may not work for all BI solutions. What else do people do? A detailed post on that would be nice.

Also, how do view the transition issue? Depending on whether the output of a BI project is a process or a product, the complexity of transition of the work to the host company varies. The trouble with processes is that it takes more training, while the trouble with products is that customizations are more difficult, which means that the product may not be robust enough to environmental changes. Which way do you lean, based on your experience?

~ramsu