Business Processes: the good, the bad and the ugly

    In a large and not even very large company, there are no processes at all. The consulting division of 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 words. In almost every project, one way or another, we design and draw processes.

    In this article we will not talk about theory, we will talk more about practice, taking into account the experience that has accumulated in the Russian HP, now in HPE. To speak in an abstract manner, we take the subject area of ​​IT services management - ITSM, and speaking of processes, we will mean ITIL processes, for example. We do not pretend to be absolutely right, we will be happy to discuss this topic.

    Why do we need processes


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

    It is important to maintain a reasonable balance between “structuring” and practical use by people in their work. Designing (building) a process is a rather time-consuming task, therefore 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 observe a picture when processes for a number of reasons (about them, a bit below) become the lot of a narrow circle of specialized process specialists. This is precisely 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) disappears or sharply decreases.

    The description of the business process in such organizations becomes a thing in itself. People don’t use it in their work, it’s not interesting for them, but the profile process people are also doing well - everything is arranged 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. Form should not prevail over content. The document should contain information necessary and sufficient for the executors of the process for its, in fact, execution.

    There are process diagrams in the process description. 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 notations now)


    On the left is the swimlane notation (a swimming pool with paths for process roles). On the right is the EPC notation. Each option has its advantages and disadvantages. The option on the left is less formal, allowing some liberties in reflecting actions within the process. The option on the right has much more refined semantics, but this “form" requires additional labor for drawing it. Yes, the formalization of the process is increased and possible errors are eliminated during the "structuring" of the activity. But the chart is becoming less readable. Of course, there are options in the middle.

    We at HPE Software Services are staunch supporters of the first option, because understanding it requires almost no special skills and knowledge is more or less obvious. This, among other things, provides an opportunity to understand 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 behind in their development. At some event, an analogy was made with a brick house. What wall of the house to build first, and which then? - All at once. One wall cannot be much higher than another. First we start the corners, and then gradually raise all the walls.

    A 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 KPI, role model, etc.

    Here, it also 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 approaches. Strong and weakly caring for the form. Everyone has a different corporate culture and different standards in the field of process management. Someone does not have such standards at all, this also happens.

    I will express an seditious thought, but I really think so - it is better to take 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 fly or not.

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

    Also popular now: