What happens when only one person understands the whole system?

Almost every established business application has one person you cannot do without. Usually someone who has been there for years, knows the process from the inside, and helped build the application. That person is not the problem. Depending on them is.

The risk is not where people look for it

The obvious thought is the outage: what if this person leaves? That is real, but it is not the most expensive consequence.

The more expensive one shows up earlier. When knowledge sits with one person, that person becomes the bottleneck for every change. Requests queue up, because only they can judge what an adjustment will trigger. Decisions slip, because their assessment is missing. Others do not dare touch the application — which deepens the dependency further.

The result is an organisation that can no longer change its own business process at the speed the business requires.

Why documentation alone does not fix it

The usual reflex is to have the knowledge written down. That helps less than hoped, for two reasons.

First, much of this knowledge is implicit. The person does not know that they know it. They make dozens of small decisions a day that feel self-evident to them — and that is exactly why those never reach a document.

Second, documentation written alongside the work goes stale immediately. It describes a state, not a structure.

What actually helps

Knowledge is not secured by copying it out, but by binding it to a second place:

Into the structure of the application. Rules that are recognisable as rules in the code need no explanation. Rules spread across several places always do.

Into the process itself. When a decision is visible in the workflow — who makes it, on what basis, with which exceptions — it is no longer tied to a person.

Into a second person, on real work. Not through onboarding in advance, but by working together on actual changes. Knowledge transfers through concrete cases, not through explanations.

The first step is an inventory, not a training course

Before any of this can be solved, it has to be visible which knowledge sits where: which rules does only one person know? Which exceptions are recorded nowhere? At which points in the process does experience decide instead of a defined rule?

That map is uncomfortable to produce and hard to ignore afterwards — which is its value. It shows where modernisation has to start if it is to achieve more than a new interface.