Business process management: a personal view

Business process management: a personal view

Business process management: a personal view

W.M.P. van der AalstDepartment of Technology Management, Eindhoven University of Technology, Eindhoven, The Netherlands

1.  Introduction

Business process management (BPM) is one of the most existing topics in information, because it addresses the interplay of people and organizations on the one hand, and “process aware software” on the other hand (van der Aalst et al., 2000, 2003b). Particularly interesting are generic tools like workflow management products to support the creation of business process systems. The definition of a business process management system I prefer, is: a generic software system that is driven by explicit process designs to enact and manage operational business processes (van der Aalst et al., 2003a). The system should be process-aware and generic in the sense that it is possible to modify the processes it supports. The process designs are often graphical and the focus is on structured processes that need to handle many cases.

To show the relevance of business process management systems, it is interesting to put them in a historical perspective. Consider Figure 1, which shows some of the ongoing trends in information systems (van der Aalst, 2002; van der Aalst et al., 2003a). This figure shows that current information systems consist of a number of layers. The center is formed by the operating system, i.e. the software that makes the hardware work. The second layer consists of generic applications that can be used in a wide range of enterprises. Moreover, these applications are typically used within multiple departments within the same enterprise. Examples of such generic applications are a database management system, a text editor, and a spreadsheet program. The third layer consists of domain specific applications. These applications are only used within specific types of enterprises and departments. Examples are decision support systems for vehicle routing, call center software, and human resource management software. The fourth layer consists of tailor-made applications. These applications are developed for specific organizations.

Figure 1 Trends relevant for business process management (van der Aalst, 2002)

In 1960s, the second and third layers were missing. Information systems were built on top of a small operating system with limited functionality. Since no generic or domain specific software was available, these systems mainly consisted of tailor-made applications. Since then, the second and third layers have developed and the ongoing trend is that the four circles are increasing in size, i.e. they are moving to the outside while absorbing new functionality. Current operating systems offer much more functionality. Database management systems that reside in the second layer offer functionality which used to be in tailor-made applications. As a result of this trend, the emphasis shifted from programming to assembling of complex software systems. The challenge no longer is the coding of individual modules, but orchestrating and gluing together pieces of software from each of the four layers.

Another trend is the shift from data to processes. The 1970s and 1980s were dominated by data-driven approaches. The focus of information technology was on storing and retrieving information and, as a result, data modeling was the starting point for building an information system. The modeling of business processes was often neglected and processes had to adapt to information technology. Management trends such as business process re-engineering illustrate the increased emphasis on processes. As a result, system engineers are resorting to a more process driven approach.

The last trend we would like to mention is the shift from carefully planned designs to redesign and organic growth. Due to the omnipresence of the Internet and its standards, information systems change on-the-fly. As a result, fewer systems are built from scratch. In many cases, existing applications are partly used in the new system. Although component-based software development still has its problems, the goal is clear and it is easy to see that software development has become more dynamic.

The trends shown in Figure 1 provide a historical context for BPM systems. BPM systems are either separate applications residing in the second layer or are integrated components in the domain specific applications, i.e. the third layer. Notable examples of business process management systems residing in the second layer are workflow management systems (van der Aalst and van Hee, 2002; Jablonski and Bussler, 1996; Lawrence, 1997; Leymann and Roller, 1999; Marinescu, 2002) such as Staffware, MQSeries, and COSA, and case handling systems such as FLOWer. Note that leading enterprise resource planning systems populating the third layer also offer a workflow management module. The workflow engines of SAP, Baan, PeopleSoft, Oracle, and JD Edwards can be considered as integrated BPM systems. The idea to isolate the management of business processes in a separate component is consistent with the three trends identified. BPM systems can be used to avoid hard-coding the work processes into tailor-made applications and thus support the shift from programming to assembling. Moreover, process orientation, re-design, and organic growth are supported. For example, the current workflow management systems can be used to integrate existing applications and support process change by merely changing the workflow diagram. Isolating the management of business processes in a separate component is also consistent with recent developments in the domain of Web services: Web services composition languages such as BPEL4WS, BPML, WSCI, XLANG, and WSFL can be used to glue services defined using WSDL together.

2.  Business process management demystified

Many people consider BPM to be the “next step” after the workflow wave of the 1990s. Therefore, we use workflow terminology to define BPM. The Workflow Management Coalition (WfMC) defines workflow as: “The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules” (Lawrence, 1997). A workflow management system (WFMS) is defined as: “A system that defines, creates and manages the execution of workflows through the use of software, running on one or more workflow engines, which is able to interpret the process definition, interact with workflow participants and, where required, invoke the use of IT tools and applications” (Lawrence, 1997). Note that both definitions emphasize the focus on enactment, i.e. the use of software to support the execution of operational processes. In the last couple of years, many researchers and practitioners started to realize that the traditional focus on enactment is too restrictive. As a result, new terms like BPM have been coined. There exist many definitions of BPM but in most cases it clearly includes workflow management (WFM). We define BPM as follows: supporting business processes using methods, techniques, and software to design, enact, control, and analyze operational processes involving humans, organizations, applications, documents and other sources of information. Note that this definition restricts BPM to operational processes, i.e. processes at the strategic level or processes that cannot be made explicit are excluded. Note that systems supporting BPM need to be “process aware”, i.e. without information about the operational processes at hand little support is possible.

Figure 2 shows the relationship between WFM and BPM using the BPM life cyle. The BPM life cyle describes the various phases in support of operational business processes. In the design phase, the processes are (re)designed. In the configuration phase, designs are implemented by configuring a process aware information system (e.g. a WFMS). After configuration, the enactment phase starts where the operational business processes are executed using the system configured. In the diagnosis phase, the operational processes are analyzed to identify problems and to find things that can be improved. The focus of traditional WFM (systems) is on the lower-half of the BPM life cyle. As a result, there is little support for the diagnosis phase. Moreover, support in the design phase is limited to providing an editor and analysis and real design support are missing. It is remarkable that few WFM systems support simulation, verification, and validation of process designs. It is also remarkable that few systems support the collection and interpretation of real-time data. Note that most WFM systems log data on cases and tasks executed. However, to support any form of diagnosis, no tools are offered by the traditional systems.

Figure 2 The BPM life cycle to compare WFM and BPM

Currently, many workflow vendors are positioning their systems as BPM systems. Gartner expects the BPM market to grow and also identifies business process analysis (BPA) as an important aspect (Gartner, 2002). It is expected that the BPA market will continue to grow. Note that BPA covers aspects neglected by traditional workflow products (e.g. diagnosis, simulation, etc.). Business activity monitoring (BAM) is one of the emerging areas in BPA. The goal of BAM tools is to use data logged by the information system to diagnose the operational processes. An example is the “ARIS process performance manager” (PPM) of IDS Scheer (2002). ARIS PPM extracts information from audit trails (i.e. information logged during the execution of cases) and displays this information in a graphical way (e.g. flow times, bottlenecks, utilization, etc.). BAM also includes process mining, i.e. extracting process models from logs (van der Aalst et al., 2003). BAM creates a number of scientific and practical challenges (e.g. which processes can be discovered and how much data are needed to provide useful information).

When it comes to redesigning operational processes two trends can be identified: straight through processing (STP) and case handling (CH). STP refers to the complete automation of a business process, i.e. handling cases without human involvement. STP is often only possible if the process is redesigned. Moreover, STP is often only possible for a selected set of cases. The latter means that cases are split into two groups:

• •

  Cases that can be handled automatically (in Dutch these cases are called “Gladde gevallen”).

• •

  Cases that require human involvement.

By separating both groups it is often possible to reduce flow time and cut costs. While STP strives for more automation, CH addresses the problem that many processes are much too variable or too complex to capture in a process diagram (van der Aalst and Berens, 2001). In CH, the normal route of a case is modeled, but at the same time other routes are allowed if not explicitly excluded. One way to do this is to make workflows data-driven rather than process-driven and allow for authorizations to skip or undo activities. Also the focus is on the case as a whole rather than on individual work-items distributed over work-lists.

3.  Conclusion

To summarize, BPM extends the traditional WFM approach by support for the diagnosis phase (cf. BPA and BAM software) and allowing for new ways to support operational processes (cf. CH and STP). This poses many scientific and practical problems. However, it is important to realize that in the 1970s, people like Ellis (1979), Holt (1985) and Zisman (1977) already worked on so-called office information systems (van der Aalst, 2002; van der Aalst et al., 2003a). These systems, just like the BPM systems developed today, were also driven by explicit process models. Therefore, it is important to learn from the past and avoid putting old wines in new (trendy) bottles. Only by this way will BPM become a mature technology.