Some debates may seem small, but they open up very large questions.
I recently read a very accurate reflection on something many organizations experience in silence: for years, we have confused improving processes with documenting them well.
And let’s be careful here, because documentation is important. I am not going to oversimplify this by saying that procedures, process maps, diagrams, or work instructions are useless. They are useful. Very useful, in fact.
The problem appears when the organization starts to believe that the work ends there.
When the procedure is published.
When the document is uploaded to the intranet.
When the map is updated.
When someone can say in an audit: “Yes, that is documented.”
But the uncomfortable question is different:
Is anyone actually using it?
Because having documented processes is one thing. Having living processes is something very different.
A living process is not an archived PDF. It is not a folder with versions. It is not a collection of beautiful diagrams known only by those who created them.
A living process is something the organization consults, understands, uses, challenges, and improves.
And that is where many companies fail.
Not because of a lack of procedures, but because of a lack of adoption.
Publishing is not implementing
There is a widespread fantasy in many organizations: the idea that publishing a procedure is the same as implementing it.
The document is written, reviewed, approved, communicated by email, and the organization assumes that people are now working that way.
But people do not change the way they work because someone has published a new version of a document.
They change when they understand why that process exists.
They change when they see that it makes their work easier.
They change when the process removes real friction.
They change when managers use it, explain it, and apply it with good judgment.
They change when they can participate in improving it.
They change when it stops feeling like a bureaucratic imposition and starts being perceived as a useful tool.
Because if a process is only published, but nobody explains it, nobody defends it, nobody consults it, and nobody improves it, the most likely outcome is always the same: each area will find its own way to get the work done.
And then the shortcuts appear.
The exceptions.
The parallel emails.
The hidden Excel files.
The informal approvals.
The “real ways of working” that do not appear in any document.
The organization believes it has a defined process, but in reality, it has two: the official process and the real process.
And almost always, the real process wins.
Top-down education is essential
Here, I believe there is a fundamental point: it is not enough to ask teams to follow processes. There needs to be top-down education.
Senior leaders and managers should not limit themselves to demanding that processes are documented. They should actively promote their use.
That means explaining what each process is for, what problem it solves, how it connects with business objectives, and why it is important for coordinating work across departments.
Because too often, processes are seen as something related to “quality,” “audits,” or “compliance.” Something we need to have because it is required. Something that gets updated when a certification is coming, when there is a non-conformity, or when someone from above asks for it.
But processes should not live trapped inside that frame.
A well-managed process should help people work better.
It should reduce ambiguity.
It should clarify responsibilities.
It should prevent rework.
It should improve coordination between departments.
It should make problems visible.
It should support decision-making.
It should help the organization learn.
If it does none of that, then we probably do not have a useful process. We have administrative documentation.
We need people to want to consult processes
This point seems especially important to me.
Many companies obsess over having their processes published, but dedicate very little energy to making people want to consult them.
And that completely changes the conversation.
Because it is not only about having an organized repository. It is about making processes easy to find, easy to understand, and useful at the exact moment someone needs them.
A process that nobody can find does not exist.
A process that nobody understands does not help.
A process that nobody consults does not govern anything.
A process that nobody can question quickly becomes obsolete.
That is why, in addition to documenting processes, we need to design the user experience of the process itself. It may sound unusual, but it is critical.
If we want someone to consult a process, that process must be written to help them, not simply to protect ourselves internally.
It should answer real questions:
What do I need to do?
Who makes the decision?
What inputs do I need?
What output should I produce?
What criteria apply?
What exceptions exist?
What should I do if something does not fit?
How do I know whether I am doing it correctly?
And, above all, who can I go to if the process does not work?
Because when a procedure only describes the theory but does not help solve the real problems of daily work, people stop consulting it.
And they are right to do so.
Challenging a process should be seen as a sign of maturity
Another essential point: people must be allowed to challenge processes.
In some organizations, questioning a process is interpreted as resistance to change or lack of discipline. But very often, it is exactly the opposite.
Someone who challenges a process from the operation may be identifying an improvement opportunity that cannot be seen from an office.
If a process creates unnecessary bureaucracy, we need to say it.
If an approval does not add value, we need to review it.
If a sequence of steps does not reflect reality, we need to correct it.
If a responsibility is badly assigned, we need to change it.
If the process pushes people to look for shortcuts, we need to ask ourselves what we are designing badly.
Criticism should not be seen as a threat. It should be seen as a source of learning.
Of course, it needs to be properly channelled. This is not about everyone doing whatever they want. It is about creating mechanisms so that processes can evolve with the reality of the business.
Because a process that is not reviewed becomes fossilized.
And a fossilized process becomes a burden.
The goal is not to have more documents, but better ways of working
I think this is the heart of the matter.
For too long, we have measured process management through deliverables: number of procedures, number of diagrams, number of updated documents, number of audits passed.
But perhaps we should start measuring it differently.
How much rework have we eliminated?
How much time have we reduced?
How many decisions have we clarified?
How many conflicts between areas have we avoided?
How many recurring exceptions have we turned into clear rules?
How many people actually consult the processes?
How many improvements have come from the teams themselves?
How much value does the process bring to the customer, whether internal or external?
Because the real success is not having the process perfectly documented.
The real success is that the organization works better because of it.
Documentation is necessary.
But documentation is not transformation.
Transformation requires adoption, leadership, education, participation, and continuous improvement.
And perhaps that is the real question we need to open up: we need to stop treating processes as documents to be published and start treating them as living systems to be cared for, used, challenged, and improved.
Because a process is not valuable because of how well it is written.
It is valuable because of how much it helps people work better.