The next session was on measuring processes in real time, namely business activity monitoring (BAM), and how it needs to be considered up front as processes are being design and implemented.
Gassman started off with a few definitions — BAM, real-time BI, operational BI, and process-driven BI — with some pretty fuzzy distinctions between some of these, especially in these days of converging functionality in the BI products. He then defined the goals of BAM: to monitor key objectives, anticipate operational risks, and reduce latency between events and actions. From an implementation standpoint, BAM is typically a real-time dashboard that’s integrated with BPM in some way and provides alerts in the context of the processes within the BPMS, but also links to more traditional BI functionality such as predictive and historical reporting. He also makes a distinction between more passive data displays that require someone to be looking at a dashboard in order to detect the condition, and sending an alert when a specific threshold condition is reached.
He talked about a number of different real-time analytic techniques, including process monitoring, logistics optimization, situational awareness, complex event processing, track and trace, and anticipate and react. Of all of these, CEP is the up-and-coming new technique (to be covered in the Event Processing summit that follows on after this BPM summit for the remainder of this week) that uses pattern recognition and matching, whereas the others are based on pre-defined metrics. Looking at it along another dimension, anticipate and react is a predictive technique that uses past and current data to predict the future state, whereas the others primarily display data or events that have already occurred.
Without monitoring, it’s difficult to detect when something has gone wrong in a business process; with BAM, not only can specific business questions be answered based on measurements, but analytical techniques can be applied to detect correlations, report on impacts, detect root causes, and make some predictions. This, in turn, feeds into the broader scope of corporate performance management.
He went on to discuss the synergy between BAM and BPM, and how BI (which he considers to be a different type of functionality) can be tossed into the mix to provide operational decision-making and even trigger new processes, on top of the “awareness” that comes from BAM. Although BAM and BPM are a natural fit, BAM doesn’t just come from the BPM vendors and isn’t just for BPM: some BAM tools are focussed on or part of business/enterprise software and BI suites. Having BAM integrated into the BPMS has some advantages however; the monitoring can be modelled right along side the processes, and drill-downs from the dashboards can go directly back to executing processes. However, many of the BAM products that are part of a BPMS are less functional than their general-purpose counterparts, and may be limited to monitoring just the business processes and not the larger business context. Because of that, Gassman’s final recommendation is to look for a BAM product that can be integrated with a BPMS but can also run standalone.