Order to cash (OTC or O2C) business process which is a very typical business process that involves receiving and fulfilling customer requests for goods or services. The term is most prominent in the design and improvement of Enterprise Resource Planning (ERP) systems such as SAP, Oracle and NetSuite.Download case study
The starting point of checking conformance is that we have logs and reference models. The logs are extracted data generated by our information systems while the reference model could be a designed model which is consistent with the scenario indicated by the information system. Next, we check the conformance in the OTC scenario of the Dolibarr ERP system. The logs are generated by the Dolibarr ERP system in the OTC scenario. Accordingly, we design an OCBC model to represent the normal business process of this scenario as follows.
The model indicates constraints both on behavioral and data perspectives. For instance, as we can see in the model, there is a response constraint from "create_order" activity to "create_shipment" activity which means each "create_order" event should be eventually followed by one or more "create_shipment" events.
We injected three types of deivations as follows:
1. Deviations on the behavioral perspective. Like other modeling language such as Petri nets, OCBC models support checking conformance on the behavioral perspective. In the normal scenario, each “create invoice” event is followed by at least one “create payment” event, indicated by the constraint c2 in Figure 2. In the experiment, we add a deviation violating c2, i.e., an “create invoice” event (i.e., “ci204” in Figure 3) is never followed by corresponding “create payment” events.
2. Deviations on the data perspective. A challenge for detecting behavioral deviations is that how to detect implicit deviations. For instance, a “create order” event has corresponding “create shipment” events but does not have sufficient ones, i.e., order lines created by the “create order” event are not totally shipped to the corresponding customer. This implicit deviation is indeed violating our scenario but satisfying the behavioral constraint (i.e., c6, which requires a one-to-many relation between “create order” events and “create shipment” events). Since OCBC models have a data perspective, it is possible to transform such implicit behavioral deviations onto the data perspective. For example, the deviation mentioned above can be interpreted as some order lines have no corresponding shipment lines, and be detected through checking the cardinality constraints on the class relationship r9. In the experiment, we add a deviating “order line” object order line734 (i.e., “ol734” in Figure 3) which has no corresponding “shipment line” objects.
3. Deviations related to the interactions between two perspectives. In the Dolibarr system, when an invoice is created, it is normally linked to one or more existing orders. As a result, one or more element relations (showing the correspondence between the invoice and the orders) are created when a “create invoice” event happens, indicated by the cardinality “1..*” of the AOC relation 3 . In reality, a possible deviating situation is that one forgets to link one invoice to any orders. In our experiment, we mimic this situation, i.e., create an invoice (i.e., “ci205” in Figure 3) without any element relations, resulting in a deviation violating the constraints (i.e., “1..*” of 3 ) on the interactions of two perspectives.
After loading the XOC event log with deviations (extracted from Dolibarr) and the OCBC model (designed based on the scenario) into ProM, we check the conformance to see if the inserted deviations can be picked up. In our experiments, the injected deviations mentioned above can be totally detected and displayed clearly in three views (model view, log view and type view). The model view shows the diagnosis result on n a high and straightforward level, by highlighting the violated constraints and cardinalities in the model. In summary, there are six constraints are violated and highlighted in red, which corresponds to the injected deviations. After obtaining a general idea about the deviations on a high level, we can use the log view to see the deviating instances and use the type view to trace the details classified in problem types.
We give the involved dataset (reference model, deviating log) next.Download dataset