BPM business scenario analysis (1) -- combined invoicing of internal transactions

In the companion Article of the previous article, the previous series is used to push business scenarios by workflow mode. This series is implemented by business scenarios and is a summary of brainstorming. It is not all correct. You are welcome to correct the problem.

(1) Description

After completing the entire business process, the internal transaction process is the centralized invoicing process. The invoicing operation is a batch operation. As to which is placed in a batch, this rule is uncertain and may be determined by the person who opens a ticket once a month.

From the perspective of business development, invoicing should be performed after internal transactions are completed. The above business flow chart is very simple, as shown below:

 

Expand to see, the desired running effect is similar:

 

(2) Solutions

A. Assigning internal transactions and centralized invoicing to different business processes is not very closely related. Therefore, it is natural to divide internal transactions into two business processes. In terms of implementation method, the internal transaction process instance ends normally, and then the participants decide which data is concentrated on an invoice to activate the invoicing process. For process backtracking, the relationship between the internal transaction process and the invoicing process should be recorded during data convergence. This solution applies to scenarios where there are no fixed rules between the internal transaction process and invoicing, and people need to be involved.

B. Use the multi-instance mode to implement this process without being sure about the number of executions during operation. The internal transaction process is a reusable activity block, the number of repeated executions of this activity is determined by the external events at run time, which may be the time or the events produced by the participants. For example, in some management methods, the time is used as an external event to describe this situation.

 

The process starts at the beginning of each month and enables repeated execution of the scope Block activity. Each internal transaction starts to activate an execution thread. After the internal transaction process ends, the entire scope Block activity is still in the enabling status until the end condition is set up 'time to the end of month'. The entire scope Block activity ends and then starts centralized invoicing.

(3) Implication

The above two solutions lead to a problem. What process should be written in one process, and what should be separated? Is there a standard of choice? Is it determined based on the experience of the implementer? The availability of the processes customized by two different levels of implementers will be quite different. The summary criteria or strategies include:

A. Is the process description and presentation clear. Can you express the meaning of a process under the constraints of a specific process Customization Tool.

B. There is no problem with data conversion. In a process, this is certainly not a problem, but the separation may be problematic.

C. Process backtracking and convenient data tracking are the same as above.

In addition to the above selection criteria, there is still a problem that cannot be ignored. To put it bluntly, how can we maintain the connection between processes? If the process is automatically activated, how can we notify the process to start? If the process is activated by a person, then notify the person. The natural association is that through message-oriented middleware, its features must have the reliability, high throughput, and feedback accuracy of communication. Microsoft's suggestion is to use BizTalk, so the following business flow chart is built under this assumption.

 

A coarse-grained business flow chart is expressed. In the figure, each square represents a process in a module, and the interoperability of processes between modules is provided by BizTalk, it mainly relies on powerful mapping for data conversion and Data Capturing. Bam is used for data tracking and messaging middleware capabilities.

another problem is that the intensity of business flow division cannot be too small. If a function is used as a business flow, the current function-driven situation is returned.