Comput Sci Res Dev (2015) 30:69–86
DOI 10.1007/s00450-013-0247-3
R E G U L A R PA P E R
Business impact analysis—a framework for a comprehensive
analysis and optimization of business processes
Sylvia Radeschütz · Holger Schwarz ·
Florian Niedermann
Received: 27 September 2010 / Accepted: 7 August 2013 / Published online: 14 September 2013
© Springer-Verlag Berlin Heidelberg 2013
Abstract The ability to continuously adapt its business pro-
cesses is a crucial ability for any company in order to sur-
vive in today’s dynamic world. In order to accomplish this
task, a company needs to profoundly analyze all its business
data. This generates the need for data integration and analy-
sis techniques that allow for a comprehensive analysis.
A particular challenge when conducting this analysis is
the integration of process data generated by workflow en-
gines and operational data that is produced by business ap-
plications and stored in data warehouses. Typically, these
two types of data are not matched as their acquisition and
analysis follows different principles, i.e., a process-oriented
view versus a view focusing on business objects.
To address this challenge, we introduce a framework that
allows to improve business processes considering an inte-
grated view on process data and operational data. We present
and evaluate various architectural options for the data ware-
house that provides this integrated view based on a special-
ized federation layer. This integrated view is also reflected in
a set of operators that we introduce. We show how these op-
erators ease the definition of analysis queries and how they
allow to extract hidden optimization patterns by using data
mining techniques.
S. Radeschütz · H. Schwarz (B) · F. Niedermann
IPVS, Universität Stuttgart, Universitätsstr. 38, 70569 Stuttgart,
Germany
e-mail: holger.schwarz@ipvs.uni-stuttgart.de
S. Radeschütz
e-mail: sylvia.radeschuetz@ipvs.uni-stuttgart.de
F. Niedermann
e-mail: florian.niedermann@ipvs.uni-stuttgart.de
Keywords Business process optimization · Data
warehousing · Information integration · OLAP · Data
mining
1 Introduction
Increasing competition and significantly shortened product
lifecycles led to a situation where fast adaption and con-
tinuous optimization of business processes are critical fac-
tors in determining the success of a company [42]. Business
process optimization aims to improve processes of an or-
ganization, e.g., by discovering and removing unnecessary
activities and by replacing activities by more efficient ones
[17, 36]. For these optimizations, companies need to analyze
process data using analysis techniques such as process mon-
itoring and process mining [37]. Operational data of other
business applications, e.g., data from business transactions
or from master data management, is stored in a data ware-
house and analyzed separately via OLAP (Online Analyti-
cal Processing) and data mining. All these methods usually
fall short when it comes to questions requiring an integrated
view on both process data and operational data. As an ex-
ample, consider a car rental company that tries to optimize
its rental process. A highly relevant question to a business
analyst would be how trainings and work experience affect
the execution time as well as the success of the process. An-
swering this question requires both process data (process ex-
ecution data, paths taken) as well as operational data related
to the employees involved in process execution (work ex-
perience, trainings, demographics). In such a situation, an
integrated analysis would make a valuable contribution by
ensuring that all relevant data is taken into account. We call
this approach Business Impact Analysis (BIA).
70 S. Radeschütz et al.

In this paper, we introduce a framework for Business Im-

pact Analysis that allows to improve business processes con-
sidering an integrated view on process data and operational
data. The main contributions are as follows:
– We discuss the structure of a data warehouse that builds
the basis for BIA. Our focus is on the evaluation of ar-
chitectural options that mainly differ in the way links bet-
ween process data and operational data are maintained.
– We introduce new operators, so-called BIA operators, that
extend the set of standard OLAP operators and take the
specific requirements of BIA into account.
– We show how to use data mining techniques for extracting
hidden optimization patterns from large audit trails and
operational data.
The remainder of this paper is organized as follows. We
give a brief overview of the BIA lifecycle in the following
section and summarize related work in Sect. 3. Section 4
shows a warehouse schema that efficiently realizes the in-
tegration of process data and operational data. In Sect. 5,
Fig. 1 Lifecycle for business impact analysis
we introduce new operators that allow to specify queries on
this integrated BIA warehouse in a user-friendly way. How
to combine these BIA operators with standard data mining
techniques in order to derive hidden patterns from the BIA
warehouse, is discussed in Sect. 6. We discuss and evalu-
ate the proposed warehouse architectures and operators in
Sect. 7 and finally summarize in Sect. 8.

2 Lifecycle for business impact analysis

In Fig. 1, we define the BIA lifecycle for improving busi-

ness processes, which are at the center of this lifecycle. Our
framework supports the necessary steps for an optimization
of these business processes in the phases of the lifecycle. We
illustrate these phases and the relevant system components
by a sample scenario which is introduced next.
2.1 Example scenario
Our sample scenario consists of a BPEL [23] process (see
parts of it in Fig. 2) that is supposed to be optimized, in the
sense that expensive, unnecessary, long running or canceled
process parts should be identified, analyzed and revised. The
process is part of a car rental service and describes the se-
lection of a rental car. It receives its input data from acti-
vity GetCustomerData together with information about the
customer and his preferred car class and checks if the re-
quested car is available by executing activity GetCarAvail-
ability. If no car is available during the desired rental period,
an employee executes the human task ContractNegotiation
to check if the customer would also accept another car class.
The task is not directly assigned to a specific employee, but
Fig. 2 Car rental process
to one of the available roles. Thus, ContractNegotiation can
be claimed and executed by all agents from departments A,
B or C. If the customer does not accept an alternative car
or renting period the process is canceled. Otherwise, the car
is handed over to the customer by an employee of depart-
ment D in human task CarHandOver. In Fig. 2, all pro-
cess variables are marked by hash marks #. The operational
data in the scenario includes useful data for optimization. It
comprises information about customers, employees or cars
(shown here as tables Customer, Employee and Automobile).
2.2 Phases of the lifecycle
Optimization at the process level is often termed business
process re-engineering [6, 8, 10, 15] or continuous process
improvement [21, 36]. We address optimization beyond this
level by exploiting operational business data at the same
Business impact analysis—a framework for a comprehensive analysis and optimization of business processes
level of importance. In order to be able to perform such
an extensive optimization, we propose a lifecycle for BIA
that comprises four phases (see Fig. 1): During the match-
ing phase, process model elements are combined with el-
ements in the operational data models. These matches are
used in the ETL (Extraction-Transformation-Load) process-
ing of the warehousing phase to cleanse and integrate pro-
cess data and operational data into one BIA warehouse (BIA
WH). The analysis phase discovers additional optimization
knowledge by considering both kinds of data. This know-
ledge provides the basis for the optimization phase, where
the process is restructured to achieve better business results.
We give an overview of the phases in the following subsec-
tions. In this paper, we focus especially on the phases for
warehousing and analysis that are discussed in Sects. 4 to 6.
2.2.1 Matching phase
The goal for this phase is to find for all variable elements of
the given process the matching elements in operational data
models. The matching phase traverses process and schema
models to determine matching schema elements for each
process variable element and assigns similarity values bet-
ween 0 and 1. There are different ways how our framework
supports the matching:
– manual matching: Matches are found and stored manually
by a business analyst.
– semi-automatic matching: Model elements are semanti-
cally annotated and matched automatically.
– automatic matching: The matches are found purely auto-
matic.
The matching phase starts by loading all process mod-
els and operational data models into the BIA-Matcher. It
also loads process variables from their process source file
or from audit trails of proprietary workflow engines where
process data is stored after process execution. Furthermore,
the BIA-Matcher loads elements of operational data models
from relational databases, XML databases or from CWM
(Common Warehouse Metamodel) [25], which is a standard
format to unify the interchange of proprietary formats in the
warehousing process. Ontologies (Web Ontology Language
(OWL) [41] and Web Service Modeling Language (WSML)
[40]), that are used for semantic semi-automatic matching,
are loaded as well.
An overview of the BIA-Matcher can be found in [27],
and [28] demonstrates its functionalities. The main compo-
nents for annotating model elements and the steps for semi-
automatic and automatic matchings are explained in the fol-
lowing:
Annotation Within Semantic Web research a number of
standards have been established for the annotation of web
71
services. One of the most prominent examples is Semantic
Annotations for WSDL (SAWSDL) [39]. SAWSDL extends
WSDL components with an URL to a given ontology con-
cept to enable their semantic annotation. Thus, we selected
SAWSDL for the annotation of model elements for semi-
automatic matching. For BIA, we are primarily interested in
SAWSDL annotations for process variable definitions. Fur-
thermore, we extended the annotation capabilities to cover
operational data as well, which leads to a set of annotated
schema elements.
Matching In this step, the BIA-Matcher applies matching
rules to find matches between variable elements and ele-
ments of operational data models. For the semi-automatic
matching, the BIA-Matcher uses a suitable reasoning tool to
infer logical consequences from semantically annotated data
using the loaded ontologies. For this purpose, the BIA-Mat-
cher holds a selection of appropriate inference rules. We are
especially interested in rules that discover synonyms, sub-
classes, equality or union relationships between the concepts
of two annotated match partners as well as other concept re-
lations defined by user-defined ontology rules.
For non-annotated or partially annotated models, the
BIA-Matcher employs rules for automatic matching that
consider process features in addition to common schema
matching algorithms. In order to match process variables
with elements in operational data models the rules exploit,
e.g., names of the elements or data dependencies via the data
flow.
In both matching approaches, the Matcher considers the
context of match partners, e.g., the names of process com-
ponents working with the matched variable or the names of
parents of operational elements. The context is used to refine
found matches and to improve the precision rate.
In our sample scenario, the Matcher combines the fol-
lowing elements: (1) We assume that the element Cust.ID of
variable inputData is combined with attribute CID of the op-
erational table Customer, (2) the executing roles (assignees)
of ContractNegotiation with table Employee, (3) element
Car.Model of variable ServiceInfo with attribute Class of ta-
ble Automobile.
2.2.2 Warehousing phase
An integrated data warehouse has to be established in order
to enable a Business Impact Analysis. The BIA-Loader as
shown in Fig. 1 supports the building of this warehouse and
its ETL flow. Its components are only briefly described here,
we explain further details in Sect. 4.
WH creation As we have to handle huge amounts of pro-
cess execution data, operational transaction data and master
data, we do not build one consolidated warehouse, but leave
72
Fig. 3 BIA warehouse
all data in their source systems. In order to realize the in-
tegrated data warehouse, we create a federated warehouse
architecture (see Fig. 3). For the federation server, one may
use standard federation systems such as IBM Infosphere
Federation Server. The data sources of process data and op-
erational data are accessible to this federated architecture via
standard wrappers, depending on the database system of the
audit trail and the operational data storage. Both data can be
used by the analyst via an SQL client.
The federation layer is responsible for the integration and
contains the mappings resulting from the matches identified
in the matching phase between the process variables from
the audit trail and the operational schema elements. These
mappings are the only integrable elements between process
data and operational data, because audit trails primarily store
attributes that are relevant during the execution like the du-
ration of the process which do not have a counter part in the
operational data. In Sect. 4.2, we propose two variants of
a federated warehouse architecture to store identified map-
pings: via one match table that contains all matches or via
one bridge table for each match between a process attribute
and an operational attribute.
ETL Standard ETL steps such as data extraction, transfor-
mation, data cleaning and normalization are done to provide
optimal input data for the BIA WH. For found matches, the
ETL flow integrates process and operational data sources.
As the user can choose from two different architectures for
the BIA WH, different transformation steps are necessary
covering bridge table creations and match table creation.
2.2.3 Analysis phase
The goal of this phase is to provide a concise view on all as-
pects of the process being considered for process optimiza-
tion. For instance, it might be important to make available
information on activity execution time, waiting time, feasi-
bility of parallelization and relevant process attributes with
regard to the process outcome. The BIA-Analyzer shown in
S. Radeschütz et al.
Fig. 1 is used for analyzing the data and receiving know-
ledge about valuable correlations as basis for this optimiza-
tion. We give an overview here and discuss details in Sects. 5
and 6. All the analysis results must be interpreted by the user
and stored as BIA knowledge for the optimization phase.
Preselection We use the BIA-Analyzer to preselect at-
tributes in the BIA WH that might be valuable for analysis.
Usually, we have to consider many dimensions in the ware-
house and many operational dimensions as well. To reduce
dimensionality, the BIA-Analyzer applies various analysis
preparation patterns. We derive these patterns from statistics
about analysis results of earlier data mining runs or OLAP
analyses. The process dimensions are preselected depending
on the impact they have on process executions, such as ex-
ecution time or process state. Hence, process dimensions or
operational dimensions that are not needed for the analysis
can be removed from the data mining input. Relevant pro-
cess attributes and their matching operational attributes are
narrowed down by statistics from earlier analyses as well.
OLAP To gain insight into problematic business processes,
OLAP queries are used on integrated process and opera-
tional data. Our framework offers a number of specialized
OLAP operators that can be used to simplify an integrated
analysis. Frequent types of subqueries are realized in these
OLAP operators and make it easier to perform complex que-
ries. They are introduced in Sect. 5.
Data mining The BIA-Analyzer can apply standard data
mining techniques on the BIA WH in order to receive new
insights into correlated effects between processes and op-
erational data. Several data mining techniques and algo-
rithms are adopted to integrated process and operational
data. OLAP-Operators can also be applied before data min-
ing in order to prepare the data for a data mining algorithm.
The analysis phase may reveal useful relationships bet-
ween the duration and result of a process and operational in-
formation on the business objects or executing resources. In
our sample scenario in Fig. 2, we may discover in (1) a cor-
relation c1 between the assets of customers (type of credit
card) and processes with a long duration. The performance
of ContractNegotiation in (2) may depend on the executing
employee and his skills (c2). In (3), there may be a rela-
tionship c3 between the rented car class and the execution
time of CarHandOver. A detailed analysis shows that cer-
tain car class features require a longer introduction time for
the customers, e.g., using sports cars. We discuss the BIA
data mining operations in detail in Sect. 6.
2.2.4 Process optimization phase
The optimization phase is based on the analysis results
gained. The BIA-Optimizer (see Fig. 1) aims to use these
Business impact analysis—a framework for a comprehensive analysis and optimization of business processes
results and to rewrite the business processes improving their
performance. To successfully rewrite and improve the pro-
cess model, the BIA-Optimizer needs to detect the appro-
priate rewrite rules depending on the given business goals.
Hence, the BIA-Optimizer gets the optimization goal as well
as any constraint that should be considered during the opti-
mization in terms of cost, quality, utilized resources or busi-
ness rules. The engine identifies applicable optimization pat-
terns (see also [22]) to fulfill these business goals and de-
cides which rewrite rule fits best and should be executed.
The rewrite rules are based on “best practice” techniques
for the optimization of processes [8]. The practices are for-
malized in these rules to achieve a high extent of automated
optimization. In the last step, the BIA-Optimizer automati-
cally rewrites the business process according to the chosen
rule and allows the user to add process modifications manu-
ally.
Using the analysis results of the correlations c1, c2 and
c3 in our sample scenario, the car rental process is restruc-
tured in the optimization phase. In order to win wealthy cus-
tomers and avoid processes with long duration in c1, they
are routed to special services. Analysis results for c2 let us
try to raise the performance of ContractNegotiation and in-
crease the number of accepted tasks. Therefore, a reorgani-
zation of the execution roles is done. In c3, the longer intro-
duction time in CarHandOver is managed. In our scenario
this activity is efficiently executed by outsourcing it during
rush hours for certain car classes.
3 Related work
Only little work has been done in the area of a global anal-
ysis of both workflow data and operational data. Hence,
related work also covers various approaches to derive
knowledge from process data or operational data in isola-
tion.
Pure process analysis is based on audit trails that store the
execution data of processes. Audit trails can be exploited
in various ways. First, they are needed for business activ-
ity monitoring (BAM) [14, 19, 43] to react to problems that
arise during process enactment. Secondly, they are used as
one basis for business process management systems that
support the definition, execution, and tracking of business
processes [3, 5, 32, 33]. A third example are process min-
ing techniques [1, 31, 36, 37, 45] that try to identify pro-
cess models, check the conformance of process execution
with existing process models or aim at process optimiza-
tion. They are based on audit trails as well. Data from au-
dit trails is often integrated in a data warehouse to be better
suited for analysis purposes. Such a data warehouse is of-
ten called a process warehouse or an audit warehouse. The
appropriate structure [9, 18] as well as the ETL processes
73
[4] of these warehouses have been studied in previous work.
But all the mentioned approaches and techniques refer to
the actual flow logic. Operational data sources with further
information are typically neglected.
Operational data comprises all data processed within the
business that is not stored in an audit trail, but by other sys-
tems, e.g., ERP systems and data warehouses. OLAP and
data mining techniques are typically employed to this data
in order to analyze it and reveal hidden pattern. OLAP sup-
ports users in interactively analyzing multidimensional data
from multiple perspectives [7]. Data mining is the process of
searching large volumes of data for patterns using methods
such as classification, clustering and association rule dis-
covery [2, 11, 29]. However, they do not consider the chal-
lenges of integrating process data and operational data and
performing analyses on such a huge amount of dimensions
resulting from this integration. The BIA operators that we
introduce in this paper, offer an efficient way to deal with
this integration and high dimensionality by preselecting rel-
evant dimensions.
Some work has been done that tries to provide a more
global view on process data and operational data. In [34], the
authors introduce an evaluation framework for process ware-
houses. They define various perspectives a process ware-
house should cover. Considering operational data in addi-
tion to process data can be seen as part of the informa-
tional perspective. But neither options for the structure of an
integrated warehouse nor operators to support the analysis
based on such a warehouse are discussed in [34]. The Pro-
cess Data Warehouse in [4] provides a warehouse model for
a global analysis. However, in contrast to our BIA WH it fo-
cuses on process dimensions and the operational dimension
is not well-defined, but mixed with the process dimensions.
The PISA tool [44] considers process variables and only
operational data that is directly stored in these variables.
No further attributes in operational dimensions are consid-
ered. Furthermore, it offers only relatively simple analyses.
None of the mentioned approaches support global data mi-
ning techniques or OLAP operators as considered in BIA. In
those systems the business analysts have to guess about op-
erational relationships to certain process data to be analyzed.
Our operators provide support for a combined analysis that
considers links between operational data and process data.
This enables analysts to make in-depth analyses more effec-
tive and more efficient.
Furthermore, our framework enables an overall business
process optimization, that considers the main performance
indicators time, cost and quality described in [6, 8]. In the
analysis and optimization phases we aim to find options for
improving the given process considering these indicators.
However, our approach even goes deeper and aims to find
hints for optimization not only in workflow data, but consid-
ers also related operational data.
74 S. Radeschütz et al.

4 BIA warehouse architecture

An integrated warehouse of both process data and opera-

tional data is the basis for BIA. Two different warehouse ar-
chitectures are presented here and we discuss how they suit
the BIA purpose. At the core of both warehouse systems are
various analysis cubes each with one fact table. The design
of the fact tables and their depending dimensions are based
on metrics that are interesting to analyze for BIA. Thus, we
first summarize these metrics in this section before we ex-
plain the architectures.

4.1 Analysis metrics

Fig. 4 Conceptual view of a BIA cube in the BIA WH
The analysis metrics for BIA can be classified along the fol-
lowing categories which are mainly based on [4]:
– Process Metrics: These metrics are based on process data,
e.g., the duration between activation and completion of
activities or time intervals between the completion of a
task and start of another one.
– Resource Metrics: These metrics consider data related to
human and automated resources, e.g., their performance
in executing tasks.
– Business Object Metrics: They comprise all business data
values that are used in the workflow.
– Operational Metrics: They consider operational data val-
ues that further describe certain process attributes.
For a comprehensive analysis, metrics from all these cat-
egories have to be considered together. Hence, they should
be stored in an integrated warehouse architecture which is Fig. 5 Detailed conceptual view of a BIA cube
introduced in the next section.

4.2 Conceptual view by none, one or more operational sub-dimensions. These

Both operational data sources and process data sources con-
tain huge amounts of operational data or process execu-
tion data. For an integrated analysis, we propose a feder-
ated warehouse architecture, as already shown in Fig. 3. The
warehouse stores BIA cubes that consist of facts being cat-
egorized by dimensions. Figure 4 shows the general con-
ceptual view of such a cube. The cube is very general as
it should be applicable to different situations, i.e., to differ-
ent business processes and operational data models, and it
should allow to analyze different metrics. The figure shows
the most significant elements. The metrics in the fact table
pfact consist of the analysis metrics discussed before. The
facts are described by the process dimensions px , py , pn ,
pm , etc. The dimensions contain process execution data and
data of the used process models.
We add operational sub-dimensions on to om in the BIA
WH. They enrich the process dimensions pn to pm by com-
plementary information from other applications in the com-
pany. Each attribute in a process dimension can be described
correlations are depicted only as gray arrows in Fig. 4, be-
cause they are different for each activity in a process model.
The operational target tables and the number of correlations
to these target tables change for each matching process at-
tribute.
One detailed conceptual view of a sample cube is de-
picted in Fig. 5. In this paper, we focus on facts about ac-
tivity execution as analysis metrics. The activity execution
facts are described by four process dimensions: workflow,
time, business object and resource. The workflow dimen-
sion stores the data about an activity, its activity instance ID
(ActivityInst), process ID and further process-specific and
activity-specific details, e.g., its name, deployed version, etc.
In the time dimension the start time of an executed activ-
ity is stored and expanded in smaller time units as days,
months, years and so on. The resource dimension stores
workflow variables that contain information about employ-
ees, machines or engines that executed an activity. In the
business object dimension the workflow variables and their
elements are listed that are worked on in the activity execu-
Business impact analysis—a framework for a comprehensive analysis and optimization of business processes 75

Table 1 Comparison of BIA WH architectures

Match table Bridge table

Integration on schema level Integration on instance level

No schema adaption, but only Schema adaption with new bridge
insertion of new match table for new match
One row per match One table per match
Cleansing during analysis phase Cleansing during ETL

tion. We refer to them by artificial business object identifiers

BOID and BOIDelem.
Both business objects and resources can be further de-
scribed by attributes from operational sub-dimensions. Fig-
ure 5 shows three operational tables: Customer, Automobile
and Employee. They contain attributes like trainings of em-
ployees or information about automobile classes. The cor-
relations between the operational attributes and the process
dimensions have been found in the matching phase. So the Fig. 6 Integrated warehouse with match table
business object elements of an activity may for example ref-
erence sub-dimension tables Customer or Automobile. Addi-
tionally, a resource may reference sub-dimension table Em-
ployee. We are only able to match the workflow variables
stored in the business object dimensions and resource di-
mensions with operational attributes in the BIA Cubes. For
every activity in a process model and its variables, different
operational sub-dimensions may be added to the BIA Cube
and then be used for analysis. As every variable is matched
to another operational attribute with another data type this
integration is not straightforward. In the federated ware-
house these matches are stored in the federation layer. In
the following, we present two ways to represent the matches
between process data and operational data in the federation
layer. In both approaches mapping names have to be created
to access process and operational tables. A brief overview
of the main characteristics of these approaches is shown in
Table 1.

4.2.1 Integration by a match table Fig. 7 Integrated warehouse with bridge tables

Figure 6 shows one way to model the federation layer in the

BIA WH. It describes the matches on the schema level. The
architecture uses only one match table to connect both pro-
cess and operational dimensions. This match table results
from the matching phase and is stored in the federation sys-
tem. The match table includes a precise definition of corre-
lations between the dimensions. It stores the mapping be-
tween a process attribute of a resource or a business object
element and the operational attribute that describe the same
real world item. The element in the process variable is iden-
tified by its name and by the identifier of its activity and
its process. The matching operational attribute of a business
object or a resource is described in the last two columns of
the match table. They store the name of the column and the
mapping names of the belonging table, database schema and
database server name. To access the source tables, we use
identifiers called nicknames in IBM Infosphere.
4.2.2 Integration by bridge tables
Another way to integrate process data and operational data
is shown in Fig. 7. This architecture dissolves the match ta-
ble and creates a new bridge table for each match. Thus,
the integration happens on the instance data level. For creat-
ing one bridge table, we proceed as follows: For each match
listed in the match table, we get all tuples from the business
object element table referring to variable elements with the
76
same name (VarElemName). Then we take only the tuples
that refer to the same activityID and processID as described
in the match table. This is done by joining the fact table and
the workflow table with the business object and business ob-
ject element table. From the received tuples only those are
taken that have the same value in the business object ele-
ment table and the matched operational table. The same is
done for the resource matches. The names of the bridge ta-
bles are composed with the related element name so that the
BIA Operators will find the appropriate bridge tables for a
certain element in the later OLAP analysis (see Sect. 5.2.1).
According to this architecture, a new table BridgeTable_
CustID is shown in Fig. 7 for the match between the element
CustID of variable inputData and column CID of table Cus-
tomer (see Fig. 2). Another bridge table BridgeTable_Car-
Model addresses the match between element CarModel of
variable ServiceInfo and column class of table Automo-
bile. As class is no primary key in table Automobile, Brid-
geTable_CarModel needs the operational attribute AID as
foreign key to clearly reference all tuples with this class in
table Automobile. For BridgeTable_AssigneeID the same is
done to bridge resourceID of the resource table and EID of
the employee table. The attributes in all bridge tables are
nicknames to identify the source attributes. Finally, standard
cleansing steps are required for the instance data to receive
correct matches, if the matched attributes do not have the
same values. Examples with instance data for this BIA WH
architecture can be seen in Sect. 5.1 where the analysis op-
erators are explained.
Fig. 8 Sample BIA-cube with bridge tables
S. Radeschütz et al.
5 Operators for a business impact analysis
In order to improve business processes on basis of our BIA
WH, it is helpful to have OLAP support that goes beyond
the usual OLAP SQL features such as ROLLUP or WIN-
DOW [12]. As introduced in the section before, the oper-
ational data dimension is divided into sub-dimensions. In
order to handle these sub-dimensions efficiently in OLAP
and data mining analyses, we propose new operators. An-
other goal of our operators is to facilitate frequently needed
queries on processes as a kind of macro, e.g., an operator
that looks for the activities with the longest duration or for
activities with errors. The operators help to analyze the three
main performance indicators: cost, time and quality of a pro-
cess (see [8]). Another purpose of the operators is to prepare
the warehouse dimensions for data mining algorithms, e.g.
returning only numeric attributes for regression mining. Be-
fore we describe the BIA operators in detail, we introduce a
sample cube in the next section. The operators use this cube
to exemplify their analysis results.
5.1 Sample BIA cube
The sample cube that we use to illustrate the BIA opera-
tors is based on the sample scenario and the process model
shown in Fig. 2. It combines process data of this car rental
process with associated operational data and is stored in a
data warehouse with bridge tables.
Figure 8 shows a fragment of this cube filled with sam-
ple data. The fact table includes all activity executions,
Business impact analysis—a framework for a comprehensive analysis and optimization of business processes
e.g., of ContractNegotiation. The variables and their de-
tails are contained in table businessobject and table busi-
nessobjectelement. The resource table with the assignees
is not shown here. BridgeTable_CarModel bridges the el-
ement Car.Model of the activity ContractNegotiation in the
CarSelectionProcess with column class of the operational
table Automobile, whereas BridgeTable_AssigneeID bridges
the resource table with the operational employee table. The
operational tables Training and CarFeatures are related to
Employee and Automobile via foreign keys.
5.2 BIA operators
All BIA operators are defined by the syntax snippets in
Fig. 9 in Backus-Naur form. As defined by the syntax snip-
pets, all operators are a component of the table reference
used in the from clause of a table expression (see Fig. 9(a)
and (b)). The bia clause in is an alternative table reference
that again consists of six alternative clauses representing the
BIA operators. The syntax is the same in both architectures,
but the operators differ in their execution. The main differ-
ence is that the operators executed on a BIA WH with match
table have to perform their cleansing steps during the execu-
tion. Hence, these cleansing steps have to be executable au-
tomatically. On a BIA WH with bridge tables, this cleansing
is part of the ETL processing.
The usage of the BIA operators requires an allocation of
several attributes and tables of the process dimensions with
strictly defined naming and foreign key relations. The op-
erators work on a schema as shown in Fig. 5 with nick-
names to identify the tables named workflow, time, activ-
ityexecution, businessobject, businessobjectelement and re-
source. At least the attributes processid, activityid and activ-
itytype amongst others in the workflow table must have nick-
names. Furthermore, there should be nicknames for the at-
tribute Name in the businessobject table, for VarElemName
and VarValue in businessobjectelement, for starttime in the
time table and for all attributes in the fact table.
5.2.1 Operators for sub-dimension analysis
A first group of operators can be used to get a first overview
of the related operational attributes for a given activity. Ac-
cording to the used BIA WH they evaluate the match ta-
ble (see Fig. 6) or the bridge tables (see Fig. 7) to find all
joins between the operational dimensions and the business
object or the resource dimension. The operators are shown
as alternative clauses for the biasub clause in Fig. 9(d). We
define the operator BIASUBALL that simply returns all re-
lated sub-dimensional attributes. Hence, the output columns
of the result table are dependent on which process and ac-
tivity models the operator is applied. Furthermore, we de-
fine two operators BIASUBLABEL and BIASUBNUM to
77
restrict the output table according to different format condi-
tions. They are especially interesting to provide the appro-
priate input for certain data mining tasks.
BIASUBALL The BIASUBALL operator has three input
parameters: var, processid and activityid (Fig. 9(e)).
BIASUBALL selects all columns and their values of the
operational tables that contain matched sub-dimensional at-
tributes for the specified variable elements in the specified
activity and process. The variable elements var are defined
by distinct element names, processid contains the identi-
fier of the requested process and activityid the identifier of
the requested activity which processes the given variables.
When no element name of a variable is specified, correla-
tions to all elements of the given activity are emitted together
with the attributes in the tables where they appear.
The operator proceeds as follows: It selects those tuples
from the process dimensions that contain the given process
ID, activity ID and variables and all attributes from related
operational tables as well as attributes from operational ta-
bles referencing the matched operational attribute by foreign
keys. The related operational attributes are gained via ex-
ploiting either the match table or the meta data of the ware-
house to look for bridge tables named after the correspond-
ing variable element. The output table contains the activity
instance and all related operational attributes. Some of them
may be used by standard data mining techniques for deriving
new optimization hints.
Example In the following, the operator BIASUBALL is il-
lustrated using the example tables from Fig. 8. The query al-
lows to figure out which attributes of the resource assignee
determine a successful execution of the activity ContractNe-
gotiation in the CarSelectionProcess:
SELECT BIA.*, BOE.VAR E LEM NAME , BOE.VARVALUE
FROM biasuball( TASKVAR . ASSIGNEEID , C AR S E -
LECTION P ROCESS , C ONTRACT N EGOTIATION ) AS BIA ,
BUSINESSOBJECT BO , BUSINESSOBJECT-
ELEMENT BOE , ACTIVITYEXECUTION A
WHERE BIA . ACTIVITY I NST = A . ACTIVITY I NST
AND BO . BOID = A . BOID
AND BO . BOID = BOE . BOID
AND BO . NAME = ‘ TASKVAR ’
AND BOE . VARELEMNAME = ‘ OUTCOME ’
We select all related operational attributes for this as-
signee by BIASUBALL and join them with the tables activi-
tyexecution and businessobject(element) to get the outcomes
of the activity as well. When this query is executed on our
sample BIA-Cube we receive a result table of which an ex-
tract is shown in Fig. 10. This result shows that the majority
of cases with Outcome = ‘Reject’ is related to the agent’s
trainings and is done by employees that are trained for sales.
78
Here we can draw this conclusion simply by looking at the
result table, but usually further analyses are necessary, e.g.
by means of data mining techniques. For an optimization,
these findings need further investigation.
BIASUBNUM and BIASUBLABEL As some data mining
approaches need restricted categories of input data, we deve-
loped two additional operators. The BIASUBLABEL opera-
tor (Fig. 9(f)) filters all attributes that have nominal val-
ues. This operator is especially necessary for data mining
approaches such as classification where all attributes are
grouped by their nominal data categories. If a transformation
of numeric values to such categories is not possible or not
wanted, this operator is very important. Its syntax is equal
and its output table is similar to the BIASUBALL output,
but only nominal attributes are emitted. The operator checks
Fig. 9 SQL Syntax of BIA operators
Fig. 10 Sample result table of
BIASUBALL
S. Radeschütz et al.
a list where all possible nominal attributes are listed (string,
character, . . . ).
The second operator BIASUBNUM (Fig. 9(g)) returns all
numeric attributes by checking a similar list (integer, float,
decimal, numeric, . . . ). This is necessary for data mining ap-
proaches such as clustering or regression where continuous
data values are needed. The syntax of the operator also re-
sembles the BIASUBALL operator.
Example If we use BIASUBNUM instead of BIASUBALL
as in the previous example, the result table looks similar
to Fig. 10. However, this time we receive only the numeric
columns. The categorical attributes are eliminated from the
operational output table. So the operational columns of em-
ployee (Name, Position, Tname and Tdate) are excluded, as
they have non-numeric data types. All other columns are
Business impact analysis—a framework for a comprehensive analysis and optimization of business processes
Fig. 11 Sample result table of
BIAHT
shown, as they are numeric (Salary) or belong to joined pro-
cess or bridge tables. BIASUBLABEL would operate anal-
ogously returning the nominal attributes instead.
5.2.2 Operators for duration analysis
As the duration of business processes plays a major role for
process optimization, our framework offers three operators
to support the duration analysis: BIAHT, BIAPL and BIA-
FLUCT. Their syntax is depicted in Figs. 9(h), (i) and (j).
BIAHT and BIAPL The human task activity and, more
general, the invoke activity waiting for response of partner
services are a source for optimization, because they often
last very long. Our operators find these activity types in the
given process executions and return the according tuples to-
gether with their variables and their duration length. The BI-
AHT operator searches for all human task activities in the
fact table for the given process identified by processid. It
joins the fact table with the workflow table (to select all ap-
propriate activities) and with the time table (to get the dura-
tion of the activity executions). The workflow and the time
table are not shown in Fig. 8, but only indicated in Fig. 5.
The approach of the BIAPL operator is just the same, but it
searches for general invoke activities to partner links instead
of only human tasks.
Example In the following example query we use BIAHT to
investigate the processing time of human task activities used
in the CarSelectionProcess:
SELECT * FROM BIAHT (C AR S ELECTION P ROCESS )
We receive the executed activities and their durations to-
gether with the business object elements and the ResourceID
of responsible employees. Using our sample BIA-Cube this
query results in an output table as shown in Fig. 11 with the
duration calculated by using the start time of the activities
in the time table, with the ResourceID of the resource ta-
ble and the CarModel, Location and CustID attributes of the
businessobjectelement table. We discover that process in-
stances in ContractNegotiation for InputData.Car.Model =
‘AudiTT’, are slower in their processing time than other car
models and need often more than 30 minutes. Using the next
BIA operator, we may take a closer look at these duration
fluctuations.
79
BIAFLUCT High duration variances for the same activ-
ity in different process executions give also hints for pro-
cess optimizations. The BIAFLUCT operator aims to find
these activities. The operator searches for all activities for
a given process similar to the previous two operators. How-
ever, it searches for tuples with activities whose execution
length fluctuates in the given duration value. That means
it searches if the amount of percent executions fluctuates
(i.e. is slower or faster) in the indicated duration than
the average time of the other instances of the same activ-
ity model. The duration value is expected in the following
format 000:00:00:000 (days:hours:minutes:seconds).
Example In the following, we further investigate all activi-
ties in the CarSelectionProcess. We create an example query
using BIAFLUCT to search all activities of which 20 % last
more than 30 minutes longer or are more than 30 minutes
faster than the average time of the according activity exe-
cution. We select the activity executions together with the
information on used variables:
SELECT *
FROM BIAFLUCT(C AR S ELECTION P ROCESS,
000:00:30:000, 20)
The output table is similar to Fig. 11. It shows the same
attributes, but only for those activity instances where at least
20 % of the instances deviate more than 30 minutes from the
average execution time for this activity. Furthermore it may
contain also other activity instances, e.g., activity GetCar-
Availability with different variable elements, as it shows all
activity types. We also get ContractNegotiation instances as
result. If we use BIASUBALL operator, the reason for the
negotiation delay for certain rental car models, e.g. AudiTT,
may be discovered: A high choice of extras in some automo-
biles needs a lot of callbacks to the customer. For a process
optimization, we could change the process model and add
an extra activity at the beginning that requests for additional
information from the customers that are interested in certain
car models.
5.2.3 Operators for exception analysis
One important optimization goal is the prevention of errors
during process execution. Our framework offers two oper-
80 S. Radeschütz et al.

Fig. 12 Sample result table of

BIAERROR

ators for the analysis of activated exceptions during execu-

tion: BIAERROR and BIAEXCEPT.

BIAERROR The first operator BIAERROR (k) compares

faulted and completed process executions and returns tu-
ples of critical activity executions together with their re-
lated business objects. BIAERROR searches for all activi-
ties in the fact table for the given process. It returns a table
with activities which are not terminated in a certain fraction
(percent) of executions. While joining all relevant tables,
the state of the processes is evaluated. The output table con-
tains their related variable data and possible resources.

Example In the following, we further investigate the activ-
ities in the CarSelectionProcess. Our example query uses
BIAERROR to search for all activities which end in a faulty
state for more than 30 percent of the executions. We select
these activity executions together with their used variable
data:
SELECT *
FROM BIAERROR(C AR S ELECTION P ROCESS , 30)
We discover in the output table shown in Fig. 12, that
process instances of activity CarHandOver are faulty very
often. For a process optimization we need further analyses
and have to check the related operational attributes of the
found activity variables and of their preceding activity vari-
ables.
BIAEXCEPT The second operator BIAEXCEPT (l) takes
a closer look at the exception handlers that are used to catch
errors that might have come up during process execution.
So this operator evaluates the execution data not for faulty
results, but for errors that are not so evident, because the
process state is completed. Although the errors have been
caught, they still signal some kind of problem that might
be worth a closer look. The operator compares regular and
caught process executions, i.e., if a exception handler is exe-
cuted (this is stored in the audit log), and returns the activity
instances together with related variable data and resources.
6 Data mining techniques for business impact analysis
As an additional option in the analysis phase, we use data
mining techniques for extracting hidden optimization pat-
Fig. 13 BIA-clustering example
terns from the audit trails and operational data. We showed
in [26] how common data mining techniques such as cluster-
ing, classification, association rule discovery and regression
(all specified in detail e.g. in [11]) are applied to a combi-
nation of process dimensions and operational dimensions in
the BIA approach. In this section, we show how to use the
BIA-Operators to preprocess data in the warehouse in order
to simplify the application of these data mining techniques.
The examples are based on the car rental scenario again.
6.1 Clustering
Grouping a set of related objects into certain classes of ob-
jects that are similar to each other and dissimilar to other
classes is called clustering [13]. Especially high-dimension
clustering methods [24] are interesting for BIA because of
the high number of sub-dimensions that result from the high
number of process variables in different process activities.
In order to prepare the data set for clustering, we may
use the BIAFLUCT and BIASUBNUM operator. In a first
step, BIAFLUCT is used to receive all services that have
big fluctuations in the CarSelectionProcess. We may dis-
cover that activity GetCarAvailability appears often. For the
clustering, we only can use numeric attributes. Therefore,
BIASUBNUM is applied for GetCarAvailability and all of
its variables. We are interested especially in applying BI-
ASUBNUM to the CustID variable in order to be able to
cluster the activities in relation to their sub-dimensional cus-
tomer attributes. Figure 13 illustrates the clustering along
two dimensions, i.e., the execution time of activity instances
Business impact analysis—a framework for a comprehensive analysis and optimization of business processes
Fig. 14 BIA-classification example
of GetCarAvailability and attribute customer ranking of sub-
dimension customer. We may gain three clusters that we la-
bel as: VIPService, FastService, DelayedVIPService.
BIA-Clustering is suited as a first analysis method to
identify the activities that have problems and that must be
further analyzed for optimization. The VIPProblemService
cluster has to be examined in detail to discover reasons for
the delay and to reorganize the processes.
6.2 Classification
Classification is a data analysis method that can be used to
extract patterns and to describe their related information in
categories [20]. In BIA, classification is very helpful for ca-
tegorizing processes.
In our example, we want to classify executed activities
according to their execution state. Thus, data of the CarSe-
lectionProcess is first preprocessed using BIAERROR. Dis-
covering that ContractNegotiation is one error-prone activ-
ity, which often leads to process termination, we continue
with the operator BIASUBLABEL for this activity. The op-
erator is executed on the Assignee variable and receives all
sub-dimensional categorical attributes. Now, classification
may start on this ContractNegotiation execution data to-
gether with the received attributes. Figure 14 shows a deci-
sion tree for ContractNegotiation and its class label attribute
process state, which has two distinct values complete and
faulty. The partition of the tuples depends on process data
and on operational data related to the employee who exe-
cutes the task. The attribute training has the highest informa-
tion gain and becomes the first splitting attribute. If the em-
ployee is trained in communication the activity is accepted
at once. For sales training there may be revealed an addi-
tional differentiation on the position attribute (employed as
rental car supplier in the agency or as rental car mechanic).
On the advertising side, we have a second differentiation on
priority for the execution of the activity.
81
Fig. 15 BIA-regression example
We can use this technique to restructure the process mo-
del in order to avoid terminated paths. For process optimiza-
tion, the employee group should be changed: Only agents
that are skilled in communication or mechanics skilled in
sales should be allowed to execute the task instead of all
employees from Dept A, B and C. For another decision tree
example, we could use BIAEXCEPT to classify certain ac-
tivity executions according to the exceptions that have to be
handled or if they have been executed without error.
6.3 Regression
Regression is closely related to classification. While classifi-
cation has discrete results, regression methods predict conti-
nuous-valued functions, e.g., by statistical methods [35].
For a flexible allocation of employees to human tasks
in the CarSelectionProcess, their duration should be pre-
dicted to reduce bottlenecks and long delays. A preprocess-
ing of data with the operators BIAHT and BIASUBNUM
may be done for our sample regression mining. First, BI-
AHT finds out that, among others, activity CarHandOver
often has a high runtime. We guess that the CarModel el-
ement needs further surveillance. The numeric operational
sub-dimensions for this element are received via BIASUB-
NUM. By standard regression methods on its result table,
we examine the duration of the activities of handing over a
car to a customer. The regression may show that the dura-
tion depends on the amount of extra features available in the
rented car model (Fig. 15).
6.4 Association rule mining
BIA-Association Rule Mining is based on a mix of multidi-
mensional association rule mining and process mining. Mul-
tidimensional association rule mining is a popular method
for discovering interesting relationships between different
kinds of attributes in large databases [16], whereas process
mining considers the process structure and tries to found out
which activities with which variables occur together in one
82
Fig. 16 BIA-association rule mining example
process [38]. Attributes that occur frequently together with
certain values in transactions are called frequent itemsets.
The task of this data mining method is to find all frequent
itemsets and use them to create association rules. The as-
sociation rule {A = a, B = b} ⇒ {C = c} indicates that if A
and B appear together with value a and b, also C with value
c is likely to appear in this transaction. A, B, and C can be
both process attributes and operational attributes.
Association rules that consider process variables, their
values and their effects on later activities are necessary in
BIA for an efficient resource planning. Operational data can
help to categorize these effects. In a first step, we may an-
alyze the activity GetCarAvailability and subsequent activ-
ities in the process. Data mining might reveal rules like in
Fig. 16(1) + (2) that are not valuable, because their support
might be too low. If we use BIASUBALL, we get more in-
formation from the operational data about the element Car-
Model. Thus, we can group the found executions by the op-
erational attribute category of the element CarModel, e.g.,
sports or family, and receive the necessary support for new
association rules like shown in Fig. 16(3) + (4). We might
use them to reimplement the process to guarantee a fast pro-
cessing.
7 Discussion and evaluation
In this section, we discuss the two warehouse architectures
introduced in Sect. 4 as well as the BIA operators introduced
in Sect. 5 and their usage for data mining as described in
Sect. 6. As both warehouse architectures (Fig. 6 + Fig. 7)
show advantages and disadvantages one has to decide which
one will fit best to specific requirements. This section gives
an evaluation of both warehouse schemes and the criteria for
this decision. In particular, we review how they influence the
data volume and complexity of ETL processing (Sect. 7.1),
we present experimental results that show the query perfor-
mance on both warehouse architectures for queries with and
without BIA operators (Sect. 7.2) and discuss usability as-
pects (Sect. 7.3). Table 2 shows an overview of these evalu-
S. Radeschütz et al.
Table 2 Evaluation overview
Match table Bridge table
Complexity of ETL + −
Data volume + −
Runtime of arbitrary SQL query − +
(Query type I)
Runtime of query with operators 0 0
(Query type II)
Usability 0 0
ation results. Finally, we discuss the usage of BIA operators
for OLAP and data mining analysis in Sect. 7.4.
7.1 Data volume and complexity of ETL processing
One major advantage of the warehouse with a match table
is that it comprises only one new table, namely the match
table. This has two aspects. First of all, the ETL process
is very simple, because it only copies the matches received
in the matching phase into the federation layer. No schema
adaption is necessary. Secondly, the BIA WH needs only ex-
tra space that depends on the number of found matches (n)
as each tuple in the match table contains one match between
the elements of the models. This space can be indicated by
O(n). The match between related instance data is not stored,
but received at query runtime.
In contrast, the warehouse with bridge tables requires
to extract and load all matches on instance level into the
bridge tables. A new bridge table is created for each match
that connects process and operational tables causing signif-
icant space requirements. Due to the huge operational data
stores (contain all executed operations) and huge audit trails
(contain all executed processes) the space requirements in
the federation layer are enormous. To give an idea of the
needed space, we show an estimation of the required num-
ber of bridge tables. We assume that in p process models,
on average v variables are handled by a activities and each
variable consists of several elements e. On average each el-
ement matches o operational columns. Hence, the number
of bridge tables can be indicated by BT = p ∗ v ∗ a ∗ e ∗ o.
We also have to consider the number of tuples stored in the
bridge tables. This number depends on the number of pro-
cess instances i and on the number of related operational
tuples ot for each matched variable element. So we receive
a total space of SBT = p ∗ v ∗ a ∗ e ∗ i ∗ o ∗ ot for the tuples
that are stored in the bridge tables in the federation layer.
This considerable storage consumption may be unneces-
sary, because many correlations and thus many of the tables
are not needed for analysis, as long as we do not plan to op-
timize the corresponding activities. Another disadvantage is
the required adaption of the warehouse schema during ETL.
Instead of only loading new matches into the match table,
Business impact analysis—a framework for a comprehensive analysis and optimization of business processes
Table 3 Evaluation of BIA WH architectures
each time a new process model has been executed also new
bridge tables have to be created for the warehouse. Thus,
not only the warehouse but also the ETL process has to be
adapted dynamically. Despite these disadvantages that the
warehouse with bridge tables holds compared to the match
table (Table 2, Complexity of ETL and Data volume), the
next section shows how one may benefit from it during anal-
ysis.
7.2 Experimental evaluation of query performance
Our experimental setting consists of the federation layer
based on IBM Infosphere Federation Server version 9.7 with
buffer size 30 KB to avoid loading all data into the buffer
pool. It runs on a Windows XP system with two 2.4 GHz
processors and 4 GB of main memory. We independently
varied the data volume in the tables storing the process in-
stances and the operational tuples, ranging from 10k up
to 10000k (k = 1000). The match table was provided in
constant size of 100 matches. In the bridge table solution,
this resulted in 100 bridge tables with a varying number of
rows. In our evaluation, this data volume of match instances
ranged from 10k up to 100k rows. It is dependent on the data
volume of process and operational data, i.e., it is unlikely to
have a high number of operational and process tuples and at
the same time a low number of rows in the bridge table.
In our experiments, we evaluate two classes of analy-
ses: analysis queries formulated as arbitrary SQL statements
(Query type I) and analysis queries using BIA operators
(Query type II). Table 3 shows the runtime of a typical rep-
resentative query for either query class on each BIA WH ar-
chitecture. These queries join operational data of a common
business warehouse with process data of a business process.
The representative query is based on a thorough analysis of
common business processes, e.g., those defined in [30]. As
we focus on the analysis of one match per process these
queries are adequate and it is not relevant which and how
many activities as well as which other operational matches
the analyzed processes have.
83
For query type I, the schema of all warehouse tables has
to be well-known. In the warehouse with bridge tables, we
only need two joins between table businessobjectelement,
a bridge table and an operational table to receive all tuples
for one variable element and all attributes in the operational
table of its related operational element. For the example il-
lustrated in Fig. 7, the following query links car class in-
formation to process variables using tables Automobile and
BridgeTable_CarModel. For simplicity, all nicknames to the
source attributes are named just as the original attributes:
SELECT A . AID , A . CLASS , A . COLOR , A . PLATE
FROM BUSINESSOBJECTELEMENT E NATURAL JOIN
B RIDGE TABLE _C AR M ODEL NATURAL JOIN
AUTOMOBILE A
In the architecture with the match table, queries of query
type I additionally join the tables businessobject, workflow
and activityexecution to receive the matching instance data
(cf. Figs. 5 and 6):
SELECT A . AID , A . CLASS , A . COLOR , A . PLATE
FROM BUSINESSOBJECTELEMENT E NATURAL JOIN
BUSINESSOBJECT B NATURAL JOIN
ACTIVITYEXECUTION F NATURAL JOIN
WORKFLOW P NATURAL JOIN
AUTOMOBILE A
WHERE A . CLASS = E . VALUE AND
E . ELEMENTNAME = ‘ CAR . MODEL’ AND
P. ACTIVITYID = ‘C AR H AND OVER ’ AND
P. PROCESSID = ‘C AR S ELECTION P ROCESS ’ AND
B . NAME = ‘S ERVICE I NFO ’
As our goal is to compare both BIA WH architectures and
show how their different mappings influence query runtime,
we only show the ratio between the query runtime on both
architectures in Table 3 instead of illustrating the absolute
time for query execution. Each entry in Table 3 is based on
the average of 10 measurements for each architecture and
Query.
As one can see in the row for Query I, the query based on
the match table always takes longer than the solution using
bridge tables. Especially when the data volume in the pro-
cess tables is much higher than in the operational and bridge
tables (results in columns 4, 7, 8, 9), the difference in ex-
ecution time becomes very large. This result was expected,
because Query I needs three additional joins between the
huge process data tables (businessobject, activityexecution,
workflow) for the BIA WH with match table. It would take
even longer if cleansing steps become necessary, because
in the architecture with match table cleansing is part of the
analysis phase. However, for the data in our measurements
cleansing is not needed. Overall, arbitrary queries are rated
lower for the match table solution than the bridge tables in
Table 2.
84
The architecture with bridge tables can be used for analy-
sis in a straightforward way without any restrictions. We are
able to perform all standard OLAP and data mining opera-
tions combining data from the process and the operational
side. On the BIA WH with a match table this integration
has to be managed during analysis. The BIA operators are
able to perform this integration as part of the query execu-
tion. Considering the three main performance indicators [8],
they reflect the most common queries needed for the inte-
grated analysis of process data and operational data. A typ-
ical representative for query type II is an operator that an-
alyzes the process side and delivers associated operational
data, e.g. car class for variable CarModel. It starts on the
process side to find operational attributes for the given pro-
cess variable element CarModel and it is unknown to the
user that the related operational column is called class. The
following query employing the BIASUBALL operator helps
the user to retrieve information from this operational column
anyway.
SELECT * their usability (Table 2). In the end the analyst has to decide
FROM BIASUBALL ( INPUTDATA . CAR . MODEL ,
CARSELECTIONPROCESS , CARHANDOVER )
This query can be used in both architectures. But on a BIA
WH with a match table, such a combined analysis would not
be possible without the BIA operators. Applying BIASUB-
ALL to variable CarModel as well as to the identifier of its
activity and process, operational attributes that are matched
with this variable can be returned. Additionally, all other op-
erational attributes that are contained in the operational ta-
ble of the matched attribute are returned as well. Hence, the
query results in tuples showing the ID of each activity in-
stance of CarHandOver in the CarSelectionProcess with its
element InputData.Car.Model as well as the matching oper-
ational attributes plus the other attributes in the operational
table.
The resulting tuples are equal in the match table and
the bridge table architecture. In both architectures, Query II
needs to join the same process data tables and operational
tables, because the operator has to start from the process ta-
bles to look for the right variable instances, before it is able
to find out the matchable operational tables that have to be
joined. Line Query II in Table 3 shows that the execution
time for Query II is similar in both architectures, we illus-
trate this fact as 0 in Table 2. Only in the first three queries
on a small data volume the difference is bigger. There is a
overhead using the match table architecture here that has to
join all elements with the operational match partner based
on their values, instead of just joining the few tuples already
extracted in the bridge table architecture. That would be dif-
ferent if we would not use our defined naming for the bridge
tables. Hence, Query II only needs to compare the bridge
table names with the element names to find the right bridge
S. Radeschütz et al.
tables for the joins. Otherwise, it would be a lot more time
consuming to find the right bridge table.
7.3 Discussion of usability
Another aspect in the comparison of the two architectures
is their usability for the warehouse analyst. The bridge ta-
ble architecture is better usable for formulating ad-hoc SQL
queries on the mapping between process and operational
data, as they are based on bridge tables with a common
structure. The queries can be formulated based on standard
SQL background knowledge. In contrast, the BIA WH with
a match table contains much less tables due to the fact, that
all matches are stored in this match table instead of creating
a new bridge table for each match. Thus, it makes it much
easier for an analyst to keep the overview of the available
tables. However, as the complexity of the queries is bigger
on the BIA WH with match table, also more background
knowledge for formulating the queries is necessary. Alto-
gether, both architectures balance each other in respect to
himself what aspects are better suitable to his needs.
7.4 Discussion of BIA operators
The BIA operators support analysts in various ways to run
holistic analyses that cover process data as well as opera-
tional data. First, they allow to efficiently handle data from
operational sub-dimensions. Consider in our example an an-
alyst who does not know the matching operational table and
columns for the variable element InputData.Car.Model in
the CarSelectionProcess. In this case, standard SQL queries
like those shown in this section are not possible, because
in both BIA WH architectures, we need a loop over all op-
erational tables of the matched operational columns to add
them dynamically to the from clause of the SQL query.
Secondly, the operators facilitate frequently needed analysis
queries. In particular, they help to analyze the main perfor-
mance indicators for processes, i.e., cost, time and quality
[8]. This is in particular reflected in specific operators to an-
alyze process duration and process exceptions. Finally, we
have shown in Sect. 6 that the BIA operators are perfectly
suited to prepare data warehouse data for data mining algo-
rithms. The BIA operators allow to extend the data basis for
data mining tasks by considering process data as well as op-
erational sub-dimensions. Hence, by using these operators
the user is able to describe more detailed and more target-
oriented types of analysis.
8 Conclusion
For performing the extended analysis techniques OLAP and
data mining for BIA, we developed two warehouse architec-
Business impact analysis—a framework for a comprehensive analysis and optimization of business processes
tures that hold both operational data and process data dimen-
sions. The architectures differ in their mapping between the
process data and their related operational data (match table
vs. bridge tables). We demonstrated the usefulness of the ar-
chitectures each depending on different aspects that the user
prefers to handle. The architecture with a match table turns
out to be better in most areas: it allows for a more efficient
ETL processing and it needs less space to store the matches.
The bridge tables allow, however, for more efficient query
processing if the analyst already knows the matches between
operational and process model. Then he can use the correct
bridge table with its stored instance data without having to
join as well the workflow table and fact table to get the ex-
ecution instances. Usability and execution time of queries
where the matches are unknown to the analyst is balanced in
both architectures.
We introduced a set of operators that allow to define effi-
cient OLAP queries without knowing the details of matches
between operational data and process data. The BIA opera-
tors put the user in the position of phrasing simple economic
queries to the BIA WH. We showed how data mining anal-
yses benefit from these operators as well.
In our future work, we will further explore how we can
utilize statistics from earlier analysis results in the ware-
housing phase that are also used in the analysis phase for
the preselection of certain attributes and their data. Statis-
tics could also be used for the creation of the BIA WH.
In this way, statistics about relevant operational attributes
could help to reduce the amount of bridge tables. Another
future step is to develop concrete optimization patterns that
apply the results gained by BIA for process improvement
and reengineering.
References
1. Agrawal R, Gunopulos D, Leymann F (1998) Mining process
models from workflow logs. In: Proc of extending database tech-
nology, London, UK
2. Agrawal R, Imielinski T, Swami A (1993) Mining association
rules between sets of items in large databases. In: Proceedings
of the 1993 ACM SIGMOD international conference on manage-
ment of data, Washington, DC, pp 26–28
3. Bruckner RM, List B, Schiefer J (2002) Striving towards near real-
time data integration for data warehouses. In: Proc of data ware-
housing and knowledge discovery, France
4. Casati F, Castellanos M, Dayal U, Salazar N (2007) A generic
solution for warehousing business process data. In: Proc very large
data bases, Austria
5. Castellanos M, Casati F, Dayal U, Shan M-C (2004) A compre-
hensive and automated approach to intelligent business processes
execution analysis. Distrib Parallel Databases 16(3):239–273
6. Champy J (1995) Reengineering management. Harper Collins,
New York
7. Chaudhuri S, Dayal U (1997) An overview of data warehousing
and OLAP technology. SIGMOD Rec 26(1):65–74
8. Dumas M et al (2005) Process-aware information systems: bridg-
ing people and software through process technology. Wiley, New
York
85
9. Eder J, Olivotto GE, Gruber W (2002) A data warehouse for work-
flow logs. In: Proceedings of the first international conference on
engineering and deployment of cooperative information systems,
EDCIS’02. Springer, London, pp 1–15
10. Hammer M (1990) Reengineering work: don’t automate, obliter-
ate. Harv Bus Rev 68(4):104–112
11. Han J (2005) Data mining: concepts and techniques. Morgan
Kaufmann, San Mateo
12. ISO (2003) ISO/IEC 9075-2. Information technolog—Database
languages—SQL. Part 2: Foundations
13. Jain AK, Murty MN, Flynn PJ (1999) Data clustering: a review.
ACM Comput Surv 31(3):264–323
14. Jeng J-J, Schiefer J, Chang H (2003) An agent-based architec-
ture for analyzing business processes of real-time enterprises. In:
EDOC, pp 86–97
15. Johansson HJ, McHugh P, Pendlebury A, Wheeler W (1993) Busi-
ness process reengineering: breakpoint strategies for market dom-
inance. Wiley, New York
16. Kamber M, Han J, Chiang J (1997) Metarule-guided mining of
multi-dimensional association rules using data cubes. In: Proceed-
ings of the third international conference on knowledge discovery
and data mining (KDD)
17. Mansar SL, Reijers HA (2005) Best practices in business pro-
cess redesign: validation of a redesign framework. Comput Ind
56(5):457–471
18. Mansmann S, Neumuth T, Scholl MH (2007) Multidimensional
data modeling for business process analysis. In: Proceedings of
the 26th international conference on Conceptual modeling, ER’07.
Springer, Berlin, pp 23–38
19. McCoy D (2002) Business activity monitoring: calm before the
storm. Technical report LE15-9727, Gartner
20. Michie D, Spiegelhalter DJ, Taylor CC, Campbell J (eds) (1994)
Machine learning, neural and statistical classification. Ellis Hor-
wood, Chichester
21. Müller R, Greiner U, Rahm E (2004) Agentwork: a workflow sys-
tem supporting rule-based workflow adaptation. Data Knowl Eng
51(2):223–256
22. Niedermann F, Radeschuetz S, Mitschang B (2010) Deep business
optimization: a platform for automated process optimization. In:
Proc BPSC
23. OASIS Standard (2007) Web services business process execu-
tion language, version 2.0. Available: http://docs.oasis-open.org/
wsbpel
24. Parsons L, Haque E, Liu H (2004) Subspace clustering for high di-
mensional data: a review. ACM SIGKDD Explor Newsl 6(1):90–
105
25. Poole J, Chang D, Tolbert D, Mellor D (2003) Common ware-
house metamodel developer’s guide. Wiley, New York
26. Radeschütz S, Mitschang B (2009) Extended analysis techniques
for a comprehensive business process optimization. In: KMIS,
pp 77–82
27. Radeschütz S, Mitschang B, Leymann F (2008) Matching of pro-
cess data and operational data for a deep business analysis. In:
Proc of I-ESA, Germany
28. Radeschütz S et al (2010) BIAEditor—matching process and op-
erational data for a business impact analysis. In: Proc EDBT conf
29. Rokach L, Maimon O (2005) Top-down induction of decision
trees classifiers—a survey. IEEE Trans Syst Man Cybern, Part C,
Appl Rev 35(4):476–487
30. Rosettanet (2011) Overview: clusters, segments, and pips, version
02.13.00. http://www.rosettanet.org
31. Rubin V, Günther CW, van der Aalst WMP, Kindler E, van Don-
gen BF, Schäfer W (2007) Process mining framework for software
processes. In: Proc of international conference on software pro-
cess, USA
32. Sayal M, Casati F, Dayal U, Shan M-C (2002) Business process
cockpit. In: Proc of very large data bases, China
86
33. Schiefer J, Jeng J-J, Bruckner RM (2003) Real-time workflow
audit data integration into data warehouse systems. In: ECIS,
pp 1697–1706
34. Shahzad K, Johannesson P (2009) An evaluation of process ware-
housing approaches for business process analysis. In: Proceedings
of the international workshop on enterprises & #38; Organiza-
tional modeling and simulation, EOMAS’09. ACM, New York
35. Uysal I, Güvenir HA (1999) An overview of regression techniques
for knowledge discovery. Knowl Eng Rev 14(4):319–340
36. van der Aalst WMP (2001) Re-engineering knock-out processes.
Decis Support Syst 30(4):451–468
37. van der Aalst WMP (2011) Process mining: discovery, confor-
mance and enhancement of business processes. Springer, Berlin
38. van der Aalst WMP, van Dongen BF, Herbst J, Maruster L,
Schimm G, Weijters AJMM (2003) Workflow mining: a survey
of issues and approaches. Data Knowl Eng 47(2):237–267
39. W3C. Semantic annotations for WSDL and XML schema. Avail-
able: http://www.w3.org/TR/sawsdl/
S. Radeschütz et al.
40. W3C Submission: web service modeling language. Available:
http://www.w3.org/Submission/WSML/
41. W3C Recommendation: web ontology language (2004) Available:
http://www.w3.org/TR/owl-ref/
42. Weerawarana S, Curbera F, Leymann F, Storey T, Ferguson DF
(2005) Web services platform architecture. Prentice Hall, New
York
43. Wetzstein B, Leitner P, Rosenberg F, Brandic I, Dustdar S, Ley-
mann F (2009) Monitoring and analyzing influential factors of
business process performance. In: EDOC, pp 141–150
44. zur Muehlen M (2004) Workflow-based process controlling.
Foundation, design, and application of workflow-driven process
information systems. Logos, Berlin
45. zur Muehlen M, Shapiro R (2009) Business process analytics.
In: Handbook on business process management, vol 2. Springer,
Berlin