Plant data is stranded
The information that would improve planning, quality and maintenance sits in equipment and control systems that were never designed to publish it anywhere.
Technology consulting for manufacturers
Manufacturing is the sector where a technology decision has physical consequences. A system that stops does not delay a report — it stops a line. That single fact reorders almost every priority engineering would otherwise apply.
Industry overview
A manufacturer's estate spans two worlds that were designed under different assumptions. Operational technology on the plant floor prioritises determinism and availability, runs on long lifecycles, and is frequently supported by equipment vendors on their own terms. Information technology prioritises change, integration and analysis.
Where they meet is where most of the difficulty sits. Plant systems hold the data that would make planning, quality and maintenance materially better, but connecting them introduces a path into an environment where availability outranks confidentiality and where a patch cannot simply be applied.
The second recurring theme is ERP that has grown by accretion — modifications made to fit a process, each reasonable, that now collectively block upgrades. Our work is usually about connecting the two worlds safely and making the business systems changeable again.
Business challenges
What manufacturers bring to us most often.
Connecting OT to IT introduces risk
Every path from the plant floor to the enterprise network is also a path in the other direction, into an environment where availability outranks everything and patching is constrained.
ERP customisation blocks upgrades
Modifications made to fit the business now prevent moving to a supported version, so the platform ages in place and the cost of moving grows each year.
Supply chain visibility ends at the supplier
Planning depends on information held by parties who have no obligation to share it in a usable form, so buffers absorb the uncertainty instead.
Equipment lifecycles outlast software support
Machinery is depreciated over decades while its control software reaches end of support in years, leaving a supported plant running unsupported code.
Quality and traceability are assembled after the fact
Where a batch must be traced through production, the record is compiled from several systems rather than produced as the batch is made.
Digital transformation challenges
Manufacturing transformation programmes fail most often by attempting plant-wide change simultaneously. A pilot on one line, one cell or one site produces evidence about whether the approach works in your environment rather than in the vendor's demonstration.
The second failure is treating plant staff as recipients of the change rather than participants in it. Operators work around systems that make their work slower, and on a production line that workaround is immediate, rational and invisible to anyone reading a dashboard.
- One line or cell proven before any plant-wide commitment is made
- Operators involved in design, because they will otherwise route around the result
- Availability of production treated as a constraint on the programme, not a risk to it
- Benefits measured at the line rather than inferred from a system going live
Regulatory considerations
Manufacturing's obligations vary sharply by product. Food, pharmaceutical, automotive and aerospace production each carry traceability and quality-record requirements that are functional requirements of the systems involved, not documentation exercises.
Where traceability is required, the record must be produced as the batch is made rather than assembled afterwards — a reconstructed record is usually the thing an audit finds. Safety-relevant control systems carry a further constraint: changes to them are validated in ways enterprise software is not.
We advise on technical design. We do not provide regulatory opinions and we do not represent NG&NR as holding certifications it has not been awarded.
- Traceability produced during production rather than reconstructed for an audit
- Change control on safety-relevant systems treated as a hard constraint
- Retention aligned to product liability horizons rather than to IT defaults
- Environmental and reporting data captured at source, not estimated later
Enterprise architecture approach
The defining architectural decision is the boundary between operational and information technology, and specifically what may cross it in each direction. A boundary that permits arbitrary traffic is not a boundary; one that permits nothing strands the data that motivated the work.
The usual answer is a deliberately narrow, well-understood interface: plant data published outward through a defined path, with inbound control restricted to specific, audited operations, and with the plant able to continue producing when the enterprise side is unavailable.
That last property is the one most often assumed rather than designed. An enterprise system that becomes a dependency of production has changed the availability requirement of the entire IT estate without anyone deciding to, and the first time that is discovered is usually during an unrelated outage.
- A narrow, explicitly specified interface between plant and enterprise
- Outbound data flow separated from inbound control, with different controls on each
- Production continues when the enterprise estate is unavailable, by design
- Equipment vendor constraints treated as fixed inputs rather than negotiable
Cloud strategy
Cloud in manufacturing is rarely a plant-floor conversation. Control systems stay local because determinism and independence from a network link are functional requirements, and no amount of connectivity improvement changes that.
Where cloud pays is above the plant: aggregating telemetry across sites, planning and analytics, quality analysis, and the enterprise systems that do not need to be adjacent to a machine. Edge processing at the site handles what must be local, and only what is needed centrally travels.
- Control and safety systems remain local; that is a requirement, not a phase
- Edge processing at each site, with only aggregated data travelling centrally
- Multi-site telemetry consolidated where cross-site comparison is the objective
- Connectivity failure treated as a normal condition rather than an incident
Data strategy
Plant data arrives at high frequency and low individual value. Storing every reading at full resolution indefinitely is expensive and rarely useful; deciding retention and aggregation by signal is where the real design work is.
The harder problem is joining plant telemetry to enterprise records. A machine knows a cycle happened; the ERP knows an order exists. Connecting the two requires a shared identifier that frequently does not exist and has to be introduced deliberately.
Context is the part most often missed. A reading is only interpretable alongside what was being produced, on which tool, under which recipe and by whom. Telemetry captured without that context supports monitoring but not the analysis it was collected for.
- Retention and aggregation decided per signal rather than uniformly
- A shared identifier introduced to join plant events to enterprise records
- Time synchronisation treated as foundational, because sequence carries meaning
- Quality tested at ingestion, since a sensor fault is indistinguishable downstream
Security considerations
Operational technology inverts the usual security priority: availability outranks confidentiality, because the consequence of stopping a line is immediate and physical. Controls designed for enterprise IT are frequently inapplicable — you cannot patch on a schedule set by anyone other than production.
The controls that work are architectural: segmentation that bounds what a compromise can reach, monitoring that does not interfere with control traffic, and compensating controls where patching genuinely cannot happen. Naming the systems that cannot be patched is more useful than a policy requiring that they be.
- Segmentation that bounds blast radius, because prevention alone will not hold
- Compensating controls named where a system genuinely cannot be patched
- Monitoring that observes without interfering with control traffic
- Remote vendor access scoped, time-bound and recorded rather than standing
Software engineering
Software that interacts with production carries a testing burden closer to embedded systems than to enterprise applications, because the environment cannot be freely exercised. You cannot load-test a physical line, and a defect has a physical consequence.
That argues for simulation, for extremely conservative failure behaviour, and for a strict separation between systems that observe production and systems that influence it — the two warrant very different levels of assurance.
- Simulation for what cannot be exercised on a physical line
- Observation and control separated, with different assurance levels for each
- Conservative failure behaviour: stop safely rather than continue uncertainly
- Offline operation supported, because plant connectivity is not guaranteed
Integration strategy
Manufacturing integration spans equipment protocols, plant systems, ERP and supplier exchange, and these have almost nothing in common technically. Attempting a single integration approach across all of them produces something that fits none well.
We generally treat the plant boundary as one integration problem with its own patterns, and the enterprise and supplier boundary as another. Supplier exchange in particular has to tolerate partners with widely differing capability, which is a design constraint rather than an inconvenience.
- Plant and enterprise integration treated as separate problems with separate patterns
- Equipment protocol translation isolated so a device change is contained
- Supplier exchange designed for partners with widely differing capability
- Store-and-forward at the site, because connectivity interruptions are normal
Recommended NG&NR services
The services usually engaged first in this sector, and why.
Enterprise Architecture
The OT/IT boundary and what crosses it in each direction — the decision every other plant integration inherits.
ERP & Business Applications
Assessing whether the ERP is genuinely the constraint, from a party that does not implement or resell any of them.
AI & Data Engineering
Joining plant telemetry to enterprise records, and deciding retention and aggregation per signal rather than uniformly.
Cybersecurity
Segmentation that bounds blast radius, and compensating controls where patching genuinely cannot happen.
Cloud Consulting
Multi-site telemetry consolidation and edge processing, while control systems correctly stay local.
Software Development
Systems that observe or influence production, built with the conservative failure behaviour that context requires.
Recommended technologies
Selected against the constraints above, not against a preference. We hold no vendor partnerships.
Databases
Time-series retention for plant telemetry and the relational records it must join to — usually the first cost surprise.
Python
Telemetry pipelines, quality analysis and the identifier reconciliation that joins plant events to orders.
Kubernetes
Workloads at the edge and centrally, where site-local processing must run independently of a network link.
.NET
Common across MES, quality and plant-adjacent applications in Microsoft-based manufacturing estates.
Java
Where larger manufacturing execution and supply chain platforms are built and extended.
Microsoft Azure
Frequently the incumbent enterprise platform, with hybrid connectivity to sites that must keep operating independently.
Delivery approach
How an engagement runs where a mistake stops a line.
Free first consultation
Your plant and enterprise estate, and whether the constraint is data access, the OT/IT boundary or the business systems above it.
Assessment against the running estate
What plant data exists, what crosses the boundary today, and what the ERP customisation is actually costing.
Constraint mapping
Equipment support positions, validation requirements, production availability and patching limits, recorded as hard inputs.
Target architecture and a pilot
Boundary design and one line or cell proven in your environment before any plant-wide commitment.
Rollout with your teams
Site by site, with operators involved in design and benefits measured at the line rather than inferred.
Handover
Runbooks, boundary documentation and decision records, so the estate is operable and extendable without us.
Frequently asked questions
Through a deliberately narrow interface where outbound data flow is separated from inbound control and each carries different controls. A boundary that permits arbitrary traffic is not a boundary, and one that permits nothing strands the data that motivated the work.
No. Determinism and independence from a network link are functional requirements of control systems, not preferences that better connectivity resolves. Cloud pays above the plant: multi-site telemetry, planning, analytics and enterprise systems.
First establish what each modification is actually earning, because a proportion usually encode a process that exists only because a previous system worked that way. Extension through supported interfaces replaces much of the rest. Replacement is the expensive answer and is not always the correct one — we resell no platform and take no commission either way.
It is a fact of the sector, and pretending otherwise produces a policy nobody follows. The workable position is to name those systems explicitly, bound what a compromise of them can reach through segmentation, and apply compensating controls with a named owner.
Through a shared identifier, which frequently does not exist and has to be introduced deliberately. A machine knows a cycle happened; the ERP knows an order exists. Without a common key, every join is an inference and the analysis inherits its error rate.
Decided per signal rather than uniformly. Storing every reading at full resolution indefinitely is expensive and rarely useful, while aggregating too early destroys the detail that diagnoses a fault. Both decisions belong to the engineers who will use the data.
One line or cell, always. A pilot produces evidence about whether the approach works in your environment rather than in a vendor demonstration, and the cost of learning that plant-wide is very high.
By treating it as a design signal rather than a compliance problem. On a production line, a workaround is immediate and rational — it happens because the system makes the work slower. Involving operators in design surfaces that before it is built rather than after.
By producing the record as the batch is made rather than assembling it afterwards. A reconstructed traceability record is usually exactly what an audit finds, and reconstruction becomes progressively harder as the systems involved change.
We treat them as fixed inputs. Supported configurations, interface limits and upgrade cycles set by an equipment vendor are not negotiable through architecture, and a design that assumes them away produces a plan the vendor will not support.
We do not name clients or publish case studies in any sector. The first consultation works through the reasoning on your own estate, which is a better test of judgement than a reference list.
Standardise the interface, not necessarily the systems. Requiring every site to run identical software is a long and disruptive programme, and the benefit most organisations actually want — comparable data and shared analysis across sites — comes from agreeing what each site publishes and in what form. That is achievable without replacing anything.
Next step
Discuss a manufacturing estate
A free first consultation covering your plant and enterprise systems, what data is currently stranded, and what could be proven on a single line before any plant-wide commitment.
No cost, no obligation. Pricing is transparent and includes GST.