Previous Chapter
Chapter 14: Toward Semantics-Based Service Composition in Transport Logistics (4/4)
395
Chapter 15
Ontology-Driven Business
Process Intelligence
Jon Espen Ingvaldsen
Norwegian University of Science and Technology, Trondheim, Norway
Contents
15.1 Introduction .............................................................................................396
15.2 Example Data: Wells Bank .......................................................................397
15.3 Architecture ............................................................................................ 400
15.4 Process Analysis Approach .......................................................................402
15.4.1 Dening Datasets .........................................................................405
15.4.1.1 Free Text Search .............................................................405
15.4.1.2 Date Interval.................................................................. 406
15.4.1.3 Search Sequences ............................................................407
15.4.2 Group Highlighting ..................................................................... 409
15.4.3 Analysis Modules ..........................................................................411
15.4.3.1 Multiperspective Control Flow Models ...........................411
15.4.3.2 Evolution Charts.............................................................416
15.4.3.3 Data Mining Characteristics ...........................................417
15.5 Related Work ...........................................................................................421
15.5.1 Semantics ......................................................................................421
15.5.2 “Spaghettiness” .............................................................................421
15.5.3 Rule Extraction ............................................................................ 422
396 ◾ Jon Espen Ingvaldsen
15.1 Introduction
Many companies have adopted enterprise resource planning (ERP) systems that
support their business processes. ERP systems have rich functionality for support-
ing the operational sides of companies. Although leading vendors of ERP systems
have incorporated analytical modules and data warehousing into their platforms,
it is not easy to validate the quality of supported business processes. According to
Casati and Shan (2002), a key problem for process analysis technologies is the dif-
culty of gaining business insights. e extracted reports are presented at a very
low level of abstraction and do not support any kind of business level analysis.
Another issue is the lack of explorative capabilities in existing analysis environ-
ments. Traditional business intelligence and data warehousing solutions tend to rely
on predened and mostly template-driven reports designed by data warehousing
professionals. Report readers cannot easily modify them (Evelson and Brown 2008;
Watson et al. 2001). e ability to perform explorative data analysis is bounded by
the functionality of a report and the data it is dened to gather.
ERP and other process-aware information systems log events related to actual
business process executions. Proper analysis of event logs can provide valuable and
important knowledge, and help organizations improve the quality of their services.
Business process intelligence (BPI) is a process-centric approach that can answer
many questions related to the quality and nature of business process executions.
BPI relates to “a set of integrated tools that supports business and IT users in man-
aging process execution quality” (Grigori et al. 2004) and refers to applications of
various measurement and analysis techniques. Process mining, statistical analysis,
and data mining are all techniques that can be applied as parts of BPI solutions
and projects. Process mining allows discovery of real business ow models from
event log structures. Statistical analysis enables investigations of quantitative pro-
cess measures and performance indicators, while data mining can be used to reveal
hidden and underlying patterns related to historic business process executions.
e main challenges related to BPI include harmonization of data from mul-
tiple sources and turning detailed and system-technical event log structures into
meaningful process information. Ontologies can be applied in BPI to provide a
shared understanding and accurate representation of domain concepts. Event logs
enriched with ontological annotations and signicant context information struc-
tures also have potential for utilizing search technologies.
In this chapter, we will present an iterative process analysis approach based on
search technology and ontologies and implemented in the Enterprise Visualization
Suite (EVS) BPI system. is approach utilizes ontologies for harmonization,
15.6 Discussion ............................................................................................... 423
15.7 Conclusions ..............................................................................................424
Acknowledgments .............................................................................................425
References .........................................................................................................425
Ontology-Driven Business Process Intelligence ◾ 397
analysis, and presentation of business process aspects. roughout the chapter we
will focus on the importance of ontologies in the process analysis approach and
demonstrate how ontologies and searches are fundamental for structuring process
mining models and analysis perspectives, and providing an explorative analysis
environment. We will use an event log from a call center at a banking company
(Wells Bank) as example data to describe the approach and functionality in EVS.
ese data stem from a call center system in a real bank, but data and ontol-
ogy structures were modied to keep the original organization and its employees
anonymous.
In Section 15.2, we describe the call center process at Wells Bank and the event
log used for examples throughout this chapter. Section 15.3 describes the construc-
tion of EVS and its modules. e analysis approach (EVS BPI Cycle) is described in
Section 15.4. We will describe each analysis phase with examples and results from
Wells Bank. Section 15.5 presents related work. A discussion on how to use BPI
results and the importance of ontologies are covered in Section 15.6, followed by
conclusions in Section 15.7.
15.2 Example Data: Wells Bank
e event log we use gathers information from events executed by an automated
voice recognition unit (VRU) and human operators. An incoming call is rst
handled by the VRU that routes the call further to a human operator via auto-
mated steps carried out by a VRU server. e employees at this call center have
dierent skills and serve dierent functions. For example, not all employees have
competence to serve English speaking customers or assist the stock trading group.
e event log is stored in Semantically Annotated Mining eXtensible Markup
Language (SA-MXML) and annotated with concepts from two external ontolo-
gies. One ontology describes aggregation between concepts related to the activities
found in the event log, while the other describes the organizational hierarchy from
employees, to groups, to higher organizational units.
MXML is the event log format used by the open source process mining frame-
work ProM. SA-MXML is an extended version of MXML that incorporates onto-
logical concept annotations on event log elements. e ontology structures in
SA-MXML are provided in external Web Service Modeling Language (WSML)
les. WSML is a formal language that provides a framework of dierent language
variants to describe semantic web services. It is a frame-based language with an
intuitive human readable syntax and XML, RDF exchange syntaxes, and a map-
ping to Web Ontology Language (OWL; Lausen et al. 2005).
e event log used for examples in this chapter describes operations carried out
in the rst week of January 2009. A fraction of this event log is shown below. We
can see how the workow model elements and originator elements are annotated
with ontological concepts.
398 ◾ Jon Espen Ingvaldsen
<ProcessInstance id=”33139” description=”Handle Customer Call”>
<Data>
<Attribute name=”Process_ID”>33139</Attribute>
</Data>
<AuditTrailEntry>
<Data>
<Attribute name=”VRU Output”>NC</
Attribute> </Data>
<WorkflowModelElement modelReference=
“file://CallCentreTasks.wsml#VRU”>VRU
</WorkflowModelElement>
<EventType>start</EventType>
<Timestamp>2009-01-01T11:23:55.000+11:00</
Timestamp>
<Originator modelReference=
“file://CallCentreOriginator.wsml#VRU_Server”>VRU_Server
</Originator>
</AuditTrailEntry>
<AuditTrailEntry>
<Data>
<Attribute name=”VRU Output”>NC</Attribute>
</Data>
<WorkflowModelElement modelReference=
“file://CallCentreTasks.wsml#VRU”>VRU
</WorkflowModelElement>
<EventType>complete</EventType>
<Timestamp>2009-01-01T11:24:04.000+11:00</
Timestamp>
<Originator modelReference=
“file://CallCentreOriginator.wsml#VRU_Server”>VRU_Server
</Originator>
</AuditTrailEntry>
<AuditTrailEntry>
<Data>
<Attribute name=”VRU Output”>NC</Attribute>
</Data>
<WorkflowModelElement modelReference=
“file://CallCentreTasks.wsml#New_Customer”>New_Customer
</WorkflowModelElement>
<EventType>start</EventType>
<Timestamp>2009-01-01T11:24:05.000+11:00</
Timestamp>
<Originator modelReference=
“file://CallCentreOriginator.wsml#Michael”>Michael
</Originator>
</AuditTrailEntry>
<AuditTrialEntry> …
Ontology-Driven Business Process Intelligence ◾ 399
Every tag in our event log is a semantically dened class in an underlying ontology
(Van Dongen and Van der Aalst 2005; Aalst 2008), and the log data form instances of
these classes. e process instance elements are the core building blocks in MXML for
describing sequences of related events. e name of an event in MXML is audit trail
entry. Such elements gather information about the activity carried out (work ow model
element), event type, time stamp showing when the event occurred, and user (originator)
executing the event. e data tag is used to add information about the event context.
e fraction from the MXML le shows one instance of the process Handle
Customer Call and its rst three events. e events describe the start and completion of
the automated steps in the process and the start of a new customer registration. As we
can see, the rst two events are executed by the VRU server, and the VRU completion
nishes 9 seconds after the VRU starts. e third event is executed by an employee
named Michael. He picks up the phone 1 second after the VRU operation nishes and
he starts serving the customer. e service is a registration of a new customer.
Both the WorkowModelElement and the Originator are annotated with a con-
cept in an external ontology. In our example, the VRU WorkowModelElement is
annotated with the ontological concept VRU found in the CallCentreTasks.wsml
le. e New Customer WorkowModelElement and all originators are annotated
similarly. To each AuditTrailEntry in this example, an attribute is added under a
data tag to provide additional information about the output from the VRU. Based
on automated phone interactions with customers, the VRU decides the service to
which the customer should be forwarded. e VRU Output attribute contains the
value of this routing decision (NC = new customer, ST = stock trading, RS = regular
service, and SE = service in English). When MXML is parsed in EVS, such data
attributes are also treated as categorical and ontological information. Based on the
MXML le and the two ontology les, the process mining algorithms can extract
knowledge about the process ows and relate these ows to dierent ontological
concepts and aggregation levels.
EVS is designed to handle the full complexity of real ERP systems like SAP. In
the database of SAP, resource and document changes are logged only as they are
completed (not scheduled or started). erefore, EVS considers events as atomic
without any state information. In MXML, an event has a type and can proceed
through dierent stages such as schedule, start, and complete. EVS does not distin-
guish between dierent types of events and considers each event as a single-staged
and completed happening with one execution time stamp. As a result, an event
with multiple stages in MXML is converted into multiple events in EVS with one
event for each stage.
Using event logs with only single-stage events produces some implications for
the potential of some process mining algorithms. Multistage events are core build-
ing blocks for process mining algorithms that try to identify and describe parallel-
ism in business ow (Wen et al. 2004). Even without multiple stages in the event
logs, we can still discover the nature of real business ows and extract meaningful
and valuable process models enriched with statistics and contextual information.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.