AI automation in manufacturing: the gap between the floor and the office

AI automation in manufacturing pays off at the boundary between the shop floor and the office, not on the line itself. The line is already automated. Production data reaches business systems through spreadsheets, printouts and numbers typed at the end of a shift, and that handover is where the accessible returns are.

The boundary exists for good reasons. Operational technology (OT, the systems that run machines) has safety and availability requirements that business software does not. The first rule of crossing it: information flows out freely, and control never flows in.

What we'll cover

• Two worlds with different rules
• Out, not in
• Getting data off the floor
• Building it with CodeWords
• What the office actually needs
• Quality records and traceability
• Maintenance, and the limits of prediction
• The people on the floor
• Changeovers, which is where the hidden time goes
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

Key takeaways

• The accessible returns in manufacturing automation sit between the shop floor and business systems, not on the line.
• Read production data out of the floor, and never write control instructions in through an integration project.
• Downtime capture with a one-press reason code is the best first build, because downtime is the largest recoverable loss in most plants.
• Changeover time is planned and usually larger in total than unplanned downtime, so measure it alongside downtime.
• Predictive maintenance needs failure history that most plants lack, so start with condition monitoring and scheduled maintenance.

Two worlds with different rules

Availability outranks everything on the production side, since a stopped line costs money by the minute.

Safety systems are regulated and interlocks exist to prevent harm to people.

Equipment lifecycles are decades, so a line can run controllers older than the engineers maintaining them.

Patching is constrained by validation requirements and by the cost of stopping production to do it.

Business systems assume the opposite, frequent change, connectivity, and downtime as an inconvenience.

Treat them as separate domains with a deliberate, narrow bridge rather than as one network.

Out, not in

Reading production data is low risk and holds nearly all the accessible value.

Writing control instructions is a different project with safety implications and a different approval process.

Never bypass a safety system, in any circumstance, for any efficiency.

Segment the networks and keep the bridge narrow, monitored and one-directional where possible.

A read-only historian or gateway is the standard pattern, and the right one.

If a proposal requires writing to the floor, it needs the engineering and safety process rather than an integration conversation.

Getting data off the floor

Machines differ enormously, some expose modern interfaces, some expose serial output, some expose nothing.

Retrofit sensors where the machine cannot report. Retrofitting is cheaper than replacing the machine in many cases.

Timestamps and clocks drift, and correlating events across machines requires them to agree.

Units and tags are inconsistent between machines and vendors, and normalising them is most of the integration work.

Sample rates matter. Storing every reading from every sensor produces volume nobody uses; aggregating loses the transient that explains a fault.

Start with what already exists. Most plants have more data being collected and discarded than they realise.

Building it with CodeWords

CodeWords connects to 3,000+ integrations (CodeWords integrations directory, 2026), and each connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which production data, how it is aggregated, who sees it, and what raises an alert.
3. Authorize the connections, the historian or data gateway, the ERP or planning system, and your notification channel.
4. Describe the exceptions: a machine offline, a reading outside plausible range, a shift changeover, a planned stoppage.
5. Run it read-only against one line and compare its output against the shift reports for a fortnight.

You describe the outcome; Cody builds it, connects it, and deploys it. The Free plan covers light use. Pro costs $39 per month and Business costs $100 per month as usage grows (CodeWords pricing page, 2026); details are on the pricing page.

What the office actually needs

Actual output against plan, in something closer to real time than a daily report typed at shift end.

Downtime with its reason, categorised. Downtime is the most valuable production number and the most inconsistently recorded.

Scrap and rework rates by product and by line, tied to what was running.

Material consumption against expected, which shows both waste and inventory drift.

Order status that a salesperson can see, so customer promises are based on reality.

Not a dashboard of everything. Three numbers people act on beat forty nobody reads.

Quality records and traceability

Traceability is a requirement in regulated sectors and increasingly a customer demand elsewhere.

Link batches to inputs, so a supplier problem can be traced to affected output rather than to a whole month.

Capture inspection results digitally, which removes transcription errors and makes the record searchable.

Automate the document assembly for certificates and compliance packs, which is pure administration.

Keep the raw record immutable, with corrections as additions rather than edits.

Recall scope is the test. How precisely you can identify affected product is what traceability is actually for.

Maintenance, and the limits of prediction

Predictive maintenance is oversold and valuable in a few cases. Know which case you are in.

Predictive models require failure history, and most plants have too few failures of any one mode to support a model.

Condition monitoring is different and more reliable, vibration, temperature and current are direct signals rather than predictions.

Start with scheduled maintenance actually happening. Coordination is the bigger gap in many plants.

Automate the logistics: work orders, parts availability, scheduling around production.

Measure whether interventions prevented anything, which is hard and is the only way to know if the programme works.

The people on the floor

They know why the line stopped and the system usually does not, which is why downtime reasons are the weak data.

Make recording trivial, a button, a code, a tablet, rather than a form at the end of a shift.

Do not build individual monitoring. Automation that measures operators rather than machines will be resisted and the data will degrade.

Show them the data, since a team that can see its own output responds to it without being managed.

Ask them what the line actually does that the specification does not describe, which is where the useful detail is.

Union and works council consultation is required in several jurisdictions before introducing anything that changes how work is measured.

Changeovers, which is where the hidden time goes

Changeover time is planned and accepted, so plants do not count it as a loss. Its total is usually larger than unplanned downtime, which gets attention only because it is visible.

Measure changeover time from last good part to next good part. The result is longer than the time anybody quotes.

Break it into steps, since the time is usually concentrated in two of them and nobody has looked.

Separate what could be done while running from what requires a stopped line. This is the largest single improvement available in most plants.

Automate the preparation: materials staged, tooling ready, documentation available before the line stops.

Sequence orders to minimise changeovers. This planning decision needs the actual changeover matrix rather than an assumption.

Report changeover time alongside downtime, because a plant that only measures unplanned loss is ignoring the larger planned one.

Making it survive

Never let the automation affect production availability, which is the constraint everything else is subordinate to.

Handle machine downtime and disconnection gracefully, since an offline machine is normal.

Validate readings against plausible ranges, because sensor failures produce confident nonsense.

Buffer locally so a network problem does not lose production data.

Report the outcome: machines reporting, gaps in coverage, alerts raised, and data quality by source.

Limits worth knowing about

Legacy equipment can be inaccessible without retrofit hardware.

Vendor lock-in is common, and some systems restrict data access by contract as well as technically.

Physical reality constrains everything, cycle times, changeovers, material properties.

Plant networks are fragile, and adding traffic needs engineering review.

Automation does not add capacity. It shows where capacity is lost, which is valuable and different.

What to build first

Build downtime capture with reasons first, made trivial for operators to record and aggregated automatically. Downtime is the largest recoverable loss in most plants. The reasons make it actionable, but plants write them on paper or reconstruct them at shift end, so nobody trusts the number.

Two habits make the difference. Keep the bridge one-directional (data out, never control in), because that rule keeps this an integration project rather than a safety-engineering one. And make recording a reason take one button press, because every additional step degrades the quality of the only data that makes downtime actionable.

Frequently asked questions

Where are the accessible returns in manufacturing automation?

The accessible returns are at the boundary between the floor and business systems, not on the line, which is already automated. Production data currently reaches the office through spreadsheets, printouts and numbers typed at shift end. Automating that handover is where manufacturers recover time and data quality.

Should automation write instructions to production equipment?

No, not as an integration project. Reading production data is low risk. Writing control instructions has safety implications and needs the engineering and safety approval process, not an integration conversation. Never bypass a safety system for any efficiency gain.

What makes getting data off the floor difficult?

Machines differ enormously in what they expose: some offer modern interfaces, some only serial output, some nothing. Clocks drift, so events cannot be correlated, and units and tags are inconsistent between vendors. Normalising them is most of the integration work.

What should the office actually see?

The office needs actual output against plan, downtime with categorised reasons, scrap and rework by product and line, material consumption against expected, and order status a salesperson can rely on. Three numbers people act on beat forty nobody reads.

Is predictive maintenance worth it?

Sometimes, but it is oversold. Predictive maintenance requires failure history that most plants do not have for any single failure mode. Condition monitoring (vibration, temperature and current) is a more reliable starting point, and making scheduled maintenance actually happen is the bigger gap in many plants.

Why are downtime reasons such poor data?

Operators know why the line stopped and the system does not, and recording the reason is usually a form filled in at shift end. Making it one button press improves the only data that makes downtime actionable, because the reason is captured while the memory is fresh.

Should operators be individually monitored?

No. Automation that measures operators rather than machines is resisted, and the data degrades in response. Several jurisdictions also require union or works council consultation before introduction. Measure machines and show the team its own output instead.

Can automation increase plant capacity?

No. Automation does not add capacity. It shows where capacity is being lost (downtime, scrap and changeovers), so the plant can recover that capacity. That is valuable, but it is a different claim from adding capacity.

Why measure changeover time separately?

Changeover time is planned, accepted and usually larger in total than unplanned downtime. Plants do not count it as a loss, so nobody looks at it. Measuring from last good part to next good part reveals a longer time than anybody quotes.

What is the largest changeover improvement available?

The largest improvement is separating work that can be done while the line runs from work that needs the line stopped. In most plants a meaningful share of changeover time is preparation that did not have to happen during the stop. Staging materials and tooling beforehand removes it.

Related reading

• Workflow automation for supply chain
• Workflow automation for operations teams
• Automating API health checks