5 Common ERP Implementation Challenges in Manufacturing and How to Solve Them

Why ERP Projects Fail More Often in Manufacturing

A finance team switching accounting systems can work around a bad week. A production line can't. When the ERP goes wrong in a factory, the consequences are physical: pickers can't find stock, machines sit idle, and dispatch trucks leave half empty.

Manufacturing also runs on data that most other industries never have to think about. Bills of materials, routings, work centres, lead times, scrap rates, lot traceability. Every one of those has to be right before the system can schedule a single job.

Then there's the third shift problem. Office software gets adopted because everyone sits in the same building and sees each other struggle. A night shift operator learns the new system alone, at 2am, with no one to ask.

If you're still at the planning stage, this ERP implementation guide covers the phases and decision points that sit around the five challenges below.

The 5 ERP Implementation Challenges That Derail Manufacturing Projects

Challenge 1: Master Data That Was Never Clean to Begin With

This is the one that sinks the most projects, and it's almost always underestimated.

Your existing system has been running for a decade. Somewhere in it are three item codes for the same washer, a bill of materials that still lists a supplier who closed in 2019, and routings that reflect how the line was set up before the last reconfiguration. Nobody noticed, because experienced staff quietly worked around it.

The ERP won't work around it. It will schedule production against whatever you give it.

How to fix it:

• Start the data audit before you sign the contract. Pull item masters, BOMs, routings and supplier records into a spreadsheet and count the duplicates. This single exercise tells you more about your real project timeline than any vendor demo.
• Assign an owner to each data set. Not the IT team. The person who actually knows the parts, usually a production planner or a senior storeman.
• Fix the source, don't just clean the extract. If item codes are created ad hoc, cleaning the file once means the mess returns within a year. Put a naming standard and an approval step in place first.
• Validate BOMs against physical builds. Take your ten highest volume products and physically reconcile the BOM to what actually goes into the product. The gaps will surprise you.
• Migrate in waves and test each one. Load master data first, verify, then transactional history. Never load everything on one weekend and hope.

Automated deduplication and pattern matching help with large item catalogues, but they work properly only once someone has defined what 'correct' looks like. Tools speed up cleanup. They don't decide the rules. The data model matters here too, and this breakdown of ERPNext for manufacturing shows how BOMs, routings and work centres need to be structured before migration starts.

Challenge 2: Customising the ERP Instead of Fixing the Process

Every manufacturer believes their process is unique. Some of it genuinely is. Most of it is habit that hardened into policy because the old system couldn't do it any other way.

The pattern is predictable. During workshops, someone says 'that's not how we do it here,' a change request gets raised, and the modification list grows. Six months later the system is heavily customised, expensive to maintain, and impossible to upgrade without a project of its own.

Here's the trade-off worth being blunt about:

• Heavy customisation locks you out of upgrades. Every vendor release becomes a regression testing exercise instead of a routine update.
• It hides bad process rather than fixing it. If approval takes four signatures because of a problem from 2015, the fix is fewer signatures, not custom code.
• It multiplies support cost. Custom code has no vendor documentation and often only one person who understands it.
• It slows the project. Each modification adds specification, build, test and rework time.
• It rarely delivers the promised benefit. Most modifications get used far less than the person who requested them expected.

A workable rule: customise only where the process is genuinely a competitive advantage. If a competitor could copy it tomorrow and gain nothing, configure instead of customise.

Where the platform is extensible, that line is easier to hold. Open source systems handled by an Odoo ERP development team let you build genuine differentiators as clean modules rather than core code changes, which keeps upgrades survivable. Everywhere else, standard functionality wins on cost and longevity.

Challenge 3: The Shop Floor Never Bought In

Ask most manufacturers who was in the ERP selection workshops and you'll hear finance, operations management, IT and maybe purchasing. Ask who wasn't there, and it's the people who will use the system forty hours a week.

Then go-live arrives and a leading hand is asked to scan, confirm and back-flush on a terminal he's never seen, while the line is running.

Resistance on the floor is almost never about technology. It's about being handed a process that makes their job harder without anyone explaining why.

What works better:

• Put two operators on the project team from day one. Not as observers. As people who sign off on the transactions they'll perform.
• Train on the shop floor, not in a meeting room. Muscle memory forms at the terminal, standing up, in the noise.
• Build for the environment. Gloves, poor lighting, dust and cold rooms all matter. A screen designed for an office desk fails at a workstation.
• Cover every shift. Night and weekend crews need equal training time and a real escalation contact after hours.
• Translate where needed. Many Australian plants run multilingual crews. Quick reference cards in the right languages remove a whole category of error.
• Explain the why, once, properly. People accept extra scanning when they understand it's what makes traceability and stock accuracy possible.

Adoption is measurable. Track transaction compliance by shift in week one and you'll know exactly where the training gap sits. Worth asking about this when choosing an ERP partner, because plenty of implementers price training as an afterthought and never set foot on the floor.

Challenge 4: Integrating With Machines and Legacy Systems

ERP doesn't run a factory on its own. It sits alongside machine controllers, an MES if you have one, barcode and RFID hardware, quality systems, freight platforms and whatever custom database someone built years ago that turns out to be running a critical process.

Worth being clear on the boundary, because it causes constant confusion: ERP handles planning, purchasing, costing, inventory and orders. MES handles what happens on the line, minute by minute. When a project tries to make ERP do the MES job, scheduling accuracy usually suffers.

Integration is where budgets quietly blow out, mostly because the discovery work happens too late.

Do this instead:

• Map every system before vendor selection. Include the spreadsheets and the Access database. Especially the Access database.
• Identify which machines can actually export data. Older equipment may need a gateway or an operator entry step, and that changes the scope.
• Decide direction and frequency for every interface. One way or two way, real time or batch. Ambiguity here creates rework later.
• Build the awkward integrations first. The hardest one should be proven months before go-live, not the week of.
• Plan for failure states. What happens to production when an interface drops for two hours? There should be a defined answer, not an improvised one.

Middleware and workflow automation platforms are often the practical answer for older equipment that will never speak natively to a modern ERP, letting you connect the plant without replacing capital assets that still have years of life in them.

Challenge 5: A Cutover That Stops Production

The cutover is the highest risk moment of the entire project, and it gets planned around the finance calendar far too often. End of financial year looks tidy on paper. It's frequently the worst possible time for the plant.

You're switching systems while raw material is arriving, work in progress is sitting on the floor, and customers still expect their orders.

Steps for a cutover that doesn't cost you output:

• Choose the window based on production, not accounting. A genuine shutdown period beats a clean month end every time.
• Run a full dress rehearsal. Complete practice migration, timed, with the real team doing the real tasks. Anything that took longer than planned is your risk register.
• Count stock as close to cutover as possible. Every day between the count and the switch is a day of drift you'll spend weeks reconciling.
• Freeze changes early. No new modifications in the final weeks. Late changes are how tested systems become untested systems.
• Decide your work in progress approach. Either finish open jobs in the old system or migrate them deliberately. Half-migrated WIP creates months of costing confusion.
• Staff hypercare properly. Two to four weeks of on-site support across every shift, with a visible escalation path.
• Set a rollback trigger in advance. Define what 'bad enough to revert' means before go-live, while everyone is calm.

Platform choice changes the detail of these steps but not the principle. This Odoo implementation guide sets out what a staged cutover looks like in practice for Australian businesses.