There is a conversation that keeps repeating. A plant wants to see its production in real time, someone proposes an MES, and the question that arrives is how much it costs and how long it takes.
That is the wrong question to open with. The right one is whether the plant is in a condition to receive it, because everything else depends on that. A shop floor monitoring project rarely fails because of the software. It fails because it was connected to an operation that was not ready, and that can be known before signing.
This is what we check before proposing anything.
1. Downtime has names, and they are the same for everyone
If you are going to measure efficiency, every minute the line did not produce has to fall into a category. And the list of categories has to be short, closed, and understood the same way across all three shifts.
Where this fails you see it fast: the morning shift calls “model changeover” what the night shift calls “adjustment”, and by month end the numbers mean nothing. No system fixes that, because the system only stores what the operator picked.
Before connecting anything, sit down with production and close the list. Ten or twelve downtime reasons are enough. If forty come out, what you have is a problem of judgment, not of catalog.
2. Somebody knows what a good part is
It sounds obvious until you ask. If the MES is going to count production, it has to count something. Does a part count when it leaves the station, when it passes inspection, or when it reaches shipping?
All three answers are valid and they produce different numbers. What you cannot do is not have decided, because then every report depends on who built it.
3. The machine has something to say
This is where more projects break than people admit. Not every machine can talk, and the ones that can do not all talk the same way.
There are three scenarios and it pays to know which one you are in before budgeting:
- The equipment has a programmable controller on the network. Best case. State is read directly and the data comes from the machine, not from an interpretation.
- The equipment is old but has electrical signals. There are lights, contactors, a counter. It can be instrumented with external sensors without touching the original control, which is usually a warranty condition anyway.
- The equipment has nothing. Then a person will capture the data at a terminal, and you have to design for that: few taps, large screen, usable with gloves on.
Most border plants have all three at once, and that is fine. What does not work is budgeting as if everything were the first case.
4. There is network where the machine is
The floor is not the office. A warehouse with steel structure and full pallet racks eats wireless signal, and the access point that covers the empty aisle perfectly stops covering it once it fills up.
The test is simple and costs an afternoon: walk the route with a device measuring signal, with the plant loaded, on the busiest shift. Not on a Sunday.
5. The operator gets something out of it
This is the most forgotten one and it decides whether the system survives past the third month.
If recording a stop only serves to let a manager look at a chart, the operator will record the minimum and pick the fastest category on the list. The data degrades in weeks and nobody knows why.
If recording a stop makes maintenance arrive sooner, or stops them fighting a machine that fails at the same hour every day, then they record it properly. Design for that: make the system give something back to the floor, not only to the front office.
6. An owner who is not from IT
An MES measures production. If the project is run by the IT department, production will experience it as an audit and will cooperate as little as possible.
You need somebody from operations who answers for the numbers and has the authority to change a process when the system shows it is wrong. Without that person the project delivers dashboards nobody uses to decide.
What happens if you skip this
We have seen it: the installation finishes, the dashboards light up, and six months later nobody looks at them. The downtime reasons are all under “other”, the production count does not match shipping, and the conclusion in the meeting is that the software did not work.
The software worked. It measured exactly what it was given.
The order that does work
Our recommendation is almost always the same, and it starts smaller than people expect.
Pick one line. The one that hurts most, not the easiest one. Close the downtime list for that line, define what a good part is, connect only what can already talk and put a terminal where one is needed. Let it run for a month and compare against what you believed was happening.
That first month almost never confirms management’s hypothesis, and that is where all the value is. From there the rollout is mechanical, because you already know what you measure and why.
If you have a line in mind and want us to look at it before anyone quotes anything, that is what the twenty minutes are for.