Automate Production Reporting Without an MES

The morning meeting runs on last night's spreadsheet

In most mid-size plants, production reporting works like this: shift leads write numbers into a spreadsheet or a paper form, someone consolidates them in the morning, and by the time management sees yesterday's output, the day's problems are already hours old. The data exists. It is just slow, manual, and occasionally wrong.

The published numbers, mostly from vendors selling reporting software, put a manufacturing site at dozens of recurring reports a week, 30 to 90 minutes of a supervisor's time each, and manual transcription errors at one to three percent. Treat those as sales figures. The direction is right and your own supervisors can give you the real number in a week of honest timekeeping: a skilled person's week spent formatting data instead of fixing the line, plus a permanent margin of numbers nobody fully trusts.

To automate production reporting you do not need to replace the measurement. You need to replace the plumbing between where the data is created and where it is read. Most of that data is created once already, out loud, at shift handover.

What the vendor guides skip: you probably don't have an MES

Search this topic and every result assumes an MES or a full IoT layer already streaming clean machine data. If you have that, most of the hard part is solved and any BI tool will draw the chart.

The plants that actually need this are the ones where reality looks like:

• Two machines with counters, six without.
• A SCADA system that exports a nightly CSV and nothing else.
• Downtime reasons written in free text at 5am, in whatever language the shift lead thinks in.
• An ERP whose production module was configured in 2011 by someone who left.
• A quality log that is genuinely a paper clipboard.

An MES project fixes this in eighteen months and seven figures. An agent-based pipeline reads what you already have and gives you a trustworthy daily report in weeks. Both are valid; only one of them is available this quarter.

How automated production reporting works

1. Capture at the source, in whatever form it exists. Machine counters and MES or SCADA data flow in directly. Human-reported data, downtime reasons, quality notes, changeover times, arrives via a quick form, an email, or a WhatsApp message the system parses. Where a system has no export at all, an agent can read it through its own interface the way a person would; that is what automating a system with no API means in practice.
2. Normalize the free text. "molde 3 dando problemas otra vez, paramos 40 min" becomes a structured downtime record: machine M3, cause tooling, duration 40 minutes, shift B. This is the step spreadsheets have never been able to do and the single biggest reason downtime data is unusable in most plants.
3. Reconcile against the ERP. Does reported output match the inventory movements and the work order bookings? Mismatches surface the same day, not at month-end stocktake. If your ERP is old, the connection is usually still possible; see connecting a legacy ERP.
4. Publish before anyone asks. The 6am summary posts itself to the management channel: output against plan, OEE, downtime by cause, scrap rate, and the exceptions that need a decision today.
5. Flag anomalies with context. "Line 2 scrap rate is three times its 30-day average; the downtime log shows a die change at 02:14." A number plus its probable cause beats a red cell in a spreadsheet.
6. Answer the follow-ups. The question that comes back in the thread, "why is line 2 down again?", gets answered from the downtime log, maintenance tickets and shift notes, in the same channel. That is the Slack or WhatsApp assistant layer sitting on top of the same data.

Where each number should come from

The reconciliation design matters more than the report design. Two sources that should agree, and a rule for what happens when they don't, is the whole trick.

Report line	Primary source	Cross-check	Typical failure it catches
Units produced	Machine counter or MES	ERP finished-goods receipt	Output booked to the wrong work order
Downtime by cause	Shift notes, parsed	Counter gaps on the same machine	Unrecorded micro-stops, "we were running"
Scrap and rework	Quality log	Material issued minus good output	Scrap absorbed silently into yield
Changeover time	Shift notes or MES state	Schedule versus actual start	Setups that always overrun the standard
Labour hours	Time clock	Hours booked to work orders	Hours parked on a catch-all job
Material consumed	ERP issue transactions	BOM times good output	Stock that walks, or a BOM that lies

If a line in your report has no cross-check, it is not a reported number, it is a claim. Start with the three rows you can genuinely reconcile and add the rest as sources come online.

Job shops and fabrication: report on the work order, not the line

Repetitive manufacturing reports on the line: OEE, units per hour, scrap rate. A fabrication shop, structural steel, sheet metal, MEP spools, weldments, has no meaningful line. Every job is different, so an automated fabrication reporting system reports against the work order instead:

• Hours booked against estimate, per job and per operation, with jobs trending over estimate flagged while there is still time to act rather than at invoicing.
• Material issued against the cut list, including drop and remnant, which is where job-shop margin quietly leaks.
• Progress in the shop's own units: spools fabricated, welds complete, joints tested, pieces primed. Nobody in a fab shop asks for OEE.
• Ship-date risk, the only report the sales office actually reads: which jobs will miss, and what is holding them.
• Weld and material traceability, heat numbers and welder IDs attached to the job record, because the report and the audit trail should be the same data. The lot-level version of that argument, and how to test whether it holds, is in batch traceability without an MES.

The pipeline is identical. What changes is the reconciliation target: the job cost record, not the inventory ledger. A shop running a job-shop ERP already has most of this data trapped in three places, and the report is the thing nobody has time to assemble.

Why an agent and not just a scheduled query

If all your data were already clean, structured and in one database, a scheduled query would be enough and you should build that instead. Reach for an agent when at least one of these is true:

• Input is unstructured. Free-text notes, voice messages, photographed forms, emailed supplier confirmations. Turning language into fields is the job.
• The mapping drifts. Operators name machines and causes their own way, and the vocabulary changes. Corrections feed back so the mapping improves; that is what self-improving skills do in a production setting.
• Follow-ups are unpredictable. A dashboard answers the questions someone thought to chart. The rest arrive as sentences.
• Sources disagree and someone must investigate. Pulling the underlying records for a mismatch is an investigation, not a query.

Where none of that applies, keep the query. Fewer moving parts.

Rollout order that works

1. Automate the consolidation first. Same data, same numbers, zero retyping. Trust builds fast when the automated report matches what people already believed, and it costs you nothing when it doesn't, because you find out on day one.
2. Add ERP reconciliation. This is where errors that used to hide until stocktake become same-day fixes. Expect the first two weeks to be uncomfortable; the discrepancies were always there.
3. Add anomaly alerts, but only after baselines exist. Thirty days of clean history first, or you will drown the shift leads in false alarms and they will mute the channel permanently.
4. Open the Q&A interface. Managers ask questions in Slack or WhatsApp against live production data instead of asking a person to build a pull.
5. Then extend upstream. Once the report is trusted, the same capture layer feeds maintenance triggers, supplier chasing and the OEE numbers that used to be assembled by hand. Machine-level detail, and why sensors only answer a third of the question, is in OEE tracking without an MES.

Keep a human on anything that writes back into the ERP. Reading and reporting can run touchless; corrections to booked production should sit behind an approval step, and every automated action should be logged so you can monitor what the agent did when a number looks wrong.

What it costs and how to check the payback

A first automated daily report over existing sources typically lands in the EUR 5,000-15,000 setup range with a few hundred a month running. The per-report model cost is negligible; shift notes are short documents.

Measure three things before you start, or the payback conversation becomes a matter of opinion:

1. Assembly hours per week. Supervisors and whoever consolidates. This is the number that drops immediately.
2. Report latency. Hours from shift end to a number management can act on. This drops from a morning to minutes.
3. Discrepancies found at stocktake or month-end. This is the compounding one, and the reason to reconcile rather than just publish.

Run the same three numbers ninety days later. The baseline-first ROI method exists because projected percentages from a vendor, including us, are worth exactly nothing next to your own before-and-after.

What this looks like deployed

Our manufacturing supply chain case study covers a real deployment: which sources were connected, the reconciliation rules, and what changed in the morning meeting. The generalized version of the pattern across finance, sales and operations is automated reporting, and the sector overview is manufacturing.

If your shift data currently lives in a spreadsheet, a WhatsApp group and someone's memory, that is a normal starting point, not a blocker. Tell us what your sources look like and we will tell you which report you can automate first.

---

Sources: Jodoo, production reporting software, iFactory, manufacturing reporting automation, Explitia, production reporting guide.