Why factory system implementations fail, and what has to be resourced

A process project wearing a software badge

The system will encode how work is done, which means the project is deciding how work will be done. That decision belongs to operations, not to a technical team or a consultant who leaves afterwards. Where no operational owner exists for a process, the consultant configures a generic version of it, and the plant discovers at go-live that the way it actually works was never described to anyone. Assign a named owner per process area with authority to change how their area operates, and give them the calendar time to exercise it rather than a title on a slide.

Nobody is free, and the plan assumed they were

The people who can specify the system correctly are the ones the plant cannot spare: the senior planner, the scheduler who knows every exception, the buyer who understands supplier behaviour, the quality engineer who knows why each check exists. Business cases habitually cost the software and the consultants and leave internal effort at nil, then the project runs on evenings and the specification is written by whoever was available. Budget backfill explicitly. A project staffed by people who could be released is staffed by people who did not know enough.

Configuring around a broken process makes it permanent

A workaround that exists because the old system could not do something gets faithfully reproduced in the new one, because reproducing it is faster than arguing about it and the deadline is fixed. That is how a plant spends heavily to buy its existing problems in a supported version. Every requirement that begins with a description of current practice deserves the question of why the practice exists, asked by somebody senior enough to change the answer. Some workarounds turn out to be genuine business needs; a great many turn out to be scar tissue from an old constraint.

Sequencing, and what you deliberately postpone

Doing everything at once maximises both risk and the number of people learning simultaneously. Doing it in phases creates temporary interfaces and a longer period of dual working. There is no universally correct answer, but there are bad ones: going live during peak season, during an audit period, or immediately before a shutdown that removes half the support team. Pilot on a line or a product family where failure is survivable, define the freeze period during which nothing else changes, and write down the criteria that would cause you to postpone, before pressure to hold the date arrives.

Hypercare, and the drift that starts after it

The support surge after go-live is planned. What follows it is not. Once the visible support disappears, people who never quite understood a transaction start inventing shortcuts, spreadsheets reappear beside the system, and configuration is quietly changed to make an irritation go away. Six months later the reported data has degraded and nobody can say when. Plan a structured review after the dust settles: which transactions are being bypassed, which reports nobody opens, which workarounds have appeared. That review is where the second wave of value is available and where it is usually left.

Frequently asked questions

Should we change our processes to fit the software?

Mostly yes for administrative and transactional processes, where the standard flow embodies practice that works and your variation is usually historical. Mostly no where the process is how you compete or how you satisfy a customer or regulatory requirement. The dangerous middle ground is a process people believe is distinctive and which is actually just familiar. Make that judgement explicitly for each area with someone senior in the room, rather than allowing it to be settled by whoever is loudest during configuration.

Who should lead the project, operations or IT?

Operations should lead, with technical leadership reporting into it. The decisions that determine success are about how the plant will work, not about infrastructure, and a technically led project tends to deliver a correctly installed system that nobody uses as intended. IT ownership of the technical delivery is essential and separate. If operational leadership cannot be resourced properly, that is a reason to move the date rather than to hand the project to whoever has capacity.

What are the early signs a project is heading for trouble?

Data cleansing slipping while the go-live date holds. Workshop attendance thinning as operational people are pulled back to the floor. Decisions recorded as open and carried forward repeatedly. Requirements agreed by people who will not use the system. Testing done by the project team rather than by the people who will operate it. Any of these appearing well before go-live indicates the schedule has become the objective, which is the condition under which the four common causes take hold.