Business Processes and Workflow Management in an Enterprise Resource Planning ContextName: Ing. M.G. (Riné) le Comte BSc. Title: Sr. Software Engineer & Architect E-mail: email@example.com Organization: Baan Labs Address: P.O. Box 250 ZIP: 6710 BG City: Ede Country: The Netherlands Phone: +31 318 696666 Fax: +31 318 651544
ABSTRACT: The research described in this paper is related to business processes and workflow management in an ERP context. Today there is a poor integration between ERP applications and workflow management systems. However, a combination of both worlds could lead to very powerful applications. Our research is working towards such integration.
Baan Company is an organization active on the so-called Enterprise Resource Planning (ERP) market. One of the departments within Baan Company is Baan Labs. Baan Labs is a research organization that pursues the integration of all kinds of new ideas, methods and technology to use in the Baan applications.
The research described in this paper is related to business processes and workflow management in an ERP context. Today there is a poor integration between ERP applications and workflow management systems. However, a combination of both worlds could lead to very powerful applications. Our research is working towards such integration.
The paper is organized in the following way. The next section describes the problems of both the current generation of ERP applications and the current generation of workflow management systems. Then the ideas for a solution are described. The last section gives some conclusions.
During the last few years Enterprise Resource Planning (ERP) applications have become popular in industry. These standard applications cover a broad range of the information needs of an enterprise, from sales to manufacturing to purchase to finance to human resource management. They offer advanced ways of dealing with complicated logistic problems. Nevertheless, developers of these systems are encountering a number of problems:
Workflow management systems too have become more popular lately, especially with the renewed interest in business process re-engineering (BPR). Workflow management systems can be categorized in several different ways, for example according to their origin or type of support. With respect to origin, one can distinguish the electronic-forms origin, the document imaging origin or the product data management (PDM) origin. With respect to type of support ad-hoc workflow, collaborative workflow and production workflow can be distinguished.
Several shortcomings of the first generation systems have been discovered. Most of the commercially available workflow management systems are not really workflow management systems, but rather workflow support systems. It means that they support the definition and execution of business processes, but offer little support in the management of processes. The following list gives some examples of areas where limited support (from a logistical point of view) is offered.
A second shortcoming of workflow management systems is that those systems typically are implemented as a layer on top of existing applications, not at the heart of them. This approach gives rise to all kinds of integration problems. An example of such a problem is the calculation of a product price. Not only the parts and the production of those parts should be taken into account but also the logistical operations. These operations are managed and stored in the workflow management system, not in the operational system. This separation makes price calculation much harder.
The focus in our research project has been combining concepts of both ERP systems and workflow management systems. Three concepts are considered crucial:
Business processes are considered an important element because it extracts the process logic from the application. This separation allows for greater flexibility since the application components can be arranged more freely. This focus on processes has widely been recognized, both in the management sciences and for example in the manufacturing literature. A generic process model is being defined that contains constructs to model many aspects of all kinds of business processes. The model is based on High-level Timed Colored Petri-nets. Because this model is used in both the workflow part and the ERP part, the integration of those parts is easier.
A business object is the representation of an entity in the business domain. From a business standpoint it is a single object with an interface, although internally it can consist of multiple objects that contain the implementation of the methods in the interface of the business object. Process-related logic is left out as much as possible. The business objects are bundled in larger components that are quite independent from each other and that can be configured relatively independently. When such components are put together they should also be able to work together seamlessly.
A business service, encapsulated in a business service object, is the representation of an algorithm or the representation of some piece of functionality. A service should be described in a declarative manner, including characteristics and constraints. Generic business services, developed in either the workflow part or the ERP part use the concepts from the generic process model to express their functionality. Both parts are able to use those services.
Integration of the concepts
The linking of business objects to business services is done via the business processes. These business processes can be configured, thus offering quite some flexibility. The activities in the business processes refer to business services for actual execution. These services transform the input resources to output resources. Resources are modeled as business objects.
By bundling the business objects into components, we achieve modularization, without losing the possibility to integrate those components. Business processes can fully transparently work across component boundaries.
Mobile Agent Framework
A business process is implemented in a mobile agent. The agent takes care of the execution of the process and keeps together the business process, its state and its related business object references. It communicates with other agents and with business services in its environment using KQML. The Mobile Agent Framework takes care of the mobility of the workflow agents using various kinds of transport mechanisms and checkpoint managers. The framework allows the business processes to be executed in an Internet or Intranet environment.
Business Object Framework
Business objects are supported by means of the Business Object Framework that takes care of transparent distribution and persistence. Business objects have both a method-based interface and a message based interface. The message-based interface allows for advanced functionality like load balancing, message interception by agents and mediating services. Business objects are bundled in larger components. Distribution is implemented using RMI, Corba and DCOM. Persistence is realized by an object-relational mapping.
Generic Process Framework
A process framework provides essential functionality to execute business processes. It uses all kinds of services in the environment, like a workflow-related Task Manager service or a Scheduling service. A part of the framework is a process engine that is able to execute and monitor processes.
Traders and directory services play an important role. Services register themselves including capabilities and constraints. The intelligent trader contains a knowledge management system and an inference engine that is used to find matches for service requests. It collaborates with other traders.
Our research has led to the conclusion that the integration of workflow concepts and ERP concepts can have a great synergistic effect. The workflow part, which is responsible for the definition, execution and management of business processes, is able to use all kinds of ERP-related services. An example is a Resource Allocation service.
The ERP-application on the other hand is built from components like business objects and services. It relies on the workflow part to link these components together. This approach gives much more flexibility.
There are still a number of open topics. An example is a generic process model, to be used not only within our application but also applicable for other domains could ease the exchange of process related data. The American NIST (www.mel.nist.gov/psl/) is working on such a model.