Five observations from practice on where process management often gets stuck: lived versus documented processes, documentation, organizational structure, indicators and the clarity of process representations.
Processes and process structures are part of an organization's management system. They give the people who move within this system orientation and enable them to do the right thing at the right time, with as little effort as possible. In my view, whether this succeeds depends on how processes are designed, described and lived in day-to-day work. In Part 1, I described five principles. This second part presents five observations from my work on where process management often gets stuck in practice. They are based on my experience. Where I rely on a source, it is cited.
At a glance
The processes actually lived often deviate from the documented processes. The documentation then describes a workflow that does not take place like that in day-to-day work.
One frequent cause, as I see it, is that organizations do not actively work with their processes. The PDCA cycle from Part 1 is then not lived. Processes are described once and then filed away. In the meantime, however, the organization keeps developing, and with it the processes in daily work. This development is not carried over into the documentation. As a result, the gap between the described process and the lived process grows over time.
The lack of accepted responsibility may also contribute. If nobody takes responsibility for a process, nobody takes care of adapting the documentation to the process as it is lived.
This becomes particularly clear before the annual external audit. The process descriptions then have to be reconciled with practice at short notice. Considerable resources often go into this reconciliation. I consider this a waste, because this effort would be smaller if the descriptions were maintained throughout the year.
This has consequences for the entire management system. Documentation that does not match the lived workflow can be used neither for onboarding nor as a basis for improvement. It thereby loses credibility among those who are supposed to work with it.
In my view, support is increasingly coming from the software side. Suitable tools are getting better and make it easier to describe processes. At the same time, they can help to maintain, review and adapt processes continuously in day-to-day work, so that the PDCA cycle does not stay on paper.
The documentation of processes is seen as additional ballast. It is regarded as a task alongside the actual work and then often remains with quality or process management, even though the specialist departments carry out the processes.
This impression is reinforced by the reconciliation of process descriptions before the annual external audit, which I described in section 1. The organization perceives this work as yet more ballast, and acceptance of the process descriptions declines even further as a result.
The standard leaves room as to how extensive a company's process documentation is [1]. What a company considers necessary for the effectiveness of its management system is, accordingly, for the company to decide.
In many organizations, too much is documented rather than too little. New documents keep being added, but old rules and descriptions are rarely questioned and removed. Something is constantly added and hardly anything falls away, so the documentation grows without end. Working actively with the processes therefore also includes regularly checking what is still needed and consistently cutting away what is outdated.
Moderation is also called for with processes. ISO 9001 refers in clause 4.4 to quality-relevant processes [2]. Occasionally this gets out of hand, and every small activity is declared a process. In many such cases, in my view, a short work instruction would suffice. A process is worthwhile where activities are connected, inputs are transformed into results, and responsibility, indicators and risks need to be considered. The degree of effort depends on the importance for the result, not on the number of activities that can be described.
A company's organizational structure often stands in the way of thinking in workflows. It arranges a company by departments and areas of responsibility. Workflow organization (process organization), by contrast, looks at how a task passes through the company from start to finish.
Within the boundaries of a department, the assignment of responsibility works. It is different as soon as a process touches several areas, and this applies to most processes. The focus then easily lies on one's own area and less on the result of the entire workflow, and there is often a lack of willingness to take responsibility for the entire workflow. A pronounced silo mentality very often slows progress.
One cause of silo thinking could be the differing objectives of the specialist departments.
In my view, a further observation is connected with this. The roles required in process management, for example the process owner, are often not filled well enough, and their responsibility is frequently not taken on. Overall responsibility for a process is then readily handed to a central department, such as quality or process management. Such a department can moderate, describe and evaluate processes. Whether it also has the authority to enforce changes in the departments involved is then the open question. Here the principle from my article on leadership applies again: responsibility without authority is a design flaw [3].
Top management assigns the roles and responsibilities. Authorities ensure that those responsible are able to act, and the roles are communicated within the company.
Practical takeaway
Another hurdle concerns indicators. Indicators that truly reflect the process are not always defined. Some have no connection or only a very general connection to the process and therefore say little about how it is running. Indicators for the effectiveness and efficiency of the process are mostly missing.
In my view, this shortcoming is costly, especially for efficiency, because process efficiency holds significant cost drivers of organizations today. What ISO 9001 describes on indicators, and how effectiveness and efficiency differ, is covered in Part 1.
Process representations are often very technical. They may not be understood by all employees. In my view, a representation that its users do not understand can fulfil its purpose as orientation in day-to-day work only to a limited extent. Here too, I see support from software. Suitable tools can help to present processes in such a way that users grasp them more easily.
In my assessment, the five observations are connected. Deviating processes, documentation perceived as ballast, the organizational structure with missing roles, indicators with little informative value and representations that are hard to understand all touch on the question of whether an organization thinks in workflows. Where a company stands on these five points can be clarified in an initial conversation.
As of: all internet sources accessed on 21 October 2026. Source titles are given in the original German, with an English translation in square brackets.
[1] DQS: Was ist dokumentierte Information [What is documented information]. https://www.dqsglobal.com/de/entdecken/wiki/was-ist-dokumentierte-information
[2] TÜV Akademie: Grundlagen Prozessmanagement [Fundamentals of process management]. https://akademie.tuv.com/blog/grundlagen-prozessmanagement/
[3] Jens Hutter, QualiTEx Global: Was 25 Jahre Qualitätsmanagement über Führung lehren [What 25 years of quality management teach about leadership]. https://qualitexglobal.de/aktuelles/25-jahre-qualitaetsmanagement-fuehrung
Let's discuss, without obligation, what this development means for your company.