Six Questions You Need to Ask Before Deploying Business Intelligence
Make sure you provide the right BI capabilities to the right people.
Yesterday, I wrote about BI's catch-22, the question of whether BI practitioners should allow business needs or architecture considerations to drive their projects. I shared the example found in Paige Robert's recent ebizQ column, "Business Need Driven vs Architecture Driven BI," and promised to revisit the issue today to share some lessons I've picked up over the years that I thought might inform this discussion.
In other words, I'm about to play "Monday morning quarterback" and probably stick my foot in my mouth as a result. That's because, like most Monday morning quarterbacks, my only qualification is my years spent reading and listening to the real experts.
With that caveat out in the open, here's why I think this issue isn't so much a catch-22 as a red herring.
I called it a "catch-22" because it seems like you would have to choose. But to be honest, I think BI practitioners could take a lesson from other IT initiatives and realize that what they really need to pursue is option C: addressing the business problems that allow you to build smart architecture.
I'm not trying to be pedantic. Here's where I think things went amiss in the BI implementation Roberts is discussing:
She (BI implementer Claudia Imhoff) has done most of her past implementations in what I would consider a very business-need driven way, building a data warehouse for customer data integration (CDI), and BI models around that, then another data warehouse for financial, and another for product/inventory. Those were the business clients within most enterprises that saw the need for BI answers, and they pushed to get their areas addressed.
To me, this suggests that the chosen BI projects were picked based on which managers made the most noise, rather than evaluating across the enterprise where BI would best address a pressing, far-reaching business problem. In this case, it seems the squeaky wheel got the grease, but not enough to stop squeaking. And that's just annoying for all concerned.
Here's why I say it's a red herring question. Over and over, whenever I talk to or read about those who succeeded with any kind of enterprise-wide initiative, the story is the same: They identify a specific point of pain - not just an annoying squeak, but a problem that's creating serious pain for the business. But they just don't pick any old pain; they pick something that can be solved within a reasonable amount of time, with a minimum investment and with the greatest impact - preferably something high profile. Then, they approach the project with an eye toward using it as a starting point for the broader initiative and a starting point for their architecture.
Once that first project is complete, it serves as an example of what can be accomplished with the technology, thus helping to win over other divisions. As an added bonus, it also helps IT keep the rollout manageable until it can build the business case for adding resources for enterprise-wide implementation.
So my first suggestion would be to change how you view "business-driven." Instead of accepting the first problems that come your way, go on a treasure hunt for the points of pain you know you can fix, given your existing resources.
Does this mean that some squeaky wheels will have to be ignored, even if they have real and pressing business problems? Yes, but only temporarily. And once you do get to address that problem, you've got experience, a list of successes, and a manageable, planned architecture backing you up, which means each project should go easier and faster than the last.
In the meantime, though, keep your squeaky wheels informed about your progress. That way, you'll already have at least a few business sponsors lined up to support your enterprise-wide initiative.
Tomorrow, I'll share what seems to me to be the critical key to solving this problem for the long term.