Business Process Mining: The opportunity to improve business process performance Part 2
The life cycle of a business process is managed through an overall activity called business process management, which has the following five distinct phases: business process design, development, execution, monitoring, and improvement. The same idea is applied by Dumas et al. [1] using similar phases. In contrast, the presented model places more emphasis on collecting metrics, monitoring the process, and using the generated data in a subsequent step for process mining. For the longest time, the emphasis has been on business process discovery, design, and implementation. The subsequent phases of business process management tended to be neglected because of budgetary constraints, because there was no infrastructure in place to collect and measure the performance of business processes, and because there was a lack of general awareness about the importance of doing so.
Essentially, business process management is a continuous cycle of events. For discussion purposes, we will start with the business process discovery and design stage. The main purpose of this stage is to identify a new process and its behaviour or to modify an existing business process. For new processes, the identification of the process can happen through design workshops or interviews or simply through evidence that this process exists. The classification of business processes should be in either operational or organizational processes. As part of the overall process discovery, it is critical that the organizational goals, strategy, and objectives are closely tied into the identification of the business processes. A further classification into core and supporting processes will help to validate the core business process against organizational objectives since they ultimately produce the value. The focus should always be first on core processes and then on related supporting processes. As the business process discovery initiative gets underway, it is important to establish a business process master list that identifies each process with a unique identifier and provides identification characteristics. In addition, the discovery process produces a process structure document that describes the relationship between organizational objectives and strategy with an organizational process overview. Further decomposition drives this down to the process master list.
Once the business processes have been identified and recorded in the master list, the actual design of the process can begin. Normally, the discovery of processes produces a level one and two process structure document. The actual design starts at level three. This brings us to the next discussion of process abstraction and decomposition. A common way to avoid information overload in business process models is to use abstraction to hide details and focus on the essentials. When engaging in the design of business process models, the development of such processes can quickly become unclear based on the level of detail that is included in the model. To better organize such detail, approaches such as abstraction and decomposition are used. Abstraction is a way to hide detail and only highlight the essential components. There are two different types of abstractions [2]. The first is elimination, which removes unnecessary detail so that the main functions are preserved. The second approach is aggregation, whereby model detail is combined. Here we are combining several sub-functions into one aggregated function and thus reducing the complexity of reading and understanding the business process.
A third approach is decomposition. With this approach, different modelled functions are decomposed into an additional lower level of detail. This new level of detail is commonly a new model. The connections between the different levels support the decomposition and are maintained through interface modelling objects. What is crucial here is that the identification process from level to level be consistent. Even though many tools support a high number of modelling levels, it is difficult to maintain understanding and consistency if a business process contains more than four levels.
The implementation phase of business process management takes the design models and starts the implementation process. This could take on different forms. For one, if application software is involved, a separate project could spin off to configure the required software. If multiple applications are involved, interface design might be required. The configuration and integration will require a detailed test and training plan which covers manual, automated, and integration steps of the business process. Detailed test scenarios with applicable test cases have to be developed that include both positive and negative testing. Finally, a change management process must be designed to train the user community on usage of the involved application software and the manual processes included in the overall business process.
Once the newly designed business process is implemented, the execution of the process can begin. Most often, all business process management activities come to an end at this stage, since it is perceived that the implementation of the required software applications is complete and has gone live. If business process management is not continued with the next steps, it will never be possible to determine the actual benefits that the newly implemented process will contribute in business value. This leads to the next business process management activity, which is business process monitoring.
Business process monitoring requires that a suitable infrastructure be in place to capture measurements during the execution of the process. The first thing to consider is the location of probes at the right locations, and second is the capability of the probes to collect the right measurements. A third consideration should be how invasive the probing is to the execution of the business process. To address these issues, the designed business process functions should be mapped against the underlying application software and if possible hardware. Wang et al. [3] define the classification of probes into instrumental and interceptors. The difference is that instrumental is integrated into the application whereas interceptors are external and most often self-contained agents. There are four different categories:
- Instrumental probe with analysis capabilities
- Instrumental probe without analysis capabilities
- Intercepting probe with analysis, and
- d. Intercepting probe without analysis.
Probes with analysis capabilities have sufficient logic to evaluate measurements against thresholds and communicate these with a central controller. Even though Wang’s example refers to web service monitoring, the concept can also be applied to a general business-process-monitoring environment. It provides a classification of the implementation of probes. The location of a probe is determined by the objective of measurement. Therefore, the question should be what and why is the measurement being taken? The answer should be related to the discovery of some behaviour of the process and should determine exceptions for alerting. The measurements collected are the event logs that will be analyzed for performance and business process compliance.
This leads to the next phase of business process management, which is the establishment of thresholds and KPIs in order to evaluate the measurements and to be able to make inferences on the behaviour of the process. The establishment of these metrics is not a one-time activity but requires constant tuning and adjustment. Consideration has to be given to the performance of underlying software components, hardware composition, and user efficiency. Metrics management requires a dedicated group of users who are familiar with the business process itself and the supporting environments. Since a process can span multiple application systems and hardware components and be distributed over various geographic locations, the internal metrics group needs to work with business and IT as well as senior management to ensure that the metrics framework is valid and will provide the right information for business process analysis activities. KPIs can be represented through interactive dashboards, and thresholds used for the alerting of exceptions.
Business process analytics uses the event logs (which contain the recorded measurements) and through specific algorithms tries to uncover behaviours of the business process that need correction. Data visualization tools can assist in discovering performance-related issues. For example, a simple scatter plot can quickly identify orders that are removed from the cluster. Other algorithms are used to determine exceptions through outliers. These outliers often provide substantial amounts of information on user, process, date and time, process step and hardware to determine why the outlier occurred in the first place. Conformance of the business process is analyzed with simulation software that can refactor the business process from the event logs and simulate the document flow. This provides information on bottlenecks and other inconsistencies in process execution.
Considering all the data collected through the process analytics steps, changes to the original process design can now be analyzed and implemented. This final step closes the loop of business process management, and the initial design process starts over again.