داده کاوی جریان کار : یک بررسی روی مسائل و رویکردها

Many of today’s information systems are driven by explicit process models. Workflow management systems, but also ERP, CRM, SCM, and B2B, are configured on the basis of a workflow model specifying the order in which tasks need to be executed. Creating a workflow design is a complicated time-consuming process and typically there are discrepancies between the actual workflow processes and the processes as perceived by the management. To support the design of workflows, we propose the use of workflow mining. Starting point for workflow mining is a so-called “workflow log” containing information about the workflow process as it is actually being executed. In this paper, we introduce the concept of workflow mining and present a common format for workflow logs. Then we discuss the most challenging problems and present some of the workflow mining approaches available today.

During the last decade workflow management technology [2], [4], [21], [35] and [41] has become readily available. Workflow management systems such as Staffware, IBM MQSeries, COSA, etc. offer generic modeling and enactment capabilities for structured business processes. By making process definitions, i.e., models describing the life-cycle of a typical case (workflow instance) in isolation, one can configure these systems to support business processes. These process definitions need to be executable and are typically graphical. Besides pure workflow management systems many other software systems have adopted workflow technology. Consider for example Enterprise Resource Planning (ERP) systems such as SAP, PeopleSoft, Baan and Oracle, Customer Relationship Management (CRM) software, Supply Chain Management (SCM) systems, Business to Business (B2B) applications, etc. which embed workflow technology. Despite its promise, many problems are encountered when applying workflow technology. One of the problems is that these systems require a workflow design, i.e., a designer has to construct a detailed model accurately describing the routing of work. Modeling a workflow is far from trivial: It requires deep knowledge of the business process at hand (i.e., lengthy discussions with the workers and management are needed) and the workflow language being used. To compare workflow mining with the traditional approach towards workflow design and enactment, consider the workflow life cycle shown in Fig. 1. The workflow life cycle consists of four phases: (A) workflow design, (B) workflow configuration, (C) workflow enactment, and (D) workflow diagnosis. In the traditional approach the design phase is used for constructing a workflow model. This is typically done by a business consultant and is driven by ideas of management on improving the business processes at hand. If the design is finished, the workflow system (or any other system that is “process aware”) is configured as specified in the design phase. In the configuration phases one has to deal with limitation and particularities of the workflow management system being used (cf. [5] and [65]). In the enactment phase, cases (i.e., workflow instances) are handled by the workflow system as specified in the design phase and realized in the configuration phase. Based on a running workflow, it is possible to collect diagnostic information which is analyzed in the diagnosis phase. The diagnosis phase can again provide input for the design phase thus completing the workflow life cycle. In the traditional approach the focus is on the design and configuration phases. Less attention is paid to the enactment phase and few organizations systematically collect runtime data which is analyzed as input for redesign (i.e., the diagnosis phase is typically missing).The goal of workflow mining is to reverse the process and collect data at runtime to support workflow design and analysis. Note that in most cases, prior to the deployment of a workflow system, the workflow was already there. Also note that in most information systems transactional data is registered (consider for example the transaction logs of ERP systems like SAP). The information collected at run-time can be used to derive a model explaining the events recorded. Such a model can be used in both the diagnosis phase and the (re)design phase. Modeling an existing process is influenced by perceptions, e.g., models are often normative in the sense that they state what “should” be done rather than describing the actual process. As a result models tend to be rather subjective. A more objective way of modeling is to use data related to the actual events that took place. Note that workflow mining is not biased by perceptions or normative behavior. However, if people bypass the system doing things differently, the log can still deviate from the actual work being done. Nevertheless, it is useful to confront man-made models with models discovered through workflow mining. Closely monitoring the events taking place at runtime also enables Delta analysis, i.e., detecting discrepancies between the design constructed in the design phase and the actual execution registered in the enactment phase. Workflow mining results in an “a posteriori” process model which can be compared with the “a priori” model. Workflow technology is moving into the direction of more operational flexibility to deal with workflow evolution and workflow exception handling [2], [7], [10], [13], [20], [30], [39], [40] and [64]. As a result workers can deviate from the prespecified workflow design. Clearly one wants to monitor these deviations. For example, a deviation may become common practice rather than being a rare exception. In such a case, the added value of a workflow system becomes questionable and an adaptation is required. Clearly, workflow mining techniques can be used to create a feedback loop to adapt the workflow model to changing circumstances and detect imperfections of the design. The topic of workflow mining is related to management trends such as Business Process Reengineering (BPR), Business Intelligence (BI), Business Process Analysis (BPA), Continuous Process Improvement (CPI), and Knowledge Management (KM). Workflow mining can be seen as part of the BI, BPA, and KM trends. Moreover, workflow mining can be used as input for BPR and CPI activities. Note that workflow mining seems to be more appropriate for BPR than for CPI. Recall that one of the basic elements of BPR is that it is radical and should not be restricted by the existing situation [23]. Also note that workflow mining is not a tool to (re)design processes. The goal is to understand what is really going on as indicated in Fig. 1. Despite the fact that workflow mining is not a tool for designing processes, it is evident that a good understanding of the existing processes is vital for any redesign effort. This paper is a joint effort of a number of researchers using different approaches to workflow mining and is a spin-off of the “Workflow Mining Workshop”.1 The goal of this paper is to introduce the concept of workflow mining, to identify scientific and practical problems, to present a common format to store workflow logs, to provide an overview of existing approaches, and to present a number of mining techniques in more detail. The remainder of this paper is organized as follows. First, we summarize related work. In Section 3 we define workflow mining and present some of the challenging problems. In Section 4 we propose a common XML-based format for storing and exchanging workflow logs. This format is used by the mining tools developed by the authors and interfaces with some of the leading workflow management systems (Staffware, MQSeries Workflow, and InConcert). 5, 6, 7, 8 and 9 introduce five approaches to workflow mining focusing on different aspects. These sections give an overview of some of the ongoing work on workflow mining. Section 10 compares the various approaches and list a number of open problems. Section 11 concludes the paper.

In this paper, we presented an overview of the various problems, techniques, tools, and approaches for workflow mining. It is quite interesting to see how the five approaches presented in 5, 6, 7, 8 and 9 differ and are driven by different problems. The more formal approach described in Section 5 uses Petri-net theory to characterize the class of workflow models that can be mined. The more heuristic approaches in 6 and 7 focus on issues such as noise and determining the quality of mining result. Unlike the other approaches, the approach in Section 8 takes into account the fact that there may be multiple tasks having the same label. Finally, the approach in Section 9 exploits the block structure (i.e., corresponding AND/XOR splits and AND/XOR joins) of many processes. Each of these approaches has its strengths and weaknesses. Section 10 compared the approaches by focusing on nine aspects (Structure, Time, Basic parallelism, Non-free choice, Basic loops, Arbitrary loops, Hidden tasks, Duplicate tasks, and Noise). This comparison reveals differences and also points out problems that need to be tackled. To join forces and to share knowledge and development efforts, we introduced a tool-independent XML format. This format was given in Section 4 and we would like to encourage other researchers/developers in this domain to use this format.