Process Mining – Why, what for, how? - Teil 2
Potential pitfalls – just to make you aware
Following this brief technical introduction, we can say that we are also a fan of process mining. That’s why we offer software to enable you to extract relevant data. We also prepare automated event logs for you.
You should, however, be aware of some potential pitfalls.
- You see only what you know (or model)
- Beware the spaghetti monster – too much insight, no action
- Screwdriver and nail – choosing the right tool for the job
Let me explain further:
You see only what you know (or model)
You may gain (or sometimes be deliberately given) the impression that you can, as if by magic, suddenly visualise all processes within your company “as is”, based on real data. This is not the case, however, and often leads to disillusionment.
As explained briefly above, the use of relevant tools requires the creation/modelling of an event log. This is then visualised, matter-of-factly, by the process mining software. By implication, however, this means that if I don't know certain data and do not incorporate them in the event log, they will not be visualised. For example, if you have a purchasing process that covers systems A, B and C but does not include the data from system B in the event log, these data (and all events, cases, etc.) will also be missing from the process graphs. Similarly, information may be missing or misrepresented if you rely on incorrect case IDs or if the attributes that define the events have been badly chosen. While a subsequent review of the process graphs may perhaps reveal consistency gaps in the data, this is by no means certain.
Process mining does not guarantee that all existing processes will be determined; process visualisation is only as good as the event log on which it is based.
Beware the spaghetti monster – too much insight, no action
People often require data analytics to bridge the gap “from insight to action” in order to achieve countable results and avoid becoming lost in the ether of data analytics.
With process mining, this is easy to illustrate using simple sample graphs:
From purchase order to invoice (PAF example)
However, things are generally complex here, too. With large companies, such graphs can in reality only be produced by reducing the number of available process variants accordingly via the options or the variant slider; i.e. by including only the relevant part of the paths rather than all occurring paths (e.g. 10% of the most relevant paths). If, on the other hand, you include all path variants that have occurred, you can quickly end up with something like this:
Spaghetti monster showing all paths
The graphic is taken from my colleague’s previously mentioned blog post. I could almost have saved myself the trouble of cooking the spaghetti.
As if matters were not already complex enough, the paths also hide business transactions, which can themselves be divided up into individual transactions (sub-process steps): A purchase transaction is divided into purchase order number 123, goods receipts A, B and C, invoice receipts X and Y, partial cancellation S and outgoing payment Z (whereby each of the letters stands for individual vouchers or documents, which you may wish to track in the system). However, these are often not immediately apparent, or despite being listed with the corresponding document numbers, sometimes have insufficient attributes to immediately identify reasons for processes that appear unusual and thus make it possible to define corresponding actions for improvement.
The findings from these complex visualisations with a sometimes difficult passage to the underlying individual transactions in the source system thus make understanding the results, deriving a concrete need for action and translating this into corresponding action a challenging task.
Directly deriving specific actions from a process graph can be a challenge, not to mention efficient identification of individual transactions.
Screwdriver and nail – choosing the right tool for the job
While process mining is ideally suited to visualising processes, it is difficult to impossible for it to eliminate all possible analytical issues per se. For example, one might think that process mining would make it easy to identify duplicate payments – you simply need to search for cases where one invoice has triggered two payments in the process. But that’s not how things work. Duplicate payments arise because invoices are posted in the system multiple times, and a separate payment is made for each invoice (or credit note) that has been posted more than once. Similarly, master data duplicates for customers or suppliers, fuzzy similarities for changes to bank details, etc. cannot be analysed, can hardly be analysed, or can only be analysed circuitously by means of process mining.
In such cases, traditional reports based on deterministic filters and transaction-based analytics are more suitable. Although the latter could for its part also be used to analyse process workflows by a roundabout route, this would present limits in terms of interpretation and visualisation. That’s why it's important to choose the right tool for the right job. Approaches are often complementary, as process mining and transaction-based analyses are generally very compatible. One example is internal audit or auditing. An effective approach here is to use process mining before an audit in order to gain an overview of the processes, and then use more focused transaction-based analyses to examine individual process areas. This makes sense when you consider that a skilled craftsman's toolbox also contains a selection of tools for different purposes.
While process mining is (logically) ideal for process-based questions, other analytical questions are better suited to transaction-based analyses. A combination of both approaches can be very effective.
Interim conclusion – do I really need process mining?
Having gained a basic technical understanding of event logs and discussed some potential pitfalls, critical readers may ask whether process mining is actually worth considering.
The answer is most definitely yes. Used in addition to transaction-based analyses, process mining offers you a complementary view of your data that focuses on your processes. Despite the potential pitfalls, the resulting transparency that can be achieved is unique and has become an integral part of data analytics as a whole. It is first necessary to recognise the importance of data acquisition and preparation, and not take it for granted. Secondly, you must always consider whether the questions that you wish to answer are suitable for process mining. Some aspects of audit, risk management, ICS or general reporting are better suited to other tools. Conversely, attempting to map process analyses in transaction-based tools will prove similarly unsuccessful. Thirdly, it is important to be clear at the outset about the objective behind the use of process mining: How to move from questions to defined actions?
Process mining today should be a standard feature of a company's data analytics portfolio. It will succeed if data capture and data preparation are correct, if the tool is the right one for the questions asked, and if the results are “actionable” enough.