Machine Learning for Manufacturing SMEs
Last updated:
The factory that already knows, but cannot see
Most small manufacturers have an experienced setter who can tell from the sound of a press that the next batch will be scrap. That knowledge is valuable, fragile and goes home at five. Machine learning in manufacturing SMEs is often an attempt to capture a small part of it from sensor and production data so the warning arrives even when that person is on holiday.
Take a 70-person injection moulding business running 20 machines on three shifts. Scrap runs at a few percent, which sounds small until you multiply by material, machine time and the rush order that has to be rerun. That is the kind of problem worth modelling, because the cost is known and the data can be collected.
Machine learning use cases for smaller manufacturers
- Scrap and yield prediction. Linking process parameters such as temperature, pressure, cycle time and material batch to quality outcomes, then warning before a run drifts.
- Visual inspection. Cameras and image models checking surface defects, labels or assembly completeness at line speed.
- Lead time and delivery prediction. Estimating when an order will really ship given current load, not the standard lead time in the ERP.
- Predictive maintenance. Worth it for a handful of critical, expensive-to-stop assets, rarely for the whole shop floor.
- Demand and material forecasting. For make-to-stock lines, so raw material buying follows likely orders.
- Quote estimation. Predicting machine time and cost for a new part from its drawing features and past jobs.
Visual inspection has moved fastest in the last two years. Smaller image models can now run on a modest industrial PC beside the line, which removes the latency and connectivity worries that used to kill these projects. We cover the practicalities in AI quality control and visual inspection.
The data problem nobody budgets for
Manufacturing ML projects rarely fail on algorithms. They fail because the quality outcome and the process data cannot be joined. The scrap is recorded per shift on a whiteboard, the machine parameters live on the PLC and are overwritten, and the material batch is on a paper traveller.
| Question | If yes | If no |
|---|---|---|
| Are machine parameters logged with timestamps? | Model directly | Add data capture first, 4-8 weeks |
| Is scrap recorded per batch or per part? | Can link cause to effect | Per-shift totals are too coarse |
| Are material batches traceable to jobs? | Material effects can be learned | An unexplained source of variation |
| Is there a record of past failures? | Maintenance model is feasible | Start logging now, model later |
An honest first phase is often data capture with no machine learning at all: connecting PLCs, adding a tablet at the line for defect logging, and storing it all in one database. It is useful on its own, because you finally get accurate OEE, and it makes the model possible six months later.
How much does it cost a manufacturer?
- Data capture and a production database for a few machines: typically six to ten weeks, plus hardware
- A scrap prediction model on one process once data exists: eight to twelve weeks
- A visual inspection station for one defect type: ten to sixteen weeks including cameras, lighting and trials
- Ongoing: retraining when materials, tooling or products change, which in manufacturing happens often
Lighting deserves its own line in any vision budget. A model trained under morning daylight and deployed under the night shift's fluorescent tubes will disappoint, and fixing it with a proper enclosure is cheaper than collecting another ten thousand images.
When not to use machine learning in a factory
Several situations where we would advise against it:
- Low-volume, high-mix jobbing work where every part is new and there is nothing to learn from
- The defect is caused by a known root cause nobody has fixed, such as a worn tool
- A simple control chart on one parameter would catch the drift
- Safety-critical decisions where a missed defect is unacceptable and inspection must remain human or deterministic
Statistical process control has been around for decades because it works. If a single temperature reading predicts scrap, you need an alarm, not a neural network. Machine learning becomes worthwhile when several parameters interact in ways a control chart cannot show.
What operators should see on the shop floor
A prediction is only useful if it reaches the person who can adjust the machine, in time, in a form they will act on. That usually means a simple screen at the line or a light on the machine, not a dashboard in the office.
Keep the message plain: which machine, what is drifting, and what the setter normally does about it. "Cycle 14 trending towards short shots, check barrel zone 3" gets acted on. A probability score of 0.73 does not. We design the alert with the operators in the room, and we log what they did in response, because that record tells you within a month whether the model is earning its place or being ignored.
A realistic first project
Choose the single defect or failure mode with the largest known cost, confirm you can record it per batch, and collect at least a few hundred labelled examples, including a fair number of bad ones. Models learn nothing from a dataset that is 99.9% good parts.
SpiderHunts approaches machine learning for manufacturers as a staged project: data capture, a baseline model, a silent trial on the line, then alerts to operators. Each stage has a go or no-go point, so you are never more than a few weeks of spend away from a decision. For the broader software side, our post on software for manufacturing SMEs covers ERP and MES choices.
Frequently asked questions
Do we need IoT sensors before starting machine learning?
How many defect images does a visual inspection model need?
Is predictive maintenance worth it for a small factory?
Can the model run without sending data to the cloud?
How long before we see results?
Losing margin to scrap, downtime or late orders?
Tell us which one hurts most and what data your machines and ERP already hold. We will say whether a model can help, or whether better data capture has to come first.
Related services
What we build for problems like this one