Designing Business Process platform_process hierarchy based on WF
I talked about the same process in [multiple States of the same process]. Different States may occur due to the differences of the observer.
In this article, I will discuss the process hierarchy from the process perspective.
Note: here, the [process hierarchy] I mentioned is not a concept of functional encapsulation, but an example of functional encapsulation.
In this example, [Notification] and [generated email] are not in the same scope,
[Notification] is a business action,
It is an obligation to inform the creator.
It is a right to access the recipient.
[Generating e-mails] and [sending text messages] are only a means to achieve [Notification] such business behavior.
The process level refers to the level of the business category.
Let's take a look at an example:
This is a non-hierarchical process, though, things are handled according to the above process. however, because the process layer is not taken into account during the design, it will bring a lot of drawbacks (I will discuss it later ),
Let's take a look at my improvements.
This is a hierarchical process. From the perspective of the upper-level managers of the process, there are only three phases of the process: [scheme formulation stage], [scheme approval stage], and [scheme implementation stage].
The following shows the effect:
After expansion, the [scheme formulation stage], [scheme approval stage], and [scheme implementation stage] have their own independent spaces.
Here,
[Department A] knows the process of formulating the scheme: [Submit the scheme by the Clerk-> Master management review scheme]
[Department B] knows the approval process: [main Management Assignment analysis solution task-> salesman Analysis Solution-> Master management approval solution]
Here, [department A] never knows how [Department B] works, or even the existence of [department B ].
[Department A] [Department B] is not required to inform [department A] of the change in internal handling methods. [Department B] only cares about the time when [department A] will be handed over to them.
At this time, we actually have four processes:
- [Solution formulation-> solution approval-> solution implementation] Process
- [Department A solution development] sub-process
- [Department B solution approval] sub-process
- [C Department solution implementation] sub-process
Of course, the [solution formulation-> solution approval-> solution implementation] process may also be part of other processes.
The [Approval Scheme] in the [department B solution approval] may also have sub-processes at the next level, such as signing
The biggest benefit of this design is that each layer can be independently designed, and internal modifications will not affect other links.
The following is an example:
Where
[Prepare materials], [sign], and [Implementation Scheme] are all subprocesses for calling.
Let's look at another example:
The above is an example of process layering.
Primary school principals only care about how to collect money and how much money is collected.
The primary school only needs to pay the money to the school.
At every level, everyone completes their own work and does not need to ask other people's work. In fact, the donation of a primary school student may promote the major process of the transition from a socialist elementary stage to a communist party.
The hierarchy of processes allows people at different levels to take responsibility for each other.
However, due to the opacity of the layer, a lot of black boxes have emerged in the case of transactions. Due to the existence of black boxes, many drawbacks have emerged.
For example, the primary school student who donated money never knows that the 10 yuan he paid will eventually be spent there.
Therefore, when designing the process layer, we also need to consider a problem, the transparency of the process.
In the next article, I will talk about process transparency.