has been published in [Lu15]. 1 d.fahland@tue.nl, Eindhoven University of Technology, The Netherlands 2 KPMG IT Advisory N.V., Eindhoven, The Netherlands 3 This article summarizes problem, approach, and selected findings of a study published as Xixi Lu, Marijn Nagelkerke, Dennis van de Wiel, and Dirk Fahland. Discovering Interacting Artifacts from ERP Systems. Services Computing, IEEE Transactions on, 8(6), 2015 doi:10.1109/TSC.2015.2474358 [Lu15].
Discovery 1 Introduction and Problem Description Information systems (IS) not only store and process data in an organization but also record event data about how and when information changed. This “historical event data” can be used to analyze, for instance, whether information processing in the past conformed to the prescribed processes or to compliance requirements. Process mining [Aa11] offers automated techniques for this task. In particular exploring visual models discovered from event data allows to identify unusual flows and their circumstances; based on which concrete measures for process improvement can be devised [Ec15]. Prerequisite to this analysis is a process event log that holds events about information changes with the assumption that each event belong to one specific execution of a specific process.
In general, information access is not tied to a particular process execution; rather the same information can be accessed and changed from various processes and applications. For
Sales documents (SD) SD id Date created Reference id Document type Value Last change S1 16-5-2020 null Sales Order 100 10-6-2020 S2 17-5-2020 null Sales Order 200 31-5-2020 S3 10-6-2020 S1 Return Order 10 NULL
F1
F4
Documents Changes Change id Date changed Reference id Table name Change type Old Value New Value 1 17-5-2020 S1 SD Price updated 100 80 2 19-5-2020 S1 SD Delivery block released X 3 19-5-2020 S1 SD Billing block released X 4 10-6-2020 B1 BD Invoice date updated 20-6-2020 21-6-2020 (a) (Sales Order) (Delivery) Divergence 7 events “Created” related to S1 (Invoice) (Delivery) (Return Order) (Invoice) (Return Delivery) (b)
Delivery documents (DD) DD id Date created Reference SD id Reference BD Document type Picking date D1 18-5-2020 S1 B1 Delivery 31-5-2020 D2 22-5-2020 S1 B2 Delivery 5-6-2020 D3 25-5-2020 S2 B2 Delivery 5-6-2020 D4 12-6-2020 S3 null Return Delivery NULL
F3
Billing documents (BD) BD id Date created Document type Clearing date B1 20-5-2020 Invoice 31-5-2020 B2 24-5-2020 Invoice 5-6-2020
Parent table
Child table Sales order created 1 Sales order
2 Return 1 dReelitvuerrny 1 Dcreelia3vteerdy 2 cInreva3otieced 1 corerad1teerd crea1ted (c)
2
Delivery Sales order 2 created
3 crea2ted Return order 1 created 1 2 1 1 Invoice Legend: created artifact
2 Event type Retucrrnead1teelidvery CoariunDistneeatvrleiararecattlicanitotginioonn instance, in Enterprise Resource Planning (ERP) systems (such as SAP and Oracle Enterprise), information is stored in business objects (or documents) which are linked via one-to-many and many-to-many relations, typically in the relational database. The objects themselves are encapsulated in services [AMZ00] which are invoked by high-level endto-end business processes; each invocation is called a transactions which is logged in the data object itself.
When applying classical process mining techniques, one first has to extract an event log based on a single case identifier to which all event data can be related. Choosing SD id in Fig. 1 leads to the two sequences of events shown in Fig. 2(a). Process discovery on this log yields the model of Fig. 2(b) which is wrong: two invoices are created before their deliveries instead of one, and three invoices are created instead of two (known as divergence and convergence, respectively) [Pi11]. 2
Approach: Discovering Artifact-Centric Models We propose to approach the problem under the “conceptual lens” of artifact-centric models [CH09]. An artifact is a data object over an information model; each artifact instance exposes services that allow changing its informational contents; a life-cycle model governs when which service of the artifact can be invoked; the invocation of a service in one artifact may trigger the invocation of another service in another artifact. Information models of different artifacts can be in one-to-many and many-to-many relations allowing to describe behavior over complex data in terms of multiple objects interacting via service invocations. Under this lens, each document of an ERP system can be seen as an artifact; a transaction on a document is a service call on the artifact; behavioral dependencies between transactions of documents can be seen as life-cycle behavior and dependencies of service calls. Describing the transactional data of Fig. 1 with artifact-centric concepts yields the model of Fig. 2(c); it visualizes the order in which objects are created and also highlights the unusual flow of invoice B2 being created before delivery D2. The problem of discovering an artifact-centric process model from relational ERP data de- SDouartcae SDcahteambaase composes into two sub-problems. (1) Given a relational data source, identify a set of artifacts, extract for each artifact an event log, and dis- 1.1 Discover cover a model of its life-cycle. (2) Given a set 2.1 Discover ArtTifyapcet of artifacts and their data source, identify inter- Type-Level actions between the artifacts, between their in- Interaction stances, between their event types and between 1.2 Extract 2r.2efAerdednccaesse their events. Figure 3 shows the overview of our approach. (1.1) We use the data schema of CCaassee AA12 CCaassee BB21 CCaassee CC12 the data source to discover artifact types which Case An Case Bm Case Ck tdiectualialralblutsimineesstsa mobpjeedctc.o(l1u.m2)nsForerlaetaecdhtoaratipfaacr-t 1.3 Discover 2.3 Discover EvLeongt we then extract a classical event log [Aa11], each case describes all events related to one instance of the artifact. (1.3) Existing process discovery algorithms allow discovering a lifecycle model of the artifact. In parallel, (2.1) LMifoed-Ceylsc.l.e. + Activity-Level Interactions we discover interactions between artifacts from foreign key relations in the data source; (2.2) Fig. 3: An overview on our approach. during log extraction, each case of an artifact is annotated with references to cases of other artifacts this case interacts with. (2.3) The case references are refined into interactions between activities of different artifact life-cycles. We implemented our approach based on [NvDF12] and conducted two case studies. By separating data into artifacts along one-to-many relations, we eliminated divergence and convergence, the interaction flows discovered from one-to-many relations were meaningful to business users, and unusual flows were detected. [Aa11] Aalst, W.M.P. van der: Process Mining: Discovery, Conformance and Enhancement of Business Processes. Springer, 2011. [AMZ00] Al-Mashari, Majed; Zairi, Mohamed: Supply-chain re-engineering using enterprise resource planning (ERP) systems: an analysis of a SAP R/3 implementation case. IJPDLM, 30(3/4):296–313, 2000. [CH09] [Ec15] [Lu15]