Replace Your ERP or Connect What You Already Have?

Follow one troublesome order

The production planner exports an order list from the ERP every morning. Purchasing maintains supplier confirmations elsewhere. Quality releases material in another record. By the afternoon, the schedule is already being corrected in a spreadsheet. When leadership asks why the ERP cannot provide a reliable answer, the team may reasonably propose a replacement. It is worth finding out exactly which answer is missing before starting that project.

Take one delayed order and reconstruct the sequence. Which record held the promised date? When did a supplier change its commitment? Who knew that stock was on hold? At what point did the planner learn that the original plan could no longer work? Check the records with the people who made the decisions. This investigation may reveal a weak ERP, an absent connection, unclear responsibility or several problems at once.

Excellence industrielle's discussion of CEI Montréal joining NUMERI frames the choice in similar practical terms: clarify whether existing software should evolve or a new ERP is needed. It does not supply a universal answer. The decision depends on the capability the operation lacks and the cost of maintaining a credible solution over time. [1]

Separate four kinds of problem

First, examine the records themselves. Duplicate item codes, unreliable units of measure and obsolete routings will create trouble in a replacement as well as the current system. Identify who can correct each definition and how downstream users learn of the change. Migration is an opportunity to clean records, but moving them does not make them true.

Next, test the handoffs. The ERP may hold an accurate purchase-order date while the planner never sees its revision. An integration could expose that change at the point of scheduling, provided the interface, permissions and ownership are suitable. Conversely, a spreadsheet may contain information that no system formally owns. Connecting it without resolving that ownership can distribute conflicting versions faster.

A third category is missing capability. Perhaps the business genuinely needs a planning, costing or traceability function that the current software cannot support within a maintainable design. Finally, consider the platform's operating condition: support availability, security, access controls, recoverability and dependence on a person who alone understands its customizations. A system can perform today's transactions and still carry unacceptable operating risk.

Test the smallest meaningful integration

Suppose a hypothetical assembly business has reliable orders and purchasing transactions, but planners repeatedly telephone buyers for current component arrival dates. A bounded experiment could connect confirmed supplier dates and material hold status to a view of affected orders. The useful test is whether a planner can recognize and resolve a delivery conflict earlier, with the source and age of the information visible.

Keep the existing ERP authoritative for the transactions it already controls. Define each shared field, its source, update direction, allowed delay and correction owner. Prefer supported interfaces or a controlled export before considering fragile screen-based workarounds. Confirm licensing and vendor support implications. A connection that depends on an undocumented database assumption may become an expensive permanent exception.

Test failures as deliberately as normal updates. What happens when the source is unavailable, a code is missing, or an update arrives twice? Show stale data as stale, retain an error queue and decide who reconciles it. Do not let a failed refresh look like a supplier confirming that nothing changed. Start without automatic operational writeback where that allows the team to validate meaning and consequences safely.

Recognize when replacement has the stronger case

Replacement deserves serious consideration when the missing capability is central to ordinary work and cannot be added without proliferating exceptions. It also deserves attention when support or recoverability is no longer credible, or when the cost of maintaining current customizations overwhelms their value. Document the evidence rather than labeling a system outdated because its interface looks old.

Ask replacement vendors to demonstrate your actual decisions using representative records. Include changed orders, partial receipts, quality holds, rework and corrections. A demonstration of a clean sales order becoming an invoice does not establish that the proposed configuration can handle your plant's difficult handoffs. Separate standard functionality, configuration, customization and promises of future development.

Find out what remains outside the replacement. Machine connections, product definitions, customer portals or specialized production software may still need integration. Retiring an ERP does not retire every interface. Map what will be kept, changed and removed, with owners for each transition. A credible replacement proposal explains both the new system and the operation that must continue while it is introduced.

Compare complete operating costs and disruption

Use the same planning horizon and scope for both options. Include licenses, implementation, data cleanup, integrations, testing, internal staff time, training, support and the effort of keeping the solution current. Replacement also needs migration rehearsals, cutover preparation and a plan for historical records. Integration needs monitoring, interface maintenance and a clear exit path if the underlying system later changes.

Keep the assumptions visible rather than collapsing everything into a single confident savings figure. Estimate separately the cash that could be avoided, the capacity that could become usable and the management effort that may be reduced. If the team still cannot establish a trustworthy baseline for missed commitments, mark the uncertainty and identify what observation would reduce it.

Consider disruption as an operating scenario. Which orders can be processed during cutover? How will balances and open transactions be reconciled? Who can pause the transition, and what makes rollback practical? For an integration, ask the equivalent questions about a failed connection. A cheaper proposal is not comparable if one option includes recovery and the other assumes it will never be needed.

Give the decision an owner and a stopping point

Use the accompanying decision brief to record the evidence, options, unresolved questions and agreed decision conditions. Set an observation window appropriate to the process: it should include the relevant order variations and exceptions, not merely a quiet demonstration day. Decide what result would support expanding an integration, changing its scope or choosing replacement instead.

Quindart begins by connecting the business question to the information and people behind it. Sometimes that leads to a small interface; sometimes the existing foundation no longer fits. The aim is to leave the factory with a maintainable way to make its decisions, rather than a new system whose gaps the same people must continue bridging by hand.