Process Mining — Identifying events name

Identifying the event from ERP traces

Process Mining, as is well known by the practitioners of this discipline, is mainly based on Data Mining techniques. This means that the process analyst (or the “miner” if we prefer this suggestive metaphor), should process a usually huge and raw amount of data, understanding how each detail of the process is represented in terms of data.

One of the common sources for the data used during process mining is the ERP System supporting the business operation, and one of the most widely used ERP application is SAP.

In this short post, I will highlight some common problems and decisions that the Miner will face understanding events information buried in the ERP data.

The main source of event data, in SAP, is the change documents archive. Change documents are a feature of SAP, common to all the functional areas of the application, that stores all the changes that are recorded on a given “document”. The “document” may be a Vendor Invoice, a Purchase Order, a Sales quotation, a Production Order, and so on.

Change Documents, are an excellent source of information because they record the User who performed the activity, the Transaction Code (TC represents the application function) that the user has invoked to perform the change, the Time when the activity occurred, and how the data were changed (storing the “before change” and “after change” values for each of the database fields updated during the activity.

Nice.

But let us start with some simple questions.

What activity was performed?

Each change document can include several updates of field values. Some examples may be the following, in the case of a Purchase Order approval process:

1. a release status flag was set;
2. the WBS element to which the cost is posted is changed;
3. the account code used for posting was changed from “400111002” to “402023001”
4. the delivery date is changed from March 11th to June 30;
5. the unit price was changed from 11.2 $ to 11.92 $.

We can follow two approaches:

1. we can consider each of the above change as an activity
2. we can try to bundle together some of the activities listed above in one single activity

Furthermore, each of the listed activities has a different meaning, and, perhaps, require a different level of authority to be performed.

Activity 1 can be classified as an approval step; this kind of activity implies a decision performed by the user.
Activities 2 and 3 are typical edits performed by the user. In many cases, these edits will be subject to a subsequent approval step.
Activity 5 is the typical kind of activity that is inspected by internal or external auditors. It is a contractual obligation change and a change that can have an impact on the balance sheet of the Company. This kind of activity usually has importance strongly dependent on the context (the process context) in which it is performed. Changing the price when a Purchase Order has not yet started the approval process may be just a matter of data entry error or evolving specifications of the goods purchased. Changing the price after the final release of the PO (usually this should be forbidden) is an activity that implies that the previous approvers haven’t seen the real total amount of the purchase order.

But we are going a little bit outside the scope of this post.

We have the problem of activity naming. Setting a correct name (= classifier) for each activity is a fundamental step toward the goal of effective process analysis.

Getting back to our example list, a possible approach could be the following:

• Activity 1 has the name of the approval underlying the status flag update (for example “Budget control office approval”).
• Activity 2 and 3 may have the same name: “Accounting edit”.
• Activity 4 may be named according to a more general classification (“Purchasing terms change”), or to a more detailed classification (“Delivery date change”). Furthermore, the activity name may also describe the kind of change performed: “Delivery date change.delay” or “Delivery date delay”.
• The same can be said for Activity 5: it could be a “Unit price change.increase” or “Unit price change.increase.up-to-15pct”

I hope that this simple example has illustrated some of the many modelling decisions that a process analyst should take (and share with the “client”) when he is approaching the data mining of process traces.