Modern process-aware information systems store detailed information about processes as they are being executed. This kind of information can be used for very di erent purposes. The term process mining refers to the techniques and tools to extract knowledge (e.g., in the form of models) from this. Several key players in this area have developed sophisticated process mining tools, such as Aris PPM and the HP Business Cockpit, that are capable of using the information available to generate meaningful insights. What most of these commercial process mining tools have in common is that installation and maintenance of the systems requires enormous e ort, and deep knowledge of the underlying information system. Moreover, information systems log events in di erent ways. Therefore, the interface between process-aware information systems and process mining tools is far from trivial. It is vital to correctly map and interpret event logs recorded by the underlying information systems. Therefore, we propose a meta model for event logs. We give the requirements for the data that should be available, both informally and formally. Furthermore, we back our meta model up with an XML format called MXML and a tooling framework that is capable of reading MXML les. Although, the approach presented in this paper is very pragmatic, it can be seen as a rst step towards and ontological analysis of process mining data.
event refers to an activity (i.e., a well-de ned step in the process), (ii) each event refers to a case (i.e., a process instance), and (iii) events are totally ordered. Furthermore, all kinds of system-speci c data elements can be present in these event logs. This immediately shows one of the biggest challenges faced in the process mining research. Each information system has its own internal data structure, and its own language to describe the internal structure. When trying to use event logs from di erent system to do process mining, we need to be able to present the logs in a standardized way, i.e., there is a need for a good description of such a log. Furthermore, for each information system, a mapping has to be provided onto that description. In other words, we need a meta model for process mining. In this paper, we take a rst step towards such a process mining meta model.
Few of the meta models described in literature (e.g., [
In practice, the mapping of event logs from one system to the standard format
is a non-trivial task. It requires the mapping of one meta model onto another.
It can be seen as a form of ontological analysis in the spirit of [
The remainder of this paper is organized as follows. In Section 2, we introduce process-aware information systems and we provide a high-level classi cation thereof. Then, in Section 3, we introduce an XML format (MXML) for storing event logs. In Section 4, we introduce the process mining framework that can work with MXML les. In Section 5, we show an example of a mapping between the the meta model of a widely-used information system (Sta ware) to our meta model, and we show how this can be translated to a mapping of the log to MXML. In this section, we also provide an ontological analysis of the logging facilities of Sta ware. Section 6, we touch some of the issues related to these mappings for other information systems. Finally, we discuss related work and conclude the paper. 2
Process-aware information systems are widely used in practice (cf. ERP, WFM, CRM, PDM systems). At the basis of most of these systems lays a process model of some kind. However, the way systems enforce the handling of cases is di erent for all systems. On the one hand there are systems that enforce a given process description to all users, while some other systems only provide an easy way of handling access to les. As a result of this, information systems are used in very diverse organizations and with all kinds of expectations. Even though each system has its individual advantages and disadvantages, these systems can be divided in several groups. In Figure 1, we give four types of information systems, and position them with respect to the structure of the process that is dealt with and whether they are data or process driven. In Figure 2, we give the trade-o s that are made for each of these four types of systems with respect to exibility, support, performance and design e ort.
explicitly structured implicitly structured
ad-hoc structured case handling production workflow ad-hoc workflow unstructured groupware high low flexibility support performance design effort data-driven
process-driven
Production work ow systems such as for example Sta ware are typically used in organizations where processes are highly standardized, and volumes are big (i.e. a lot of cases are to be dealt with in parallel). These systems not only handle data, but enforce a certain process de nition to be followed by the letter. Case handling systems such as Flower on the other hand, are typically used in environments where people have a good understanding of the complete process. This allows these so-called \knowledge workers" to handle cases with more exibility. In the end however, the case handling system keeps structure in both the data involved and the steps required. Ad-hoc work ow systems such as InConcert allow for the users to deviate completely from given processes. Processes de nitions are still provided, but not enforced on an execution level. They merely serve as reference models. The nal category of systems, i.e. groupware is the most exible one. Systems such as Lotus Notes provide a structured way to store and retrieve data, but no processes are de ned at all.
Due to the fact that each information system serves a di erent purpose, and that they are used in very di erent organizations, it is obvious that there is a di erence in the internal data warehousing of those systems. In this paper, we are interested in the event logs that can be generated by process-aware information systems. Since the information in an event log highly depends on the internal data representation of each individual system, it is safe to assume that each system provides information in its own way. Therefore, we need to provide a standard for the information we need and mappings from each system to this standard. For this, we introduce MXML.
As we stated in the introduction, there is a minimal amount of information that needs to be present in order to do process mining. In this section, we rst give some requirements with respect to this information. From these requirements, we derive a meta model in terms of a UML class diagram. Then, we introduce a formal XML de nition for event logs, called MXML, to support this meta model. We conclude the section with an example of an MXML le. 3.1
All process-aware information systems have one thing in common, namely the process speci cation. For groupware systems, such a speci cation is nothing more than a unstructured set of possible activities, while for production work ows this speci cation is extremely detailed. For process mining, log les of such systems are needed as a starting point. First we give the requirements for the information needed.
To make the distinction between events that took place, and logged events, we will refer to the latter by audit trail entries from here on. When events are logged in some information system, we need them to meet the following requirements in order to be useful in the context of process mining: 1. Each audit trail entry should be an event that happened at a given point in time. It should not refer to a period of time. For example, starting to work on some work-item in a work ow system would be an event, as well as nishing the work-item. The process of working on the work-item itself is not. 2. Each audit trail entry should refer to one activity only, and activities should be uniquely identi able. 3. Each audit trail entry should contain a description of the event that happened with respect to the activity. For example, the activity was started or completed. 4. Each audit trail entry should refer to a speci c process instance (case).
We need to know, for example, for which invoice the payment activity was started. 5. Each process instance should belong to a speci c process.
Using the requirements given above, we are able to make a meta model of the information that should be provided for process mining. 3.2
From the requirements given in the previous section, we derive the UML class diagram of Figure 3. Note that we use the term \Work ow Model Element" instead of activity, and \Work ow log" instead of event log. This is done for historic reasons. assign 1..*
As we stated in the requirements, each audit trail entry contains a description of the event that generated it. In order to be able to talk about these events in a standardized way, we developed a transactional model that shows the events that we assume can appear in a log. This model is based on analyzing the di erent types of logs in real-life systems (e.g., Sta ware, SAP, FLOWer, etc.) Figure 4 shows this transactional model.
When an activity (or Work ow Model Element) is created, it is either \scheduled" or skipped automatically (\autoskip"). Scheduling an activity means that the control over that activity is put into the information system. The information system can now \assign" this activity to a certain person or group of persons. It is possible to \reassign" an assigned activity to another person or group of persons. This can be done by the system, or by a user. A user can \start" working on an activity that was assigned to him, or some user can decide to \withdraw" the activity or skip it manually (\manualskip"), which can even happen before the activity was assigned. The main di erence between a withdrawal and a manual skip is the fact that after the manual skip the activity has been executed correctly, while after a withdrawal it is not. The user that started an activity can \suspend" and \resume" the activity several times, but in the end he or she either has to \complete" or abort (\ate abort") it. Note the activity can get aborted (\pi abort") during its entire life cycle. Since we cannot claim that we have captured all possible behavior of all systems, we will have to allow for user de ned events in the MXML format. 3.3
Using the meta model of Figure 3, we can easily derive an XML format for storing event logs. In Figure 5 a schema de nition is given for the format that is used by our process mining framework ProM.
Most of the elements in the XML schema can be found in the meta model and they speak for themselves. There are however two exceptions. First, there is the \Data" element. This element allows for storing arbitrary textual data, and contains a list of \Attribute" elements. On every level, it can be used to store information about the environment in which the log was created. Second, there is the \Source" element. This element can be used to store information about the information system this log originated from. It can in itself contain a data element, to store information about the information system. It can for example be used to store con guration settings. 3.4
We conclude the section about the MXML format with an example of an XML log le. This example log is the
rst part of a translation of a Sta ware log to the MXML format (without the standard headers). In Section 5, we introduce this translation in more detail. It shows two audit trail entries in a complaints handling process.
<Source program="staffware"> <Data>
<Attribute name="version">7.0</Attribute> </Data> </Source> <Process id="main_process"> <Data>
<Attribute name="description">complaints handling</Attribute>
</Data>
<ProcessInstance id="Case 1">
<AuditTrailEntry>
<WorkflowModelElement>Case start</WorkflowModelElement>
<EventType unknowntype="case_event">unknown</EventType>
<Timestamp>2002-04-16T11:06:00.000+01:00</Timestamp>
</AuditTrailEntry>
<AuditTrailEntry>
<WorkflowModelElement>Register complaint</WorkflowModelElement>
<EventType>schedule</EventType>
<Timestamp>2002-04-16T11:16:00.000+01:00</Timestamp>
<originator>jvluin@staffw</originator>
</AuditTrailEntry>
up by a good tool. For this, the ProM framework [
The ProM framework can read log les in the MXML format. Through the
Import plug-ins a wide variety of models can be loaded ranging from a Petri net to
LTL formulas. The Mining plug-ins do the actual mining and the result is stored
as a Frame. These frames can be used for visualization, e.g., displaying a Petri
net [
Using the ProM framework, we have seen promising results with respect to the applicability of process mining in real business environments. In the next section, we present a small case study thereof. 5
In this section, we show that it is possible to actually extract MXML log les from commercial systems, since this greatly improves the practical applicability of the ProM framework. As a case study, we show that this is possible for a commercial work ow system called TIBCO Sta ware Process Suite (in short Sta ware). Through this example, we show why we call our model from Figure 3 a meta-model. We consider the data model used by Sta ware as an instantiation of the meta-model. Then, the Sta ware log le should be seen as an instantiation of the Sta ware data model. By studying the mapping between the Sta ware data model and our meta-model in Section 5.2 we give a translation from the Sta ware log le to the MXML le. 5.1
In Table 2, we show an example of a Sta ware log le. It consists of one complete case of a complaint handling process and a second, incomplete case of the same process. 5.2
In order to map Sta ware logs to MXML, we st need to map the internal data model of Sta ware onto our model from Figure 3. In Figure 6, we show the Sta ware data model, and we show how the mapping should be done.
When this mapping is available, it is almost trivial to map log les to MXML. Each audit in Sta ware, contains the logs of only one procedure (or process) of which each audit trail is described separately. These audit trails can easily be 1 For more information about ProM, we refer to http://www.processmining.org.
Case 1 Diractive Description Event User yyyy/mm/dd hh:mm --------------------------------------------------------------------
Start jvluin@staffw 2002/04/16 11:06 Register complaint Processed To jvluin@staffw 2002/04/16 11:16 Register complaint Released By jvluin@staffw 2002/04/16 11:26 Evaluate complaint Processed To jvluin@staffw 2002/04/16 11:36 Evaluate complaint Released By jvluin@staffw 2002/04/16 11:46
Terminated 2002/04/16 11:56 Case 2 Diractive Description Event User yyyy/mm/dd hh:mm --------------------------------------------------------------------
Start jvluin@staffw 2002/04/16 12:36 Register complaint Processed To jvluin@staffw 2002/04/16 12:46 Register complaint Expired jvluin@staffw 2002/04/17 13:07 Register complaint Withdrawn jvluin@staffw 2002/04/17 13:07 mapped onto \process instances". Each line of text in the audit le of Table 2 contains four columns. The
rst column can be mapped onto the \work ow model element", since they refer to manual steps of which the process is composed. The third and fourth column are obviously mapped onto the \originator" and \timestamp" respectively. In Table 3, we show the mapping for the events that can appear in the second column of Table 2 and what to do with the beginning of a case and the end of a case, i.e. the \Start" and \Terminated" events respectively. The beginning and end of a case are special situations, since they are lines of text without an associated manual step. Therefore, we have to create virtual manual steps.
Terminated
\case start"
as in 2nd column
as in 2nd column
as in 2nd column
as in 2nd column
\case end"
unknown: case event
schedule
complete
unknown: expire
withdrawn
unknown: case event
In the spirit of [
In Section 3.1, we gave ve requirements for log les in order for them to be useful for process mining. In this section, we discuss whether these requirements are met for Sta ware, taking the mapping we established and the ontological analysis into account. 1. Each audit trail entry refers to a speci c point in time. In the Sta ware log, each line is an audit trail entry and since each line has a timestamp, this requirement is met. 2. Each audit trail entry refers to one activity. In the Sta ware log, the activities are described by the rst column. However, there are two problems. First of all, the start and termination of a case does not have an activity-name. Second, we cannot conclude that the activity names are unique. In fact it is possible to have multiple activities in the de nition of a Sta ware process with the same label. To still meet this requirement, we assume the start and end of a case to belong to a ctive manual step. Furthermore, we just assume that activities are uniquely identi ed by their labels. 3. The second column contains a reference to the event that actually happened, so this requirement is met. 4. The audit trail entries are sorted per case, so this requirement is met. 5. The cases all belong to the same process, since a Sta ware log le always contains at most one procedure. Therefore, the last requirement is met as well.
In this section we have shown that it is possible to make mappings from log les of commercial systems to MXML. Due to space limitations, we cannot show the complete result of the translation. However, Table 1 shows a part of the converted log le.
In Section 5, we have shown that it is possible to map Sta ware logs onto MXML. It may be clear that our goal is to come up with such mappings for as many information systems as possible. So far, we have discovered that for most production work ow system, making these mappings is almost trivial. However, for systems that are more data driven than process driven, these mappings become extremely di cult. For example, information systems like SAP R/3 and Peoplesoft are capable of logging almost anything on a database level. However, it has proven to be impossible to discover the case (process instance) to which an event belongs from the event log.
Obviously, the internal data structures of complex information systems like SAP and Peoplesoft have to be able to link database transactions to cases. However, usually, the way these are linked is implementation and release speci c, which makes it almost impossible to derive generic results. On an implementationspeci c level however, we have seen promising results in both SAP and Peoplesoft.
Another issue that needs to be addressed is the situation where not one system is providing the event logs, but logs are taken from multiple legacy systems. This of course requires even more bookkeeping and makes it even harder to restore relations between events, cases, etc. However, data warehousing techniques may ease the burden. 7
The MXML format presented in this paper is not the only attempt to give
a formalization of data models for event logging. Several papers focus on the
use of meta models in the context of process-aware information systems [
We would like to discuss two related approaches in more detail. The rst is an attempt by the Work ow Management Coalition (WFMC) to standardize the communication between work ow engines and administration and monitoring tools. The second is the tool Aris PPM (Process Performance Monitor), developed by IDS Scheer. 7.1
In the area of work ow management, the Work ow Management Coalition has
developed a reference model for communication between the core of a work ow
system, i.e. the Work ow Engine, and several supporting tools. For this, ve
interfaces have been developed, of which Interface 5 is of most interest to us.
It is de ned as the interface for communication between the work ow engine
and administration and monitoring tools. Unfortunately, a good standard for
this interface has never been developed. A meta model for this interface was
proposed recently in Section 4, page 175 of [
Typically, Aris PPM communicates with systems like Sta ware and SAP R/3 using a number of custom-made adapters. These adapters, unfortunately, can only create instance EPCs if the actual process is known. As a result, it is very time consuming to build adapters. Moreover, the approaches used only work in environments where there are explicit process models available. 8
In this paper, we introduced a standard for storing event logs generated by process-aware information systems. For this, we provide requirements, a data model and an XML format called MXML. Furthermore, we have shown an example of a mapping from an event log of a commercial work ow system to MXML. In Section 4, we introduced the process mining framework ProM. This framework accepts event logs in the MXML format and it enables researchers to implement new process mining techniques and bene t from each others ideas, without having to care about the information system the event logs were generated by. Furthermore, by mapping event logs from commercial information systems to MXML, the applicability of process mining in business environments greatly improves. However, to establish mappings from the log formats of di erent information systems to the MXML format, an in-depth evaluation of a large enough number of these systems is needed. We thank INTEROP for supporting this work that has been conducted in the context of the INTEROP work package \Domain Ontologies for Interoperability". More speci cally, the paper touches the issue of how to deal with multiple data-models (and accompanying ontologies) of logs of information systems, which ts into Subtask 2 of the work package. Furthermore, especially the mapping presented deals with issues stated in Subtask 3 of the work package, i.e. semantic mapping of ontologies and data models. Since the work is inspired by a practical problem, it can be used as a starting point for further work in Subtask 4, i.e., the investigation of the e ectiveness of the use of ontologies for interoperability. As indicated, an evaluation of a more systems (FLOWer, FileNet, IBM Websphere, etc.) is planned in the context of this subtask.