Art Meets Science: Business Intelligence Requirements Gathering

(click to enlarge)

Requirements gathering.  So many organizations don’t realize this is often where success in a Business Intelligence (BI) deployment lives or dies.

When it comes to BI, we have all heard that BI is more than just simple reporting.  That’s become the BI vendor’s mantra.

However, the challenge we see all the time is how to realize the tremendous benefits of BI beyond reporting or even making existing reporting more valuable.  Through our experience and working with our clients, we have developed a proven, repeatable process to help make the vast promises of BI a reality.

It all begins with the premise that BI is not a tool, but rather part of the business process that should be used to improve business processes. Unfortunately, traditional report requirements gathering procedures have focused on – wait for it! – reports.  In essence, that process is flawed from the start.

If an organization simply wants reports that may or may not assist the business process or answer business questions, then the old, outmoded approach is fine.

What happens if you go down this road?

Well, tunnel-vision happens: 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.  Their perception is based upon the knowledge or lack of knowledge of the true capabilities of BI.

That’s a myopic – and oft-committed – error when trying to establish a real BI practice.

Embedding Bi into the business process is really an exercise of peeling back the metaphorical onion. In looking at the diagram below, if we think of a business process such as AP invoice payment, each process is surrounded by six key questions/considerations.  By securing answers to these questions, we can help ensure that the requirements gathered do not result in a siloed report and that the downstream and upstream impact of this information is understood and usable.  As these questions are asked and answers interpreted, they ultimately influence and refine what is being asked for. This inevitably leads to improved business intelligence far beyond glorified reporting.

BI business process

This is only the tip of this discussion.  If you would like to see additional detail and a practical example laid out in real-world terms, register for our free whitepaper, MiPro’s Business Intelligence Manifesto: Six Requirements for an Effective BI Deployment.  It provides much more information and expands upon the theoretical with plain English examples.

Also, if you would like further information on an enterprise BI strategy or BI applications in general, please email me.  I’m a nice guy.  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.

Related posts:

Related whitepapers (PDF):

Tags: , , , , , , , Posted by

10 Responses

  1. […] Art Meets Science: Business Intelligence Requirements Gathering […]

  2. […] Art Meets Science: Business Intelligence Requirements Gathering […]

  3. […] about topics that our customers and prospects are interested in, and in the past we’ve done exactly that. We even create whitepapers if the demand is great […]

  4. […] Art Meets Science: Business Intelligence Requirements Gathering […]

  5. […] Art Meets Science: Business Intelligence Requirements Gathering […]

  6. […] 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 […]

  7. […] Art Meets Science: Business Intelligence Requirements Gathering […]

  8. […] Intelligence Art Meets Science: Business Intelligence Requirements Gathering Business Intelligence Apps: Build vs. Buy Business Intelligence: A Picture (or Flash Demo) Is Worth […]

  9. If you do any one thing with SaaS/cloud computing, make sure your requirements are set in stone. It’s an entire model shift for many organizations, and going at it too loosely is like building your house with only a napkin sketch: things will go wrong.

  10. Khürt says:

    This is true within the IT organization at my employer as well. We are “negotiating” with the folks in R&D over allowing access to cloud based storage and other services. I have concerns over data leakage (anyone can open an unlimited S3 account with Amazon) but when asked for their requirements I am being told that “We want to explore what is possible and don’t want to be limited”.

Leave a Reply

%d bloggers like this: