Workflow and business flow in ERP system

First, two concepts are explained:

Workflow, which breaks down the work into several different tasks, and then executes these tasks and monitors them through certain rules and procedures to improve work efficiency and reduce production costs, to improve the competitiveness of enterprises. it is mostly used in office automation.

Business Flow: it refers to the data flow between internal resources of an enterprise. Generally, the enterprise's logistics, capital flow, and information flow are comprehensively integrated and managed through the enterprise resource planning system (ERP.

However, in actual enterprises, there are often some requirements that need to be switched back and forth between the OA system and the ERP system, such as: purchase payment application, payment, creden are functions (such as) in the ERP system ).

In addition, enterprises may generate some business data after they use the OA system for workflow approval. These business data may be external data sources in the ERP system, such as the data on the purchase expense application. To avoid data duplication and ensure the uniqueness of the data source, you need to integrate the workflow system and business flow system.

The current common integration methods are summarized into two categories.

1): interface-Based Integrated encapsulation mode, using the interfaces provided by OA and ERP (this interface has the following meanings: database table structure, Web service interface, and other custom interfaces ), mutual access between two data is achieved.

2): Based on the intercommunication mode of intermediate tables, data is stored in the same data model and shared data between different systems is directly operated on the data tables of the two systems, data access between different systems, as well as data consistency and real-time transmission.

From the above analysis, we can see that this integration is still difficult, at least requires secondary development to varying degrees. If secondary development is used, I personally prefer web service, web Service is the SOA architecture we often hear. It is an architecture platform that integrates various services. The core point is to completely separate services from technologies, so as to achieve service integration and restructuring to the maximum extent. (Note: If I strongly disagree with the SOA architecture in ERP development, I have always felt that SOA is only used in some specific business scenarios, the most suitable method is to provide external service interfaces). Why not use tables? Because
The approval flow of ERP is quite special. The execution of its process is actually the transfer of control between two subsystems. If it is a table-based mutual access mode, this is a tightly coupled integration method, it will affect the system flexibility and scalability, hinder the adjustment and optimization of business processes, and is not conducive to the development of enterprises.

Recently, I have studied a domestic Open Source System fireworkflow (http://www.fireflow.org), and analyzed its source code (first make an advertisement, then I will write the process of source code analysis into a blog for your exchange, correction ).

Some of the ideas mentioned by fireworkflow are very helpful to me, for example, a common leave process.

 

The execution process of the flowchart is described as follows:

First, the workflow subsystem starts a new business flow instance, and then creates a new task instance-

Please "and give the control to the business subsystem. The business subsystem waits for the applicant to fill out the form. After the applicant completes the form, the control is handed over to the workflow subsystem, which determines the next route. This is done by an element called synchronize R (the circle marked with "S" in the figure ). In this business example, it calculates that the next operation is "department manager approval ". Therefore, a task instance named "department manager approval" is created and the control is handed over to the business subsystem. The business subsystem waits for the department manager to approve the task.

The workflow logic and business logic in the figure are clearly divided. The business operation performed after approval is determined by an "operation" of the workflow logic subsystem. The "approval" Operation in the business logic subsystem is only responsible for completing the specific business logic. Other operations are irrelevant. This is exactly the result I want. A good ERP, it should include the workflow subsystem and business flow subsystem. The two subsystems are unrelated and can collaborate with each other. disassociation means that one of them is missing and the other can work normally. Mutual collaboration means that they can be used to better serve enterprise development.