Manufacturers are told the answer is an MES or an ERP module, and often discover the first problem they need to solve is not one those systems attack directly. Operations software tends to go wrong when it starts from the product catalogue instead of the shop floor. Here is how we decide what to build first — the same approach behind our custom internal tools work.
Why off-the-shelf MES and ERP rarely fit the first problem
Full MES and ERP suites are built for breadth and for the average factory. They excel at the standard flows and struggle with the specific ones — how your lines are actually scheduled, how your quality checks really work, how your shifts and exceptions run. Implementation becomes a long configuration project chasing a process the product did not anticipate.
That does not make the suites wrong. It means they are the wrong first move when the immediate pain is a specific operational bottleneck they do not address head-on.
Rank the pain before the software
- Where does work physically stall — queues, changeovers, waiting on information or material?
- Where does rework or scrap come from, and is it visible in time to act?
- What is typed on paper or into spreadsheets and then re-entered somewhere else?
- Where does someone walk the floor because no system tells them the truth?
- Which of these has a measurable cost — hours, yield, on-time delivery — that you can move?
What to build first, usually
- Production tracking: what is running, on which line, at what stage, against which order — visible in real time.
- Work instructions and checks: the right steps and sign-offs at the right station, captured digitally.
- Quality and inspection: defects and inspection results recorded at the point of work, not after.
- Maintenance and downtime: tracking stops and causes so you attack the biggest losses first.
- Inventory and material flow: connecting consumption to production so counts and costs stay honest.
Shop-floor realities that decide design
Shop-floor software lives under constraints office software does not. Devices may be rugged tablets or shared terminals rather than personal laptops; connectivity can drop; operators wear gloves and have seconds, not minutes. A tool that needs a mouse and a fresh login every time will be abandoned by the second shift.
Design for the floor: large touch targets, fast role-based access, offline tolerance with sync, and interfaces that tolerate interruption. These constraints shape the tool more than any feature list.
Integration with existing ERP and MES
The new tool should feed and draw from the systems of record rather than replace them. Order data comes from ERP; production events flow back to it. That usually means integrating at clear boundaries — orders, work orders, inventory movements — rather than attempting a full synchronisation both systems will fight.
Getting these boundaries right is the same integration discipline that decides success in any operations software project, and it is where the estimate lives or dies.
Start with one line, one product family
Do not roll out across the whole plant at once. Pick one line or product family where the pain is sharpest and the measurement is clearest, build the smallest tool that moves that number, prove it in production, then extend. A win on one line earns the trust and the data model needed to scale to the next.
Key takeaways
- Start from the shop-floor bottleneck, not the software category; full MES/ERP suites rarely fit the first, specific problem.
- Build the smallest tool that moves a measurable cost on one line, then extend — usually production tracking or quality first.
- Design for the floor — rugged devices, fast sign-in, offline tolerance — and integrate with ERP at clear boundaries.
Founder & CEO
Yashwant DanielYashwant Daniel writes on compliance and trust engineering, custom software delivery and applied AI at Solvstrat — covering how regulated and mid-market teams build systems that hold up under audit, scale and scrutiny.
LinkedIn