Six Misconceptions About Process Mining

A central issue of entrepreneurial action that decides success or failure is finding the best way to achieve value creation goals, if they are clearly defined.

This challenge is also taken up by the analytical approach of process mining. The basic idea is impressive. From the machine-driven collection of recorded event data, statements are derived for automated analysis of business processes. Free from any conceptual and subjective transfiguration – such as they took place. A realistic image of computer system processes at the touch of a button.

This method seems simple, targeted, and holds out the hope of being faster and more efficient than any manual or interview-based inventory of operational workflows (as-is analysis). It is notably thanks to this idea that process mining has found a prominent place in the analysis of business application systems. Indeed, process mining helps to discover, reconstruct and monitor real processes close to reality.

Historically, this method is not a new approach, but looks back on many years of development. Opinions differ as to the exact date of the emergence of the idea of ​​process mining, whether it dates back to the 1990s or emerged in the 2000s from research projects that pursued the goal of developing new meta-models and ontologies for process flows from workflow-based analytics. The reasons for conducting such an investigation are multiple:

  • existing processes are becoming more inefficient and costly due to gradually changing requirements over time;
  • process flows and responsibilities are unclear, especially in the context of distributed organizational units;
  • there is heterogeneity within a group of companies, perhaps due to growth;
  • company-specific or vendor-specific best practices are not applied; there is a low degree of standardization, perhaps due to unstructured and non-strategic business requirements;
  • the degree of automation to reduce process costs is too low or process costs are not allocated according to their benefits.

This is more than enough motivation to seek full transparency of business processes.

Event logs and visualization

However, does process mining really do justice to these tasks and the current hype? How meaningful and reliable are the results of process mining? And is every process mining approach the same?

To answer these questions, a basic understanding of how process mining works is necessary. Event logs, which record the use of the process by employees, form the basis of information. This helps generate visualizations that provide a correct and up-to-date overview. This is exactly the strength of process mining, because by using data from real business transactions, an objective picture of the process can be created. The extraction of this information is generally done either by a complete extraction, or by a direct connection to the system under study. In any case, full access to all individual document data is necessary to ensure completeness of process chains and to be able to process the initial data preparation in an analytically meaningful way. The focus is on transaction data for which a context is then created (filtered), for example by means of master data such as customers, articles or organizational units.

An automatic and generic structuring and classification of data into activities and paths seems rather cumbersome and the question arises as to whether the consideration of event logs does not neglect significant aspects of a particular SAP system, such as as system configuration settings. This is exactly where classic process mining reaches its limits – a misunderstanding that will be examined with a few others in what follows.

Six misconceptions

  • Misconception 1: Process mining provides rapid problem diagnosis and bottleneck detection. The basic assumption that weak points in daily activities are unknown and must first be identified has been refuted in many projects. An SAP system provides each employee with a solid overview of the imbalances in their area of ​​work, but not of the structural causes and the full extent of their integration effects. As a result, the statements made initially often belong to the domain of innocuous observations or deliver false positives. Expensive investigative iterations result. This can be remedied by a comprehensive analysis model based on a large set of key figures and available from the start. However, this model must be compatible with both the specifics of the company and the target concepts stored in the software configuration. Otherwise, there is a risk of costly efforts for subject matter experts and subsequent adjustments to target analytical parameters.
  • Misconception 2: Process mining gives quick insight. Many Process Mining providers offer the technical possibility for the analysis but only include simple models without orientation to the specific customer situation or the differentiated possibilities of the software. This conception is also often moved into the realm of expensive complementary consulting services. It is worth checking here exactly the extent of the analytical content available and which skills come into play at which price with the corresponding service offers.
  • Misconception 3: Process mining helps assess compliance, risk, or other issues. Of course, process mining can also help assess the opportunities and risks of business activities, as well as investigate compliance. After all, the analysis accesses all of the process information. But applying test logic requires robust data transformation, analysis, preparation, and evaluation, as well as consideration of individual risk characteristics or business-specific requirements. Therefore, these statements are also highly dependent on the underlying referencing content or add-on services. Sometimes the promises made by software makers leave the real possibilities of this approach unfulfilled.
  • Myth 4: Process Mining helps consolidate process data across multiple systems. The idealistic expectation of a central ERP system is often not realized, especially in large companies or organizations. In practice, there are separate system landscapes with distributed processes. For their analysis, classical process mining is rather unsuitable, because reconciliation of cross-system process chains is associated with high effort, especially in the case of variant-rich process logics and heterogeneous technical systems. A direct comparison option at the level of system technology and organizational units could help here and also offer approaches for consolidation and harmonization projects, but this is only available in very few cases.
  • Misconception 5: Process mining provides an end-to-end view for businesses. The desire to have a complete view of all business processes and all work steps involved in a business process is understandable but requires multiple levels of process analysis. Particularly for purposes of documentation, testing efforts, and discussions of change, such scalability is useful and desirable, especially for integrated and heterogeneous domains, such as the links between logistics and finance. However, building such a representation is very complex and requires a good deal of transversal knowledge. For this reason, process mining rarely uses end-to-end models, but rather fragmented sub-processes.
  • Myth 6: Process Mining Supports Process Automation. Automation in the sense of eliminating functions or process steps that are no longer performed by the users of the dialog, but by the software itself, can certainly be measured by process mining approaches. However, the implementation and improvement of these processes ultimately fall within the knowledge of the consultant, especially since a clear coordination of the relevant departments of the company and their internal work processes is required here.

Reference models

In summary, more content-related aspects should be used to assess the suitability of specific process mining approaches. First of all, it is the benchmark analytical models for structuring process data and deriving business statements from it that define the quality benchmark. This includes, in particular, the availability of software-based target models as well as correct and comprehensive key figure systems that can look behind the scenes.

Moreover, it is the type of extraction, transformation and preparation of the technical database that determines the quality and accuracy of the evaluation options. A complete database does not always meet the cost/benefit requirements and requires some work and specialist knowledge to develop the desired informational value. Enriching the event log information with change histories, benchmarks or configuration information can be extremely useful here and significantly speed up knowledge acquisition.

Nevertheless, the necessities of finding good consultants and internal resources remain, and elaborate modeling efforts for customization must be made. As a tip for the initial deployment, it is advisable to have a clear direction in your Process Mining project. First, get an overview of using the process. Then take a deeper look at the existing content where there are very individual processes. However, it is crucial that you keep in mind the goal you have set. After all, the ultimate goal is to invest in effective solutions to problems, not in a trend.

Margie D. Carlisle