You already have the data. That is the problem.
Manufacturers rarely need more instrumentation. A plant with a historian, a manufacturing execution system, an enterprise resource planning system and a quality system is already recording more than anyone reads. What it does not have is agreement. The historian says the press ran for six hours and eleven minutes. The MES says the job took five hours and forty. The ERP says nine hundred good parts and the quality system says eight hundred and sixty-one. All four are honest and all four are measuring slightly different things at slightly different boundaries. The work is not collection. It is reconciliation, and it is unglamorous enough that it gets skipped in favour of a model that then trains on numbers nobody can defend.
Before anything else, write down what each system is actually authoritative for. Most disagreements dissolve the moment somebody does.
The controllers and the historian. Authoritative for machine state and process values in time: was it running, what was the temperature, what did the torque curve look like. Not authoritative for what was being made or whether it was any good.
The MES or production reporting system. Authoritative for the association between a time window and a job, an operator, a tool and a lot. This is the system that turns a tag history into something a person can reason about, and it is usually the weakest one in the building.
The ERP. Authoritative for the commercial facts: the order, the item master, the routing, the standard cost, what shipped. Its production numbers are backflushed from standards more often than anyone admits, which is why they are smooth and slightly wrong.
The quality or laboratory system. Authoritative for dispositions and test results. Frequently keyed to a lot number that does not appear anywhere in the historian.
The maintenance system. Authoritative for what was repaired and when. Its asset identifiers are almost never the same identifiers used by the controls team, and reconciling those two lists is a week of somebody's life that nobody budgets.
You are probably here because
- Two departments bring different numbers for the same line to the same meeting, every month
- The OEE figure on the board is 82% and nobody in operations believes it
- A vendor quoted a plant-wide platform and the payback case is entirely in the last slide
- You know which machine is the problem and cannot prove it with anything you could show a customer
The joins section explains the first. The downtime section explains the second. The cost section is what to hold the third against.
The seams are where the money is
Five joins carry almost all of the difficulty in manufacturing data, and they fail in the same ways in almost every plant. None of them is a modeling problem. All of them are decided by somebody sitting with two extracts and a domain expert.
| The join | What it is supposed to connect | How it actually breaks |
|---|---|---|
| Time | A tag history to a shift, a job, a day | Local time with daylight saving in one system and UTC in another; a shift that starts at 06:00 but is credited to the previous day; a controller clock that drifted four minutes in a year |
| Product | Part number to item number to drawing to customer part | Revisions embedded in some identifiers and not others; a dash that is a hyphen in one system and an en dash in the export; an item renamed for a customer three years ago |
| Order | Work order to job to lot to batch | Splits and merges. A job split across two shifts becomes two records in one system and one in another, and the join silently doubles the output |
| Asset | Controller tag to equipment to the maintenance asset register | Tag names that encode a panel location rather than a machine; a machine moved between cells; two asset records for one press after a rebuild |
| Unit | Counts, weights, lengths, cases, pallets | Yield and scrap reported in different units than production; a conversion factor that lives in one person’s spreadsheet |
The practical test of whether a data project is real: ask to see one shift reconciled end to end. One line, one shift, every number traced from the raw tag to the figure on the report, with the discrepancies named and explained rather than smoothed. If that cannot be produced, no dashboard built on top of it will survive its first serious question.
Downtime is a coding problem, not a sensor problem
Overall equipment effectiveness is availability multiplied by performance multiplied by quality, and each of the three has a well-known way of being wrong.
Availability depends on what counts as planned. Move a changeover from unplanned downtime to planned and the number rises without a single improvement on the floor. Every plant has a definition; few have it written down; almost none have it written down the same way as the sister plant they are being compared against.
Performance depends on the ideal cycle time, which is very often a figure typed into a routing when the machine was new and never revisited. If the standard is optimistic the line looks bad forever; if it is stale and slow the line reports over a hundred percent and people quietly stop reading the report.
Quality depends on whether rework is counted as good. Two plants using opposite conventions cannot be compared, and they usually are.
Then there is the reason code. An operator standing at a stopped machine with a screen offering thirty reasons will pick one of the first three, or the one nearest their thumb, and the resulting histogram is a map of the user interface rather than of the plant. This is the cheapest and least technical fix available to most manufacturers, and one of the most useful: cut the list to the eight reasons that would actually change a decision, put them on large buttons, and let the system infer the rest from context it already has. Short lists get used. Long lists get gamed.
Micro-stops deserve their own sentence. Most systems only log a stoppage past a threshold, often three or five minutes. On a fast line the stops under the threshold can be the largest single loss in the building and they are invisible by construction. If the historian holds the machine-state tag at a fine enough resolution, that loss can be recovered from data you already pay to store.
Where plant data work pays, as we rank it at scoping
Editorial weighting from our own scoping practice, shown to explain the order we recommend. Not a measured statistic.
What plant data engineering actually is
Stripped of vocabulary, the job has four parts and they are done in this order.
Get the values out, reliably, without touching the control system. Usually a read-only collector on the plant side, speaking to the historian or to an OPC server, buffering locally so a network outage does not create a hole, and pushing to somewhere on the business side. Buffering is the requirement people skip; a plant network that drops for ninety seconds twice a week will otherwise leave gaps that quietly ruin every downtime calculation.
Give the tags meaning. A tag called L3_PRS2_MTR_RUN is not information until something records that it is the run signal of press two on line three, that it went into service in 2018, and that it was moved to line four last spring. This equipment model is the asset that makes everything afterwards cheap, and it is the thing a plant most often has only in one maintenance planner's head.
Land it somewhere that can be joined and audited. A modest warehouse holding raw history, the joined production record and the definitions is enough for nearly every mid-size manufacturer. The requirement is not scale; it is that every number on a report can be traced back to its source rows in one query.
Publish definitions once. One definition of a shift, of good production, of downtime, of a changeover, of scrap. Written down, versioned, with a name attached. This is the part that makes two departments stop bringing different numbers, and it is not a technology deliverable at all.
Historian compression is lossy on purpose, and it will surprise your analysis
Process historians store a value only when it changes by more than a configured deadband, then reconstruct the rest on read. That is a sound engineering choice for trending and a trap for analytics: a slow drift inside the deadband is not recorded, and a naive average over interpolated points is not the average of the process. Ask what the compression settings are on the tags you plan to model before you conclude anything from them, and check whether the resolution you need still exists a year back.
The network conversation decides the schedule
The part of a manufacturing data project that slips is almost never the analytics. It is getting permission for a connection. Plant networks are deliberately segregated from business networks, the segregation is a genuine safety and security control rather than an obstruction, and the person who owns it is a controls engineer whose job is that nothing stops.
Expect and plan for four conversations. Which zone the collector may live in and what may cross the boundary, in which direction. Whether the equipment vendor's support agreement permits any additional connection at all, because some do not and the answer changes the design. Who owns the credential and how it will be rotated. And what happens to the collector during a plant shutdown, when everything is powered down and the person who knows the password is on holiday.
Two practical notes. Read-only is not a slogan; it should be enforced by the account and the protocol, and it is what makes the controls engineer willing to say yes. And a plant with equipment older than about fifteen years will have at least one machine reachable only through a serial converter or a vendor box with a web page from 2009, which is a solvable problem that no one includes in an estimate.
What it costs and how long
Prices vary with how many lines and how bad the identifiers are, but the shape is consistent.
| Scope | What you get | Typical range | Calendar |
|---|---|---|---|
| Assessment | One line, one shift reconciled end to end, a written data map, named blockers and owners, a build price | $18K–$45K | 2–4 weeks |
| Foundation, one plant | Collector, equipment model, warehouse, definitions, downtime and scrap reporting operations will defend | $120K–$300K | 10–20 weeks |
| One decision model | A scored model on a specific decision, with the screen where a person acts on it | $70K–$180K | 8–16 weeks |
| Second and later plants | The same foundation where equipment and identifiers are similar | 40–60% of the first | 6–12 weeks |
Running cost afterwards is generally fifteen to twenty-five percent of the build a year, and the largest line in it is not compute. It is the person who keeps the equipment model current as machines move, get rebuilt and get renamed. A plant that does not fund that role gets an accurate system that decays into an inaccurate one over about eighteen months, which is worse than not having built it, because people have started trusting it.
Send one shift and we will tell you what reconciles.
A tag export for one line for one shift, the production record for the same window, and the scrap figures. Email contact@precisionfederal.com. You get back a written note naming where the three disagree, which join is causing it, and what we would fix first. One business day, no charge.
contact@precisionfederal.comThree questions before any model gets built
Machine learning has real uses on a plant floor and a much smaller set of them than the market suggests. Three questions settle nearly every case.
How often does the event happen? A bearing failure that occurs twice a year gives you two examples. No method recovers from that. Condition monitoring on rotating equipment works because the degradation signal is continuous, not because failures are frequent, and the honest version of that project is a threshold on a well-chosen measurement long before it is a learned model.
What does being wrong cost, in each direction? A false alarm that pulls a machine down for an inspection has a price and so does a missed failure. If a maintenance planner cannot tell you both numbers, the model has no decision threshold and it will be tuned by whoever complains loudest.
Who acts on it at three in the morning, and what do they do? An alert with no named recipient and no defined action is a notification that will be muted within a month. Design the response before the detector.
How manufacturing data projects fail
- A dashboard built before one shift reconciled, so the first hard question ends its credibility
- Definitions that differ by plant, turning a comparison into an argument about accounting
- A collector with no local buffer, quietly dropping data during every network blip
- Thirty downtime reason codes, producing a histogram nobody can act on
- The equipment model kept in one planner’s head, and the planner retires
- Predictive maintenance on assets that have failed twice, with no examples to learn from
- An alert with no named owner, muted within a month and cited for years as proof this does not work
- Ideal cycle times from the machine’s installation year, making every performance figure fiction
A first sixteen weeks
One plant, one line first
Step six is where the value is decided. A supervisor who looks at a downtime chart and says "that Tuesday is wrong, we were waiting on material" is giving you the most useful defect report in the project. Systems that operations does not believe get worked around, and a plant that works around a system will keep its real numbers on a whiteboard where nobody can aggregate them.
Before you sign anything
- One line and one shift reconciled end to end, with discrepancies explained
- Written definitions of shift, good, scrap, downtime and changeover, signed by operations and finance
- A named controls owner who has agreed the connection in principle
- Vendor support terms checked for every machine you intend to read from
- Historian compression settings and retention confirmed for the tags you need
- A local buffer in the collector design, with a stated outage tolerance
- An owner and a budget for keeping the equipment model current
- For any alert: a named recipient and a written action
Bottom line
The value in manufacturing data is mostly recovered by making systems you already own agree with each other, and most of that work is definitional rather than technical. Reconcile one shift before building anything. Fix the downtime reason codes before buying a model. Expect the schedule risk to sit in the network conversation and the vendor support terms rather than in the analytics. And fund the person who keeps the equipment model honest, because without that role an accurate system becomes an inaccurate one slowly enough that nobody notices until a decision has been made on it.
Frequently asked questions
No. A mid-size manufacturer with a few dozen machines produces a volume that a modest warehouse handles comfortably. The requirement is traceability, not scale: every number on a report should be traceable to its source rows in one query. Start with one line, prove the reconciliation, and let the architecture follow the volume rather than the sales deck.
Usually one of three causes. Changeovers classified as planned downtime, which raises availability without changing anything real. An ideal cycle time from the machine's installation year, which flatters performance. Or rework counted as good production. All three are definitional, all three are fixable in a week, and none of them requires new software.
On a short list of critical rotating assets with continuous condition signals, often yes. Across a whole plant, usually not yet. The deciding questions are how many examples of the failure exist, what a false alarm and a miss each cost, and whether a named person will act on the alert at three in the morning. If the failure has happened twice, no method will learn it and a well-chosen threshold is the honest answer.
Not if the connection is read-only, enforced by the account and the protocol rather than by intention, lives in the boundary zone your controls team defines, and carries a credential somebody owns and rotates. That design is normal industrial practice and it is what makes a controls engineer willing to approve it. The risky version is the ad-hoc laptop somebody already plugged in to pull data for a report.
The reconciliation and downtime work usually shows a defensible number within one quarter of going live, because it changes what a scheduling or maintenance decision is based on rather than requiring new capital. Model-based work takes longer and should be judged against a measured baseline that existed before the project, which is one more reason to do the foundation first.