Ask Who Knows How the Dispatch System Works, and the Answer Is a Phone Number.

A large customer has disputed an invoice. They say the freight was charged twice on a split delivery.

The finance head asks the head of IT how the dispatch system works out freight when a load is split. The head of IT does not know. Nobody in the building does. The system was built eleven years ago by an outside partner, who has looked after it ever since.

So the question goes to the partner. The reply comes four days later, and it is accurate and helpful. The finance head has spent those four days unable to tell a customer how the firm’s own invoice was calculated.

What We Found

For this article we went through the public record on manufacturers whose knowledge of their own systems sits with an outside partner or with one person: one account from a very large Indian manufacturer, and three sources from outside manufacturing on written records, scarce skills and documentation drafted by tools.

The one account from the sector describes an arrangement, not a failure. In a press article some years ago, a former CIO of a very large Indian manufacturer described how its work was arranged: its applications and its infrastructure were each handed to an outside partner. It is an older account, of a firm far larger than our readers, and we use only its description of how the work was arranged. It gives no cost, and we draw none.

Where the written record and the system disagree, firms report harm. In one survey of more than 600 technology leaders and practitioners in the US and UK, run by a firm that sells software tools, more than nine in ten reported harm to the business from a mismatch between the architecture as built and the documented standards. That survey covers every sector, not manufacturing alone, and it is about documents that no longer match what was built. A firm whose only record is in a partner’s heads has no document to match.

The people who understand older systems are hard to find, even for large firms. In one survey of about 500 senior leaders at large enterprises that run mainframes, about seven in ten said they had struggled to find the right skills. The skills in question 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: knowledge held by a few people is not easily bought in again.

A tool’s draft is not a record until someone checks it. One engineer, writing on a developers’ forum about a legacy codebase, described documentation that teammates had produced with AI tools as simply wrong and wholly made up, and said that no document can be better than a bad one. That is one person’s account, and we use it only as a reason for engineers to review whatever a tool drafts.

Our reading is that most firms in this position did nothing wrong. They hired a partner, or relied on one able employee, so that they would not need to know how the system worked. Nobody asked for a record, so none was made.

What Waits While the Answer Is Somewhere Else

Depending on a partner or one person is usually treated as a supplier matter, or a staffing one. Our reading is that it is about what the firm itself holds.

The first cost is the waiting. A customer or a plant head waits while the firm asks someone else.

The second is that the firm cannot check what it is told. It has nothing of its own to set the answer against, however good the answer is.

The third is that every later choice starts from nothing. A second quote, a new hire or a replacement all begin with a description nobody in the firm holds.

This is our reading of the evidence. It is not a measured market figure.

Four Ways to Hold the Answer in the Building, Weighed

There are four real options. Each one is right for somebody.

Option	When it fits	What it risks
Keep asking the partner or the one person	Questions are rare, the relationship works, and nothing is about to change	Each answer is used and lost, the firm has nothing to check it against, and the dependence deepens with every change
Ask the partner or the person to write it all down	They have the time, and the record is part of what the firm pays for	The writer is also the one keeping the system running, and the running always wins
Have a tool draft documentation from the code	A quick first look is enough, and someone will check every line afterwards	An unchecked draft can be confidently wrong, and a wrong record is trusted more than no record
An assessment that writes the specification from the code, checked by engineers and confirmed by the firm’s own people	The firm wants a record it owns, that it can read, show and rely on	It costs money and changes nothing in the system. It needs read-only access to the code, which the firm arranges, and time from the people who know

Where You Are Now, and Where You Should Be

Before any work begins we set a benchmark: a few measures taken from your own position, each with a target.

Measure	Typical starting point	Where it should be	How it is checked
What the system does	Known to the partner or to one person	Every function written down in plain words, confirmed by your own people	The specification
Where a question about the system is answered	By a call to the partner, or a wait for one person	In the building, from the firm’s own record	Reported at every review
Where the code is held, and who holds access	Not known, or never asked	Named, with read-only access arranged by the firm before the assessment	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 the public record suggests and what we expect to find. In an engagement they are replaced by your own figures, 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.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about your systems, who looks after them, and the questions nobody in the building can answer. 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. This article is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is the applications an outside partner or one of your own people built and looks after, with read-only access to the code arranged by you before the assessment begins. It produces a map of the system as it stands, 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. You get the options and our recommendation.
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 decide you want one; many firms in this position need the record, not a new system. We never do a single cutover. Each module has a traceability matrix. 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. After each module 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 approach has a price. Producing the record is real work, it costs money, and it changes nothing in the system itself. It needs the code: if your partner or your own expert holds it, you arrange read-only access before the assessment begins. It needs time from the people who know the system, who confirm what we write. And it goes out of date unless someone on your side keeps it current; we do not do that afterwards, and we do not keep the system running. We offer no assistant that staff can put questions to. We do not work inside a packaged ERP product, on plant control systems, or in RPG or COBOL. The older technologies we read include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP. We have no published case of this work for a manufacturer.

What changes for the business:

Role	What they gain
CEO	The firm can explain its own systems without making a call.
CTO or CIO	A specification the firm owns: the rules, the scheduled jobs and the connections, taken from the code and confirmed in-house.
CFO	A partner’s estimate can be read against a record of what is actually there.
COO	A question about how an order or a batch was handled is answered the same day, in-house.
Head of people	What the firm knows about its systems stops being counted in people.

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

The case	What IOanyT does
At a very large Indian manufacturer, in a former CIO’s account, its applications and its infrastructure were each handed to an outside partner.	Our part is far narrower than this case. We do not take work back from a partner, supply staff or obtain anything from a partner, and we draw no cost from the record. We read a system’s code, once the firm has arranged access, and write down what it does, so the firm holds its own record whoever looks after the system.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We start by writing down what your system does, so the answer to the next question is already in the building.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →