Business intelligence (BI) has traditionally been viewed in the context of strategic decision-making - a solution that provides senior and executive management with insight into organizational performance and enables strategic decisions. As a result, the audience for BI in most companies has been limited to the top few rungs of the organizational hierarchy. To a lesser extent, BI applications have been created to enable middle management to track performance indicators at a tactical level. Relatively, the use of BI to support operational functions has been limited. It has been mostly individual initiatives addressed at solving very specific problems, rather than as a part of the enterprise IT strategy. In other words, BI has yet to establish itself as an enterprise-wide solution.

But this is about to change. We are seeing a second phase in the evolution of BI where the objectives that characterized BI in the first phase will be challenged. This article presents some trends that are shaping the evolution of BI into a broader solution that may be referred to as "enterprise intelligence."

Characteristics of Operational BI

Operational BI has some distinctive characteristics that distinguish it from traditional BI. These are related to audience, latency tolerance, granularity and availability.

Audience: The audience for operational BI includes employees involved in operational activities, such as sales executives, contact center agents, technical personnel and shop floor engineers. It could also include managers who need to track operational-level performance indicators. In some cases, if the organization is able to establish a relationship between strategic KPIs and operational metrics that drive them, the audience could also include senior management executives who wish to drill down from strategic trends to operational metrics. Therefore, the audience for operational BI is much wider than traditional BI.

Latency tolerance: The latency tolerance for operational BI is significantly lower than for traditional BI in terms of data capture as well as data delivery. Most operational functions require data that has a freshness of between a few seconds to a few minutes. Consequently, BI applications supporting these functions also inherit a similarly low tolerance level for data latency and often need to be supported by real or near real-time data warehousing. In terms of data delivery, operational BI demands an equally challenging response time. Operational BI is required to support human decision points in operational processes. Often these decisions need to be made in a matter of seconds and, therefore, demand subsecond response times of BI data delivery.

Granularity: While traditional BI relies on aggregated data to derive a holistic perspective on corporate performance, operational BI requires a much higher level of data granularity to address the needs of the specific operational function it supports. This may not be true of all operational BI applications; some operational decisions may rely on aggregated data from the data warehouse. An example of this could be the lifetime value of a customer that is used by a contact center agent.

Availability: Operational BI is generally used to directly support transactional business processes that are often required to adhere to stringent service levels. An outage of an operational BI application could have a direct impact on the organization's ability to do business or to service its customers. Therefore, it becomes essential that operational BI applications are designed to be highly available.

Implementation Approaches

The most common approach is to embed BI applications or application components into an operational application to enable inline analysis. An alternative approach is to call on a BI service at a decision point in a process defined as part of an operational application. This service may return a calculated value or render a report or a dashboard. In both approaches, BI augments the capabilities of an existing operational application. A more state-of-the-art approach would be to create an operational BI application by combining the data-centric capabilities of a BI tool and the process-centric capabilities of a business process management (BPM) tool.

These two approaches only cover the outward manifestation of operational BI. The real challenge is to build a back-end framework that supports this front-end manifestation - in other words, the BI framework and infrastructure that deliver the kind of latency tolerance that operational BI demands. To put things into perspective, this section details some real-world implementations of operational BI and the business value delivered by them.

The Problem: In the heightened security environment created after the 9/11 attacks on the World Trade Center, the Transport Security Administration (TSA) of the U.S. government created lists of suspects called the "no fly," "selectee" and "prevent departure" lists. It was mandated that all airlines operating flights to the U.S. match passengers against these lists and take prescribed action if a match is detected. Noncompliance made airlines liable for heavy fines in addition to the likely possibility of a flight diversion or midflight turnaround to the source airport. The complexity of the problem was multiplied by the fact that 1) bookings were accepted up to a few minutes before departure; 2) the lists included several thousand names; 3) new names were continuously added to the lists, and airlines were required to comply to the new lists within a few hours; 4) the airlines had flights taking off round the clock from various airports around the globe. The stakes were high, considering the negative publicity and loss of customer goodwill and revenue brought about by a midflight turnaround or diversion.

The Solution: The solution consisted of a near real-time operational data store that integrated customer reservations data and TSA lists (see Figure 1). Message queues were implemented to enable near real-time data capture. Complex name standardization and matching routines were used to cleanse the data and flag potential matches. Business intelligence tools were used to generate reports containing potential matches for every flight. These reports were scheduled for delivery to various airports around the clock, depending on the flight departure times. To cater to bookings made between the report generation time and flight departure time, a service was developed that accepted the name of a customer and returned potential matches from the TSA lists.

Figure 1: An Airline Leverages Operational BI to Tighten Aviation Security

The Problem: A leading fertilizer company had strategic objectives to retain their leadership position in the fertilizer market and increase market share by providing value-added products and services to farmers. One such market-differentiating service was to advise farmers on fertilizers. This recommendation had to consider local soil conditions and local environmental factors that vary significantly from region to region. At the same time, the advice had to be consistent, reliable and accurate in order to win and retain customer confidence. The organization did not have the infrastructure to make this data available to the field officer visiting the farmer.

The Solution: The solution was a decision support system consisting of a central data warehouse (DW) that consolidated data on soil samples, lab results, environmental statistics and customer information (see Figure 2). A product was used to model the business rules governing the nutrient recommendations based on local environmental factors and soil conditions. The end-user interface was designed using Java. The field officer could access this interface through his PDA for instant data on soil conditions and local environmental factors. The process engine was used to recommend the best-fit fertilizer to the farmer.

Figure 2: Use of Operational BI to Advise Farmers on Soil Nutrients

The Problem: As part of a key customer-centricity initiative, a major telecom desired to equip its contact center agents with a 360-degree view of the customer they were servicing. The objectives were to achieve a higher level of customer satisfaction and to enable agents to identify opportunities to up-sell, cross-sell and market specific offerings. The challenge was that the data to support this objective was in many different systems. Secondly, in order to be meaningful, some of this data was required on a near real-time basis. Thirdly, average call durations of a few seconds meant that response times for the generation of the dashboard had to be in milliseconds.

The Solution: The solution was a BI application called the next best action (NBA) dashboard. The agent types in a customer account number and within subseconds, an NBA dashboard pops up. At one glance, this dashboard tells the agent all that he or she needs to know to best service the customer as well as maximize revenue from the customer. The dashboard covers faults history, customer complaints, service outages, campaign history and the lifetime value of the customer. At the bottom of the dashboard is the NBA list that consists of specific recommendations. Another interesting feature of this system was that it also captured the outcome of the customer interaction, and this data was fed back into the process engine to complete the loop. The primary backbone of this application was the single view of the customer that was created through a process of customer data integration, cleansing and deduplication. The underlying DW was near real time, achieved through replication and Oracle Warehouse Builder for extract, transform and load (ETL). A rule-based process engine was created, and a data mining engine identified trends and customer behavioral patterns. Finally, the NBA function was packaged and deployed as a Web service. When called upon with the customer ID as a parameter, this Web service would render the NBA screen as shown in Figure 3.

Figure 3: Operational BI Helps Contact Center Agents


As illustrated by these case studies, operational BI has mostly been driven by individual initiatives addressed at solving very specific problems, rather than as a part of the enterprise IT strategy. One of the reasons for this could be that BI technology vendors have yet to achieve the technological maturity to support such implementations. Traditionally, BI vendors have built their products around proprietary architectures. While these architectures are ideal for strategic BI, they are not suited for operational BI. Because operational BI entails coupling BI applications with operation applications and operational processes, a component-based, service-oriented architecture (SOA) is necessary to fully support operational BI. Some leading BI vendors have recently moved all their BI capabilities to SOA. However, the maturity of these products in terms of their adoption of SOA and the extent to which this architecture can be exploited for operational BI from an implementation perspective remains to be seen.

The other market trend that opens exciting possibilities is the increasing collaboration between BI and BPM vendors. BI vendors can leverage this collaboration to enhance their operational BI capabilities. Some of the areas of collaboration in this regard are:

  • BI vendors can leverage BPM to present data in the context of processes. From a strategic BI standpoint, this means that managers will not only be able to see performance data, but also the decision workflows they need to invoke to act on the data. Further, they will be able to continuously model these workflows themselves, with little or no assistance from IT. From an operational BI perspective, this means that IT can build end-to-end operational BI applications that closely integrate operational data with operational processes.
  • BI event management capabilities can tie in with BPM processes. This will enable BI vendors to offer complete event lifecycle support. From an operational BI perspective, this means that BI events can be configured to launch operational processes. For example, if the "inventory on hand" indicator falls below a critical threshold, it can be configured to launch an operational process to replenish the inventory.
  • In the future, BPM may be able to release key operational metrics to BI. This will enable BI to capture these metrics on a real-time basis as events unfold in the process domain. Further, if the organization is able to establish a relationship between strategic KPIs and the operational metrics that drive them, then senior management executives will be able to drill down from the strategic level to the operational metrics behind the trends.

Traditional implementations of operational BI have largely used custom-made components and services. This has primarily been due to the lack of maturity of BI tools in this area. However, with these new technology trends and product roadmaps of leading BI tool vendors, it looks like BI tools will have an increasing role to play in operational BI implementations.
While BI has traditionally been viewed in the context of strategic decision-making, it now seems poised to evolve into a broader enterprise-wide solution. This transition will be driven by trends in the BI technology market that clearly indicate a shift towards service-oriented architecture, which is a key enabler for operational BI. The landscape for operational BI will also be strongly influenced by the increasing collaboration between BI and BPM vendors. 

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access