Chapter 5: Process Design Methodology - Become a slave to the machine or create corruption

Author:neo yang Time:2022/06/07 Read: 4704

---

Document outline

1. The nature of the process
2. Elements of the process
1. Driving force mode
2. Tasks and status
3. Node
(1) Verification mechanism
(2) Rejection mechanism
4. Supervision mechanism
3. Process design pattern
1. Status-oriented (anyone can do it, focus on things)
H2. Node-oriented (not everyone can do it, people-centered)
3. State-oriented or node-oriented, this is a question.
4. Process model
1. Arrow model
2. Stacked model
(1) There are two types of stacked models:
(2) Feedback mechanism
3. Pool model
4. Mixed use of models
5. Design of multi-layer processes
1. Single task, multi-layer status
2. Single main task, multiple subtasks
3. Both methods of multi-layer process design have their own advantages and disadvantages.

In the past few years, I used to work for a leading Internet company in China. At that time, the company used a work order system to achieve work collaboration. At that time, unlike now, there were many collaboration tools to choose from. Therefore, that work order system was carefully studied by me.

It was at that time that I began to focus on process design and management.

In the years that followed, I made many process products, and even a process engine.

In the past few years, I have specifically reviewed these process-based products, and finally developed my own set of process design methodology.

It may not be as highly abstract as many methodologies, but it is better than being simple and practical. At least for the design of most processes, it can basically be used out of the box.

1. The nature of the process

The essence of process is the ordering of the state of things.

Anything, according to certain standards, can be marked with a series of states. The ordering of these states forms a process.

2. Elements of the process

1. Driving force mode

Passive mode and active mode.

The operation of any process has its own driving force.

The driving force of the passive mode comes from the previous process node, that is, the previous node drives the next node. (Simple understanding: the task is transferred from the previous executor to the next executor, and the next executor executes it passively.)

The driving force of active mode comes from the process node itself, or it is called self-driving.

Different driving force models determine how to choose a process model during process design.

Process design must consider the driving force model of the entire process. Otherwise, it is likely that the process you design will be "unusable", "unreasonable", and "too troublesome". . . . . .

Active and passive modes can be mixed within the same process. It mainly depends on the specific affairs and scenarios.

2. Tasks and status

The flow of a process requires a stateful thing to coordinate the entire process. This is the task. The orderly changes in the status of tasks form a process.

A task can be a document, a ticket, an order, a work order, a card, etc.

A process can only have one task. Or there can be only one main task, which can be split into multiple subtasks for execution in the process.

3. Node

The node is the executor.

That is, the specific executor of the status of each task. It can be a person, a program, a machine, etc.

A node can execute only one state or multiple states. This mainly depends on the design pattern of the process (see "3. Process Design Pattern" later for details).

For each node, the switching of the state does not necessarily accompany the switching of the node, but the switching of the node will definitely be accompanied by the switching of the state. This is considered a process design principle.

For each node switching, a corresponding verification mechanism will be required, as well as a rejection mechanism that may be used.

(1) Verification mechanism

Every time a node changes, verification will be performed.

• Pre-verification:

Some verify the execution results of the current node before switching nodes. If the verification is passed, switch to the next node.

• Post-validation:

After node switching, the execution result of the previous node is verified. If it cannot pass the verification, the rejection mechanism is executed.

(2) Rejection mechanism

If the verification mechanism of the process is post-validation, then there must be a rejection mechanism. The rejection mechanism is a mechanism that verifies that the task submitted by the previous node is unqualified and returns it to the previous node. Specific verification standards, specifications, return methods, how to handle rejections, etc. all need to be considered when designing the process.

4. Supervision mechanism

Every process should have a monitoring mechanism. There are two main types of regulatory mechanisms.

• record-keeping supervision

The simplest and most basic supervision mechanism is to record the execution process of the task, that is, the changes in the task status and the attributes and execution results of each status. When something goes wrong, you can trace the cause.

• Real-time supervision

Supervise the execution of each status of the process in real time, and intervene immediately if any non-compliance is found.

3. Process design pattern

1. Status-oriented (anyone can do it, focus on things)

This is relatively common. Heavy on states, light on nodes. Most of the processes we see and do are such design patterns.

Do something first, and then get a certain state, then do something again, and then get a certain state, and then use image recognition to get a certain state, and then do something again, and get a certain state. . . . . .

All nodes in the process (people, programs, machines, etc.) revolve around one thing, a mechanized step, and do what they are responsible for according to fixed rules.

You can think of it as an "assembly line".

2. Node-oriented (not everyone can do it, people-centered)

This is relatively rare. Light on states, heavy on nodes.

To whom the task is given first, what result can be obtained, and then to whom, what result can be obtained, and then to which machine can the task be given, and what result can be obtained, and then to whom, what result can be obtained. . . . . . .

Generally speaking, it will only be considered for use in some non-standardized situations where node output results vary greatly, or in some loose organizations and processes.

It is rare among Internet products. At present, it is mainly used in some collaborative office products.

3. State-oriented or node-oriented, this is a question.

Perhaps the reason why God exists is because this world is imperfect.

The design of a process, whether state-oriented or node-oriented, cannot design an absolutely perfect process.

Facing the ultimate state, human beings will eventually become slaves of programs and machines.

Being node-oriented can easily lead to the concentration of power and corruption.

So, in the end, what design pattern should be used in the process depends on the specific business scenario. What is suitable is the best.

4. Process model