A cash-flow-critical billing process that no longer depends on one person.
Wholesale distributor. Operator application on P21 data with rule checking. About 4 weeks.
Read the full storySolution
One person knows how it works. That is the problem.
Key-person dependency is when a business-critical process can only be run, checked, or fixed by one employee. The fix is not documentation alone. It is moving the knowledge out of that person's head and into a system that applies the rules, catches the errors, and can be operated by anyone you train.
How it happens
Nobody decides to build a business around one person. It happens by accumulation. A process gets created to solve a real problem. It gets patched as things change. The people who built it leave. One employee becomes good at running it, learns where it breaks, and quietly catches the errors before anyone else sees them.
That employee is not the problem. They are usually one of the most valuable people in the building. The problem is that their judgment has become a component of the system, and it is the one component with no backup.
What it actually costs
- You are one resignation, illness, or retirement away from a crisis. Everyone knows it, and nobody says it.
- Errors are caught by vigilance, not design. When the process fails, it fails silently. The only alarm is a person noticing.
- Your best person is stuck. They cannot take a real vacation, and they cannot move into a bigger role, because the process cannot spare them.
- You cannot change anything nearby. An ERP upgrade, a move to the cloud, or a new module all carry the question nobody can answer: will it break the thing that has to work?
Why documentation is not enough
The usual first move is to have the expert write everything down. It helps, but less than expected. The knowledge that matters most is not the steps. It is the judgment: this number looks wrong, this customer is an exception, this error means that. People are poor at writing down what they do by instinct.
Software is a better container for that knowledge. A rule encoded in a system is applied every time, by whoever is operating it. An error the expert would have spotted gets flagged for someone who would not have known to look.
How I approach it
- Sit with the expert. They know things nobody has written down. The project treats them as the authority they are, and most are glad to finally have a backup.
- Separate the rules from the routine. What is a genuine business rule, what is a workaround for an old limitation, and what is habit.
- Build the system around the rules. It pulls the data from Prophet 21, applies the rules, and tells the operator exactly what needs attention.
- Train a primary and backups. The measure of success is that the process runs correctly on a day the expert is out.
Related work
Questions
Will this threaten the person who runs it now?
In my experience it does the opposite. They stop being the single point of failure and get to take a vacation.
What if nobody fully understands the process anymore?
That is common, and it is a reason to start sooner. The data and the outputs usually tell the rest of the story.
Request a call back
Did a name come to mind while you read this page?
That is the process to talk about.
- One conversation, no obligation. There is no charge and no pitch.
- A plain answer. If it is not feasible, or I am not the right fit, I will say so.
- The first 30 days are guaranteed. If you are not satisfied and I cannot make it right, in your opinion, you get your money back.