Choosing OEE Software for a Small Plant: A Realistic Checklist
Most OEE software advice assumes you have an IT department, an integration budget, and a year. If you have three lines and a supervisor with strong opinions, the evaluation looks completely different.
Read the typical "how to choose OEE software" guide and you can tell instantly who it was written for: there's a section on integration architecture, a vendor scorecard with forty criteria, and an implementation timeline measured in quarters. Useful, if you're a plant network with an IT department.
Most plants aren't. Most plants are three to a dozen lines, a maintenance crew that's already stretched, and a plant manager who'll be doing the evaluation personally, between other jobs. For that plant, the enterprise checklist isn't just overkill — it actively selects the wrong product. Here's the evaluation that fits.
Start from the failure mode, not the feature list
Small-plant OEE rollouts don't fail because the software lacked a feature. They fail because the system never became a habit: logging was too slow so operators lapsed, setup dragged so momentum died, or the one person who understood the configuration left. Every question on your shortlist should trace back to habit-formation, which reorders the priorities dramatically.
How many seconds to log a stop? This is the number one question, and vendors rarely volunteer it because the answer is a design philosophy, not a feature. Have an actual operator — not you — log an actual stop during the demo: from "line stopped" to "reason recorded," count the taps and the seconds. Under ten seconds at the machine, it'll get used during the stop. Over thirty, entries will be reconstructed at shift end, and you'll have bought an expensive way to collect fiction. Everything in why operators stop logging downtime applies to your demo scorecard.
Can we be running in days, without a project? For a small plant, time-to-first-data is more predictive of success than any capability. Ask the vendor to set up one of *your* lines, with *your* products and shift pattern, during the trial — not a sandbox demo. If configuration requires their professional services team, it'll require them again every time you change a product or add a line, and that dependency is a tax forever. Bonus points for vendors who ship industry starter content — a downtime-reason tree for bottling or molding that's right on day one beats a blank tree you must invent — as long as you can edit it freely, because your floor will need reasons no template predicted. (That editability question — "can a supervisor add a reason code in under a minute, without a support ticket?" — is worth asking verbatim.)
Does it work without sensors, and grow into them? You should be able to start with operator-entered data alone — the case is laid out in do you need sensors to start tracking OEE — but not be trapped there. The right shape: manual now, automatic counts on the bottleneck line next year, no migration in between. Be suspicious in both directions: hardware-first systems make you buy the wrong project first; manual-only systems make this year's tool next year's ceiling.
The questions that sound important but aren't (yet)
A little permission to ignore things: ERP integration is an enterprise concern that small plants postpone for years without cost — a monthly export covers finance long before an API matters. AI-powered anomaly detection and predictive features are marketing at your scale; your first two years of value come from a Pareto chart and a fixed feeder, no models required. And a giant configurable-report library mostly signals complexity — you need perhaps five views (live line status, shift summary, downtime Pareto, changeover trend, weekly OEE trend), and you need them good, not a hundred of them possible.
The one "enterprise" concern you should keep: data export. Whatever you choose, confirm you can get your raw data out — stops, counts, timestamps — in a usable format, any time. It keeps vendors honest and futures open.
Run the only evaluation that means anything
Shortlist two or three products, then put one line on a real trial for two to four weeks — real operators, real stops, real shifts. Not a proof of concept run by the vendor; a normal month, run by your crew. Then the scorecard is short:
- Did operators log stops without being chased, by week two?
- Did the supervisor pull up the downtime Pareto without asking how?
- Did anything from the data get *fixed* during the trial?
- Does anyone on the floor object to keeping it?
Software that passes that month will survive in your plant. Software that needs conditions the trial didn't have — more training, more configuration, more enforcement — will need them forever.
The enterprise guides aren't wrong; they're solving a different problem. Yours is smaller and harder: making measurement a habit in a building where everyone already has two jobs. Buy the tool that makes the habit cheap, and the habit will pay for everything else.
