Process knowledge: what an organisation knows about its own work

Process knowledge is everything an organisation knows about its own workflows: what the steps are, who owns them, which rules apply and why things run this way and not another. Only a small part of it sits in documents. The larger part lives in people’s heads, in habits, and in the exceptions nobody ever wrote down.

Documented is not the same as known

This is the gap most projects fall into. An organisation can be fully documented and still be unable to say how it works.

A manual describes a state as of the day it was signed off. Process knowledge is what holds today — including the three deviations that have settled in since, and the one rule that is still in the policy but that nobody has followed for two years.

That makes process documentation the form, not the content. It is the attempt to capture process knowledge. Whether it succeeds depends on whether what was captured keeps pace with reality.

Where process knowledge actually lives

It spreads across four places, and only the first is the one everybody searches first:

• In documents. Work instructions, SOPs, quality manuals, contracts, standards. Easy to find, often outdated, rarely reconciled with one another.
• In systems. What your ERP, CRM or ticketing tool records says something about how work happens. But it only shows what that particular system sees.
• In people’s heads. The largest share, and the only one that goes home at night. Whoever knows that approval with this one supplier always takes two weeks didn’t read it anywhere.
• In the exceptions. Every workflow has special cases, and special cases almost never appear in the description. They are part of the process all the same.

Why it disappears

Process knowledge doesn’t break, it leaves. Three occasions are enough:

• Turnover. Someone moves department or retires, and what was never written down goes with them.
• Reorganisation. Responsibilities get re-cut. The workflow stays; the knowledge of why it looks like this stays with the old roles.
• System migration. Whatever logic sat in the legacy system gets rebuilt in the new one — usually without anyone carrying over the reasoning.

Rule of thumb: if only one person can answer “why do we do it this way?”, that isn’t the organisation’s knowledge. It’s theirs.

How you notice some is missing

Missing process knowledge rarely shows up on its own. It shows up when something has to build on it:

• A migration is coming, and nobody can say which workflows outside the core system are affected.
• An audit asks, and documented practice doesn’t match lived practice.
• Onboarding takes months, because new people assemble the picture from conversations.
• An AI initiative stalls, because nobody agrees on what the agent should take over, or under which rules.

In all four cases the diagnosis is the same. What’s missing isn’t software and isn’t headcount — it’s a current picture of how work actually happens.

From knowledge to a body of record

The route there doesn’t run through a modelling project. Classic BPM tools assume the knowledge already exists and merely needs to be put into a notation — which is precisely the gap (more in the comparison ProcessCollector vs. BPM tools).

The sturdier route is the other way round: start from what is already there. An existing work instruction becomes a structured workflow with roles and steps, and the people who live the process correct that instead of starting from a blank page. This is where ProcessCollector comes in. The process map emerges along the way, rather than being scrambled together at the end.

In short

Process knowledge is what an organisation knows about itself — and it is perishable. Securing it doesn’t mean documenting more; it means moving the act of capturing close enough to the actual work that the two don’t drift apart.