BI Requirements: Don't Just Give Users What They Want

Ann All

Trying to come up with the right requirements for your business intelligence system? Most companies simply ask business users what they want. This certainly seems like a logical approach. But it's not, writes Larry Zagata on MiPro Consulting's Unfiltered blog.


The problem is, users are (either knowingly or unwittingly) selfish. Zagata explains:


... if you ask users what type of reports they need, they will provide an answer based upon the limits of their experience and job domain. Answers will be derived from what they use now, problems they have experienced in getting data or information, and "individualized" not process-based needs.


The key is to embed BI in business processes, an exercise Zagata likens to "peeling back the metaphorical onion." Happily, Zagata followed up with a later post in which he offered a real-world illustration of what he meant.


Using a chart for a consumer packaged goods/retail business, Zagata shows how requirements gathering must focus on:

  • A business process (inventory)
  • A key business question (How long does inventory sit in the warehouse?)
  • Who asks the question (inventory manager, sales VP and marketing VP)
  • The importance (improves inventory turns, lowers cost of inventory)
  • Who/what benefits (corporate expense, inventory manager and marketing, since it can better market promotions to move inventory)
  • Metric employed to measure success (inventory turns)
  • Further questions driven by the measurement (What items should we purchase? Do we need to run promotions? Is the pricing appropriate?)


If done right, requirements gathering will yield useful reports for all areas of the business potentially impacted by the inventory process. As he notes:


This is a far cry from simply creating an inventory turns report for the inventory manager.


This sounds a lot like a process-oriented approach to BI requirements gathering I wrote about last year, from Steve Williams of DecisionPath Consulting. Like Zagata, Williams recommends specifying:

  • A targeted business process
  • How BI can improve the process
  • When BI will be used
  • What kind of BI is needed
  • Who will use it
  • How improvements will be measured


Essentially, if you want the right answers, you've got to learn to ask the right questions. This is true of business in general (and life in general, for that matter), but especially for BI initiatives.

Add Comment      Leave a comment on this blog post
Aug 24, 2009 5:19 AM Jill Dyche Jill Dyche  says:


I've been enjoying your blog posts and just want to add one comment to the BI Requirements conversation, which is amplified at many of our current clients right now.

Some companies are more process-centric than others. While embedding BI requirements into specific business processes can be very effective, its value is only as good as the company's ability to articulate and circumscribe its business processes. Larry is absolutely correct in discouraging people to use existing reports as the basis for new requirements ("if you always do what you've always done, you'll always get what you always got"), we also have to meet companies where they are. So a process-centric approach to BI requirements may be too lofty or overwhelming for some clients.

Another effective method for requirements gathering is by deconstructing corporate strategy down to information needs. The strategy mapping approach made popular by Kaplan and Norton a few years ago, can drive even more business value than the process-centric approach to BI requirements. Moreover, it can cement executive buy-in.

Of course, combining strategy and process with data will yield the best results of all!

Keep up the good work!

Jill Dyche

Baseline Consulting

Aug 28, 2009 4:43 AM Richard Winter Richard Winter  says:


This article makes a point fundamental to the way we approach data warehouse requirements.  Usually a BI implementation -- and the data warehouse that will support it -- is motivated by a desire to improve a business process or create a new one.   So get the requirements you have to work with users to first envision the new business process and then understand how BI will support it.  Only then can you tease out the requirements.  

What is often left out -- even with the approaches you describe -- is the engineering portion of the requirements: those that deal with performance, availability and scalability.  One place to read more about this is in this Information Week Article

Richard Winter



Post a comment





(Maximum characters: 1200). You have 1200 characters left.



Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.