Oops! The input is malformed!
Originally published 3 September 2008
This article looks at how companies can improve business performance by leveraging operational business intelligence (BI). It also looks at what you need to do to get started in this underestimated area of BI technology. In order to do that, let us first define what operational BI is and what it is not.
I have heard many definitions of operational BI from simple reporting on data in operational systems to complex event processing. While I understand that simply using BI tools to run reports directly against operational systems could be construed as operational BI, I think that this is a very limited definition. In fact, I do not regard this as a sufficient definition of operational BI, as companies have been doing this kind of operational reporting for years – well before the term business intelligence was invented. By operational BI, I mean being able to deliver precisely the right role-based intelligence at the right time to assist users in specific roles to perform a particular operational business process activity much more effectively. The objective is to get everyone in operations executing on business strategy at all levels of the enterprise. This vision is echoed in the recent book by Dr. Robert Kaplan and David Norton on strategy execution. The idea is that right-time intelligence helps the majority of the employee base working in business operations to contribute to the overall performance of the business on a continuous everyday basis. It is a bit like saying, “In order to perform this particular activity, precisely what BI is in play to help me be more effective?” or, “For this specific process activity, would only the relevant BI please stand up”?
In order to make this possible, intelligence needs to be made available on-demand to business users to help them execute everyday decisions in such a way that keeps the business running smoothly and in line with strategy. In addition, operational BI deployments should also include automated monitoring and analysis of operational activity to support management by exception. In today’s enterprises, with so much information available to be analysed, management by exception is becoming increasingly important. Therefore, events and operational states need to be monitored so that when business problems (or opportunities) arise and are detected, action can be taken to keep the business running optimally. This management by exception approach is not on-demand. On the contrary, it is event driven. So, we have two broad types of operational BI. These are on-demand operational use of BI and event-driven operational use of BI. Both of these are heavily linked to business process. Thus, understanding activities and decision points in a business process model as well as process events that are received or generated during process execution are critical success factors in getting the most out of an operational BI environment.
Before we get into looking at processes in more detail, it is worth looking at what we need to get started in operational BI. I have written about some of the things to consider in my article Top Ten Tips for Integrating BI into the Enterprise. If you take time to read that article, one of the key points within it is to clean up you BI systems before you start. What this means is to address any data quality issues in BI systems and to establish a common vocabulary across your BI systems and tools so that common data names and common data definitions persist everywhere. This latter point ensures that there is common understanding in any on-demand intelligence served up to users and applications from BI systems. This is not that easy to achieve – especially if you have multiple BI systems. The more BI systems you have, the more complex any assessment and tidy up of these systems will be. Nevertheless, you need to do this preparatory work if you are to maximise the benefit of operational BI.
Given that you have to do this work, then any review of existing BI systems to resolve inconsistent vocabularies and data quality issues should also double up as a readiness assessment of your BI systems to support operational BI. An operational BI readiness assessment should determine what processes you have documented, who needs what intelligence when, and what technology you have available to make it happen. Therefore when assessing your current technology capabilities, you should check if it is technically possible for applications and processes to request BI on-demand from your existing BI systems. This means checking if there are any standard interfaces to your BI tools (e.g., web services interfaces) and whether or not you need to upgrade the BI platform tools you have in place (e.g., to a more recent version) before you can exploit this kind of capability. An Operational BI readiness assessment should also check whether or not your BI infrastructure software can support the monitoring of live operational events. Typically, this requires support in your existing infrastructure for:
While it is common to find support for event-driven data integration in existing ETL tools, I often find that many companies do not have all of these components. In particular, many are missing a rules engine or data mining technology to support the development of predictive models or both. If you have no tools for predictive and scoring model development, then you may not be able to implement event monitoring unless you purchase additional software to support this. Alternatively, you may wish to invest in specific event monitoring products such as IBM Cognos Now, Progress Apama, SAS Real-Time Decision Server, SeeWhy, SL RTView, Systar, Tibco, ThinkAnalytics, etc. These kinds of technologies typically provide all of the aforementioned three elements in a single product.
A key point in getting started with operational BI is that your core business processes are documented. Without this, you are to a large extent working blind from a business perspective. Lack of understanding of how a core business process works is also likely to stall any business sponsorship that may be forthcoming. This is because lack of understanding of how you operate makes it difficult to articulate a business case for operational BI in a way that is clearly understood by business professionals. This does not mean that you have to be executing your processes under the control of business process management (BPM) infrastructure software. However, it does mean that process models are extremely beneficial in helping to understand where operational BI can be deployed most effectively. Also, processes in the modern world need to be dynamic as opposed to static (i.e., their behaviour may need to change on the fly). If you want a “gold” customer to be treated differently than a “bronze” customer, for example, then the rules of the process itself may rely on business intelligence to dictate the path of execution.
Once you have assessed your existing setup and laid the groundwork for embedding BI into processes, the next thing is to create an inventory of core business processes. You can start by simply creating a list of what your core business processes are and what they do. A good example is the order-to-cash process in a manufacturer or an underwriting process in an insurance company.
Once you have this process inventory, the next challenge is then to work out what processes and specific activities within these processes would benefit the most from leveraging operational BI. Also what type of operational BI is most appropriate to yield business benefit? Is it on-demand intelligence that needs integrated into the process or is it event-driven monitoring? Or is it both?
From here, you need to identify precisely which activities in a particular process are the ones that would most benefit from on-demand intelligence. Are these activities performed by an application (automated task) or by a person (human task)? In the case of process monitoring, precisely what events should be monitored? Let’s take a look at an order-to-cash business process example. Figure 1 shows this process and the activities within it. Of course, this process is enterprise wide and may span multiple applications and business units.
Looking at Figure 1, it is clear that there are events in this process that drive the process forward. For example, new customer credit verification is often checked with an external agency. In this case, the process needs to emit an event to a credit agency and receive a credit verification back. This indicates that there can be outbound events generated by a process and inbound events received by a process. If an inbound credit verification event is not received, then the process cannot continue to its next activity. In this case, the inbound event is said to be a driver event . Also consider whether or not this process included a business-to-business component. Figure 1 shows an activity called special order fulfilment. In this case, if the order contains something other than CDs, books and videos, it may mean that the additional products ordered need to supplied externally. In this case, the process generates outbound events to an electronic marketplace to see who can provide these additional products within an acceptable time frame and at the lowest price. Inbound events are then received from companies in the market stating when they can fulfil an order and for how much. At this point, some decision has to be made as to what external supplier to choose for the special order element of the overall order placed. In order to make that decision, operational BI may be required to allow a supplier with a reliable track record on delivery to be selected.
Another problem that could arise here is that inbound events from external suppliers may indicate that the special order element of this order cannot be fulfilled in a time frame that is acceptable. What happens then? This is clearly a point in the process where this problem needs to be detected, the impact of it analysed and some kind of action taken to resolve the problem (e.g., ship some of the order and send the rest later). This detection, analysis and action taking is an example of event-driven operational BI (sometimes referred to as business activity monitoring or complex event processing).
Overall then, certain events need to be monitored to allow the business to respond in a timely manner if there is disruption or if a disruption is likely during process execution. The challenge from an operational BI perspective is to be able to identify all the events associated with a process and then work out the best ones to monitor to keep the business running optimally at the lowest cost. Real-time monitoring is therefore an important operational BI tool.
Recent articles by Mike Ferguson