What are the Challenges in Making Operational BI Work for the Enterprise?

Firstly, to be clear, I would define "Operational BI" to be providing integrated or embedded reporting and analysis alongside or within a production (or operational) application, the purpose of which is to make the application more useful and actionable (for decision-making, process improvement, etc.).

Then, I would offer the following key challenges for operational BI in an enterprise:

1. Modifying or extending an existing application to include operational BI features. Often, older application architectures are limiting.
2. Keeping the integrated BI capabilities simple, but powerful. If it doesn't solve sufficiently for the mainstream end user's analytic needs, it won't be used.
3. Creating an analytic silo. If the operational BI design doesn't include key data required to generate truly insightful analysis, once again it won't be used.

Of course, each of these challenges can be readily overcome with available technology, techniques and some planning. Done correctly, operational BI holds the promise of reaching more business end users than any other type of BI implementation. But, I'll leave that for another post because this question was just about the challenges.

Brian Gentile
Chief Executive Officer
Jaspersoft

Operational BI is the key to also improving business processes. Operational BI needs to have a sense of the business process flow also to recognize bottlenecks in the process as identified by the BI.

Challenges are to find tools that have a rich enough semantics to capture process flows and augment it in the background with appropriate Operational store design that makes sense for many different processes, many different kinds of Key Performance Indicators.

It is easy to design a Sales Data Warehouse and do fancy slicing and dicing for insights. Operational BI may deal with such a variety of KPIs - Financial, People, Process and Customer KPIs, having a tool that's flexible enough to be designed and put in operation in iterations is key.

The analysis capabilities and the design capabilities need to be flexible enough to be meaningful for use! This is not as easy as it seems!

Operational BI is all about improving business operation by pushing information and decision making out to front line staff and managers. This represents a cultural change at the user level because the responsibility of the user can be greatly expanded and may require new training, new evaluation criteria, etc. That impact should be evaluated and planned for ahead of time.

Also, don’t overlook the fact that making operational BI work for the enterprise requires a different mindset from BI developers. We’ve seen that if you put a strategic BI developer on an operational BI project, you may get a new version of your dashboards, but may not immediately get new capability. The reason is that a developer needs to forcibly change their mental model of what data can be made available to the user. One of our very successful BI customers had to teach their BI developers to think about enabling “click-through to action� and not be held back by prior assumptions about having to use ETL tools, warehouses, etc.

John Joseph
Director of Product Management, Ensemble and DeepSee
InterSystems Corporation

John Joseph came close to the critical challenge when he mentions mental models and I would like to expand on his comment.

To paraphrase Einstein: "The mental maps used in application development that got us into our current situation are not going to produce operational BI any time soon."

As a useful metaphor, imagine if your brain was built using the same approach as the one used to 'build' your arm. Like the old song goes, your shoulder bone's connected to your humerous bone, and your humerous bone's connected to your 'el-bone' etc. The form of your arm supports a number of very specific functions, but 'thinking' is not one of them. Unfortunately for most developers the attitude seems to be: what worked once can be repeated anywhere and for any application.

There's a reason your brain is the shape it is, and it has everything to do with speed, precision and adaptability. I see the primary challenge with operational BI as getting IT and by extension the developers in a company to not only adopt a new mental model, but to stop using old tools, technology and metaphors and start thinking about a whole different 'physiology'.

I agree with the comments above, that you need to pick the right KPI's and think about "actionable dashboards" in order to make Operational BI relevant. There is however, one critical point that I have found in trying to implement BI and BAM systems that has made some of these efforts complete no starters and that has been an appropriate means of extracting and consolidating and normalizing the data that comes from diverse systems.
If we are talking about building dashboards that pull all their data from one system, then this problem doesn’t exist. But then if all the data lives in one system, that application more than likely has its own form of BI or analytics usually built in. In most cases, the reason that users need an operational dashboard to begin with is because they lose track of “work items� as they move through a particular business process and invariably, through a number of different systems.
In my mind, the biggest stumbling block to successful Operational BI and BAM projects is that most project teams underestimate (or completely ignore) the amount of effort involved at the application integration layer of the stack. And make no mistake about it, in most cases we are talking about true application integration being done as part of these projects.
Would anyone like to have a conversation about how an SOA integration layer should be layered on top of our enterprise applications before starting an Operational BI project? I feel another thread coming on that belongs in the SOA forum :-)