When the One Person Who Knows Is on Leave, the Firm Should Still Have an Answer.

The person who wrote the planning application is on two weeks’ leave. It is the first proper break they have taken in three years.

On the second day, the plant head asks why the system has scheduled a rush order behind three ordinary ones. Nobody can say. On the fourth day, a small change is needed for a new shift pattern. Nobody dares make it. A list of questions grows on the empty desk.

On the sixth day, someone telephones. The answers take ten minutes. The person on leave spends the rest of the afternoon thinking about work.

What We Found

For this article we went through the public record on firms whose knowledge of a system sits with one person or one partner: the sector’s own research, two sources from outside manufacturing and one survey of small Indian firms.

The record for manufacturing itself is thin. The sector’s research holds one account of this issue, from a very large Indian manufacturer, and nothing about plants that depend on one employee.

People who understand older systems are hard to find. In one survey of 500 senior leaders at large enterprises that run mainframes, seven in ten said they had found it hard to hire the right skills. The skills include cloud, security and AI as well as the mainframe itself. It is a vendor’s survey, not about manufacturing, and mainframes are not our kind of work. Our narrow point: if the one person leaves, a replacement is not easily found.

Skills are short in smaller Indian firms too. In one survey of more than 400 small and mid-size Indian firms across IT, manufacturing, education and retail, 56% cite a lack of technical skills to adopt modern solutions. That is about technology in general, not about one expert or one system.

A record nobody checked can be worse than none. One engineer, writing on a developers’ forum about a legacy codebase, described documentation that teammates had produced with AI tools: “The AI docs are simply wrong, 100% hallucinations”, and “Sometimes no doc is better than a bad doc.” That is one person’s account, used only as a reason for engineers to review what a tool drafts.

Our reading is that the one person is rarely the problem; they are usually the reason the system works. They were always there, so nobody planned for their absence, and they never had a quiet month to write anything down.

What Opens Up When the Knowledge Is Written Down

Key-person risk is usually handled as a staffing question. Our reading is that the opening is a document.

• The expert can take leave, a new role or retirement. A successor starts from a record, not from a month of handover.
• Questions are answered on the day. Whoever is on duty can look up how the system decides.
• The expert’s time goes further. An hour confirming a record replaces a year of being the only answer.
• Other firms can quote. More than one supplier can price from the record.

This is our reading. It is not a measured market figure.

Four Ways to Take the Knowledge Out of One Head, Weighed

Option	When it fits	What it risks
Hire or assign a second person to learn from the first	The firm can recruit, and the expert has time to teach	The skills are scarce, the teaching waits on the expert’s diary, and the knowledge is still unwritten, now in two heads
Ask the expert to write a handover document	A quiet period is coming, and the expert wants to write it	The running of the system always comes first. A notice period is far too short for years of decisions
Have a tool draft documentation from the code	A quick first look is enough, and someone will check every line	An unchecked draft can be confidently wrong, and staff trust it
A specification written from the code by others, with the expert confirming it	The firm wants a record that lets it manage without one person, and the expert is willing	It costs money and some of the expert’s time while nothing is wrong. It needs read-only code access, which the firm arranges

Where You Are Now, and Where You Should Be

This is the benchmark we would set before work starts, and fill in as the assessment goes on.

Measure	Typical starting point	Where it should be	How it is checked
What the system does	Known to one person or one partner	Every function written down in plain words, confirmed by the firm’s own people, including the expert	The specification
Questions answerable without the one holder	Few: most wait for their return	Answered in the building, from the record	A sample of recent questions, looked up in the record, reported at every review
Firms able to quote from the specification	Only the holder	More than one, each pricing from the same specification	The quotes set beside the specification
Where the code is held, and who holds access	On one person’s machine, or with a partner; not recorded	Named, kept where the firm can reach it, with read-only access arranged by the firm	Confirmed before the assessment begins
What a tool drafted	Not separated from what was checked	Every statement traced to the code and confirmed	The specification and its review record
What could not be established	Not known	Listed plainly, with where the gap is	The risk register

The starting points above are what we expect to find. In an engagement they are replaced by your own position, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a manufacturer.

A small part of the filled-in benchmark might look like this.

Part of the application	Written down	Confirmed by	Questions from last month answered from the record
Order priority and rush orders	38 rules	The application’s author and the planning head	9 of 11
Shift patterns and capacity	22 rules	The application’s author	4 of 4
Overnight transfer to the ERP	In progress	Not yet	0 of 3; the author still answers these

The rows above are an illustration, not taken from a real firm.

How We Work With You, and What You Are Left With

1. We listen: a free Reliability Review. A first conversation about the system, who knows it, and what waits when they are away. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is the application one of your own people, or one partner, built and looks after, with read-only access to the code arranged by you before the assessment begins. It produces a written specification of what it does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage.
4. If you approve, we build. We replace a system one module at a time while the old one keeps running. Here that means a rebuild only if you want one; your expert keeps the old application running meanwhile. We never do a single cutover. A traceability matrix links every old function to its replacement. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
5. We review against the benchmark. Before work starts we set the benchmark above. As the work goes on we show you where each measure stands, and the filled-in benchmark is yours at the end.

The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.

This has a price. It costs money and some of your expert’s time at a point when nothing is yet wrong. A record does not make your other staff experts; it gives them somewhere to start. Whether to add tests around the code that stays is your own team’s choice; the specification is what they check against. We offer no assistant that staff can put questions to: what we produce is a document. We do not supply staff, train them or look after the system, and we do not keep the record current after we hand it over. It needs care for the person concerned, who may wonder why the firm suddenly wants everything written down; how you raise it is yours. We do not work inside a packaged ERP product or in RPG or COBOL. We have no published case of this work for a manufacturer.

At the end you hold the specification, the risk register, and a filled-in benchmark that shows what was written down, who confirmed it, and which questions the record now answers.

What changes for the business:

Role	What they gain
CEO	A holiday, an illness or a resignation stops being a risk to the business.
CTO or CIO	Other engineers can start on the system from a confirmed record, not from a month of handover.
CFO	A departure is planned for with a record in hand, and does not bring an emergency contract on the holder’s terms.
COO	Whoever is on duty can find out how the system decides, from the record.
Head of people	The person who carried the system alone can take leave, be promoted or retire, and a successor starts from a document.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
In one vendor’s survey of 500 senior leaders, seven in ten said they had found it hard to hire the right skills.	We are not a staffing firm and supply nobody. We write down what an application does, so a successor or a second supplier starts from a record. We do not work on mainframes.
One engineer wrote of documentation produced with AI tools, “Sometimes no doc is better than a bad doc.”	AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Nothing enters the specification on a tool’s word alone.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We agree what “written down” means before we start, so you can see how far the firm has come while your expert is still there to confirm it.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →