ERP Selection for Multi-Plant Manufacturers - What Changes When You Run Three Plants
Updated: 11 hours ago
Most ERP systems can run one plant. The question for a manufacturer with three or more is whether the system can run the network: plants that make different things in different ways, share components and customers, and report to one finance team. That is where selections go wrong. A product that looks strong in a single-plant demonstration can struggle with interplant transfers, multi-site planning or costing that crosses legal entities, and those gaps usually surface after go-live.
This guide covers what changes in an ERP selection for a multi-plant manufacturer, the decisions to make before you look at software, and the demonstration scenarios that separate a true multi-site manufacturing ERP from a single-site system with a site field added.
What changes at three plants
Plants work differently - One plant runs engineer-to-order projects, another repetitive production, a third a mix. The system has to support each mode without forcing all of them into one.
Material moves between plants - Components made in one plant are consumed in another. Transfers, in-transit inventory and transfer prices have to live in the system, not in spreadsheets.
Planning crosses sites - Demand at one plant creates requirements at another. Multi-site planning, sourcing rules and capacity at each site decide whether planners trust the system or work around it.
Costing crosses entities - When plants are separate legal entities, intercompany sales, transfer pricing and the elimination of internal profit on consolidation become part of every month-end.
One customer, several plants - Customers expect one order, one delivery promise and one invoice, even when the product ships from two sites.
Shared services and local control - Purchasing, finance and customer service are often shared, while quality, maintenance and scheduling stay local. Security, approvals and reporting have to fit that split.
Decide the operating model before you see software
One instance or several - A single instance gives one set of master data and one view of the network. Separate instances give plants autonomy at the cost of integration and consolidation work. Most multi-plant manufacturers are better served by one instance, but the choice should follow the operating model, not a vendor's architecture.
A global template with named exceptions - Decide which processes must be the same everywhere, such as item numbering, the chart of accounts, the costing method and quality records, and where plants may differ, such as scheduling and shop-floor data collection. Write the exceptions down, because every one of them costs money to build and support.
Master data ownership - Decide who owns the item master, bills of material, routings and suppliers across plants. Harmonizing part numbers is often the longest task in the whole program, and it belongs on the plan now.
Plant-floor systems - Decide which plants keep their MES, data collection or scheduling tools, and what the ERP must exchange with them.
Write requirements for the network, not the headquarters plant
Requirements workshops should include every plant, not only the largest one, and plant controllers as well as plant managers, because costing differences between plants are where the surprises hide. Run them by process across plants, so the differences come out in the room, and write each requirement as a scenario that names the plants involved. "Plant B consumes a subassembly made in Plant A; the transfer cost rolls into Plant B's product cost and is eliminated on consolidation" can be demonstrated and scored. "Multi-site capability" cannot.
Demonstration scenarios that expose a weak fit
Give every finalist the same scenarios on your own data, and have each plant's people score the parts that affect them.
Interplant transfer - A transfer from Plant A to Plant B, with in-transit inventory, receipt, and the cost landing correctly at both sites.
Cross-plant fulfillment - A customer order entered at one plant and shipped from another, with one confirmation and one invoice to the customer.
Multi-site planning - A demand spike at one plant that creates requirements at a supplying plant, visible to both planners.
Shared purchasing - One supplier agreement with releases and receipts at several plants, and the spend visible centrally.
Different manufacturing modes - An engineer-to-order job at one plant and a repetitive schedule at another, in the same system.
Month-end across entities - Intercompany invoices, eliminations and a consolidated close, shown end to end.
Traceability across sites - A lot or serial number followed from a supplier through two plants to the customer.
A finalist that handles these well at three plants will usually handle a fourth. One that struggles with them in a scripted demonstration will struggle more in production.
Choosing the implementation partner for a multi-plant rollout
Rollout experience - Ask for programs where a template was built at a pilot plant and rolled out in waves, and speak with those clients.
Named people - The partner's manufacturing and costing leads matter more than the account team. Meet them before you sign.
A credible wave plan - The plan should say which plant goes first and why, how long each wave takes, and how the template will be protected from plant-by-plant customization.
Partner selection deserves the same rigor as software selection; here is how we approach implementation partner selection.
Common mistakes
Letting the headquarters plant write the requirements - The other plants discover the gaps during testing, when changes cost the most.
Demonstrating one plant at a time - Every finalist looks good in a single-plant demonstration. The interplant scenarios are the real test.
Treating part-number harmonization as a data task - It is a business decision about how the plants will work together, and it takes months.
Assuming single-site experience carries over - Rolling a template out across plants is its own skill, for the partner and for your team.
What this looks like in practice
In a recent selection for a multi-site industrial fabricator, one site ran engineer-to-order projects and another more repeatable production. The requirements, the RFP and the scripted demonstrations were built around that difference, and the program went from RFP to signed contracts in under three months. We ran a similar program for a multi-site contract manufacturer. Both followed the same ERP software selection method.
Frequently asked questions
Should every plant run the same ERP? Usually, on one instance with a common template, unless the plants are run as separate businesses or are likely to be sold.
Should we go live at all plants at once? Rarely. Most multi-plant programs build the template at a pilot plant and roll out in waves, so later plants benefit from what the first one learned.
How long does an ERP selection take for a multi-plant manufacturer? Twelve to twenty weeks. More plants and more modes of manufacturing push it toward the upper end, mostly because the requirements workshops have to include every site.
Do we need an MES as well as an ERP? Not always. Many plants run well on the ERP's own shop-floor functions, while plants with high-volume, highly automated or regulated production often need a separate MES. Decide plant by plant, and make the exchange between the two part of the requirements.
What if one plant works very differently from the rest? Document it as an explicit exception and test it in the demonstrations. If no finalist supports it well, decide whether that plant's process should change before you decide on the system.
If you run several plants and the ERP question is on the table, talk to John about your ERP program.
