Industry / Manufacturing
Data engineering for manufacturing connects ERP records, machine events and quality observations, each on a different clock, into metrics that plant and planning teams can actually compare. Quorlytic defines what counts as downtime, scrap and good output, reconciles those definitions with the process owner, and keeps automation separate from safety-critical control decisions.
By QuorlyticUpdated
A plant and the enterprise that owns it run on different systems, different identifiers and different clocks. ERP knows what was ordered, MES knows what was made, the historian knows what the machine did, and the maintenance system knows what broke — usually without agreeing on which asset any of it refers to. This page sets out the operating lifecycle those systems describe, and what has to be true before analytics or AI can be trusted on top of them.
Lifecycle
Nine stages from a demand signal to what the field reports back. Information is supposed to travel both ways; in most estates it travels forward and stops.
Forecast and plan
Turn demand into a production plan. The plan is built in the enterprise system's units and calendar, which are rarely the units and calendar the plant schedules in.
Source and procure
Secure materials against the plan. Supplier lead time variability, not average lead time, is what determines whether the plan survives contact with the month.
Schedule production
Sequence the plan onto lines and shifts, including changeovers. Schedules change during the day; if only the original version is recorded, every downstream analysis compares against a plan that never ran.
Execute production
Make it, and record what actually happened. Counts, states and reasons are entered by people under time pressure and captured by machines that do not know why they stopped.
Inspect quality
Check the output against specification, in line and in the lab. Results arrive on a different clock from production — often after the material has moved on.
Maintain assets
Keep equipment available. The record of what failed, why, and what was done about it is the input any maintenance analysis depends on, and it is usually the weakest record in the estate.
Hold and move inventory
Store raw material, work in progress and finished goods. Inventory accuracy at the plant is what determines whether the schedule is executable.
Distribute
Get finished goods to the customer or the next plant. Shipment and delivery events close the loop between the plan and the promise made to the customer.
Learn from the field
Warranty claims, returns and service history say what the plant's measures could not. This is the stage most estates never connect back, which is why quality signals stay internal to the plant.
Where it breaks
These appear in industrial data estates repeatedly. Most of them are identity or context problems wearing a reporting problem's clothes.
A machine is a tag in the historian, an equipment number in the maintenance system, a work centre in ERP and a line name on the whiteboard, with no maintained mapping between them.
What it costsDowntime cannot be attributed to an asset, maintenance cost cannot be compared to output, and every cross-system analysis starts with a spreadsheet somebody rebuilds each month.
A temperature series is available at one-second resolution with no record of which product was running, which recipe was loaded, or which shift was on.
What it costsAnomalies cannot be separated from ordinary product changeovers, so alerting either floods or is switched off — usually both, in that order.
The failure mode, the cause and the intervention live in a technician's notes rather than in coded fields, and the codes that do exist are used inconsistently between sites.
What it costsThere is no label to train or validate a maintenance model against, and reliability reporting measures how often work orders were raised rather than what actually failed. This is a data quality problem rather than a monitoring one, and the two need different remedies.
Planned downtime, scrap, rework and good output are defined locally, often by the person who built the original report.
What it costsCross-plant comparison ranks definitions rather than performance, and a corporate target drives local behaviour that improves the number without improving the operation. A definition only holds when breaching it stops a deployment.
Sequence changes made during a shift are applied in the execution system without being written back, so the plan of record is the morning's version.
What it costsSchedule adherence is measured against a plan nobody followed, and the reasons for change — the genuinely useful signal — are lost.
Plant networks drop, edge buffers fill, and events arrive late, out of order or not at all.
What it costsAggregations computed on arrival time under-report production for the affected window, and the correction, if it happens, arrives after the meeting it mattered for. Detection, containment and safe replay is what turns this from an incident into a handled case.
Functions
Manufacturing organisations divide by function, and the data each function trusts comes from a different system. The foundation's job is to make them reconcilable without asking any of them to abandon the system they run on.
| Function | The question it owns | Data it needs | Analytics | Decision |
|---|---|---|---|---|
| Planning | Is this plan executable with the capacity and materials we will actually have? | Demand forecast, order book, capacity and calendar, material availability, changeover cost | Demand forecasting, capacity and constraint modelling, plan-versus-actual reconciliation | Production volume and period, and where the plan has to be cut |
| Procurement | Which supplier variability is putting the plan at risk? | Purchase orders and confirmations, lead-time history, goods receipts, incoming quality results | Lead-time variability analysis, supplier performance comparison, risk exposure by material | Order timing, buffer levels and supplier allocation |
| Production | Where is output actually being lost, and to what? | Work-order confirmations, machine states and counts, downtime events with reason codes, shift and product context | Loss analysis by reason and asset, throughput and cycle-time comparison, schedule adherence | Line sequencing, staffing, and which loss to attack first |
| Quality | What is driving this defect, and which batches are affected? | Inspection and lab results, non-conformances, process parameters at time of manufacture, batch genealogy | Defect pattern analysis, parameter correlation, traceability across batch and lot | Release, hold or recall, and which process parameter to change |
| Maintenance | Which assets should be serviced next, and is the evidence good enough to say so? | Work orders with failure and repair codes, condition readings, parts consumption, asset hierarchy | Failure-mode analysis, condition trending, maintenance-cost-to-output comparison | Service scheduling, spare holdings, and whether prediction is supportable yet |
| Logistics and service | Did what we shipped meet the promise, and what came back? | Shipments and delivery events, transport cost, warranty and field failures, returns with traceability | Service-level analysis, cost-to-serve, field-failure linkage to production batch | Dispatch prioritisation, and what to change upstream in specification or process |
Decisions
Four industrial decisions traced end to end. Each one names the data prerequisite that usually blocks it, because in manufacturing the prerequisite is almost always the real project.
Data required
Analytics
Decision
The committed production plan, and the specific lines or periods where it has to be reduced or resequenced.
Measurement
What this does not settleThis depends on one agreed definition of available capacity. Where planning uses nominal capacity and the plant measures against demonstrated output, the plan will be infeasible in a way no model will surface — the mismatch is in the definition, not in the arithmetic.
Data required
Analytics
Decision
The maintenance schedule for the coming window, and which spares to hold.
Measurement
What this does not settleSensor data describes operating conditions; it is not a failure record. If failures are captured in free text, if the asset mapping is unmaintained, or if the maintenance window is shorter than the warning a model could give, the correct first deliverable is a reliable asset and failure history — not a prediction that cannot be validated or acted on.
Data required
Analytics
Decision
Release, hold or recall the affected batches, and which process parameter or supplier to change.
Measurement
What this does not settleCorrelation between a process parameter and a defect is a starting point for an investigation, not a cause. Changeovers, material lot changes and shift patterns move together often enough to produce convincing relationships that do not survive a controlled trial.
Data required
Analytics
Decision
Order quantity, timing and holding location per material.
Measurement
What this does not settleSafety stock calculated from an average lead time understates the buffer needed for the suppliers that actually cause stoppages. The distribution matters more than the mean, and a supplier whose variability is unmeasured cannot be planned around.
Illustrative interface
A fictional screen showing the shape of a production loss review. No real plant, asset, product or figure is represented, and every value here is invented.
| Asset and shift | Loss recorded as | Record quality | Next step |
|---|---|---|---|
| OK: Line 2 · night shift | Planned changeover | Reason code present, matches schedule | No action |
| Watch: Line 4 · day shift | Unplanned stop | Reason code blank on a third of events | Fix capture before attributing |
| Risk: Press cell · all shifts | Short stops below threshold | Not recorded individually at source | Loss is real and currently invisible |
| Watch: Line 1 · weekend | Output below plan | Confirmations entered at shift end, not at event time | Reconcile against machine counts |
Data foundation
Industrial data crosses a boundary that retail data does not: the one between control systems and enterprise systems. ISA-95 exists precisely to describe that interface, and most integration pain is the absence of an agreed model across it.
Source systems
Plant and enterprise, on opposite sides of the ISA-95 boundary. The ten systems are enumerated in the table below.
Industrial ingestion
Event time preserved separately from arrival time
Cloud platform
One place plant and enterprise history meet
Identity & context
The prerequisite for every cross-system question
Quality & contracts
Definitions that survive a plant boundary
Operational models
Comparable across sites
Decision surfaces
Where planners and engineers work
Action
Never the control system
Real time is a decision property, not a virtue. A line-stop alert needs seconds; a yield comparison needs the shift to be complete and reconciled, and computing it continuously produces a number that changes under the reader. Where machine data is exposed through a standard information model such as OPC UA, the semantics travel with the values, which is what makes cross-plant comparison possible without a bespoke mapping per site. The choice between change data capture, batch and streaming follows from the decision each feed serves. If a read-only operational alert needs low-latency feeds, real-time pipeline design must define event time, late readings and replay separately from the plant control system.
Orders, materials, cost, production confirmations, financial postings
Check before trustingConfirmations are often entered in batches at shift end, so timing does not match machine reality
Work orders, routings, execution records, batch genealogy
Check before trustingThe authoritative account of what was made; frequently holds a different product identifier from ERP
Machine states, counts, process values at high frequency
Check before trustingValues without product, recipe or shift context; compression and interpolation settings change what is stored
Raw signals and events from equipment
Check before trustingBuffered during connectivity loss, so arrival order is not event order; event time must be preserved separately
Inspections, non-conformances, lab results, dispositions
Check before trustingLab results arrive after the material has moved; joining on receipt time misattributes them
Work orders, failure and repair codes, parts, asset hierarchy
Check before trustingFailure detail is often in free-text notes; the asset hierarchy drifts from what the plant actually runs
Warehouse positions, movements, bins, batch and quarantine status
Check before trustingPlant-floor material moves are sometimes recorded only in MES, so positions disagree by design
Demand plans, supply plans, capacity assumptions
Check before trustingThe plan of record is usually the published version, not the one that ran after mid-period changes
Confirmations, advance shipping notices, certificates of analysis
Check before trustingFormat and timeliness vary by supplier; a missing confirmation is information, not an error to discard
Consumption by meter, sometimes by line or area
Check before trustingMeter boundaries rarely match asset boundaries, so per-unit energy figures need an explicit allocation rule
Analytics & AI
The same dependency chain as anywhere else, with one industrial difference: the prerequisites are usually physical records rather than modelling choices, and no amount of platform will substitute for them.
What ran, what stopped, what was made and what was rejected — available to the plant on the day rather than in next month's pack.
RequiresAsset and product identifiers mapped across systems, and event time preserved separately from arrival time
Downtime, scrap, rework and good output defined once and reconciled with the process owner, so two plants can be compared without arbitrating definitions first.
RequiresAgreed definitions with a named owner per measure, and the local exceptions documented rather than hidden
Attributing loss to an asset, a reason, a product or a shift, and separating genuine process variation from changeover and material-lot effects.
RequiresReason codes used consistently, and context — product, recipe, shift — carried alongside telemetry
Forecasting demand and consumption, and — where the records support it — modelling a specific failure mode rather than failure in general.
RequiresLabelled events with enough history, and a maintenance or planning window long enough for the prediction to be actionable
Turning analysis into a recommended schedule, buffer or maintenance sequence inside real constraints, with the planner able to override and the override recorded.
RequiresEncoded constraints, a named decision owner, and a recorded override path
Retrieval over governed engineering and maintenance documentation, and narrowly bounded actions such as raising an exception or drafting a work order.
RequiresEverything above, permission-aware retrieval, explicit action limits, and complete separation from safety-critical control
Maturity
Progress here is usually blocked by a record that does not exist rather than by a capability that has not been bought. The readiness test for each stage is deliberately concrete.
Each plant can see its own output and downtime, in its own definitions, mostly after the fact.
Ready for the next stage whenAsset and product identifiers are mapped across ERP, MES and the historian, and the mapping has an owner.
Downtime, scrap and good output mean the same thing at every site, and differences are explained rather than disputed.
Ready for the next stage whenDefinitions are owned, tested in the pipeline, and local exceptions are documented instead of quietly applied.
Loss is attributed to asset, reason, product and shift, and changeover effects are separated from process variation.
Ready for the next stage whenReason codes are used consistently and telemetry carries product and shift context at the point of capture.
Planning, maintenance and quality decisions arrive with a recommendation and the evidence behind it.
Ready for the next stage whenConstraints are encoded, the decision has a named owner, and overrides are recorded and reviewed.
Retrieval and bounded automation support engineers and planners, with control systems untouched.
Ready for the next stage whenPermissions are enforced at retrieval, actions have explicit limits and a log, and safety-critical paths are formally out of scope.
Measurement
A measurement framework for the decisions above. Manufacturing metrics are unusually sensitive to definition, so each one is worth agreeing before it is compared.
| Measure | What it captures | Decision it informs |
|---|---|---|
| Overall equipment effectiveness | Availability, performance and quality combined into one figure for an asset or line | Where to focus improvement effort — but only after its three components are read separately |
| Unplanned downtime | Time lost to events that were not scheduled, attributed to an asset and a reason | Maintenance priority and spares holding |
| Schedule adherence | How closely production followed the plan of record | Whether the planning assumptions or the execution needs to change |
| First-pass yield | Proportion of output meeting specification without rework | Which process step or parameter to investigate |
| Scrap and rework rate | Material lost or reprocessed, by cause and by line | Process change, supplier change or specification review |
| Throughput | Units produced per available hour against demonstrated capability | Line sequencing and capacity commitment |
| Capacity utilisation | Use of available capacity, distinguished from nominal capacity | Investment, outsourcing and plan feasibility |
| Material availability | Whether the materials the schedule assumes are actually present and released | Buffer levels and supplier allocation |
| Planned-to-reactive work ratio | How much maintenance is scheduled rather than responding to failure | Maintenance strategy and staffing |
| Field failures traced to production | Warranty and service failures linked back to a batch, line or material lot | Specification, process and supplier decisions upstream |
These are common industrial measures and their usual reading, not results Quorlytic has produced for a client. Definitions — particularly of planned downtime, available capacity and good output — vary between organisations and often between plants in the same organisation.
Principles
ERP records, machine events and quality observations have different identifiers and timing. Model product, asset, batch and shift relationships before aggregating performance. Preserve time-zone and event-time context to avoid incorrect downtime or throughput calculations.
Define what counts as planned downtime, scrap, rework and good output. Reconcile source totals with the team responsible for the process. A standardized chart is useful only when its definitions match plant operations.
An analytics project can begin with read-only data and operator decision support. Direct machine control, safety-critical decisions and autonomous maintenance actions require separate engineering, validation and operational authorization.
Account for interrupted connectivity, delayed events, source retention and plant-specific mappings. Agree who resolves missing data and who approves model changes. Start with a representative production line before extending to a multi-plant model.
Capacity planning connects demand, materials, changeover and shift patterns, and it fails when planning definitions do not match how the plant measures output. Agree one definition of available capacity and changeover cost with the process owner, then reconcile the plan against what production actually recorded.
Sensor data describes operating conditions; maintenance analytics needs labelled failures, work orders and the intervention that followed. Before modelling, check whether failures are recorded consistently, whether the asset history is complete, and whether a planner can act on the output within the maintenance window. Without those, reliable asset data is the better first deliverable.
Engagement
A typical engagement can progress through these stages. It is a sequence rather than a proprietary method, and in manufacturing the early stages routinely take longer than expected because the identifiers have to be reconciled before anything can be compared.
Discover
OutputAn inventory of the decisions in scope, the plants they cover, and who owns each one
Map identity
OutputA maintained mapping of asset, product, batch and work-order identifiers across ERP, MES, historian and maintenance systems
Audit the data
OutputA source and quality map: what each system carries, how late it arrives, and where definitions differ by site
Design the architecture
OutputA target-state design with the ingestion pattern chosen per source and event-time handling made explicit
Build the foundation
OutputPipelines, contextualised telemetry, quality gates and the models the first decision needs
Build the decision layer
OutputThe planning, quality or maintenance analysis the decision requires, validated against how the plant measures
Operationalise
OutputMonitoring, named ownership, recovery runbooks for connectivity loss, and an exception path
Measure and improve
OutputA decision-level measurement framework and the next plant or decision prioritised against it
Where this connects
The identifier mapping, contextualised telemetry and quality gates every decision above depends on
Ownership, monitoring and recovery for pipelines that lose connectivity as a matter of routine
Failure-mode, yield and capacity analysis, scoped to what the records can actually support
Forecasting at the planning grain, reconciled with what the plant demonstrably produces
Moving plant and enterprise data onto one platform without losing event-time fidelity
One definition of downtime, scrap and good output, owned and tested rather than negotiated
How a metric definition becomes something a build fails on, which is what makes plants comparable
Choosing ingestion per source from freshness, load and replay — the streaming-versus-batch question in plant terms
Detection, containment and safe replay for feeds that arrive late or out of order
The difference between knowing a feed stopped and knowing the values in it are wrong
Choosing the forecast measure for demand and consumption planning
The readiness conditions behind the top two rungs of the analytics progression
Questions
First check asset history, failure labels, operating conditions and the decision process. If the evidence is insufficient, reliable asset and maintenance data is a better first deliverable than an unsupported prediction target.
Your next data decision
Bring the business question.
We'll help shape the engineering brief.
