Change Management in Manufacturing: Adoption, Culture and the Human Factor

Industrial digitalisation projects rarely fail because of the technology: they fail because the plant never adopts it. Adoption is the share of real work that flows through the new system, and it is managed like any other project variable: with a diagnosis, with middle managers as the main lever, with training delivered at the right moment, and with usage metrics that depend not on what people say but on what they do.

Why technology fails on adoption, not on engineering

When an industrial digitalisation project is written off as a failure, the post-mortem almost never finds an insurmountable technical problem. The software worked. The sensors measured. The dashboard refreshed. What did not happen was something else: operators kept logging stoppages in the same old notebook, the shift leader kept planning with his spreadsheet and, six months after go-live, the new system was a parallel layer that nobody looked at. The project did not die: it simply emptied out.

This pattern has a structural explanation. A technical project is planned around verifiable deliverables: install, configure, integrate, test. Adoption, by contrast, is not a deliverable but the sustained behaviour of dozens of people with their own incentives, fears and routines. Because it does not appear on the Gantt chart with the same sharpness as an integration, it gets less budget, less time and, above all, less management attention. The result is predictable: the technology is delivered and everyone trusts that usage will follow by itself. It does not.

Throughout this article we will use a running example: a machining plant of around 80 employees that deploys a production data capture system to replace paper work orders. It is a deliberately modest case, with no artificial intelligence and no robots, because the adoption problem appears just as readily in the smallest project as in the most ambitious one. Whether that system gets used or ignored will depend not on the technology chosen but on the change management decisions taken before, during and after go-live. That is why any serious transformation roadmap treats adoption as a workstream with its own resources, not as a footnote to the deployment plan.

Shop-floor resistance: what really causes it

The word resistance carries an unfair connotation: it suggests that the operator who does not use the new system is an obstacle. Shop-floor experience teaches the opposite: resistance is almost always a rational response to a poorly designed change. It pays to distinguish its causes, because each one is treated differently.

In our machining plant, the first reaction to the capture screens was not open rejection but something more corrosive: minimal compliance. Operators logged just enough so that nobody would call them out, but stoppage causes were recorded as «other» and the resulting data was useless. Nobody disobeyed. Simply, nobody believed the system was there to help them. The dominant fear was surveillance: the suspicion that performance data would end up in an individual league table. Until management stated in writing that data would be used by line and never by person, and then kept that promise, the quality of the records did not improve.

The general lesson: before designing a single training course, diagnose what type of resistance exists in each group. Treating a trust problem with more training, or a friction problem with more communication, is spending the change budget on the wrong lever.

Middle managers: the lever almost nobody uses

If there is one decisive figure in industrial adoption, it is the middle manager: the shift leader, the line supervisor, the maintenance manager. Operators do not decide their behaviour by looking at management slides; they decide it by looking at what their supervisor does every morning. If the supervisor opens the new system in the shift meeting and takes decisions with that data, the system is real. If the supervisor keeps asking for the paper report «just in case», the system is decoration.

The paradox is that middle managers are usually the group treated worst by transformation projects. They take pressure from above (make people use it) and from below (this makes our lives harder), rarely take part in the design, and often have the most to lose: their authority rested on being the only person who knew what was happening on their shift, and a transparent data system erodes precisely that information monopoly.

Working the middle-manager lever means, concretely:

• Involve them in the design, do not just inform them of the outcome. The supervisor who chose which stoppage causes appear on the screen will defend that screen; the one who received it ready-made will look for its flaws.
• Give them the system before anyone else. A manager who reaches go-live with a two-week head start on his team can help; one who learns at the same time as his operators is exposed and goes on the defensive.
• Rewrite the script of the shift meeting. The moment the daily meeting starts opening with data from the system is the moment adoption becomes irreversible. It is a change of liturgy, and liturgies are set by the managers.
• Measure their part and recognise it. If the supervisor's objective is still only to produce parts, the new system competes against his objective. If the quality of his shift's records forms part of his evaluation, it stops competing.

In the machining plant, the turning point was not technological. It was the day the production manager stopped accepting a verbal summary from each shift and started projecting the system screen in the 7:30 meeting. Within two weeks, supervisors who arrived with incomplete data felt uncomfortable in front of their peers. Nobody imposed a sanction; the social norm changed. That mechanism, lateral peer pressure mediated by a visible ritual, is more powerful than any circular.

Operator training: when, how and how much

Training is the part of change that everyone budgets for and almost everyone executes badly. The three classic mistakes concern timing, format and scope.

When: close to use, not close to purchase

Retention of a skill that is not practised collapses within days. Training the whole workforce two months before go-live, because that was when the vendor had availability, guarantees that at go-live nobody remembers anything and the first real experience with the system is one of frustration. The practical rule: training for a group must finish days before that group starts using the system for real, not weeks. If the rollout is phased, the training is phased too.

How: at the workstation, with their own case

A machine operator does not learn software in a classroom with a projector; he learns in front of his machine, with his part, with his stoppages. Effective shop-floor training looks more like coaching than a course: short sessions at the workstation, a trainer who comes back the next day, and reference material that fits on a laminated sheet next to the screen, not in a sixty-page manual. The first days of real use are part of the training, and should be planned as such: with support present, explicit tolerance for mistakes and a clear channel to ask questions without feeling examined.

How much: less syllabus, more repetition

The syllabus must cover what that person will do every day, not everything the system can do. In the machining example, 90% of an operator's daily use comes down to three actions: declaring the start of an order, logging a stoppage with its cause and closing the order. Mastering those three actions to the point of automaticity is worth more than a passing acquaintance with twenty functions. Advanced functions are introduced later, once the basics are routine, and are often spread better by colleagues than by an external trainer.

Communicating change without internal propaganda

Change communication has a bad reputation on the shop floor because it is usually confused with propaganda: posters proclaiming «on course for industry 4.0», launch talks with plenty of enthusiasm and little substance. That tone produces the opposite of the intended effect, because a shop-floor audience detects the emptiness instantly and files it away as yet another office fad.

Communication that works in an industrial environment has a different grammar:

• Answer first the questions people are actually asking: what changes in my job, from when, what happens if I make a mistake, what my data will be used for, and what happens to those who do not adapt. Until those five questions have clear answers, every other message is noise.
• Use the chain of command, not only corporate channels. The same message carries different weight said by the director in an email and said by the supervisor in the shift meeting. Decisions cascade down, with materials that help each manager tell the story in his own words.
• Communicate the uncomfortable parts too. If the system will make visible the stoppages that were previously invisible, saying so beforehand counts double: it avoids any sense of entrapment and allows the rules of the game to be agreed. Trust is built not with positive messages but with messages that later turn out to be true.
• Close the loop. Communicating is not just broadcasting: it is demonstrating that what the plant says comes back transformed into decisions. Publishing every month which user suggestions have been incorporated into the system communicates more adoption than any campaign.

Typical mistakes: imposing without listening, training too late

Projects that end in abandonment tend to commit mistakes from a surprisingly short catalogue. Recognising them in time is the cheapest form of change management.

Two of these mistakes deserve emphasis. The first is keeping the old process running in parallel with no retirement date: as long as paper remains valid, paper wins, because twenty years of habit outweigh three weeks of novelty. The coexistence of both processes must be short, explicit and with an end date communicated from day one. The second is declaring victory at go-live. The real adoption curve almost always has a valley after the initial enthusiasm: in the first weeks usage is high because attention and support are present; then the support is withdrawn, the difficult cases appear and usage drops. The projects that survive are the ones with someone watching the curve in that valley, not the ones that staged the best launch.

How to measure real adoption (not declared adoption)

Asking people whether they use the system is the worst way to measure adoption: the polite answer is always yes. Real adoption is measured in usage data and in the disappearance of the alternative processes. A reasonable scorecard for a shop-floor system combines four levels:

The order matters: without coverage there is no data quality worth having, and without data quality any use in decisions is theatre. In our example plant, the indicator that exposed the problem was not coverage (high from the start, because declaring the order was mandatory) but quality: 60% of stoppages logged as «other» betrayed that capture was a formality, not a tool. When that percentage dropped below 15%, and only then, the data began to feed the cycle of analysis and action that characterises a continuous improvement programme that works: losses become visible, get prioritised, get tackled, and the result is verified in the system itself.

A methodological nuance: these indicators are measured by area and by group, never by individual, and are reviewed with the same cadence as production indicators. Adoption measured only at the end of the project is not a metric: it is an obituary.

Useful reference frameworks and their limits

Change management has a consolidated body of knowledge worth knowing, although no framework substitutes for judgement on the ground. Three common references:

• John Kotter's eight-step model (Leading Change, 1996) provides the classic sequence: create a sense of urgency, form a coalition, communicate the vision, generate short-term wins and anchor the change in the culture. Its value on the shop floor lies above all in two ideas: change needs a visible coalition to sustain it, and early wins must be manufactured on purpose, not waited for.
• ADKAR (Awareness, Desire, Knowledge, Ability, Reinforcement), developed by Prosci, looks at change person by person: someone adopts when they understand why, want to do it, know how, can do it in practice and receive reinforcement afterwards. It is useful as a diagnostic: when a group does not adopt, ADKAR helps locate which of the five links is failing, which is almost never the one everybody assumes.
• Everett Rogers' diffusion of innovations (Diffusion of Innovations, 1962) explains why adoption spreads by imitation among peers and not by decree: early adopters convince the early majority far better than any executive. On the shop floor this translates into choosing the pilot lines and the reference operators well.

The common limit of these frameworks is that they were born in general corporate contexts. An industrial environment has constraints of its own that no generic model captures: shifts that make it hard to gather the workforce, collective agreements and works councils that must participate from the start, an oral culture where a written memo weighs less than the supervisor's word, and a relationship with machinery where a mistake has physical consequences, not just administrative ones. Frameworks organise the thinking; adapting them to the shop-floor context is the real work.

Frequently asked questions on adoption and culture

Technology is bought; adoption is built. If you are planning a deployment and want the human factor in the plan from day one, at Captia Consulting we help design the full transformation, from the transformation roadmap to the continuous improvement programme that keeps the change alive after go-live.