Why Adoption Fails on the Floor, Not in the Demo
By Nishkam Batta
Six months after a new warehouse system goes live, walk the receiving dock and look for the clipboard.
It is usually there. Sometimes it is a laminated sheet taped to a post. Sometimes it is a notebook in a supervisor’s back pocket with the real cycle count numbers in it, the ones that get typed into the system later, after somebody has had a chance to reconcile them. The plant paid six figures for software specifically to eliminate that notebook. The notebook won. Most conversations about manufacturing software development never get anywhere near that notebook. They stop at the build: which ERP, which integrations, how long, what it costs.
Nobody on the leadership team knows this is happening. The dashboard looks fine. Transactions are posting. The vendor’s quarterly review shows green. And the receiver who keeps the notebook is not being difficult. He is being competent, because the system as designed does not let him do his job during the twenty minutes a week when the network drops in the back rack aisle, and he learned in month two that a stuck transaction takes forty minutes to unstick.
This is the most expensive pattern in mid-market manufacturing software, and it almost never gets diagnosed correctly.
Workarounds Are Data, Not Defiance
The best research on this does not come from manufacturing at all. It comes from hospitals.
In 2008, Ross Koppel and colleagues at the University of Pennsylvania published a study in the Journal of the American Medical Informatics Association examining how nurses actually used barcode medication administration systems across five hospitals. These systems scan a patient wristband and a medication package to confirm the right drug goes to the right person. The safety case for them is overwhelming.
The researchers documented 15 distinct types of workaround, traced to 31 separate causes. Nurses affixed patient barcodes to computer carts and doorjambs so they could scan without walking to the bedside. They carried pre-scanned medications for several patients at once. Across the observed sites, the scan step was overridden for roughly one in ten medications charted.
None of these nurses were careless. Each workaround was a rational response to a specific friction the system created, in an environment where the work still had to get done. The study’s most useful contribution was the categorization: omitted steps, steps performed out of sequence, and unauthorized steps. Every workaround fell into one of those three, and every one pointed at a design decision made by someone who was not doing the work.
Swap the wristband for a pallet license plate and the medication cart for a forklift, and you have described most warehouse floors in America.
The workaround is not the problem. The workaround is the diagnostic readout. It tells you precisely where the software and the physical process diverged, and it is generally the only honest signal a plant produces about its own systems, because it is the one nobody thought to report upward.
Why the Demo Cannot Surface This
The demo happens in a conference room. Good lighting, strong Wi-Fi, a clean data set, a vendor engineer driving, and an audience of people who mostly do not scan things for a living.
Under those conditions, almost any warehouse system looks competent. The screens are legible on a laptop. The scan works every time because the barcode is a crisp printout, not a label that has been sitting in a freezer, or one that a forklift tine caught last Tuesday. Nobody is wearing gloves. Nobody is holding a device in one hand and a case in the other. The network does not drop, because the conference room is thirty feet from the access point.
The variables that determine whether software gets used are almost entirely absent from the environment where the buying decision gets made. That is a structural problem, not a vendor failing, and it explains why implementation failure statistics stay stubbornly high across two decades of improving technology. Gartner expects that by 2027, more than seventy percent of recently implemented ERP initiatives will fall short of their original business case goals. Godlan’s 2026 analysis of more than 2,400 discrete manufacturing implementations put the failure rate in that segment at 73 percent, with cost overruns averaging 215 percent. Prosci’s research on the same question found that human factors mattered roughly six times more than technical factors in whether an ERP program delivered its expected benefits.
Six times. The industry keeps responding to that finding by buying better technology.
Three Design Decisions That Decide Everything
Most failed floor software fails on the same small set of choices. Not features. Choices.
What the operator sees when a scan does not work. A good scan screen presents one unambiguous action, in text large enough to read at arm’s length under warehouse lighting, with a failure state that says what went wrong and what to do next. A bad one presents four equally weighted buttons and, on a bad scan, either does nothing visible or throws a code. The operator has two options at that point: find a supervisor, or find another way to record the transaction. On a busy shift, it is always the second one. That is your notebook.
What happens when the network drops. In most mid-market deployments this question is never formally answered, which means it gets answered by default, usually badly. The real specification has four parts: what the device does with a transaction it cannot post, how the queue replays when the connection returns, how conflicts get resolved if inventory moved in the interim, and what the operator sees during all of it. A system that silently discards a scan teaches the floor within a week that scans cannot be trusted. Once that lesson lands, it does not un-land.
Whether failed transactions have a visible owner. This is the one that gets cut from scope most often, and it is the one that matters most. Every integrated system produces exceptions. A receiving quantity that does not match the purchase order, a lot number that fails validation, a financial posting that the ERP rejects. The question is not whether exceptions happen. It is whether there is a queue where they land, a named person responsible for that queue, and a retry path that does not require a developer.
Without that, exceptions become invisible. They accumulate as inventory drift, and six weeks later somebody is running a full physical count trying to work out where 400 units went. Studies of warehouse inventory accuracy consistently find operations relying on manual entry or degraded scanning workflows sitting in the 63 to 85 percent range, against 95 to 99.9 percent for operations with scanning that people actually use. The gap is not about workforce quality. Manual keyboard entry produces roughly one error per 300 keystrokes no matter who is typing, and a warehouse doing thousands of transactions a day compounds that into meaningful drift within days.
That exception log, incidentally, is also the most useful dataset a plant owns if it later wants to apply AI Solutions for Manufacturing to receiving variance or consumption anomalies. It is a structured record of where the process actually breaks, which is exactly what a model needs and exactly what most operations never capture.
What Changes When the Floor Is in the Room
A Fishbowl ERP manufacturer we worked with was running about twelve hours a day of manual entry across the ERP, warehouse workflows, and procurement. Same data typed three times. Inventory was never current and lot genealogy took days to reconstruct.
The middleware we built posted receiving, putaway, picking, and shipping events to Fishbowl in real time. Manual entry dropped to under two hours a day, an 85 percent reduction, and lot genealogy became traceable in minutes.
The integration is not the interesting part of that project. Plenty of vendors can post events to Fishbowl. The interesting part is that user acceptance testing ran with actual warehouse staff, on the actual handheld hardware, against live ERP data, before go-live rather than after. Three workflow changes came out of that testing that nobody in the requirements sessions had anticipated. All three were things a picker knew and an architect did not.
That is not a methodology innovation. It is just refusing to skip the one step that everybody skips because it is inconvenient to schedule.
Training Is Not the Fix
When adoption is poor, the standard response is more training. Sometimes a refresher program. Occasionally a compliance push, where supervisors are asked to enforce scanning.
Consider what that costs against the arithmetic of the workforce. Manufacturing turnover averaged around 28 percent annually across subsectors in 2025, and warehouse and distribution roles run higher. A plant that solves a design defect with training is committing to re-solve it, at cost, for a rotating population, indefinitely. Meanwhile the workaround propagates informally, because the person who leaves teaches it to the person who replaces them long before the trainer does.
Training closes a knowledge gap. It does not close a design gap. If a new hire needs to be taught a workaround in week one, you do not have a training problem.
What to Specify Before Development Starts
Whether a plant is building custom or configuring a packaged system, six things should be written down and agreed before anybody starts building. Not after the first demo. Before.
- The scan screen action model. One primary action per screen, defined failure states, readable at arm’s length, operable with gloves on. Draw the screens, then have a picker walk through them.
- Offline and degraded network behavior. Queue depth, replay logic, conflict resolution rules, and what the operator sees at each stage. Test it by turning the access point off, not by discussing it.
- The permission model, mapped to job roles. Not to the org chart. A lead who covers three areas needs access that matches what the shift actually asks of them.
- The exception queue. Where failed transactions land, who owns them by name, what the retry path is, and what the escalation threshold looks like.
- The hardware and environment standard. Device model, mounting, cold or wet conditions, lighting, label durability, charging. These constrain the software design and should be settled first.
- Acceptance criteria written with floor staff, tested on real hardware with live data. This is the requirement that most reliably predicts whether the notebook comes back.
None of this is exotic. It is the difference between a system specified around a data model and a system specified around a shift. Every one of these six items costs a conversation to settle before development starts, and costs a rebuild to settle after go-live.
The Question Worth Asking This Week
Go find the clipboard.
Ask the person who keeps it what it is for, and make it clear that you are asking as a diagnostic and not as an audit. What you get back will be the most accurate description of your systems anyone will give you this year. It will be specific, it will be unflattering, and it will point directly at three or four decisions that were made in a room without a picker in it.
Software that people work around is not underused. It is telling you something. The only real question is whether anyone in the building is set up to hear it.
About the Contributor
Nishkam Batta, Editor-in-Chief, HonestAI Magazine | AI Consultant, GrayCyan AI Solutions
Nish leads an applied AI company helping manufacturing and related companies automate operations with human-in-the-loop AI that integrates into ERPs, WMS, CRMs, and other enterprise tools, with an emphasis on explainable AI, clear audit trails, and measurable outcomes. His team builds agentic ERP systems that execute multi-step tasks inside approved guardrails so humans keep accountability, approvals, and override control. Why Adoption Fails on the Floor, Not in the Demo