“Only one person knows how our system really works”
Every long-established business has someone like this. They were there when the system went in. They know which report to run on a Monday, which field must never be left blank, and how to coax month-end through when it sticks. Ask anyone else and they'll say, "Check with them."
That person is usually brilliant and loyal. Leaning on them that hard is still a risk, for them and for the business.
Why it happens
Business systems pick up knowledge in layers. A workaround here, a custom report there, a field reused for something it was never meant for because the business needed it that week. Each change made sense at the time. Ten or fifteen years later, the way the system really works lives more in one person's head than in any manual.
It's also a sign the system fitted the business well enough that nobody needed to look at it closely, until the business started changing faster than the workarounds could.
What it costs
- Holidays become a planning exercise. Some jobs simply wait until they're back.
- Training takes months. New starters learn the workarounds, not the process.
- Change slows down. Every new idea goes through the one person who understands the knock-on effects, on top of their day job.
- Key-person risk. If they're ill, leave or retire, the business loses capability overnight.
- Hidden errors. When only one person understands a process, nobody else can spot when it's quietly going wrong.
None of this shows up on a P&L. It shows up as a business that hesitates.
What changing looks like
The goal isn't to replace the person. It's to move their knowledge out of their head and into a system that makes the right way the obvious way.
- Write down what actually happens. Before any software decision, map the real process, including the workarounds. Your expert is the most valuable person in this step. Make them part of the project, not a casualty of it.
- Decide what to keep. Some workarounds exist because the business is genuinely different. Those become proper features or settings. Others exist only because the old system couldn't do something, and they can go.
- Put the process in the software. Screens, statuses and permissions should guide people through orders, receiving, picking and dispatch, so a new starter can follow it.
- Make reporting self-serve. Live dashboards instead of "ask so-and-so to run the report".
- Keep changes small and frequent. A platform that can be adjusted as the business moves means knowledge stays in the system rather than drifting back into people's heads.
With Dark Store Systems, development can be owned code or leased, so you decide how much of the platform is yours.
Questions to ask yourself
- Could the business run month-end next week if your expert were off?
- How long does it take a new starter to be trusted with the system?
- How many spreadsheets sit alongside the system to make it work?
FAQs
Isn't this just a documentation problem? Partly. Documentation helps, but if the system relies on workarounds, documenting them still leaves you with a fragile process. Building the process into the software is more durable.
Will our expert feel pushed out? Not if they lead the project. Their knowledge decides what the new process looks like, and they get to stop being the only safety net.
Do we lose our custom reports? Reports are part of discovery. The ones that matter are rebuilt, ideally as live dashboards anyone can open.
Where do we start? Shadow your expert for a week and list every task only they do. That list is your project scope.
Software that moves as fast as your business. Talk to us about where your business is going.