Operator Adoption Is a Measurement Problem

The story has one shape. A plant buys a monitoring system. Terminals go up on the line. Operators are asked to log stops and pick reason codes. For a few weeks the data looks good, because someone is watching. Then a bad week arrives: two people out, a rush order, a machine misbehaving. Logging becomes whatever there was time for. A shift's worth of entries gets typed at once, near the end. A default code gets picked because it is first in the list. A stop never gets written down at all, because clearing it mattered more than recording it.

Nothing in that sequence is a discipline problem. It is what happens when a measurement demands attention at exactly the moment attention is most expensive. Ask for data entry during the worst hour of the week and you will get data entry that reflects the worst hour of the week.

The consequence is what kills the system. The number goes soft. People notice it is soft. Then it stops being usable in any argument that matters, because whoever is losing the argument can say the data is wrong and be right. A dashboard nobody will cite in a disagreement is already dead; it just takes a year for someone to turn it off. Plenty of these systems survive in name only and get dusted off a month before an audit, which is not adoption. That is compliance with extra steps.

We are at design-partner stage and have no customers, so this is not a case study and there is no plant here whose turnaround we are going to describe. It is an argument about where the failure comes from, and it should be useful to you whether or not you ever buy anything from us.

Ask it plainly, because the floor will ask it plainly. Is this monitoring machines or monitoring people?

What KaizenFlow does is price losses. It attributes lost time and lost units to a machine, a line, a shift pattern, and a cause, then ranks what each loss costs so the biggest one can be worked first. That is what OEE and TEEP analytics produces. It is not a time-and-motion tool. It does not watch operators, does not score them, and does not produce an individual performance number, because that is not the product and not what we intend to build.

Now the part vendors skip. Any measurement system can be pointed at people if management decides to point it at them. Ours included. If a line runs one operator per shift, a shift-level loss number is a person-level number in practice, whatever the label on the chart says. We are not going to pretend a technical control fixes that, because it does not. The tool does not decide how it gets read. The plant decides, and the plant's answer is set by what managers do the first time the data is inconvenient for somebody.

So here is what we will not build, stated so you can hold us to it: individual operator scorecards, productivity rankings by name, idle-time tracking of people, or anything whose purpose is to assemble a disciplinary case. What we do build is access control and a record. Roles are Admin, Manager, Engineer, and Viewer, so you choose who sees what, and every recommendation and action is attributable and audit-logged, so there is a trail of who looked and who decided. The full posture is on the security page.

And here is what your plant has to decide, in writing, before day one: what this data will be used for, and what it will not. Say both halves out loud to the people who work the line. If you cannot say it honestly, do not switch anything on yet, because the measurement is not your problem. The answer to that question is your problem, and no software will answer it for you.

This is not a change-management program. It is four things, in order, and only the last one has no recovery.

• Say what it is for, and what it is not for, before day one. Not in a kickoff deck. Say it in the language you would want used if you were on the other side of it, and lead with the "not for" half. Vagueness here is read as a threat, and that reading is usually correct, which is why it is the default one.
• Show the floor the first thing it fixed for them, not the first thing it caught. The first output people see defines what they think this is. If the debut is a loss somebody gets asked about, you have taught the plant precisely what to expect from it. If the debut is a recurring jam that finally got engineering time because it turned out to cost real money, you have taught them something else, and you only get to teach it once.
• Put the ranked list where the line can see it. Not only in a manager's browser. A ranking the floor cannot read is a ranking the floor cannot argue with, and you want them arguing.
• Never use it in a disciplinary conversation if you told them you would not. Every other mistake on this page is fixable. This one is permanent, and it outlives the software, the manager who did it, and the vendor. A plant's model of what a system is for gets set the first time that system costs someone something, and it does not update afterwards.

Note what is missing from that list. No training rollout, no adoption champions, no engagement targets. Those exist to prop up systems whose numbers need human labor to stay true. If the measurement does not need propping up, the introduction is a conversation about intent, not a campaign.

How much data entry do operators have to do? None to get OEE. KaizenFlow reads run, stop, rate, and quality signals from the systems already running on your floor, so availability, performance, and quality are calculated without anyone entering anything. Where your MES already collects operator reason codes, we read them as one more field. They sharpen the cause of a stop; they do not produce the number.

Is this monitoring machines or monitoring people? Machines. KaizenFlow prices losses by machine, line, shift pattern, and cause. It is not a time-and-motion tool and it does not score individual operators. The honest caveat: any measurement system can be pointed at people if management chooses to point it at them, and on a line running one operator per shift a shift-level number is a person-level number in practice. The tool does not decide that. The plant does.

Our last system failed because nobody used it. Why would this be different? It depends on why it failed. If the number came from operators logging codes at a terminal and degraded into whatever people had time to type, the difference is structural: our number does not depend on anyone remembering to write a stop down, so it does not get worse on a bad week. If it failed because the plant used the data to blame people, no vendor fixes that, and we would rather you fix it before you buy anything from anyone.

Will operators see their own data? There is no personal data page, because we do not build a personal record. What the floor can see is what everyone else sees: losses by machine, line, and shift, ranked by what they cost. Access is role-based across four roles - Admin, Manager, Engineer, and Viewer - so you decide who reads what. Our view is that the ranked list belongs in front of the people who work the line.

Do you track individual operator performance? No. We do not build individual operator scorecards, productivity rankings by name, or idle-time tracking of people. What we do instead is attribute lost time and lost units to machines, lines, shift patterns, and causes, then rank those losses by cost so the plant works the biggest loss first rather than the most visible person.

What do we tell the floor before we switch it on? Say what the data will be used for and what it will not be used for, say it before day one, and say it in plain language rather than in a kickoff deck. Then keep it. The one unrecoverable mistake is using the data in a disciplinary conversation after telling operators you would not. Every other mistake here is fixable; that one is permanent.