The art of creating process diagrams

When you want to quickly explain the essence of a process, you usually draw several rectangles with text on a piece of paper and draw connections between them. This simple principle is followed by the majority of methodologies for describing business processes, technological processes and any other human activity. It can be taken for granted that such schemes are very important in the modern paradigm of knowledge accumulation.

Therefore, several years ago, I developed an application that allows you to build process diagrams to plan the execution of projects or simply to achieve any goals. All this time I worked closely with users, quite often and for various reasons they sent me their diagrams. Studying hundreds of different schemes, I noticed that some of them are easier to perceive and understand than others, and vice versa, it was damned difficult to disassemble individual schemes. It is interesting that often it was not the complexity or simplicity of the process itself, but in the manner of constructing the diagram. Showing a bit of zeal, even the simplest process can be illustrated with a confusing scheme, the essence of which will be difficult to understand without further study.

Analyzing my experience in building diagrams and systematizing successful findings and user errors, I developed a set of principles that allow you to build good diagrams.
')


A few words about the structure of the article. The material is quite extensive, so I will try to break it into several parts and try to present the material thesis, avoiding unnecessary explanations. This article will be devoted to quite general principles, quite obvious, but which should be mentioned. Subsequent parts will be closer to specific practices.

So, first agree on the main subject of the article - process diagrams (hereinafter, for brevity, sometimes just diagrams). As a rule, the process diagram is a collection of graphical objects, named by text, which are connected between themselves by arrows. Objects denote processes, resources, states, etc. Arrows denote the order in which control passes from one object to another. It is necessary to distinguish process diagrams from externally very similar structural diagrams, process diagrams suggest dynamics, while structural diagrams are static, describing the constructive interrelationships of objects, usually a description of organizational hierarchies, data structures, or “mind maps.”

There are many notations describing process diagrams, these are IDEF0, BPMN, UML, EPC, CMMN, and others. This article applies equally to all of them, the examples used the notation of their own application.

In the article, the word “process”, depending on the context, can be referred to as the main process described by the diagram, as well as the processes included in the diagram. The word “task” can mean a process, a goal or a resource, or an integral combination of a resource, a process and a goal. In general, see context.

Since the dynamics is the main distinctive feature of the diagrams considered by us, then, therefore, the key part of such a diagram is its scenario . The basic requirements for the scenario are consistency and continuity. Contradictions arise in the wrong order of causes and effects, as well as in a situation where one object must be simultaneously in different places (or two must be combined in the same place). Continuity is lost when the consequences are not due to causes or when a significant fragment of the narration is lost.

Here you need to highlight one important point regarding the script and the diagram as a whole. The purpose of creating a diagram is not only in describing a specific process, but also in transmitting this knowledge to the addressee. That is, the plot of the diagram is influenced both by the process described by it and by its audience. For example, if you need to clarify the point of traffic rules for children, you will use a different method of presentation than the one used in the officially established rules. As a rule, if the plot is not adapted to the audience, then its continuity is lost, because the individual causal relationships are not obvious or incomprehensible to the addressees.

Many different methods of debugging diagrams can be mentioned to eliminate inconsistencies and maintain continuity. But it will be more effective to build quality diagrams right away, and since the article is more practical in nature, then instead of describing quality analysis methods, I will simply provide a step-by-step algorithm for constructing good diagrams.

Step 1. Place your goals as resources in the lower right corner of the chart.
Usually the processes that it makes sense to describe have a clearly defined end goal or group of goals. Such a goal can also serve as a state after which the further execution of the process does not make sense. As a rule, processes are created for specific goals, and it is often obvious what to write in the lower right corner of the diagram. However, it is sometimes farsighted to indicate not only a positive goal, but to list the states in which the execution of the process is interrupted, but the original goal is not achieved or is not fully achieved. It is recommended to explicitly list such negative goals in cases where the probability of achieving the main goal is below 60%.

Looking ahead, I will say that the recommendation on the placement of the final goal at the bottom right of the diagram (as well as subsequent similar recommendations) refers to the composition of the diagram, which will be the subject of another article.

Step 2. Mark the available resources as objects at the top of the diagram.
Obviously, not all possible resources should be listed, but only those that are seen as useful for achieving the goal and whose liquidity is beyond doubt. A list of these resources will be the initial conditions for the start of the process. One of these resources should be a trigger that starts the whole process, usually it is an external influence: a client request, a change in the indicator state, a request from the system, etc.

Step 3. Place the proposed intermediate goals as resources in the middle of the diagram.
Complex goals usually consist of a set of components that must be implemented in advance. Large projects are conveniently divided into stages, the result of which is the production of one of the components of the final goal. Mentally decompose the end goal into such components and place them on the diagram. In some cases, instead of components, you can break the final product into a sequence of product maturity evolutions or combine both approaches.

Step 4. Before the goals in the diagram, place the processes that lead to the achievement of these goals, and connect the new processes with their goals.
Note that so far there has not been a single process in our process diagram, this is not accidental. The specificity of our thinking is such that, starting to do something, we concentrate more on processes, forgetting a little that the essence of our activity is in goals. Process diagrams, consisting of processes alone, are a frequent occurrence, but it should be remembered that we strive for continuity and clarity of presentation, and often indicating the goals of the process execution speaks more about it than the name of the process and its description. Try to always explicitly indicate the objectives of the process, in practice this means that the arrow from one process to another is a rare phenomenon, usually between processes there is an intermediate resource, which is the result of the execution of one process and the source resource for another. In some formalisms (for example, DFD), the arrow itself can be a description of a resource. However, if such an intermediate resource is obvious, then in order to simplify the scheme, you can omit it and draw an arrow from one process to another. For example, if the laundry process after the “Drying” process is followed by the “Ironing” process, in some cases the intermediate resource “Dry laundry” can be skipped.

Step 5. Make connections from the resources available in the diagram to the processes using them; if the required resource for the process is not in the diagram, add a new goal, returning to Step 3.
Obviously, if there is no resource required by the process, this leads to a contradiction in the execution of the task, since not all the reasons for the desired consequences have been observed. Therefore, it is necessary to fulfill the completeness criterion - everything necessary for the execution of each process should be available. However, it is not always justified to explicitly indicate obvious resources, for example, when machining a part with a machine, one of the obvious resources is electricity, an explicit allocation of this resource most likely will not make the diagram clearer, but without significant reasons complicate it. Remember your audience: the viewer always completes part of the diagram mentally, it is inevitable. Try to have the imaginary part of the diagram relate to the obvious moments, moreover, things that are too obvious that are written out on the diagram can tire and even annoy.

Step 6. Conduct connections between processes whose execution depends on each other.
Pairwise check all processes placed on the diagram, whether there are any implicit dependencies or mutual influence between them. For example, it is often useful to group “dirty” processes together to save on cleaning the work area. Also, if two processes use a limited resource competitively, they should be diluted in time, making a connection from one of them to the other. Note that resources that we do not display on the diagram can also be the cause of hidden dependencies, for example, when two processes use energy-intensive machines that should not be turned on simultaneously.

Step 7. Make sure that the diagram is easy to read and contains no more than 20 objects; if this is not the case, group several context-related objects into one object of a suitable type with a nested diagram containing this group.
Practice shows that when a diagram contains more than 20 objects (resources or processes), the scheme ceases to be perceived as a whole, but begins to look like a maze in which the viewer needs to look for ways he is interested in. On the other hand, it is rare for a project or business process to fit into such a small number of objects. Fortunately, the fact that one diagram does not fit will fit on several, do not strive to state everything at once, remember: you can always make another diagram.

So, if the scheme turned out to be cumbersome, select a group of objects that are as loosely connected with another part of the diagram as possible, and replace them with one process. Deleted objects will be the basis of the new diagram, which will explain the essence of the new process.

Such a seemingly purely technical task is in fact of great importance, since a hierarchy of task specification and the separation of process execution contexts are built in this way. Now, from the point of view of the main diagram, it does not matter how the new process is implemented, the details of its implementation are put in a separate diagram, they exist as if in a separate space, on which the main scheme has limited influence. This is a pretty useful feature: the more independent the neighboring tasks, the less likely it is that the mistakes and problems of one of them will affect the others.

Another important aspect of chart detailing is the ability to dilute audiences: as a rule, top-level diagrams are interesting to managers, and nested diagrams are more useful to technical specialists. Having broken a diagram into levels, we can design each new diagram with regard to its audience, forming a plot that is understandable and fascinating for it.

Step 8. Make sure that the objects have the type corresponding to their essence, visually separate the information and physical flows. If the diagram contains several context-related objects, select them using the group. In places requiring clarification, place objects such as comments.
Depending on the chosen description of the process description notation, we will have access to various types of graphical objects describing specific aspects of the tasks, carefully review the list of available objects and use the most suitable description for each of the tasks. Sometimes the notation allows you to separately highlight the area on the diagram, inside which you can arrange the tasks associated with some common feature: the performer, the place of performance, etc.

Often, such areas are drawn up as horizontal tracks, after which the diagram looks like a pool in which each performer swims along his path along his tasks. Such an organization of the diagram is quite obvious, but it may have its compositional flaws.

Step 9. For processes that are not elementary operations, build a nested diagram, starting with Step 1.
In Step 7, we synthetically created a new task from a group of objects and detailed it with a nested diagram. In this step, the same is done, but analytically: we are trying to decompose a complex object into simpler processes and display them in a nested diagram. In project management, this process is called structural work decomposition. When splitting tasks into smaller ones or merging them into larger ones, you should make sure that the tasks of one level, displayed in one diagram, are approximately equal in importance and labor intensity.

Step 10. For individual resources, where necessary, add a nested chart for preparing the resource for use. For selected goals, add a chart to verify the required qualities of the achieved goal.
We continue to work on decomposition, but focus on resources and goals.

Having successfully completed all ten steps, we must obtain a set of process diagrams illustrating a consistent and continuous scenario for achieving the planned goals. However, these diagrams are not yet a finished product, for each of them you need to find a suitable compositional solution and arrange them, observing a number of visual formalities and nuances. The following articles will be devoted to how to turn our raw ore into sonorous metal, but for now let's summarize this.

So, the description of any process begins with the creation of a script that links the objective structure of the process with the audience for which the description is intended. If the recipient is a person, it is convenient to use compact process diagrams organized in a hierarchical structure based on the process architecture. Note that the hierarchy embedded in the process description may not be part of the process itself, it is more necessary for the purposes of effective perception by the audience - sometimes, in order to make something simpler, you first need to complicate it.



UPD
Next article: “ Technical Composition of Process Diagrams ”

In the comments I was rightly told that it is necessary to distinguish between process modeling and functional modeling, this is true, but most of the recommendations of the article are equally applicable to both types of diagrams. Nonetheless, this is a valuable remark emphasizing how important it is to read and comment apart from the article.