A 40-ton press goes down on second shift. The maintenance lead pulls the work order history and finds three near-identical failures over the past eighteen months, each one logged in a slightly different way by a different tech, none of them connected to the others until now. The bearing had been telling you it was failing for months. Nobody was listening, because the signal was scattered across a paper binder, a spreadsheet, and someone’s memory.
This is the actual state of maintenance at most mid-market manufacturers. Not a lack of data. A lack of data that anyone can use. And into that gap walks a vendor with a slide deck promising AI-driven predictive maintenance across your entire plant floor, full sensor retrofit, a digital twin, the works. The number at the bottom of the deck has a lot of zeros, and the timeline runs eighteen to twenty-four months before you see anything.
You should be skeptical. Not because predictive maintenance doesn’t work, it does, but because the version being sold to you is built for a plant ten times your size with a staffed data science team and a capital budget to match. The big-bang rollout is where mid-market predictive maintenance programs go to die. They stall in procurement, drown in integration work, and get quietly defunded when the first quarter passes with nothing to show.
There’s a better way to do this, and it starts with the data you already have.
Start with the data you’re already sitting on
Before you spend a dollar on sensors, inventory what you already collect. Most manufacturers are surprised by how much is there once they go looking.
- Downtime and work order logs. Your CMMS or even a shared spreadsheet has years of failure history. What broke, when, how long it took to fix, what part went in.
- SCADA and historian data. If you run any process automation, you’re already logging temperatures, pressures, flow rates, motor currents, and cycle counts. That historian is a goldmine that mostly gets used for real-time dashboards and then forgotten.
- Quality and scrap records. Rising defect rates often precede mechanical failure. That correlation is sitting in your QA data.
- Operator notes and shift logs. Unstructured, messy, and genuinely useful. “Machine 7 sounds rough” is a leading indicator, even if nobody treated it as one.
The point of starting here is not that this data is clean. It almost certainly isn’t. The point is that it’s free, it already exists, and it covers a long time window that no new sensor can give you. A sensor you install today starts collecting history today. Your work orders go back years. For failure modes that happen a few times a year, that history is worth more than a brand-new high-frequency data stream.
What “good enough” data looks like
You do not need perfect data to start. You need data that is good enough to find a pattern in one asset class. If your downtime logs reliably capture which machine failed and roughly when, you can already calculate mean time between failures, spot which assets are your worst actors, and identify whether failures cluster around shifts, products, or seasons. That analysis alone often pays for the whole exercise, and it requires zero new hardware.
Pick one critical asset class and prove it
The single biggest mistake I see is scope. Teams try to instrument the whole plant at once because it feels more thorough. It isn’t. It’s slower, more expensive, and far more likely to fail.
Pick one asset class. Not one machine, one class, a population of similar assets you have several of: your CNC spindles, your injection molding machines, your conveyor gearboxes, your air compressors. You want enough units that patterns are statistically meaningful, but a narrow enough type that the failure physics are consistent.
Choose the class using a simple filter:
- High downtime cost. When it stops, the line stops, or a customer order slips.
- Frequent enough to learn from. Something that fails once a decade gives you nothing to model. You want a failure mode that recurs.
- Data already exists. Bias hard toward assets your historian already watches. That cuts your time-to-value dramatically.
A compressor that fails three times a year, costs you a full shift each time, and already reports discharge temperature and motor current to your historian is a far better starting point than the exotic five-axis machine everyone’s worried about but nobody has data on.
Prove value before you scale anything
Your first milestone is not a deployed model. It’s an answer to a question: can we see this failure coming in the data we have? Pull the history for your chosen asset class, line up the sensor traces and work orders against known past failures, and look for the signature. Did motor current creep up before each bearing failure? Did cycle time drift before the breakdown?
If the signal is there, you’ve proven the concept on real history before building anything operational. If it isn’t there in your existing data, that’s the moment to ask whether a sensor would reveal it, and that’s a much smarter time to spend on hardware than at the start.
Close the data gaps deliberately, not reflexively
Every honest assessment turns up gaps. Failures logged with no timestamp. A historian that samples once a minute when the failure develops over seconds. Three different spellings of the same fault code. Here’s how to think about closing them.
Fix the cheap gaps first
A lot of what looks like a data problem is a process problem. Standardizing failure codes, requiring a cause field on every work order, training techs to log consistently, none of this costs capital, and all of it compounds. Six months of clean logging is worth more than any algorithm you can buy. Start the clean-data habit now, even while you’re still analyzing the messy historical stuff.
Know when a sensor is actually worth it
Sensors are justified, but only under specific conditions. Add instrumentation when:
- You’ve confirmed a failure mode matters but it’s invisible in current data, the historian samples too slowly, or the relevant signal (vibration, ultrasonic, oil particulates) simply isn’t being measured.
- The asset is critical enough that the avoided downtime clearly exceeds the cost of the sensor, the wiring, and the integration work, which is usually the larger cost.
- You have a specific question the sensor answers. “More data” is not a reason. “We believe vibration at this frequency precedes the gearbox failure and we can’t see it today” is.
Vibration monitoring on a critical rotating asset can pay for itself in a single avoided failure. A temperature sensor on a machine that already fails gracefully and cheaply is a gadget. The discipline is matching the sensor to a failure mode you’ve already decided is worth catching, not blanketing the floor and hoping.
Resist the urge to boil the ocean
The instinct to instrument everything comes from a good place, you want to be thorough. But a plant-wide sensor rollout creates an integration and data-management burden that mid-market teams cannot absorb, and most of those sensors will watch assets that rarely fail or fail cheaply. You end up paying to collect data you’ll never act on. Stay narrow until narrow stops working.
Build the boring infrastructure that makes it last
The unglamorous part determines whether this survives past the pilot. You need somewhere to land the data, a pipeline to keep it flowing, and a way to put results in front of the people who turn the wrenches.
- A solid data foundation for it to live in. Pulling historian and CMMS data into one queryable store is most of the real work. It’s plumbing, and it’s where the time goes.
- Alerts that reach a human who can act. A model that flags a developing fault is useless if the warning dies in a dashboard nobody opens. The output has to land in the maintenance planner’s existing workflow.
- A feedback loop. When the system flags something, the tech who inspects it needs to record what they actually found. That feedback is what makes the next prediction better. Without it, the model never improves and trust erodes the first time it’s wrong.
None of this requires a data science team on staff. It requires solid data engineering and someone who understands the maintenance workflow well enough to fit the tooling into it rather than around it. That combination is what we focus on at Ryshe Forge, and it’s deliberately the unsexy half of the work, because it’s the half that decides whether you still have a working program a year from now.
Expand only after the first win is real
Once your one asset class is delivering, real catches, real avoided downtime, trust from the maintenance crew, expansion becomes straightforward. You repeat the pattern: pick the next class, reuse the infrastructure you built, apply the lessons you learned. Each cycle is faster because the plumbing already exists and the team already believes.
This is the opposite of the big-bang approach, and it’s why it works. You’re never betting the program on a single massive rollout. You’re compounding small, proven wins, each one self-funding the next. By the time you’ve covered three or four asset classes, you have a genuine predictive maintenance capability, built incrementally, paid for as it went, and owned by your own people.
The takeaway
Predictive maintenance for a mid-market manufacturer is not an AI problem. It’s a sequencing problem. The technology is mature and largely commoditized. What separates the programs that deliver from the ones that stall is discipline: start with the data you have, prove value on one critical asset class, add sensors only where a real failure mode demands them, and expand only after the first win is undeniable.
The vendors selling you the plant-wide moonshot are not wrong that predictive maintenance works. They’re wrong about how a company your size should get there. Staged beats heroic, every time.
If you want a second set of eyes on what’s hiding in your downtime logs and historian before you commit to anything, that’s a good first conversation to have, and a 30-minute call is usually enough to tell whether you’re sitting on a quick win or a longer build. Either way, you’ll know more than the slide deck told you.
