ERP for Manufacturing: How to Choose the Best System for Your Company

A system that worked well for a single production site, a few dozen SKUs and relatively simple planning may no longer be enough as the business grows. As the number of orders, products, locations and process exceptions increases, so does the amount of data that needs to be collected, verified and passed between teams.

The problem becomes visible when sales works with different information than production, planners manually combine data from several sources, warehouse stock is updated separately from shop-floor activity, and the actual cost of an order can only be calculated once production is complete.

ERP for manufacturing is designed to bring these dependencies together. It connects information about orders, materials, resources, production, quality, warehousing and finance, allowing decisions to be based on consistent data.

This does not mean that one system should replace every application used across the plant. In a modern architecture, ERP more often acts as the central business layer working alongside MES, WMS, quality systems, engineering tools and automation platforms.

This is why choosing an ERP system for a manufacturing company starts long before comparing feature lists. The first step is to understand the production model, data flows and the processes that actually need to change.

When does a manufacturing company need an ERP system?

There is no single point at which every manufacturing business should implement ERP. A much better reference point is how well current processes are working.

If existing tools still allow the company to plan production efficiently, control materials, calculate costs and share reliable information between departments, replacing the environment simply because “a company should have ERP” makes little sense.

The need for change usually appears when the organisation starts losing control over dependencies between processes.

Signs that the current environment is no longer sufficient

It is worth taking a closer look at the current operating model if:

• order, inventory and production data is stored across different systems or spreadsheets;
• the same information is entered manually by several departments;
• planning requires data to be combined from multiple sources;
• it is difficult to quickly determine the actual cost of fulfilling an order;
• production, warehouse and sales teams work with different versions of the same information;
• the company struggles to measure resource utilisation or delivery performance;
• a growing number of products or orders causes a disproportionate increase in administrative work;
• new plants, production lines or business units are difficult to incorporate into the existing operating model.

Some of these problems can be worked around for a long time using additional spreadsheets, manual reconciliations and the knowledge of individual employees. As the business scales, however, the cost of this approach increases, along with the risk that a critical process depends on someone manually passing the right information at exactly the right time.

ERP does not always mean replacing the entire IT environment

A common mistake in modernisation programmes is to assume that implementing ERP means replacing every other system.

It does not.

A company may continue using a specialist MES, WMS, PLM, CAD platform or quality management solution. The key is to establish:

• which system is the source of a particular piece of information;
• where decisions are made;
• which data needs to flow between applications;
• how quickly it needs to be updated;
• who is responsible for its quality.

ERP then becomes part of a broader architecture rather than a standalone platform expected to solve every organisational problem.

How does ERP support the manufacturing process from order to fulfilment?

The easiest way to understand the role of ERP is to look at the full lifecycle of an order rather than individual modules.

In simplified form, the process may look like this:

order → material requirements → planning → production → quality control → warehouse → shipment → costing and analysis

In a fragmented environment, these stages may be handled by separate applications, spreadsheets and teams. ERP helps connect their data into one coherent process.

Material and resource planning

Once an order is received, several basic questions need to be answered: what do we need, how much do we already have, what is missing and when must the missing materials become available?

The system can bring together information such as:

• requirements resulting from the production plan;
• the product’s bill of materials;
• current inventory levels;
• purchase orders already placed;
• expected delivery dates;
• component availability for other production orders.

Material planning therefore stops being an isolated activity carried out separately by warehouse, purchasing and production teams.

Production scheduling and execution

Having the required materials available does not necessarily mean an order can be completed on time.

The plan also needs to account for:

• machine availability;
• workforce capacity;
• operation sequences;
• changeover times;
• production capacity;
• order priorities;
• dependencies between operations.

In more complex manufacturing environments, the production plan may therefore draw not only on ERP data but also on MES or advanced scheduling systems.

ERP provides the business context: which customer order is being fulfilled, why it has a particular priority, which materials are required and how execution affects costs and delivery dates.

Quality, traceability and production costing

Production does not end when an operation is completed.

In many industries, organisations also need to know:

• which batch the material came from;
• which production line was used;
• which quality checks were performed;
• whether any non-conformities occurred;
• how much material and time were actually consumed;
• what the final cost of production was.

Traceability — the ability to reconstruct the history of a product, component or batch — may be important for both operational and regulatory reasons.

Production data then flows back into the business layer. This makes it possible to compare plan versus actual performance, analyse deviations and use the results in future decisions.

How does the production model affect ERP selection?

Not every plant plans production in the same way. A company manufacturing high-volume products for stock has very different requirements from a business engineering individual machines for specific customers.

This is why the production model is one of the first areas to assess before selecting an ERP system.

Make-to-Stock – manufacturing for inventory

In the MTS (Make-to-Stock) model, production is primarily driven by forecast demand. Products are manufactured before a specific customer order is received and are held in inventory.

The following areas become particularly important:

• demand forecasting;
• material requirements planning;
• production batch sizes;
• inventory turnover;
• raw material availability;
• minimum and safety stock levels.

An inaccurate forecast can result either in shortages or excessive inventory. The ERP system should therefore connect sales planning, inventory, purchasing and production capacity.

Make-to-Order – manufacturing to customer order

In the MTO (Make-to-Order) model, production begins after a customer order has been received.

This places greater emphasis on:

• resource availability at a specific point in time;
• responsive scheduling;
• changing priorities;
• shorter production runs;
• product variants;
• on-time delivery.

The flow of information between sales and production also becomes critical. A promised delivery date cannot be set independently of current plant capacity and material availability.

Engineer-to-Order – project-based manufacturing

ETO (Engineer-to-Order) goes one step further. The product is designed from scratch or significantly modified in response to a specific customer requirement.

In this model, ERP needs to work closely with the engineering process.

Important capabilities may include:

• evolving BOM structures;
• document version control;
• project management;
• project cost tracking;
• integration with PDM or PLM;
• links to CAD;
• engineering change control.

Separating engineering data from purchasing and production quickly creates problems in this type of environment. A component change in engineering documentation should be reflected correctly in downstream processes.

It is also important to remember that labels such as MTS, MTO or ETO are not a ready-made system specification. The production model is a starting point for defining actual functional and integration requirements.

What functions should a manufacturing ERP include?

The scope should reflect the organisation’s processes. However, certain areas commonly form the core of a manufacturing ERP environment.

A feature list alone says relatively little about the quality of a system.

Two platforms may both include MRP but handle exceptions differently. Both may support scheduling while differing significantly in how they account for real production constraints. Both may offer APIs, but one may be much easier to integrate into the existing architecture.

This is why requirements should be described through specific business scenarios, not simply by checking whether a module exists.

ERP, MES, WMS and other systems – how to build a coherent manufacturing ecosystem

ERP does not need to know everything. It does need to know enough for the right information to move between processes.

In larger manufacturing environments, the architecture often consists of several specialist layers.

ERP and MES – planning versus production execution

ERP primarily operates at the business level: orders, materials, costs, planning, purchasing and finance.

MES (Manufacturing Execution System) operates closer to the shop floor. It may collect information about production operations, order status, workstation activity and actual manufacturing performance.

The greatest value comes when the two environments exchange data.

ERP can send a production order and plan to MES, while MES can return information about:

• completed operations;
• material consumption;
• labour or machine time;
• quantities produced;
• downtime;
• scrap;
• deviations from plan.

This makes it possible to compare the plan with what is actually happening on the shop floor.

ERP and WMS, QMS, PLM/PDM and CAD

The same principle applies to other systems.

WMS can manage detailed warehouse operations.

QMS structures quality management processes.

PLM and PDM support product lifecycle and engineering data management.

CAD remains the working environment for designers and engineers.

There is no need to move all of this functionality into ERP. What matters is determining which data should be shared and which system is its source of truth.

API integration, machine data and IoT

More advanced environments may also include machine data, SCADA systems and IoT devices.

This does not mean that every ERP platform should connect directly to every machine.

However, the more important real-time information becomes for planning, maintenance or quality, the more important efficient data exchange between operational and business layers becomes.

This may involve integration through MES, middleware, APIs or a data platform.

The key question is therefore not: “How many systems can we connect to ERP?”

A better question is:

“What data is needed to make a particular decision, and where should it come from?”

How does ERP data translate into manufacturing performance?

Implementing ERP does not automatically make a plant produce more or operate at a lower cost.

It can, however, create the conditions for improved performance if it provides reliable data and supports well-designed processes.

The mechanism is relatively straightforward:

data → visibility → decision → adjustment → result

If a planner can see current inventory, material availability and production load, they can react more quickly to changes in orders.

If planned times are compared with actual execution times, it becomes easier to identify areas where deviations occur repeatedly.

If quality, production and cost data are connected, the organisation can determine whether an issue is associated with a specific product, supplier, batch or operation.

ERP can therefore have the greatest impact in areas such as:

• resource utilisation;
• inventory levels and availability;
• on-time delivery;
• information flow;
• data quality;
• cost control.

However, the quality of input data remains a prerequisite. If item data, BOMs, operation times or stock levels are outdated, the system may process inaccurate information faster — but it will still be inaccurate.

Data preparation is therefore not a technical add-on to an ERP project. It is one of the conditions for effective planning, reporting, automation and the later use of AI.

How to calculate the real cost of ERP: the licence is only part of TCO

When comparing ERP solutions, it is easy to focus on the licence fee or monthly subscription.

That is only one part of the total cost.

A more useful perspective is TCO — Total Cost of Ownership, meaning the full cost of owning and operating the solution over a defined period.

TCO may include:

• licences or subscriptions;
• infrastructure;
• pre-implementation analysis;
• configuration;
• integrations;
• data migration and cleansing;
• development of additional functionality;
• testing;
• training;
• maintenance;
• future upgrades;
• further system development.

The scale of customisation is also important.

Adapting ERP to a process that genuinely differentiates the organisation may be justified. Problems begin when every difference from the standard system leads to another code modification.

As customisations accumulate, the cost of testing, maintenance and future upgrades may increase.

For every non-standard requirement, it is therefore worth asking:

does this process genuinely create business value or represent a business necessity, or can it safely be aligned with the standard system?

Cloud, on-premise or hybrid?

The infrastructure model also affects TCO, but the comparison cannot be reduced to saying that one option is always cheaper.

In a cloud environment, part of the infrastructure and operational cost shifts into a service model. Scaling the environment and rolling out updates may also be easier.

With on-premise, the organisation retains greater responsibility for its own infrastructure, maintenance, security and development.

A hybrid model allows the two approaches to be combined where required by processes, existing architecture or regulatory constraints.

The decision should therefore consider:

• TCO;
• security;
• regulatory requirements;
• integrations;
• operational needs;
• internal IT capabilities;
• the organisation’s technology strategy.

Learn more: ERP data security – key protection principles

How to choose an ERP system for a manufacturing company

The safest place to start is with the organisation itself, not a list of products available on the market.

A good sales presentation can demonstrate what a system is capable of. It will not automatically answer whether that solution fits the way a particular organisation operates.

1. Map the processes and problems the system needs to address

The first step is to describe both the current process and the desired target model.

Two perspectives are useful:

As-Is – how the process works today.

To-Be – how it should work after the change.

IT involvement alone is not enough. Process owners should also take part: people responsible for production, planning, logistics, finance, quality and technology.

Their task is not only to list expected features, but above all to identify problems:

• where delays occur;
• which data is entered repeatedly;
• where errors appear;
• which decisions are made too late;
• where accountability or visibility is missing.

2. Define functional and integration requirements

The requirements should then be divided at least into:

• critical;
• important;
• optional.

In addition to functionality, the organisation should consider:

• the number of users and locations;
• data volumes;
• systems that need to be integrated;
• security standards;
• regulatory requirements;
• cloud/on-premise model;
• reporting;
• scalability;
• how the solution may need to evolve in the coming years.

The requirements list then starts to describe the architecture of the future environment rather than just the system interface.

3. Prepare RFI/RFP documentation and compare solutions using the same criteria

If several vendors are answering completely different questions, comparing proposals quickly becomes a comparison of presentations. An RFI or RFP helps structure the process and gather information in a consistent format. The objective is not to create a document containing hundreds of requirements simply because it is possible.

The important part is to identify the scenarios that genuinely differentiate the solutions.

4. Validate the system using real business scenarios

A demo becomes much more valuable when the vendor demonstrates a real customer process rather than giving a standard tour of every module.

For example, the organisation can ask the vendor to demonstrate:

• handling an unusual customer order;
• changing a BOM;
• dealing with a missing component;
• rescheduling production;
• batch handling;
• costing a specific production order.

For particularly complex projects, a Proof of Concept may also be useful. It is not always necessary, but it can reduce uncertainty when a critical process is non-standard or an integration is particularly demanding.

5. Assess the implementation partner, not just the product

ERP will operate within the organisation for years. This means that the capabilities of the team implementing and later developing the platform matter just as much as the software vendor itself.

Areas worth assessing include:

• experience in manufacturing environments;
• integration capabilities;
• understanding of business processes;
• project delivery model;
• availability of specialists;
• approach to post-go-live support;
• ability to support further development.

MINDBOX works with ERP in this broader model: from implementation and integration through configuration and further development to ongoing support and Managed Services. The portfolio includes Epicor Kinetic, Epicor iScala and supporting solutions such as CPQ.

What does an ERP implementation in a manufacturing company look like?

An ERP implementation project should not start with configuring screens. The first step is to define the scope of change.

Analysis and solution design

At this stage, the team:

• maps processes;
• gathers requirements;
• performs a Fit & Gap analysis;
• defines integrations;
• establishes the architecture;
• defines the scope of the first rollout.

Fit & Gap analysis helps determine which requirements are covered by the standard system, where configuration is sufficient and where a process change, integration or additional development is required. The way subsequent phases are delivered is also influenced by the chosen ERP implementation methodology.

This is an important stage because a significant proportion of the future cost and complexity of the system is determined here.

Data migration and preparation

Data migration should not simply mean copying everything from the old system.

The organisation needs to determine:

• which data is required for day-to-day operations;
• which historical data needs to be available in the new environment;
• what can remain in an archive;
• how duplicates will be removed;
• how item codes and reference data will be standardised;
• who will validate data accuracy.

This is also a good point to assign data ownership.

The better this stage is prepared, the lower the risk that the new system will go live with problems inherited from the previous environment.

Configuration, integrations and testing

Testing should cover more than individual modules.

If a business process starts in sales, passes through planning and warehousing, moves into production and finally reaches finance, the organisation needs to test the entire end-to-end process.

This is where issues that remain invisible when individual functions are tested in isolation are most likely to emerge.

Go-live and stabilisation

Production go-live is not the end of the implementation.

The first few weeks usually require:

• user support;
• error monitoring;
• configuration adjustments;
• integration monitoring;
• data-quality verification;
• monitoring of key KPIs.

The organisation should also define in advance how incidents and changes will be handled once the main implementation project is complete.

ERP after go-live – maintenance, development and automation

The business does not stop changing on the day ERP goes live.

New products, locations, customer requirements, regulations, systems and ways of working will continue to appear. The ERP environment therefore needs to evolve with the organisation.

Over time, this may require:

• new reports;
• integrations;
• additional modules;
• automation;
• upgrades;
• adaptations to process changes;
• performance improvements;
• rollout to additional companies or plants.

Maintenance should therefore mean more than reacting to incidents. In a mature model, ERP maintenance and development also covers controlled evolution of the environment.

When should ERP be extended, and when should another solution be integrated?

Not every new requirement needs to be implemented directly in ERP.

In broad terms:

• a process that belongs to the organisation’s core business model will often remain in ERP;
• detailed production execution may belong in MES;
• advanced warehouse operations may remain in WMS;
• complex product configuration may require CPQ;
• a simple dedicated workflow may be built using low-code;
• repetitive activities across applications may be good candidates for RPA.

MINDBOX follows a similar approach to modernisation: not every new requirement justifies replacing an existing system. Integration or gradual extension of the environment can often be a better option, while maintaining operational continuity.

AI in ERP – another layer, not the starting point

Artificial intelligence is also creating new opportunities around ERP.

It can support areas such as:

• data analysis;
• forecasting;
• anomaly detection;
• document processing;
• natural-language access to knowledge;
• agents handling selected parts of business processes.

But AI will not fix inconsistent data or a poorly designed process.

If information about materials, products or orders is incomplete, an AI model cannot turn it into a reliable basis for decision-making.

AI should therefore be treated as another layer of a mature ERP environment: first data, processes and integrations, then increasingly advanced automation.

Frequently asked questions about ERP for manufacturing

ERP should evolve together with the company’s processes

Choosing an ERP system for manufacturing is about much more than selecting licences and modules. The organisation is effectively deciding how information will flow between sales, planning, production, warehousing, quality and finance for years to come.

A well-designed environment therefore needs to support more than today’s processes. It should leave room for new integrations, additional plants, changing production models, automation and new ways of using data.

MINDBOX supports organisations from requirements analysis and ERP implementation through integration and further development to ongoing maintenance under a Managed Services model. If you are planning to replace your ERP system, or your current environment is starting to limit the growth of manufacturing operations, a good starting point is to analyse processes, data and integrations before creating a shortlist of specific products.