Every plant runs on more software than its managers realise, and less of it fits than they would like to admit. There is an ERP that knows about orders and money, a scheduling spreadsheet a planner guards like a family recipe, and a shop floor where the real state of production lives on paper travellers and in the heads of the people running the machines. The gap between what the systems say and what is actually happening on the line is where custom software earns its place.
MES and ERP are not the same tool
The most expensive confusion in manufacturing software is treating the ERP as if it could run the shop floor. An ERP is a system of business record — orders, inventory, purchasing, cost. It thinks in transactions and days. A manufacturing execution system thinks in operations and minutes: which order is on which machine right now, what the operator just scanned, why line three stopped, whether this batch passed inspection. The ERP tells you what you promised to make; the MES tells you what is actually being made.
Trying to force one to do the other's job is where projects go wrong in both directions. Push shop-floor detail into the ERP and you get a system too slow and too coarse to run a line. Push business logic into a homegrown MES and you rebuild accounting badly. The two need to exist, talk to each other cleanly, and stay in their lanes — and the interface between them is one of the most important design decisions in the whole system.
The interface between them is also where timing lives. The ERP does not need to know about every scan the instant it happens; the MES cannot wait for an overnight batch to learn that a work order changed. Deciding what flows in real time, what flows on a schedule, and what is the authoritative source for each shared fact — the order, the routing, the inventory count — is unglamorous integration work, and it is precisely the work that determines whether the two systems reinforce each other or quietly disagree.
Why generic tools rarely fit a plant
Two factories making similar products can run completely different processes — different routing, different quality gates, different ways of handling a rework, different definitions of what "done" even means at each station. A generic MES has to assume one of those, and it assumes the average. The average fits no one exactly, so the plant adapts itself to the software: operators learn to enter data in the order the screen demands rather than the order the work happens, and the planner keeps the real schedule in the spreadsheet the tool cannot express.
This is the honest tradeoff. A platform is faster to stand up and someone else maintains it, but a plant's process is often its competitive edge, and forcing that edge through generic software files it down. Custom software fits the process instead of the other way around — which is worth paying for exactly when the process is specific enough to matter, and not worth it when you are doing something the whole industry does the same way.
The shop floor is not an office
Software designed by people who sit at desks tends to assume everyone does. On the floor, the operator is wearing gloves, standing at a ruggedised terminal, working in noise and sometimes in poor light, and cannot afford to lose thirty seconds to a spinner. The network drops. The device takes a knock. A screen designed for a mouse and a full keyboard is the wrong tool entirely.
Good shop-floor software respects those constraints as first-class requirements, not afterthoughts. Big touch targets and few taps to log a step. Offline-first behaviour so a dropped network pauses nothing and the terminal syncs when the connection returns. Screens designed around what the operator does next, not around the data model. Get this wrong and adoption fails no matter how correct the backend is — the floor simply routes around software that slows the work, back to paper, and you are worse off than before because now the data is both incomplete and trusted.
There is a human dimension the datasheet never mentions. The operator is the person who knows the most about what is actually happening at the station, and the system either captures that knowledge or wastes it. Software that only takes data from operators, and gives nothing useful back, is resented and fed the minimum. Software that shows them what to run next, flags a problem before it becomes scrap, and saves them a walk to the office earns the cooperation that makes the data trustworthy in the first place.
Machines, PLCs, and sensors
The real leverage in modern manufacturing software is connecting to the machines. A PLC, a CNC controller, a sensor on a spindle, a scale, a vision system — each can tell you what an operator typing into a terminal never will, in real time and without a human step. Cycle counts, downtime reasons, temperatures, part counts, the true basis for an OEE number that people actually believe.
The reality is messier than the pitch. The floor is a museum of protocols and vintages — a machine from this decade next to one from two decades ago, OPC UA beside a serial port and a proprietary format with no documentation. Some machines expose everything; some expose nothing without an added sensor. The integration work is real and specific, and it is where a partner who has actually stood on a shop floor is worth more than one who has only read the datasheet. The correct approach is incremental: instrument the machines that matter first, prove the data is trustworthy, and expand — not attempt a total connected-factory build in one contract.
Traceability and scheduling
For many manufacturers, traceability is not optional. Regulated sectors, automotive supply chains, food and medical production all demand that you can answer, for any unit shipped, exactly what went into it, on which machine, by whom, and whether every check passed. That is a data-model decision made at the start, not a report bolted on at the end — genealogy, lot tracking, and an audit trail that cannot be quietly edited have to be designed into the core, because retrofitting traceability into a system that did not plan for it is close to a rebuild.
Scheduling is the genuinely hard problem, and it is worth being honest that no product fully solves it. Real production scheduling is a constraint puzzle — machine availability, changeover times, material arrival, labour, due dates, all shifting through the day as a machine goes down or a rush order lands. A tool can help enormously; it cannot remove the judgment. The best systems treat the planner as the decision-maker and give them a fast, honest picture plus the ability to try a change and see the consequence, rather than pretending an algorithm can own a decision that depends on things the algorithm cannot see.
It is worth separating the two because they fail differently. Traceability that was designed in is cheap to satisfy and expensive to add later; scheduling that was over-promised is expensive to satisfy and disappointing to deliver. The honest position on scheduling is to be modest about automation and generous about visibility: a planner with a clear, current picture and fast what-if answers will outperform a black-box optimiser that no one trusts and everyone overrides, and the overrides are where the real schedule quietly moves back into a spreadsheet.
Roll out line by line, and keep data where the rules demand
A manufacturing rollout should never be a single switch. The right shape is one line, one cell, or one process proven in production, with the old method still available underneath, before the next. This keeps production running throughout, surfaces the mismatches between the design and the floor while they are cheap to fix, and builds the operator trust that decides whether the system lives or dies. A big-bang go-live across a whole plant is how a good system gets rejected by the people who have to use it.
The rollout is also how you discover what you got wrong, and you always got something wrong. The first line will reveal an assumption about how a changeover works, or a step the process map skipped, or a terminal placed where no one can reach it. Discovering this on one line, with the old method still there to fall back on, costs a week. Discovering it across a plant after a full go-live costs the credibility of the whole project. Incremental is not caution for its own sake; it is the cheapest way to be wrong.
Two more realities shape the architecture. Connectivity on a factory floor is not a datacentre's, and some control decisions cannot wait for a round trip to the cloud, so an edge or on-prem layer is often not a preference but a requirement — the line has to keep running when the internet does not. And data-residency rules, customer confidentiality, and plain caution about production data mean much of it may need to stay in the building. For Central Europe's dense manufacturing base — automotive, electronics, and their supplier tiers — these are everyday constraints, not edge cases. The sane first step is a short, fixed-fee assessment: walk the line, map the process and the machines, find where the spreadsheets and paper live, and turn "we need an MES" into a costed plan that says what to buy, what to integrate, and what to build.