Business processes: the good, the bad and the ugly

In a large and even very large company without any processes. Consulting Hewlett Packard Enterprise Software is engaged in building processes in the IT departments of its customers. ITSM / ITIL, project management, development management, and DevOps are all these words. Within almost every project, in one way or another, we design and draw processes.

In this article we will not talk about the theory, we will talk more about the practice taking into account the experience that has accumulated in the Russian HP, now in HPE. In order not to speak in the abstract, let's take the subject area of ​​IT service management - ITSM, and speaking about processes, we will have in mind ITIL processes, for example. We do not pretend to absolute rightness, we will be happy to discuss this topic.

Why do we need processes

We believe that processes are needed so that people in organizations equally understand what and how they should do. You can also say "to structure the activities of the organization" and many other words.

Here it is important to keep a reasonable balance between “structuring” and the practical use of people at work. Designing (building) a process is quite a laborious task, so it should have a practical result. Process documents should have a fairly wide audience. Ideally, people should look directly into the processes and understand what and in what order they should do in a given situation.
')
In a number of customers, we see a picture when processes for a number of reasons (about them - just below) become the lot of a narrow circle of specialized process specialists. This is exactly the case when “structuring” (the near-scientific task) prevails over practical use. And if the process is not a “reference book” of people who work within the framework of this process, then the feedback flow from the performers who see that the process needs to be changed (improved) is lost or sharply reduced.

Description of the business process in such organizations becomes a thing in itself. People do not use them in their work, they are not interested, and profile process people are also fine - everything is built on paper. In such situations, the “role of the individual in history” greatly increases, that is, effectiveness and efficiency, as well as feedback, depend on the person who is responsible for this process.

Processes for people

What should be the descriptions of business processes so that a wide audience can benefit from them? - Simple enough and practical. The form should not prevail over the content. The document must contain the information necessary and sufficient for the executors of the process for its actual execution.

In the process description there are process diagrams. They can be drawn in different ways, in different notations and with varying degrees of detail. Compare two options (this is not the same process, we'll talk about notation now)


On the left, the process in swimlane notation (a swimming pool with “tracks” for process roles). Right - in EPC notation. Each option has its advantages and disadvantages. The variant to the left is less formal, allows some liberties in reflecting actions within the framework of the process. The variant on the right has much more refined semantics, but this “form” requires additional labor for its drawing. Yes, the formalization of the process is enhanced and possible errors are excluded during the "structuring" of activities. But the diagram becomes less readable. Of course, there are options in the middle.

We at HPE Software Services are staunch supporters of the first option, because its understanding does not require virtually any special skills and knowledge, everything is more or less obvious. This, in particular, provides the possibility of understanding the process by a wide target audience. Content prevails over form, and this, in our opinion, is not bad.

Integrity and consistency

Another task is to control the process landscape as a whole. So that all processes are mutually coordinated and slightly lagged behind in their development from each other. At some event, an analogy with a brick house was made. What wall to build a house first, and what then? - All at once. It is impossible that one wall was much higher than the other. First we start the corners, and then gradually raise all the walls.

Large formalization requires great efforts to maintain the consistency of process models, the mutual correspondence of interfaces between processes, the unity of terminology, approaches to the formation of KPIs, role models, etc.

Here, too, it seems to us that it is better to sacrifice form and detail, but to design and draw more processes. That is, coverage is more important than detail.

Among our customers were and remain companies that are committed to both the first and second approach. Strongly and poorly caring about the form. Everyone has a different corporate culture and different standards in process management. Someone has no such standards at all, this also happens.

I will express a seditious thought, but I really think so - it is better to ascend to the sky on a fairly simple two-seater airplane than to build a beautiful and large airliner and not be sure whether this thing will take off or not.

The result of drawing processes is more important and more valuable than the process of drawing processes, if you like.