Your ERP scheduled a work order for 14 hours, but is it the real duration?
This value was defined a year ago, or worse, when the part was first industrialized, and nobody has re-measured it since the last engineering change. The production team knows the number is wrong, so they stop trusting the plan and rebuild it by hand in Excel.
And this is just one of the issues of using a financial and supply chain management software for production work. The ERP does what it was designed for: it holds the plan, the bill of materials, the purchase orders and the financial record.
What it cannot do is watch and control production execution as it is happening. A manufacturing execution system for aerospace is the layer that does that.
The pitch was “one system for finance, inventory, procurement and production”: all your core business processes covered within one system, so no need to duplicate data and lower IT bills!
But then, after a few weeks, the production team starts asking why the production plan is wrong, where the evidence for a serial number lives, and where they can find the status of a customer work order when they ask for an updated delivery date.
A standard time on a routing usually starts as a rough estimate from the shop floor or the engineering team. It might then be updated a few times, often irregularly, but it is hard for the production team to keep it up to date, as product changes and variants get introduced.
High-mix, low-volume work makes that gap harder to catch. When a shop builds a few dozen units a year across several configurations, the same routing rarely repeats often enough for anyone to notice it's off by 30 or 40 percent and the production team works around it every week.
Serialization makes it worse. A production manager at a components manufacturer told us they split a 10-unit work order into 10 separate single-unit orders, to keep test results and traceability tied to the correct serial number. The ERP now manages 10 objects for what the shop still runs as one flow.
The tool built to plan orders and purchases is being asked to plan at the level of the individual unit, a job it was never designed for.
ERPs are built for finance teams first, and this transpires in the capabilities available for production teams. A production order only needs four states to answer what finance and supply chain ask: planned, in progress, closed, hold. That's enough to track financial transactions, if the order exists, and if we need to restock some items.
It's the wrong resolution for the person responsible for updating a customer on their upcoming order. A head of operations at a European space manufacturer described this issue like this: they create orders in the ERP, but there's no way to trace the phases in between, so the real status lives in someone's head. The workaround is again to rely on people’s expertise and Excel to manually calculate these estimates, which can take one to three hours per request. Worse, the answer arrives too late to act on and is no longer relevant the next day.
And this is the bigger issue. Without real-time status, production catches problems (too) late, which costs more to fix.
ERPs were not built to talk to test equipment, including the ones marketed as production-execution capable. Odoo for aerospace manufacturing and AIT is the clearest case: a capable ERP whose quality module records a binary OK or NOK, but without any details of the tests performed and associated measurements.
So, as soon as a unit enters testing, the ERP becomes “blind” and data gets generated in disparate locations: inspection photos in a folder, S-parameter files on a bench PC, a scanned traveler as a PDF, …
This is fine for simple products, but aerospace and defense companies build the most complex hardware. They require intensive testing, which generates lots of data and evidence. The quality team then needs to assemble them into a report uploaded into the ERP as attachment to the production order.
This operation can take hours to days, delaying production deliveries. And this solution is far from ideal. When a problem is detected on a unit, only a subset of the test data is readily available in the ERP. The rest live on shared drives, depending on teams to follow naming conventions so that information can be easily found. If that is not the case, root cause analysis will take longer.
Cost of goods sold in high-mix, low-volume shops is often estimated by a standard cost with a variance account. The standard comes from the same routing estimate that's driving the schedule, so the plan and the P&L are wrong for the same reason.
Rework compounds it. A unit that goes back for a second pass consumes hours that rarely get billed to it, because nothing links the extra time to the unit that needed it. The hours land in overhead, get spread across the program, and the shop loses the ability to tell an expensive configuration from a cheap one. Material behaves the same way: without a scan-verified kit or an as-built record, a substitution or a scrapped part disappears into an inventory variance instead of attaching to the serial number that consumed it.
On a fixed-price, milestone-based contract that stops being an accounting nuance. The finance team relies on that same standard cost to report program margin while the work is running, so the number everyone is tracking carries the same error as the schedule. And the first hard signal a program manager gets that the contract needs a conversation is usually the closing report, by which point there's no scope left to renegotiate.
Let’s go back to the 14-hour routing.
An MES running underneath the ERP replaces that estimate with a measurement, taken once per unit, as a byproduct of the operator doing the work. The ERP stays the system of record, but with the actual cost and duration of each step in the production process.
Digital work instructions carry a planned time per step. As the operator runs the step and closes it, the MES records the step duration along with any rework or deviation. The measurement is a byproduct of doing the work.
This data is available in production dashboards to show work in progress, work order status and station utilization across every site or work station. So, when a customer asks a question about their next order, it can be answered instantly from a screen.
The same data also answers a question the ERP has never been able to. Anywaves tracks the duration of every step in assembly, integration and test, and uses that to identify the steps with highest ROI for automation or process optimization. MES data coupled with ERP can be used to inform future investments.
An MES is connected to all the equipment and test instruments on the shop floor so that the evidence captured during execution is automatically linked to the serial number.
MES built for aerospace & defense go further and automatically gather photos, approvals, and test results into an EN9100 or AS9100 evidence package. EDGX, an onboard computer manufacturer, was able to decrease report generation from 4 hours to 5 min after implementing Connektica, an MES designed for A&D.
An MES uses REST APIs and Python SDK to push and pull manufacturing and test data with the ERP, so cycle time, rework counts and as-built consumption flow back into the system that owns the plan and the financial record.
With actuals in the ERP, your financial team and program managers can now accurately track in near real time the status and margin of each program without making assumptions. And your sales team can use this to better price the next customer order.
Not every manufacturer needs one. If your routings are stable, your mix is narrow, and no contract requires serial-level traceability, your ERP with a disciplined team is a good answer.
Above that line, the same four symptoms show up together:
Any one of these on its own is an inconvenience good teams absorb. But together with volumes of 20 or 50 or 200 units a year, it starts being the reason the company can't take the next contract without hiring or worse, risking quality issues.
If two or three sound familiar, size the gap with the aerospace MES evaluation checklist.
At Anywaves, closing that gap cut the time to test a space antenna from 8 hours to 15 minutes, a 97% reduction. Book a working session with our AIT experts to evaluate what the gains could be for you.