Most writing about ERP and procurement assumes one ERP. Plenty of manufacturers do not have one.
They have two, sometimes three. An acquisition brought a second system that was never merged. A migration started, delivered half its scope, and stopped when the budget ran out or the sponsor left. A division was carved out and kept its own stack. However it happened, the result is the same: a buying process that crosses a system boundary somewhere in the middle, and nobody who can draw the whole thing on one page.
We spent four months inside exactly that — SAP alongside MFG/PRO at a US manufacturer, rebuilding their procurement operation. What follows is what we learned, and most of it was not about either product.
The systems are not the problem
Both SAP and MFG/PRO are capable. Neither was misconfigured in any way their own vendor would recognize as wrong. The documentation for each was adequate.
The problem is the space between them, and that space is not documented anywhere, because it was never designed. It accumulated. Somebody needed a purchase order raised in one system to be visible to a planner working in the other, so they solved it — with an export, a scheduled job, a shared report, or a person who checks both screens every morning. That solution worked. Nobody wrote it down, because at the time it was obvious.
Ten years later the person who built it has moved on, the export runs on a server nobody audits, and the process depends on it entirely.
The one we found
Purchase orders raised in SAP were exported into a spreadsheet and validated by hand before planners working in MFG/PRO could act on them. The process had grown over years and was no longer written down anywhere.
When the export failed or ran late, procurement and planning spent the morning hunting for transactions that existed perfectly well — just not yet in the system where somebody needed them.
What this costs, in ways that do not show up as costs
A dual-ERP procurement process leaks in specific, recognizable ways.
Data means different things on each side. A part number, a supplier record, a unit of measure — each system has its own version, and they agree until they do not. Reconciliation becomes somebody's recurring job.
Reporting stops at the boundary. You can report accurately on what happens inside each system. Reporting across both requires somebody to assemble it.
Nobody owns the whole process. The people who know SAP know their end. The people who know MFG/PRO know theirs. The handoff belongs to neither, so when it breaks the first hour goes on working out whose problem it is.
Reporting was the worst of the three for our client. Each system reported on itself accurately enough. Management reporting needed both, which meant somebody consolidating by hand — several hours every week, and visibility into supplier issues, inventory shortages and procurement bottlenecks that arrived after the fact rather than in time to act on. By the point a discrepancy surfaced in a report, the window to do anything useful about it had usually closed.
Knowing the product is not knowing the installation
This is the part most transition plans get wrong, and it is worth stating plainly: experience with SAP does not mean experience with this SAP.
Every ERP of any age is configured to the business that runs it. The field that means one thing in the manual means something else here because of a decision made in 2014 for a reason that may no longer apply. Custom fields carry meaning that exists nowhere in the schema. A workflow has an approval step that looks redundant and is not, because of an audit finding from years ago.
A team that assumes product knowledge transfers will be confidently wrong for about six weeks, which in procurement is long enough to stop a production line.
How we approached it
We mapped both environments before proposing anything. Not the products — the installations. What each system held, how the data was shaped, where a process crossed between them, and what happened to the data on the way across.
The crossings were the priority. For each one: what triggers it, what moves, what validates it, what happens when it fails, and who notices.
25+
crossings between the two systems
4
months mapping both installations
Most
had no monitoring, several had no owner
Purchase order creation, planning updates, supplier master maintenance, inventory reconciliation, receiving transactions, management reporting — each one a point where the process left one system and had to arrive intact in the other.
Then we wrote it down, which sounds trivial and was not. Much of this knowledge existed only in people's heads, and those people were busy doing their jobs. We built questionnaires and validation documents rather than waiting to be taught, and drove the sessions ourselves.
What we would tell someone starting this
Map the seams before the systems. You will be tempted to understand each ERP thoroughly first. Resist it. The crossings are where the risk is, and they take longest to uncover because nobody thinks to mention them.
Find the undocumented integrations early. Ask what people check every morning. Ask what breaks when somebody is on vacation. Those questions find things that architecture diagrams do not.
Do not assume the second system is the legacy one. It is easy to treat the older or smaller system as the one being phased out. That assumption was wrong here. SAP was regarded as the primary ERP and MFG/PRO as the system on its way out — but discovery found MFG/PRO still carrying several business-critical planning and operational processes that had never been migrated across. Removing or bypassing it would have broken workflows nobody had counted, in a business where broken workflows stop production.
Validate against the real thing, for longer than feels necessary. We ran a full month of validation before go-live, working real processes against live systems. In a dual-ERP environment that is not caution. It is the minimum.
The point
The point
Dual-ERP environments are usually treated as a problem to be fixed — consolidate, migrate, simplify. Often that is right, eventually. But eventually is expensive, and meanwhile procurement still has to run.
There is a lot of ground between living with it and migrating everything, and most of the value sits there: document the seams, monitor the crossings, give the whole process an owner. None of that requires a migration budget, and all of it makes the migration easier when it finally comes.
Written by
Procurement Lead, Modern Signal
Modern Signal's procurement practice, running sourcing and supply chain operations for manufacturers.
