2013 17th IEEE International Enterprise Distributed Object Computing Conference Workshops 2013
DOI: 10.1109/edocw.2013.13
|View full text |Cite
|
Sign up to set email alerts
|

A Practical Approach to Automated Business Process Discovery

Abstract: Process mining has been studied for many years but has not been so widely adopted in real business practices. In this study, we propose a practical approach to process mining. This approach has three characteristics. Firstly, we make use of transaction databases of business systems that don't necessarily have an identifier throughout a process instance, rather than workflow logs. Secondly, we visualize and analyze what really happened without model inference. Thirdly, we also analyze exceptional processes as w… Show more

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
1
1
1

Citation Types

0
3
0

Year Published

2015
2015
2020
2020

Publication Types

Select...
3
2
1

Relationship

0
6

Authors

Journals

citations
Cited by 6 publications
(3 citation statements)
references
References 18 publications
0
3
0
Order By: Relevance
“…Manually approaches to extracting data from relational databases of SAP systems particularly failed to separate events related to various processes; analyzing what was part of the process was hard and time consuming [21,22]. In the generic log extraction approach of [5], the user defines a mapping from from tables and columns to log concepts such as traces, events, and attributes (assuming the existence of a single case identifier to which all events can be related); various works exist to improve finding optimal case identifiers and relations between the identifiers and events [6,7,23]. If the event data is structured along multiple case identifiers as in ERP systems, all these approaches suffers from data convergence and divergence (Sect.…”
Section: Example B -Tables As Artifact Typesmentioning
confidence: 99%
“…Manually approaches to extracting data from relational databases of SAP systems particularly failed to separate events related to various processes; analyzing what was part of the process was hard and time consuming [21,22]. In the generic log extraction approach of [5], the user defines a mapping from from tables and columns to log concepts such as traces, events, and attributes (assuming the existence of a single case identifier to which all events can be related); various works exist to improve finding optimal case identifiers and relations between the identifiers and events [6,7,23]. If the event data is structured along multiple case identifiers as in ERP systems, all these approaches suffers from data convergence and divergence (Sect.…”
Section: Example B -Tables As Artifact Typesmentioning
confidence: 99%
“…Events correspond to updates of the database, i.e., changes of the "state" of the information system. These updates may have been stored in tables of the databases (through in-table versioning like the change tables in SAP or any table that contains dates or timestamps) or can be retrieved using some database log (like redo logs [37,28] explicitly storing all database updates).…”
Section: Introductionmentioning
confidence: 99%
“…Other tools/IEs can access the modeling artifacts through the APIs. For example, data from the business process flow are provided to the BPM monitoring tool for monitoring the execution of business processes [15].…”
Section: ) Toole Integration Through Bpm-ie Apismentioning
confidence: 99%