To view PDF files

You need Adobe Reader 7.0 or later in order to read PDF files on this site.
If Adobe Reader is not installed on your computer, click the button below and go to the download site.


Business Process Optimization Support Tool for Visualizing Operating Procedures by Using Execution Logs of Enterprise Information Systems

Shiro Ogasawara, Hiroyuki Tanaka, Kimio Tsuchikawa,
Satoru Sugimoto, and Tsutomu Maruyama


We have developed a tool that can automatically reconstruct and visualize actual business processes solely by using execution logs stored in various types of enterprise information systems.

NTT Access Network Service Systems Laboratories
Yokosuka-shi, 239-0847 Japan

1. Introduction

In the current competitive business environment, enterprises need to provide their services and products efficiently, i.e., quickly, inexpensively, and reliably. In modern enterprises, it is common for many sectors, including sales promotion, order acceptance, inventory control, and procurement, to all be involved in providing customers with their services and products, and each sector performs various tasks. Therefore, these sectors and tasks should be efficiently coordinated and managed.

For this purpose, enterprises define business process models, like the example shown in Fig. 1. The model specifies operating procedures related to the kinds of tasks that should be executed for orders and specifies how the orders should be routed among the tasks. In addition, enterprises develop and use various information systems ranging from application tools on personal computers to database systems on gigantic servers in response to the predefined business process models.

Fig. 1. Example of a business process model.

In actual businesses, however, workers often face unexpected circumstances when dealing with diverse and complicated orders, and it is very difficult to define detailed business process models that cover both normal and exceptional cases before the systems are developed. In addition, some workers might not fully understand how to use the systems. In such situations, the systems tend to be used in ways that differ from the predefined business process models. Furthermore, the types of orders and the number of orders vary as stock and market demand change. Workers gradually become skilled and change their operating procedures so they can complete their tasks more efficiently. Thus, both actual and ideal business processes gradually deviate from the predefined models.

Therefore, to conduct businesses efficiently using enterprise information systems, it is essential to understand actual business processes, find their defects, and attempt to eliminate them, which is known as business process management (BPM).

To achieve continuous BPM, we have developed a business process optimization support tool called BPOST [1], which we describe below after reviewing the actual circumstances of BPM and existing techniques.

2. Difficulties with BPM: Understanding the actual business situation

For decades, enterprises have devoted a lot of effort to business efficiency. The approaches they have used include business process reengineering in the 1990s and BPM in recent years. Although these approaches are sometimes distinguished from one another in terms of scale, period, and frequency, most of them follow a plan-do-check-act (PDCA) cycle to achieve continuous improvement.

(1) Plan: Design or revise business process models and systems

(2) Do: Implement the plan and conduct business

(3) Check: Understand the actual business situations and measure their performance

(4) Act: Analyze defects and devise ways to overcome them

A broad range of software packages designed to support BPM has been provided by system developers. Modeling tools and business process simulators are useful for designing and revising the models and for predicting the effects of the devised solutions, respectively. BPM engines, or workflow engines, are widely used to control operating procedures according to predefined models.

On the other hand, actual business situations have typically been understood through interviews and observations including time & motion studies using stopwatches, and performance evaluation has depended on the results of those investigations. The third step of the PDCA cycle, which uses interviews and observations, involves many consultants, managers, and workers and requires a lot of time and effort. Moreover, while individual workers might be familiar with their own tasks and defects, they rarely have comprehensive knowledge of the entire business. Because of this problem and the infeasibility of performing exhaustive interviews and observations, the results of such investigations have shortcomings in terms of coverage and objectivity.

3. Utilization of execution logs

To establish a way of easily understanding actual business situations with wide coverage and high objectivity, we have been working on techniques for supporting business analysis by using the execution logs stored in systems [2]. Execution logs can be easily obtained because they are automatically accumulated in most systems for the purposes of crash recovery, debugging, and transaction management. In addition, investigation results with wide coverage and high objectivity can be easily obtained because execution logs directly reflect what actually happened when orders were dealt with regardless of the worker involved. Execution logs are now commonly used for business analysis. In fact, key terms such as business process visualization have recently gained currency, and many BPM engines are accompanied by tools that allow business analysts to understand and monitor actual business situations. Through the use of predefined business process models, these tools visually indicate which task is being executed for each order and how each order is routed among the tasks in real time. These tools can effectively complement costly interviews and observations. However, the systems of an enterprise are rarely all under the control of a single BPM engine, although some systems are coordinated with one another and a few groups of systems are formed. Since a monitoring tool that accompanies a BPM engine is exclusive to that BPM engine, it cannot be applied to a wide-ranging business across these different groups.


4.1 Reconstruction and visualization of actual business processes

To understand the actual business situations across several systems in different groups, we have devised a method for estimating, reconstructing, and visualizing actual business processes by using execution logs stored in the systems, without any knowledge of the processes themselves [3]. For the massive number of orders in execution logs, our method examines which tasks were executed for which order in which sequence to determine the task interdependence, and it estimates an individual business process for every order so that all of the individual business processes conform to this interdependence. By overlapping common parts of the individual business processes, our method derives and visualizes a business process model that inclusively represents which tasks were actually executed for all past orders and how the orders were actually routed among the tasks (Fig. 2). Our method can reconstruct those business processes in which some tasks are executed by different workers in parallel for the same order because it extracts the task interdependence relationships from all the execution logs and uses them as constraints when estimating individual business processes, rather than just connecting one task to the next.

Fig. 2. Summary of our method for reconstructing actual business processes by using execution logs.

We applied our method to several real businesses and found that many orders were handled in exceptional operating procedures that deviated from the predefined business process models. Moreover, these exceptional procedures varied greatly depending on the departments or branches responsible for the businesses. We also used our method to confirm that discrepancies between actual and predefined business processes were gradually reduced and that the business performance was improved after the application of countermeasures.

4.2 Architecture

The overall architecture of BPOST is shown in Fig. 3. To understand the actual business situation using BPOST, one must first import execution logs into BPOST. In general, execution logs are recorded in system log files or databases. The way log files or databases are imported and transformed depends on their content and format. It is also subject to limitations on the timing with which the systems can output the execution logs, as well as the requirements for analysis granularity, i.e., whether macro or micro business processes are needed. Moreover, in aggregation and statistical processing, business performance measures, such as lead time or working time, and grouped fields, such as branch offices or order types, depend on the goals of BPM and the achievement levels.

Fig. 3. BPOST architecture.

To meet these various analysis conditions, BPOST is composed of common engines that are independent of the analysis conditions and adapters that are dependent on them. It can handle any log file or database format. By switching adapters for the import and transformation of log files or databases and those for the aggregation and statistical processing of execution logs, one can apply BPOST to different businesses without needing to make any changes to the systems.

4.3 Useful functions for business analysis

BPOST has the following functions for advanced business analysis in addition to the abovementioned function for the reconstruction and visualization of actual business processes.

(1) Comparison of business process models

This function compares two business process models, detects differences, and reveals them (Fig. 4). Because there are several graph structures made up of nodes and edges that express the same business process model, unnecessary differences would be detected if two graph structures expressing two models were simply compared. BPOST compares combinations of transition sources and combinations of transition destinations of a model with those of another model for every task. Consequently, it detects the differences between two models correctly. It lets business analysts, i.e., consultants, managers, and workers, easily find unexpected operating procedures when actual and predefined business process models are compared. It also shows them differences between the operating procedures of different branch offices and their changes over time.

Fig. 4. Comparison of business process models.

(2) Classification of orders depending on process patterns

This function classifies orders according to process patterns. Whether one process pattern is the same as another is determined according to operating procedures related to only tasks of interest to business analysts: any differences related to other tasks are ignored (Fig. 5). This classification manner gives business analysts a summary of how important tasks were executed in actual business processes, so, as described in (3), they can evaluate the impact of operating procedures on business performance.

Fig. 5. Classification of orders according to process patterns.

(3) Aggregation and statistical processing associated with business process analysis

For example, business analysts can evaluate the impact of operating procedures on lead time by using the results of classification according to process patterns as grouped fields of an aggregation with respect to lead time (Fig. 6). To obtain the same aggregation results with the existing techniques, they would have to determine how orders should be classified and develop exclusive adapters for transformation by implementing the classification algorithm beforehand. BPOST, on the other hand, can combine the business process analysis results and the aggregation and statistical processing results, so it enables interactive trial-and-error analysis. Therefore, business analysts can determine how orders should be classified and which classification result should be used as grouped fields during analysis, and they can effectively narrow down defects and their causes in business processes.

Fig. 6. Aggregation and statistical processing associated with business process analysis.

4.4 Role in BPM

Unfortunately, if BPOST is used alone, it is impossible for business analysts to understand why operating procedures deviated from predefined business process models or why some tasks were executed again and again because not all the information about actual business situations is contained in the execution logs. In particular, the logs contain no information about the intentions of workers. However, the prior understanding of actual business processes and their impact on business performance provided by BPOST can enable improvements to be made in the effectiveness of interviews and observations. Moreover, BPOST strongly supports continuous evaluation and monitoring of the effects of the introduction and modification of enterprise information systems.

5. Concluding remarks

With the collaboration of NTT Group companies, we will promote the application of BPOST to NTT’s businesses and help to make them more efficient and provide customers with better services. In addition, we will collaborate with companies working on systems consultation and integration to expand the application domain beyond the communication industry.


[1] A. Inoue, S. Ogasawara, and K. Tsuchikawa, “Business Process Optimization Support Tools based on Operation Logs,” Technical report of IEICE. TM, Vol. 107, No. 448, pp. 51–56, 2008 (in Japanese).
[2] S. Miyagawa, S. Ogasawara, K. Tayama, T. Maruyama, and T. Yamamura, “Using History Information of a Workflow-OSS for Business Process Reengineering of an Optical Access Network Element Allocation,” Technical report of IEICE. TM, Vol. 104, No. 35, pp. 1–6, 2004 (in Japanese).
[3] S. Ogasawara, K. Tayama, and T. Yamamura, “Estimating Structures of Business Process Models from Execution Logs,” Proc. of the 10th IEEE Intl. Conf. on Enterprise Distributed Object Computing, pp. 106–115, Hong Kong, China, 2006.
Shiro Ogasawara
Research Engineer, NTT Access Network Service Systems Laboratories.
He received the B.E. and M.E. degrees in aeronautics and astronautics from the University of Tokyo in 2001 and 2003, respectively. He joined NTT in 2003 and is currently working on operations support systems and BPM techniques. He is a member of the Institute of Electronics, Information and Communication Engineers (IEICE) of Japan and the Japanese Society for Artificial Intelligence.
Hiroyuki Tanaka
Research Engineer, NTT Access Network Service Systems Laboratories.
He received the M.S. degree in bioinformatics from Nara Institute of Science and Technology in 2006. From 2006 to 2008, he worked for a service management department of a branch office of NTT WEST. He joined NTT in 2008 and is currently working on operations support systems.
Kimio Tsuchikawa
Research Engineer, NTT Access Network Service Systems Laboratories.
He received the B.E. and M.E. degrees in applied physics from Nagoya University, Aichi, in 2000 and 2002, respectively. He joined NTT in 2002 and is currently working on operations support systems and BPM techniques.
Satoru Sugimoto
Senior Research Engineer, Supervisor, NTT Access Network Service Systems Laboratories.
He received the B.E. and M.E. degrees in electrical engineering from Gunma University in 1983 and 1985, respectively. He joined NTT in 1985 and engaged in R&D of access network systems and network operations support systems. He is a member of IEICE.
Tsutomu Maruyama
Senior Research Engineer, Supervisor, NTT Access Network Service Systems Laboratories.
He received the B.E. degree in information engineering from Shinshu University, Nagano, in 1986. He joined NTT Access Network Service Systems Laboratories in 2000 and is currently studying operations support systems.