Process Mining is highly popular. Because customers want to learn about their business. In detail.

Unfortunately, this high level of customer interest has lured vendors into taking technical shortcuts which are questionable at least.

The typical approach in process mining is to look out for so-called event logs.

“Event logs: To be able to apply process mining techniques it is essential to extract event logs from data sources (e.g., databases, transaction logs, audit trails, etc.).” (http://www.processmining.org/logs/start)

In case of technical systems such as database or transaction management systems event logs are the basis for ensuring their transactional integrity.

“Examples from double-entry accounting systems often illustrate the concept of transactions. In double-entry accounting every debit requires the recording of an associated credit. If one writes a check for $100 to buy groceries, a transactional double-entry accounting system must record the following two entries to cover the single transaction: 1. Debit $100 to Groceries Expense Account 2. Credit $100 to Checking Account A transactional system would make both entries pass or both entries would fail. By treating the recording of multiple entries as an atomic transactional unit of work the system maintains the integrity of the data recorded. In other words, nobody ends up with a situation in which a debit is recorded but no associated credit is recorded, or vice versa.” (https://en.wikipedia.org/wiki/Database_transaction)

The transactional integrity can only be preserved if and only if the respective event log is 100% accurate and complete. Hence event logs in transactional systems are highly reliable for subsequent process mining as for example performed by Splunk.

In case of business systems like SAP ERP such accurate and complete event logs don’t exist. Because the functioning of the business system doesn’t depend on event logs; i.e. business systems work even without any event logs. In case of SAP this becomes very clear by looking for the so-called “document flow” tables. There are many processes in SAP which are not covered by document flow tables at all.

Since such document flow tables exist because of the graciousness of the developers. If they program the provisioning of the document flow table, the respective event entries would exist and otherwise not. Even worse this applies not only to the SAP developers but also to all who are developing custom code for SAP. They have to be “gracious” – or disciplined – as well in order to ensure that all events are properly recorded.

These fundamental shortcomings apply also to the most popular document flow table VBFA (sales document flow). There is no guarantee that the VBFA is accurate and complete. The opposite is true: just google for “VBFA issues” to get an impression yourself.

Not a good situation if you want to govern your processes for compliance, fraud and risk for example.

So far so bad.

But it gets even worse:

  • Business system event logs (e.g. document flows) are not guaranteed to be accurate and complete.
  • Business system event logs (e.g. document flows) are not end-to-end (they cover only sub-sections of the cash-to-cash conversion cycle).
  • Business system event logs (e.g. document flows) do not span multiple ERP systems (it is quite common that business processes start in one SAP ERP system and terminate in a different SAP ERP system).

All in all relying on event logs seems to be a dead-end street for comprehensive process mining.

At Trufa we have taken a different approach. For example, we don’t make use of SAP VBFA at all. We are going back to the primary business documents (postings, “Belege”) and reconstruct the business processes from there.

In consequence

  • With Trufa reconstructed business processes are accurate and complete
  • With Trufa reconstructed business processes are end-to-end
  • With Trufa reconstructed business processes span multiple ERP systems

We believe these are the table stakes for process mining.

How does your vendor stack up?