Every company we work with has a person like this. Ask how orders really move through the business, and people don't point at a document. They point at a name. "Talk to Sarah. She knows." Sarah is the operations manager. She has been here nine years. She knows which suppliers slip, which customers need a call before their order ships, and which rules bend and which never do. On paper there is a process. In practice, the process is Sarah.
This works. It works well, most days. Until Sarah is out sick, or on holiday, or one day hands in her notice. Then the company finds out how much of the business was living in one head. Orders sit. Questions pile up. The people around her can do the steps, but they don't know the reasons behind them. That gap is where the risk lives.
Why it ends up in one head
No one plans for this. It happens slowly, and for good reasons.
A person learns a job by doing it. They hit the odd cases, the exceptions, the "this customer is different" moments, and they remember. Over years they build a map of how things really work. That map is valuable. It is also invisible. It never gets written down, because writing it down is slow and the work is always waiting.
The org chart shows boxes and lines. It does not show that the whole shipping schedule quietly depends on one person checking one thing every morning. The real process and the drawn process are two different things. Almost every company we see runs on the real one.
This is a risk, not a fault
We want to be clear about this. When a process lives in one person's head, that is not a failing of the person. It is usually a sign they are good at their job. They cared enough to learn it properly.
The risk is not about them. It is about the business having one copy of something important. One copy of a document is a risk. One copy of a process is the same risk, just harder to see. You would not run your accounts with a single file on one laptop and no backup. A key process held in a single memory is that file.
So the goal is not to replace the person. The goal is to make a second copy of what they know, so the business is not exposed the day they are away.
Finding the person, and the real work
Every build here starts the same way. We sit with the people who actually do the work and we watch. Not the manager's summary of the job. The job.
We ask plain questions. What do you do first? Then what? How do you know this order is fine and that one needs a call? What breaks, and what do you do when it breaks? We follow one real order from start to finish, and we write down every step, including the small ones people skip when they describe it out loud.
What comes out is almost always richer than the written procedure. There are checks no document mentions. There are rules that only exist because of one bad week three years ago. This is the thing worth capturing. Not the tidy version. The true one. We also find where the person is the bottleneck: the approvals only they can give, the questions only they can answer. Those are the points where the business stalls when they step away, and the first places software can help.
What the software keeps, and what stays with the person
Here is the line we hold. Software is good at the routine and the rules. People are good at judgment. We build for that split on purpose.
The software takes the repeatable parts. The steps that happen the same way every time. The checks that should always run. The rule that says an order over a certain size needs a second look, or that this kind of request goes down this path. Once that lives in a system, it does not forget, it does not go on holiday, and a new hire can follow it on day one without a nine-year memory.
The judgment stays with the person. The odd call. The exception that needs a human to weigh it. The moment where the right answer depends on context a system does not have. We do not try to remove that. We surface it clearly and put it in front of the person who should decide.
The result is quieter than it sounds. The person is not pushed out. They get their time back. The routine runs without them, and they are freed to handle the cases that genuinely need them. The knowledge that used to live in one head now lives in one head and in the system too. Two copies. That is the whole point.
How a build actually starts
We keep the start small and honest. First, we map the work. A week or two of watching, asking, and writing down how one real process runs today. No code yet. Just a clear picture both sides agree on.
Then we ship one workflow. Not the whole business. One process, end to end, the one where the risk or the delay is worst. We put it into daily use and let the people who do the job tell us where it is wrong.
Then we keep the person in control. They see what the system is doing. They can step in, override, and correct it. Trust is earned one workflow at a time, not asked for up front. That is how a business stops depending on a single memory. Not with a big rebuild. With one process, mapped honestly and shipped for real, and then the next one.