What Not to do on a BI Project Series – #2 – Implement Reactive Projects

Is your BI team having trouble keeping its head above water due to a deluge of business requests for newer features and functionality?  Spend all of your time reacting to an endless stream of small requests with short timelines and little time for the big picture?  Then you are most likely in a reactionary mode playing defense against your business users.  Defenses usually don’t score points in most games – you need to get on offense!

Don’t feel bad though – this is a nearly ubiquitous problem among IT implementations today, particularly in BI.  If you have a new BI tool like OBI in place, then you truly are swimming against the current.  Keeping afloat, achieving small victories along the way, perhaps slipstreaming some infrastructure or data management in is about all you can hope for.

Unfortunately, reacting to what seems to be almost an ad-hoc set of user requirements does not allow you to plan for a good BI system.  A reporting system has no problem functioning in a reactive manner:  Place your report order and IT will serve it up for you over and over again. You want fries with that?

The central theme to this blog is the distinction between BI and reporting; if you are in a reactionary report building mode then you are not doing BI.  I don’t care if you are using a tool called The Most Awesome Super BI Tool Ever, all you will be doing reporting using BI, and a BI tool is a poor reporting tool substitute.  Thus this post is really one of Reporting vs. BI.  By doing reporting projects you do not get the benefits of a BI system spoken about time and time again by software vendors and BI experts.  In fact all you are really doing is putting up a new UI, which is Issue #1 – UI Replacement Projects.

What is a BI System?

Here are a few thoughts on what BI Systems are:

  • A BI system is a well thought out, planned and coordinated collection of efforts designed to produce a system that is so well organized it allows your user community to ask sophisticated questions of it and get those answers quickly and with a high degree of accuracy.
  • BI Systems like to be efficient in how they are built – they prefer to do their work once and only once, allowing for small adjustments as needed over time.  Reporting systems will re-do the same work over and over again, sometimes a little differently than the last.  A simple OBI example of this:  If you have multiple business models from the same source database and you have the same dimensions defined in each.
  • BI Systems take extensive efforts to ensure they think long term and big-picture.   The first requirement you get will not be the last, so don’t paint yourself into a corner.  They are very much concerned with foundation, architecture, management process, standards and the like.
  • BI Systems place the majority of their focus on their data and information derived from raw data as opposed to tools, user interfaces and reports.   Reports are an outcome, but BI understands that your reporting tool will probably only be around for a few years before it’s replaced, while your data and information will provide value long beyond your UI tools.  Information is useful to a business user; data is not.  Information tells them something by making a comparison or a projection.
  • A Report request to a BI System is considered a starting point and not necessarily what should be built; sometimes there are solutions that are better than a report a user thinks they want.  As BI systems are business process focused, they look beyond the report and consider the entire process.  Perhaps that user is doing a very intensive and error prone manual Excel process.  Reporting doesn’t even consider this portion, where BI aims to streamline it in an effort to assist actual people doing actual work.
  • BI Systems are concerned with their place within the corporate information environment, and are concerned if other systems might produce different results.  Consistent results is a top priority for BI, regardless of which tool it comes from.  Obtaining well accepted corporate definitions and identifying systems of record are critical for BI to be successful and powerful.

These characteristics, along with many others I could have mentioned, indicated a very different type of strategy than a reporting request reactionary plan.  You need to get out in front of these reporting requests and start to plan your BI environment.

Planning means:

  • Develop a BI Road Map – define the phase-in of systems, process and user groups
  • Develop a Data Warehousing Architecture that suits your needs, budget and expertise
  • Develop an overall BI Tool Architecture – what tools will you use and how will you ensure their results are consistent.  Define from where those user tools will get their information.
  • Develop a real Data Governance Program to ensure the data and information you put into your BI environment is the right data and everyone understands how to use it and modify it.  Treat your data as a corporate asset and ensure you manage and protect it
  • Define a Center of Excellence / Competency Center – define how you do projects, your standards, your roles & responsibilities, templates, architectural review points, etc.  This is where the pie-in-the-sky planning comes down to earth into tangible steps to take.
  • Define a communication and change management approach – how will your BI system be deployed to users and how will they get up to speed on how to use it.

To sum up then, the take-away from this post is the approaches in Reporting vs. BI are essentially reactive vs. proactive approaches.    Get out in front of your company’s informational and analysis needs, plan for a flexible and well defined BI environment, and make it happen.  If you spend all of your budget treading water you will never make any progress towards a powerful BI system.

Advertisements

Posted on September 7, 2009, in BI Theory and Best Practices and tagged , . Bookmark the permalink. 4 Comments.

  1. Hi Jeff,

    many thanks for this series. I couldn’t agree more. The problem is that even most of the developers/consultants don’t get the message of “Think BI not reports”. How should the user community get it?

    A BI project without the “I” is just a “B” project.

    have a nice day

    @lex

    • @lex:
      A difficult question. I think the business community needs to be educated on what BI vs reporting is, with particular attention paid to the benefits they can get out of it. Part of the education can be presentations by BI experts (not Oracle Sales Reps). One thing I’ve liked is having people attend BI conferences like TDWI – they can hear good stories about what BI is all about from a variety of experts and even companies who have implemented a productive BI system. As for showing users the benefits they’ll get, dig into some of their manual processes and main pain points – show them how a BI approach will make their job easier.

      Jeff

  2. Really enjoying this set of blog posts. More please 🙂

  3. Unfortunately, reacting to what seems to be almost an ad-hoc set of user requirements does not allow you to plan for a good BI system.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: