The software is ready, the tests have passed, the date is set. What remains is the moment many SME manufacturers dread: going live with production software on the shop floor, the day the workshop stops working with its paper sheets and habits and starts clocking, checking and consuming materials in the tool. This go-live, far more than the choice of software, decides whether the project succeeds.
We have supported this transition in several workshops. The finding is always the same: the difficulties rarely come from the software itself. They come from the data, from the interfaces with the ERP and, above all, from the people who have to change the way they work.
This article offers a step-by-step guide in five stages (data preparation, pilot, training, cutover, follow-up), then describes what really happens in the first weeks, based on a rollout we went through ourselves, and lists the mistakes we see in the field.
A production software go-live is won or lost before day one
Production software only reflects the data it is given: items, bills of materials, routings, work centres, standard times. If a product's routing has three operations on paper and five in the workshop, operators will notice from the very first manufacturing order, and the tool will lose their trust in a single morning. Data preparation is therefore not an administrative task: it is the first step of the rollout.
The second thing to settle before day one is the interfaces. Production software rarely works alone: it receives manufacturing orders from the ERP and sends back times, quantities and material consumption. A fault on that side is experienced by the workshop as a fault in the production software, even if the cause lies elsewhere. We will come back to this, because it is exactly what happened to us.
The five steps of a production software go-live
- Prepare the data. Check the routings and bills of materials of the products that run most often, clean up item codes, define work centres as they physically exist, and enter standard times, even approximate ones: they will be corrected with actual times. Decide who is the master of each piece of data (usually the ERP) and how it reaches the production software.
- Run a pilot on a limited scope. One workshop, one line or one product family, for two to four weeks, with real manufacturing orders. On the rollout described below, we started with the first operation of the routing (releasing the manufacturing order) and the last (final validation with quality control), before covering the intermediate operations. The pilot must have a measurable objective: share of manufacturing orders clocked, gaps between standard and actual times, number of blockages.
- Train at the workstation, not in a meeting room. A one-hour demonstration in a meeting room is not enough. Each operator must have carried out, personally and at their own workstation, the three or four actions they will perform every day: start an operation, finish it, declare a quantity, answer a check. Provide a one-page sheet per workstation and a shop floor champion for each team.
- Cut over with extra people on site. Choose a period without a load peak, warn the ERP team and support, freeze changes to the software a week before, and stay physically in the workshop for the first few days. Have a fallback procedure (paper entry, then catching up) in case a blockage occurs.
- Monitor and adjust for six to eight weeks. A daily review in the first week, then weekly: what is blocking, what is irritating, what is missing. Measure adoption (share of manufacturing orders clocked in the tool) and quickly fix usability irritants. The rollout does not end on cutover day; it ends when the workshop stops talking about the tool.
What really happens in the first weeks: our lessons learned
On this rollout, the technical outcome was simple: no malfunction on the production software side. Operation traceability worked, quality checks were triggered at the right time, the certificate of conformity was produced automatically and material consumption was recorded after the operation was validated. On paper, everything was fine.
In the workshop, however, tension was at its peak. The trigger was a bug in the ERP, outside the production software, which disrupted the first few days. For the operators, there was no distinction between the two tools: the new system did not work. Above all, this bug acted as a catalyst for a deeper resistance that we had not gauged.
Productivity versus quality: the real issue
Before the production software, quality control questions were asked in a fixed order, the answers were written on a paper form, and a non-conformity blocked nothing: output came first. With the production software, the answers are analysed, the checks are enforced and blocking, and validation is mandatory before moving on to the next operation.
This is not a change of tool; it is a change in the rules of the game. An operator judged on parts per hour sees a system arrive that, from their point of view, slows them down. We realised, a little late, that this issue should have been dealt with by management well before the cutover. These checks are described in detail in the case study on quality checks in production software.
Change management on the shop floor: the three fears to address
Three fears crystallised the reluctance, and we find them on most projects:
- The fear of losing control: operators used to decide alone on the order of tasks and on what to do about an anomaly; the tool imposes a framework.
- Worries about skills: knowing how to use the screen, the handheld scanner or the phone, and knowing what to do after an input error.
- Habits being called into question: routines established over many years.
What we did in response: explain clearly, and more than once, what the tool brings to each person (less paper, actual times that give an objective view of the load); organise short, repeated support sessions at the workstation; take feedback from the shop floor into account and deliver adjustments quickly, to prove that we were really listening; and value the operators' expertise by involving them in defining the screens and checks.
The mistakes we see in real workshops
- Testing the production software on its own. The tests had validated the software, not the complete chain of ERP, interface, production software and label printer. This end-to-end test must take place before day one, with real manufacturing orders.
- Discovering the change in rules on cutover day. A blocking check is a management decision, not a software setting. It must be announced, explained and owned by management before go-live.
- Involving users too late. Operators and team leaders who took part in the design workshops defend the tool; the others put up with it.
- Rolling out without a change management plan. Who explains what, to whom, and when? Who is in the workshop in the first week? Who answers questions at 6 a.m.?
- Treating the cutover as the end of the project. Friction appears on contact with the shop floor, and it is impossible to anticipate all of it. The capacity to adjust quickly in the following weeks is part of the budget.
What this rollout finally delivered
Despite a tense start, the production software is used every day. Non-conformities have fallen markedly, traceability covers the entire production process, and the workshop produces slightly fewer parts, but with a higher conformity rate: this is the trade-off management wanted, and one that paper could not sustain.
Going live with production software on the shop floor is first and foremost an organisational project. Technical preparation is necessary; preparing the people is decisive. The resistance encountered, hard to live through at the time, sends useful signals for adjusting the tool and winning buy-in.
At Planitools, we carry out these rollouts with Planitrack for tracking times and operations with a handheld scanner, and with Odoo when the ERP itself needs to be implemented or replaced. The hub page simple production management software for SMEs presents our whole approach. Preparing a go-live? Book a demo with us.