Zeroing in on the Right BI Business Requirements

Ann All

One of my favorite aspects of a presentation by Guy Kawasaki I saw a few months ago was the serial entrepreneur's illustration of the generic nature of most mission statements.


His example, from Wendy's:

"Our guiding mission is to deliver superior quality products and services for our customers and communities through leadership, innovation and partnerships."

All too typical of mission statements, it leaves the reader clueless as to what the company actually sells.


While generic can be good in the case of prescription drugs, it just doesn't work for mission statements. Or for business requirements, as Steve Williams of DecisionPath Consulting points out in a B Eye Network article.


Generic business requirements can cripple business intelligence initiatives, says Williams. Squishy statements about "providing a single version of the truth" or "managing data as an organizational asset" aren't likely to win the backing of senior executives or business users.


And BI won't be successful if people don't recognize its value. A lack of buy-in is one of nine "dumb ideas" associated with BI failures mentioned in this CIOUpdate article.


Williams writes:

(Business executives) see no reason to get excited about business intelligence absent a more compelling business case and more concrete BI requirements that relate to the things they do, like conduct marketing campaigns, manufacture and ship products, buy raw materials, provide services to customers, and so forth. As a result, they underfund business intelligence, which limits its business impact and thereby justifies their skepticism.

Some companies get hung up on functional requirements or specifications. While it's good to be aware of such desired features as "the system shall enable integration of data from multiple disparate sources" or "the system shall provide the ability to specify organizational hierarchies," Williams says these are now standard capabilities of most commercially available BI tools.


They offer little help in creating BI applications that actually meet users' needs, he says, because they don't address the specific types of business information, analytical techniques or decision support that will be used or even the core business processes that the company hopes to improve.


Some companies list data elements in lieu of business requirements, says Williams. This is even more vague than the aforementioned generic statements or functional requirements. How will the information actually be used, and will it need to be integrated with other data? Who knows?


Not only that, writes Williams, but:

BI capabilities built on top of large stores of unintegrated subject data elements run the risk of spawning inconsistent business intelligence depending on how development teams and/or power users choose to integrate data for their specific purposes.

Just when the article starts to seem a bit discouraging, Williams provides a seven-step list for establishing BI requirements that are driven by the business. He offers a couple of helpful graphics to further illustrate some of the most important parts of the process. For example, when defining what he calls BIOs (business improvement opportunities), you should specify:

  • 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

Williams' suggestions could certainly help companies gain more from their BI investments in the five areas mentioned as needing improvement by respondents to a recent CIO Insight survey:

  1. better alignment of BI with business strategy
  2. improved data quality
  3. better integration of BI systems with other systems, such as CRM or ERP
  4. better understanding of user needs and requirements
  5. improved user training

His advice seems particularly helpful for items 1, 3 and 4 on the list.

Add Comment      Leave a comment on this blog post
Feb 27, 2008 2:54 AM Robin Goldsmith Robin Goldsmith  says:
The flaw in this logic is that it's starting with the conclusion that BI in fact is what the business requires, whereas BI if useful at all for the situation is an albeit high-level design how solution to a presumed REAL business requirement, which typically nobody has know to define or how to define, partly because they're presuming BI is their requirement. My book, Discovering REAL Business Requirements for Software Project Success, explains these differences and how to deal with them more fully. Reply
Feb 28, 2008 1:44 AM Brian Fending Brian Fending  says:
The real and only question to ask in gathering BI requirements is, "What decisions are you looking to make from these data?" Often, the business user won't even know the possibilities and it becomes a longer conversation, but it's this kind of thinking that will generate better requirements - and funding - in the long run. Reply

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.