Historical Process Analysis

The analysis of process metrics after the completion of processes is typically used when trends across multiple process instances or time periods (such as fiscal quarters or years) are of interest. It can also serve as a baseline, if process changes are imminent and an organization wants to understand if and how these changes will affect process metrics. This type of analysis is valuable as a first step to understand the actual process performance of an organization. The source data for historical process analysis can be found in the log files and event streams of workflow systems and other types of transaction processing software.

While the automated gathering and processing of this type of information is an easy and accurate way to determine process metrics, organizations that are just beginning to analyze their processes may not have the necessary infrastructure to obtain this type of data. In these cases, a manual measurement approach is often the only feasible way to obtain this information (zur Muehlen and Ho 2008).

Historical process information can be stored in data warehouse structures, following star or snowflake schemas of conventional data warehouses (Pau et al. 2007; zur Muehlen 2004; List et al. 2001). For the analysis of this information, OnLine Analytical Processing tools can be employed. If line of business data is captured with the elementary process metrics, the warehouse may contain a hypercube with many dimensions, as the warehouse structure of process audit data intersects with the warehouse structure of the line of business information. The selection of appropriate dimensions for analysis can thus require significant domain expertise.

Real-Time Process Analysis

Real-time process analytics focuses on the in-flight control of running process instances. Typically a business activity monitoring (BAM) system updates a set of key performance Indicators in real time (McCoy 2002). When a rules engine is applied to these indicators, a BAM system can generate alerts and actions, which inform managers of critical situations and may alter the behavior of the running processes. A typical example is the monitoring of workload in a BPMS. If the queue of pending work items for any users exceeds a certain threshold, the BAM system can automatically initiate the redistribution of excess work to other qualified performers. If no such performers are available, the system can then alert a manager to manually intervene. The purpose of BAM is to provide real-time control over currently active process instances.

The visualization of the analysis results commonly takes place in process dashboards that resemble a manufacturing control station. Figure 6 shows such a dashboard from a commercial Business Process Management system (Global 360). A properly designed dashboard allows an analyst to drill down into the process instances whose metrics are represented, in order to perform on-the-fly adjustments such as the reassignment of a work item.

Fig. 6 Process dashboard

An advanced variant of the BAM systems sends analytics events to an embedded rules engine that may trigger automated actions such as the automatic notification of decision makers or the automatic reprioritization of work. This configuration allows the automation of certain exception handling mechanisms and results in the implementation of a simple sense-and-respond environment. BAM systems have an advantage over traditional reporting systems (as well as historical process analytics) in that they reflect current operations that have not yet concluded. Their information is thus available in a more timely fashion than that of a warehouse-based system. However, the nature of the dashboard displays often limits the degree with which an analyst can combine the metrics with line-of-business attributes, since this relationship needs to be known during the design phase of the dashboard.

 
< Prev   CONTENTS   Next >