Ending Manual Re-Entry of Plant Data: A Benchmark

A consultant has proposed a project to predict which batches will be rejected. The managing director likes the idea. The consultant asks for two years of records: output, stoppages and rejections, by machine and by shift.

The head of operations walks to the plant office and opens a steel cupboard. The records are all there. Years of shift sheets in box files. Stoppages written in the margins. Rejections in a spreadsheet the quality inspector keeps on a laptop. And most of the same figures, typed again, in the ERP, the planning sheet and the month-end report, each a little different.

Nothing has been lost. Every shift was recorded, by people who knew what they were looking at.

The paradox: The plant has written down everything it has done, several times over, and nobody can say which copy to trust.

What We Found

For this article we went through the public record on what holds manufacturers back from using their own figures: an industry body’s survey of manufacturers on barriers to AI, and a report of an Indian industry summit in 2026.

Data comes before machines. In the industry body’s survey, published in April 2026, respondents picked their top three barriers to AI. About six in ten named “Data issues”. Fewer, 25.9%, named the “Need to upgrade legacy equipment”. The page does not give the size of the sample or where the respondents are, and the survey is about AI, not about connecting systems.

In India, fragmented data is named first. The summit report says that “smaller and mid-sized Indian producers encounter a deeper barrier: fragmented data, aging machinery, and a lack of standardized operating frameworks”. The report comes from a market-data firm that rewrites news, and names no firm of that size.

Without that groundwork, results stay small. The same report says “a successful pilot might remain merely a pilot”. A project that runs on figures gathered by hand for the purpose stops when the gathering stops.

Our reading is narrow. A plant’s records are usually careful. What makes them hard to use is that each figure is copied by hand into several other places, at different times, and nobody has ever counted the copies or named which one is the source. Machines are part of the picture, but in the survey they come well behind data, and the state of the records is something a firm can measure without buying a single machine.

What our review does not show: We found no named mid-size manufacturer with this problem and we name none. The survey on AI gives no sample size or country and is not about connecting systems. The summit report is one market-data firm’s account of one event and gives no figure. We found no figure for how many times a plant’s figures are copied, how often the copies disagree, or what that costs. That counting the copies is the place to start is our reasoning, not a measured finding.

What a Benchmark Opens Up

A project to “connect the systems” usually has no measure of progress except the day it finishes. Our reading is that this is why such projects are hard to approve and harder to stop.

Progress can be seen. When the copies of each figure are counted before work starts, the count can be checked at every review, and it should fall.
A disagreement has an address. When every crossing is on the map, a difference between two reports is traced to the crossing that makes it, not argued over.
A project knows where its figures come from. A pilot that starts from one named source for each figure can be run again next month on the same figures.

The gap we see: most manufacturers set out to connect their systems without first counting how their figures travel today, so nobody can say whether a year’s work has helped. The difference is a benchmark agreed before work starts: every crossing mapped, the copies of each figure counted, and one source named for each. A manufacturer that holds that benchmark can watch the copies fall, module by module.

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

Three Ways to Get the Figures Off the Clipboard, Weighed

Option	When it fits	What it risks
Type up the records each time a project needs them	The question is a one-off and the records are few	The typing is paid for again at the next project, and the project stops when the typing stops
A records product, or a connection to the machines, from a specialist	The machines can report, and the firm is ready to buy and run such a product	Older machines may report nothing, and the firm’s own applications still have to receive the figures
A benchmark agreed before work starts: map every crossing, count the copies, name one source for each figure, then rebuild the firm’s own application one module at a time	The records already exist and are copied by hand into the firm’s own applications	It takes longer on the calendar, counting takes people’s time, and paper may stay at the start of the chain

Our recommendation: agree the benchmark before any work begins. Map every crossing between the firm’s own applications, its ERP and its plant records, including those made by hand, by timed files and through spreadsheets. Count the copies of each figure and name its source. Then rebuild the firm’s own application one module at a time, beside the old one, so each figure is entered once and the copies fall at every review. How a figure is first captured on the plant floor is the firm’s own decision: a records product, or anything that reads from machines, is the firm’s option with specialists. We do not connect to machines, read machine signals or work on plant control systems, and we have no connection or integration product.

Where You Are Now, and Where You Should Be

This is the benchmark we would set before the first module moves, and fill in as each module is accepted.

Measure	Typical starting point	Where it should be	How it is checked
Crossings between your applications, your ERP and your plant records	Listed nowhere	Every crossing mapped, including by hand, timed files and spreadsheets	The map of the system
How each crossing travels, and when	Known to the person who does it	Written down: by whom or by what, and at what time	The specification
Figures re-typed from one place to another	Not counted	Counted, and falling as each module is accepted	Reported at every review
The source of each figure	Several copies, none named as the source	One named source for each figure	The specification
Disagreements between systems	Argued in meetings and adjusted	Each traced to the crossing that makes it	The risk register, at every review
Scripts, macros and timed files that carry figures	Unknown, with no owner	Listed, each with an owner on your side	The risk register
Crossings that end inside a packaged ERP or at a machine	Not marked	Marked, and left to your own specialists	The map of the system

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.

Figure	First written	Typed again in	Status
Shift output	Shift sheet	ERP, planning sheet, customer’s portal	Source named; planning sheet now reads from the rebuilt module
Rejections	Inspector’s spreadsheet	ERP, month-end scrap report	Mapped; module under review
Stoppages	Margins of the shift sheet	Nowhere	Mapped; listed for the business to decide

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

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

We listen: a free Reliability Review. A first conversation about your applications, the copies of your figures and how you would measure progress. 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.
We research. We research your sector, the regulator’s position and what the public record says about firms in your situation.
We read the system and propose: the Legacy System Specification Assessment. Here the system is the applications you built or had built beside your ERP, with a map of every crossing that carries a figure in or out of them. 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.
If you approve, we build. We replace a system one module at a time while the old one keeps running. 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.
We review against the benchmark. Before work starts we set the benchmark above. As each module is accepted 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. Counting the copies takes your people’s time, and the work takes longer on the calendar than one large project would promise. Paper may stay at the start of the chain: a benchmark shows where each figure is first written, it does not move the clipboard. We have no connection or integration product, we do not connect to machines, read machine signals or work on plant control systems, and we cannot see inside or change a packaged ERP product. We do not run or monitor a connection after hand-over, we do not clean or reconcile your records, and we promise no result from AI. We have no published case of this work for a manufacturer.

At the end you hold the map of every crossing, the specification, the traceability matrix for every module we rebuilt, and a filled-in benchmark that shows how many copies of each figure remain, and where each figure comes from.

What changes for the business:

Role	What they gain
CEO	The board can see, figure by figure, how many copies are left, and progress is a number that falls at every review.
CTO or CIO	Every script, macro and timed file that carries a figure has an owner on the firm’s side, and the list gets shorter.
CFO	Each production figure that reaches the books has one named source, and every month-end difference has a crossing beside it.
COO	The plant’s careful records are used as they are written, and nobody’s morning goes on copying them again.
Head of digital	A pilot starts from figures with one known source, so what it shows can be run again next month.

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

The case	What IOanyT does
In an industry body’s survey, about six in ten manufacturers named “Data issues” among their top three barriers to AI; 25.9% named the need to upgrade legacy equipment.	Our part is narrower. We do not upgrade or connect machines and promise no result from AI. For a manufacturer’s own applications, we count the copies of each figure and rebuild the application that receives it, module by module.
A report of an Indian industry summit says that without groundwork on fragmented data, “a successful pilot might remain merely a pilot”. No firm of that size is named.	We do not work on plant control systems. We set a benchmark before work starts, so the firm can see each figure come down to one source.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We count the copies first, so that progress has a number before the work starts.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →