Business Intelligence Requirements Gathering: Digging Deeper

August 11, 2009
Larry Zagata
Blog

First off: wow. I wouldn’t have guessed that Business Intelligence (BI) requirements gathering was such a popular topic. I say this becuase since I wrote my first post on the subject, about 20% of this blog’s daily traffic comes to us via search strings related to BI requirements gathering. Clearly, people understand the importance – and complexity – of this stage. That’s good.

In my prior post, we outlined our approach to BI requirements gathering here at MiPro Consulting and discussed how it is different and superior to status quo report requirements gathering processes. The net of that message was that in the end of a vanilla BI requirements gathering exercise, you may still get reports or possibly dashboards or a combination of the two. However, by taking a more strategic and investigative approach by looking at the business process and identifying the key questions around that business process, the end results are more effective, valuable, business intelligence reports. Ones that actually lend themselves to organizational decision-making – which has been the promise of BI all along.

(It’s just a shame BI got caught up in the “fancy reports” stigma. True BI done right is so much more.)

Since we like to provide real-world examples instead of wading to0 deeply in academia, let look at a scenario involving inventory turns for a CPG/retail business. If we utilize our process and ask the key questions we know to be valuable, we may get a result resembling the chart below. This has been simplified for the sake of IP and readability, but the very basic core is there.

(click to enlarge chart)

The net of this process – which is more detailed and comprehensive than this can possibly show – is that we simply end up with more effective BI.

Why? How?

Because in this example, we learn that it is not just the inventory manager who is interested in inventory turns. Low inventory turns can be a reflection of poor product quality, poor product design, poor packaging concepts, pricing issues or seasonality issues. Perhaps sales and marketing need to analyze the items with low inventory turns so they can run a marketing campaign to move the material or adjust prices or revamp packaging?

So in the end, we design our report or reports and dashboards to make sure all areas of the business potentially impacted by this business process/business question are provided the right information, in the right format, at the right time. This is a far cry from simply creating an inventory turns report for the inventory manager. And the requirements gathering process is the hub of something a subtle as this. Do it wrong, you get a report for the inventory manager. Do it right, you get something that serves information to multiple roles in the company in the right format at the right time. That’s BI.

Under the MiPro process, as we finalize requirements, we have large matrix of metrics and analysis requirements across various organizational areas that are impacted by a particular process. Through this, we can clearly see the cross-functional needs of the client and design a solution that meets the needs of the business and improves the business process and function for all impacted areas.

It all starts with the requirements. You put the wrong stuff in, you get the wrong stuff out. I can’t overstate that.

If you would like further information on an enterprise BI strategy or BI applications in general, please email me. Seriously. I’m a nice guy and would love to have a chat with you. If social media is more your thing, you can follow us on Twitter or become our fan on Facebook. Or, if old school RSS is your gig, you can subscribe here.

Previously by Larry Zagata: