Change projects try to optimize business processes and structures and seek to make better use of the resources across the enterprise. In these change projects, business process models are commonly applied to represent both the current and future situation. These models have the ability to show how resources like employees, data, and departments are related to business operations. However, existing business process models lack the abilities both to show load distribution through process flows and to treat capabilities and performance of resources individually. We will in this paper describe how identifiers of past business performance can be incorporated into business models, thus providing a communicative source of information where many potential improvements can be grasped instantly. The approach is supported by an application called Enterprise Visualization Suite that analyzes transactional data from SAP R/3 and extract empirical models of the business flow.
Information technology plays an important role in change projects [
We will in this paper describe how information based on empirical performance data can be incorporated into business models, thereby providing a communicative source of information where potential improvements can be grasped instantly and analyzed more in detail in related statistical reports.
Related work is found in simulation modelling and process mining activities.
Business simulation models are able to represent the dynamics of business
processes, such as, the build up of queues [
The activity of designing business processes modeling is not new - there are articles and studies dating back to the 1940s and earlier about workflow design. Although dozens of models exist within this domain, little effort is done to show empirical analyses of past business process performance by use of models. Empirical business models incorporates indicators like execution times and load distributions into maps of business flows; making the business models semantically rich enough to point out both how business actually is executed and measures of strengths and weaknesses in the present process structure. The goal of empirical business models is to create a communicative source of information with reliable measures of improvement potentials. Having structured collections of past business events available, empirical business models may easily be extended with more detailed statistical reports.
Enterprise Visualization Suite (EVS) is a web-based process mining tool that extracts data of historic business executions from enterprise information systems (EIS) and constructs empirical business models and performance analyses. EVS aims at giving an exact picture of the AS-IS situation and a foundation for both defining measurable goals for the TO-BE situation and performing delta analyses. We will use examples from this process mining tool to illustrate both potentials and challenges of empirical business models.
An example of how the extracted empirical models are visualized is shown in figure 1. This example shows a decomposed view of the process ”Spare parts processing”. The first of ”Plant maintenance order” or ”Material requirements planning”. Based on the assignment of purchase requisition, a set of Request for Quotations (RFQs) can be created. Based on the RFQs, three options are available; to create an inforecord for the spare parts, to create a contract with the vendor, or to reject the quotation that a vendor has to offer. A Purchase Order (PO) can be created directly from the assigned Purchase Requisition (PR) or on the basis of an inforecord or contract. The creation of the PO is followed up by the activity ”Create goods receipt”, which belongs to the process ”Inventory management”.
Elements at the leaf node level in the process hierarchy are called activities.
A process is a set of activities or sub processes. Processes are shown as arrowed
boxes while activities are shown as boxes with rounded corners. Activities are
directly connected to the executable applications in the EIS. Both executions of
activities and their dependencies are found in the event logs. The dependencies
are found by identifying which resources the activities consumes and produces.
The dependencies between a set of processes are defined as the aggregation of
dependencies between their sub-activities [
The size of the pie-chart on each activity indicates the number of executions. An activity with many executions implies a large pie-chart. The size of the darkgray pie in the pie-chart indicates average execution time for the activity. In the example in figure 1, we can see that ”Assign purchasing requisition” is run most frequently, while ”Create contract for spare parts” is the most time consuming activity. There are less RFQs being processed than assigned purchasing requisitions (smaller piechart), since some purchase orders are created directly from purchasing requisitions without sending RFQs first. Both magnitude of number of executions and execution times are shown relative to the maximum and minimum values present in the model.
The goal of the bar-charts inside each activity is to visualize improvement potentials and value variations of execution time and frequency. The lower green area illustrates the value span from zero to lowest observed value, while the top of the upper white area illustrates the highest observed value. The top of the red area identify average value for the last month. A short red area implies that the average value for the last month is close to the lowest value that ever has been observed. In the example in figure 1, we can see that this is valid for the activity ”Create contract for spare parts”, where the average execution time for the last month is pretty close to the minimal observed value.
EVS is able to show business processes at multiple aggregation levels. An example of such aggregation is shown in figure 1, where six of the activities are assigned to the process ”Spare parts processing”. The user can further navigate upwards to higherlevel processes and do drill-down analysis of processes and activities in other process areas.
To enhance the expressiveness, EVS also exploits interactive opportunities of the web. For each activity and process the user can get information about business documents and resources that an activity or process consumes and produces, user roles that have been involved in the activity or process execution, and departments of where an activity or process has been executed.
The empirical data sources that are collected in order to construct the business models may also be connected to external information sources, and thus form a platform for cause analyses. Such external information sources can be properties like involved customers, vendors, distribution channels, shipping categories, sales regions, routes, principals, priorities, number of items, controlling area, etc. Many relevant causes of specific business behavior are found as properties in the header and items of business documents that are involved in the process executions. Cause analyses try to give statistical answers to why specific business behavior occurs. Such questions include identifications of reasons to why similar business processes are executed differently or give different results. 3
The issue of managing change and innovation in organizations is important due
to competitive pressure and changing business conditions. Over the years we
have seen the introduction of a number of change philosophies, including Total
Quality Management (TQM), Just in Time (JIT), Business Process
Reengineering (BPR), and Process Innovation (PI). Even though they are rooted in
different disciplinary or functional areas within management, they tend so share some
common features. They advocate a company-wide approach to managing change,
intend to improve business performance, and require strong management
support [
It is common to use process modeling techniques to support the analysis of
AS-IS situations and propose possible TO-BE situations. As pointed out [
Even more problematic is the analysis of performance issues. There are efficiency problems that stem from structural weaknesses and can be detected from traditional business process models. For example, purchasing processes that enforce approval procedures for both requisitions and purchase orders may involve unnecessary double checking of purchasing needs. If too many departments are involved in the same process and departmental interfaces are vaguely defined, the process outcome is likely to suffer.
Most performance problems are however more complex to detect and analyze. In addition to assessing the way processes are carried out and the resources available to the organization, the project needs to investigate the performance of their resources, the external load on the organization, and factors affecting the quality of the organization’s products and services.
The empirical business models that the EVS application provides valuable input to change projects based on the organization’s EIS. Adding empirical data from previously run business transactions to models of their business processes, we can immediately see the amount of work carried out in the different parts of the process. Whereas the models themselves are annotated with aggregated empirical data, the user can drill down to more detailed analysis of performance issues when that is needed. Process variation is categorized and automatically analyzed in terms of characteristics and possible explanations.
Where traditional approaches can only discuss whether a certain number of people would be or should be enough to carry out a specific task, we can now measure the performance of these people and tell us whether they have been able to do this task according to the standards set. Moreover, we can also detect bottlenecks by analyzing how their performance depends on other parts of the system. How many customer orders is the organization able to deal with, for example, without getting too delayed with their deliveries? If more orders come in, which part of the organization is most likely to be delayed with their part of the process? What characterizes and causes situations where the wrong product has been delivered or it has taken an unreasonable long time to ship it? By analyzing these kinds of questions and getting accurate empirically based answers from EVS, the change project has a better chance of addressing the real problems of the AS-IS situation and come up with a more efficient design of the organization’s structures and processes. Take a look at Figure 1. As seen from the pie chart, it takes substantially longer time to create contracts for spare parts than info records. From a reengineering point of view, this is something that has to be investigated in some more depth. 4
The claim of this paper is that business process models, which are applied in change projects, are not semantically rich enough to perform comparable interpretations of how the processes actually have been performed. In order to make an enrichment of such models, an approach for extracting and incorporating empirical performance measures into models of business flow has been presented. These empirical measures enable abilities to communicatively present how loads and execution times are distributed throughout the process flows.
Practical experiences from multiple organizations and change projects are a necessity in order to decide which measures that should be present in the models and how to visualize them. In such projects we will investigate the practical relevance and representative validity of proposed results from cause analysis. Our approach for extracting data from event logs in and constructing empirical business models has mainly two limitations. That is, the ability to describe business processes that are not supported by the EIS, and to describe qualitative measures of process executions.
EVS is currently being evaluated by reengineering consultants and implemented at a Norwegian company. The goal of these projects is to find the most appropriate and applicable way of including measures from empirical data analyses in business models.