BPMN modeling method

BPMN (business process management) is a systematic method to capture, design, execute, record, measure, monitor and control automated and non-automated processes to meet the company's goals and business strategies.

Through BPMN, the process can be consistent with the business strategy, and the process optimization within the business department or even beyond the company boundary will help improve the company's operating efficiency.

BPMN is widely used in China, but many enterprises have spent a lot of money to buy third-party process platforms, but they have not received corresponding benefits; I think the fundamental reason lies in the ignorance of BPMN itself-it is far from as simple as it looks, and the specification document of version 2.0 alone has reached 500 pages.

Therefore, in my opinion, a designer who has a thorough understanding of BPMN is very important for its smooth implementation. At the same time, designers need to have business thinking, management thinking and certain technical thinking.

Taking a property maintenance process as an example, this paper aims to introduce a systematic BPMN modeling method and provide a direction and choice for people who have just stepped into this field.

This is a typical property maintenance process, which provides so little information that it is almost impossible for us to design a perfect BPMN process based on it, but even the most professional property managers can only provide a flow chart.

In order to achieve our goal, we need to establish a strategic process, which may be rough, but its purpose is not to present a complete and detailed view at an early stage.

Its role may have the following points:

1. clarify what is part of this process and what is not.

2. Determine the resources of the process and assign responsibilities.

3. Determine key performance indicators and clarify their characteristics.

4. Before starting the optimization process, make a general review.

Volume: the strategic process model should be as small as possible, and the process elements should not exceed 10. If a process spans several sheets of paper, no one can understand it.

Grammar: Be as correct as possible, but not too strict when necessary.

Making a preliminary model of the process is usually much more difficult than expected. Sometimes it is better to have enough information and standard operating procedures at hand, but most of the time we have to communicate with customers in depth.

When the product goes to a meeting to communicate with customers, I can easily imagine the following scene-when you only draw a circle and two rectangles:

Customer participants:

Our maintenance process doesn't always start with the owner filling out the maintenance form, and the owner may also call for repair.

If the maintenance workload is heavy, we should put forward a plan first, and then submit it to the company leader for approval.

If the warranty expires, we have to collect money.

If the owner has an appointment, we will arrange the work according to his appointment time.

It is not necessarily the owner who reported the repair, but also the problems found during the property inspection, and the inspectors reported the repair.

..........

..........

..........

If you don't have a vicious person to chair the meeting, the product will be easily lost and the customer participants will lose interest in your plan. To make matters worse, others will agree with a wrong model in the chaos.

Therefore, the person presiding over the meeting needs to declare at the beginning that all the process models are incomplete, but it still has some functions.

It is impossible to find out every possibility at the beginning. Before this meeting, you should tell the customer what the goal of this first iteration is.

1. We need to record this process from beginning to end.

We only record n steps of this process at most.

We only record the standard form of this process.

If anyone wants to jump out of the designated range during the meeting, stop it immediately.

Let's go back to the theme-property maintenance process.

Based on the above traditional flow chart, we can get the following information:

1. This process is often caused by the maintenance needs of the owner.

2. The sponsor fills in the maintenance order, the issuing department (namely the administrative department) submits the maintenance order to the customer service center, and the customer service center manager fills in the summary of the engineering order, and then issues the maintenance task to the maintenance department. The supervisor assigns the work to the maintenance worker, who performs the task and checks with the issuing department to confirm the completion of the maintenance.

When the maintenance is completed, the process is over.

According to the key information, we can construct the following flow chart. Here, for the principle of BPM, first of all, we should put the closing event on the swimming lane of the demand side.

Although there are many problems in this model, at this stage, it is possible to ensure that customers can understand it effortlessly.

Next, we can start to correct this wrong model step by step.

The first is the swimming pool and the swimming lane. According to the specification requirements of BPMN, each process should have a top coordinator (please refer to the BPMN specification yourself) who is responsible for coordinating the participants and systems in the process, but this process is not controlled by the process engine (controlled by the initiator), so there is no such coordinator at present. When the owner reports the maintenance, it cannot be routed to the next activity (if the person in charge of the work assigned to the next node is regarded as the routing method, the process engine is actually the coordinator at this time). Therefore, this party should be modeled as a message flow, and the owner should be assigned to another pool.

The more detailed we model, the more problems we find. For example, if the owner doesn't want to maintain it halfway, this process can't end "normally" in this mode. If it needs to meet this business demand and does not want to end suddenly through technical means, then it needs boundary events. In addition, if maintenance workers need to use some materials, what should they do, whether they need to apply, and who should they apply to?

For the strategic model, in order to be as simple as possible, we usually don't use multiple pools unless the owners are independent of the property management company as mentioned above, but since our focus should still be on the internal processes of the property management company, we will talk about the folding of the owners' pools next.

Tasks often appear in the strategic process model, but subprocesses rarely appear. In the strategic process model, the task type is not specified, and labels other than loops are not used, because loops are relatively easy to understand.

Sub-processes should refine the process model. In the maintenance process model, the tasks we define may not be simple, and may correspond to very complicated operations. However, for the tasks such as the issuer filling in the registration form, from the information we got, it is enough to fill in, so we still regard them as tasks. Based on these considerations, we can get the following model.

For tasks that may have complex logic, we just need to make a subtask tag.

The model given above is only based on the most common situation. For some situations that really need branching, we need to use gateways to model this situation, but usually we don't introduce gateways into the strategic process model.

The types of events used in the strategic process model are limited:

Empty types can be used for start, middle and end events, and middle events can record a certain state during process execution, which is convenient for customers to understand.

Message types and timing types can be used as start events and intermediate events because their symbols are clear at a glance.

At this point, the strategic process model can be ended.

In the operational process model, you can start to show the process details about people and technology, and some problems will be involved here:

1. For process designers: How is the work done?

2. Process developer: What functions does the process engine need to achieve?

3. Process participants: How to complete their own work?

It is not easy to reconcile these three roles, which is exactly what the business process model needs to do. If you answer these three questions well, you can get the following benefits:

The logic of 1. business process model is consistent in practical operation and technical implementation.

2. The gap of understanding and communication between business and technology has been narrowed, and both sides regard the process model as the same language.

3. The process realized by the process engine is easier to observe.

Unlike the strategic process model, this level model can tolerate some grammatical errors, so we must model according to the specification.

In addition to specification, accuracy must be achieved, because customers need to arrange their work according to this process model. At the same time, try not to make this process too complicated. After all, process participants care about their work rather than BPM, and processes are just a means to achieve their goals.

As mentioned earlier, the business process model should be accurate enough, but not too complicated, which may sound contradictory. To this end, let's make a table to see what the view of the business process model looks like in the three roles. Process participants only need to pay attention to what they need to do, when they need to wait for others to finish something, and don't be distracted by the details of what others have done.

The core idea of the operational process model is to distinguish between arrangement and collaboration. As mentioned earlier, each process participant has its own pool.

Taking the process engine as a separate pool can make process developers pay more attention to it.

The role of process designer is very important here. It needs to know BPMN very well and can simulate this process from the perspectives of different participants.

The designer's process may be as follows:

1. Review the strategic process model

2. Divide the fairway into separate pools.

3. Modeling from the perspectives of different participants.

4. Prepare technical modeling.

5. Technical modeling is not necessarily executable, and the purpose is to refine the model.

6. Add the necessary comments

Of course, this is just an empirical method. You can also analyze and model directly from the technical level, from the bottom up.

Continuing the example of our property maintenance process, in order to simplify the model complexity of each process participant, we need to divide the swimming lanes of the three participants under the property management company into separate pools. At the same time, we also need to solve some obvious logical errors, such as:

1. No joint owner's acceptance.

2. The warehouse administrator is omitted.

3. Omitted the weekly summary and progress supervision of the customer service specialist.

4. When the owners apply for maintenance, they mostly declare by telephone.

The biggest difficulty here is that because of the existence of agents, it is difficult for us to completely separate the owner pool from the operator pool. Although two process variables (initiator and owner) can be used to solve the problem at the process engine level, this method can not express the meaning well at the model presentation level, and it will also increase the workload of development, so we can model this situation in the form of multiple startup events.

This is a model diagram after process participants are divided into separate pools. There are still some problems here, such as we haven't graded the maintenance projects, how to adjust the parameters if the acceptance fails, and so on. But in this step, we only clarify the relationship between the process participants, so there is no need to go too far.

Starting from this step, it is usually necessary to communicate with process participants in more detail.

Starting from the owner, we can see that the owner involves operators, administrative departments and electromechanical maintenance departments, and then the pool of the two can be folded up.

According to our known business scenarios:

If the maintenance project declared by the owner is paid service, customer service needs to reconfirm.

If a paid service is involved, the owner needs to have a payment operation.

After further consideration, we found that the owner pool will also involve the customer service department, and finally we got the following model.

The process of the administrative department is relatively simple, and other pools involved include the owner and the customer service center:

What the customer service center should pay attention to is that in the traditional flow chart given by customers, there are tasks of regular statistics and reminders. In this case, we should regard it as another independent process model and distinguish it from the current maintenance process model.

Through the investigation, it can be found that after completing the property service, the customer service center often has a process of returning to investigate. Therefore, after the maintenance is completed and the owner accepts and confirms, we should also increase the return visit process, but the return visit does not exist in a specific process, so it is omitted here for the time being and modeled as an independent process.

In addition, the customer service center also needs to communicate with the owner in advance before sending the order, and there are certain rules for classifying the maintenance items:

1. Is it a minor, medium or major repair?

2. Is there a charge?

After investigation, we can learn that:

All three types of maintenance may be charged.

Medium repair and overhaul often need to go through an additional approval process to continue.

I put the maintenance project evaluation task here because the customer service needs to know the maintenance price and other information before contacting the owner.

Electromechanical maintenance department should consider the following factors:

In charge of the details of the task.

1. Should the rework times be recorded?

2. Distinguish between different levels of maintenance projects.

The premise of the supervisor's assignment is to receive the maintenance demand, specifically, to receive the engineering order summary table filled in by the customer service center. The existing attributes in the current table may include customer name, maintenance address, contact telephone number, maintenance content, appointment time, etc.

At this point, the supervisor needs to judge whether the current maintenance plan needs to go through an additional approval process according to the known situation, and this process should be independent of the current maintenance process. As for the process of this additional process, it is not known at present, so it is still replaced by a sub-process.

The warehouse manager needs to consider how the process will proceed if the acceptance fails. In fact, the acceptance here should be the acceptance of the material warehouse, which has nothing to do with the maintenance process, but customers often can't clearly express this meaning. Therefore, this step is temporarily omitted, and the next step is modeled as an independent material warehouse inspection process.

Finally, the operator, the operator's process is relatively simple, you can fill in the maintenance form after receiving the repair call:

We used to talk about the process between people, so we will introduce the process engine from this step. As mentioned above, developers need to know what they want to do with the process engine, so this step will add more details including technical implementation, such as checking whether the owner pays. But the first version of the technical process model is not necessarily executable.

The technical process model of the first edition is as follows:

In the next design, we need to consider more external factors. If it is found that the process of a lane can be reused by other process models during maintenance, they need to be separated and deployed separately. If we are satisfied with the separate deployment of this huge maintenance process, we may need to make more modifications, especially in the event type (here, the use of message events violates the BPMN specification, and it is more appropriate if it is deployed in the same process definition.

For the current maintenance process, I tend to design and implement all the processes separately for the following reasons:

1. A huge model, and its version migration process is often very complicated. If properly decomposed, then we only need to migrate the changed parts, which can effectively reduce the migration cost.

2. For developers, a huge or overly complex model will lead to a rapid increase in the cost of understanding and development. A single model can only be taken care of by one developer and is not suitable for multi-person cooperation. Decomposition means can decompose a single complex model into several simple and independently developed process models, which can improve the development efficiency and reduce the difficulty of understanding.

3. For enterprise workflows, there are often * * * connected parts between multiple workflows, just like the property service return visit process here. Stripping these common parts can improve the reuse rate of the model in the long run, thus improving the development efficiency.

However, the shortcomings of this scheme are also obvious, mainly including:

The degree of decomposition of 1. is not so easy to grasp. Although it is often decomposed into each process participant according to experience, sometimes some participant processes with simple tasks can be merged.

2. In order to realize the communication between process instances, there are often many message/signal events or calling activities, which requires developers to have enough knowledge of the events in BPMN.

3. The observation of process trends may be complicated, because it is necessary to switch back and forth between multiple process instances.

The technical process of the first edition is realized as follows. There are still many areas worthy of improvement, such as the separation of payment process and exception handling, the maintenance of automatic rules for supervisors to assign tasks, and the regularization of operator processes (using regular tasks to judge what kind of message events to send according to input parameters, which may be filling in maintenance orders or filling out other forms on behalf of others), but for cost reasons, we cannot continue to refine the implementation of the first version endlessly:

/LLLLimbo/camunda-demo.git？