The tidy diagram shows one ERP at the centre of the enterprise. The reality, in most organisations above a certain size, is several. An acquisition arrived with its own platform. A region standardised differently. A division runs something specialised because its industry demanded it. Consolidation was planned, then deferred, and the estate settled into a shape nobody designed.

This is the normal condition, not a failure state. But it has consequences for automation that are usually discovered late.

The cost of per-system automation

When automation is procured per platform, the organisation ends up owning several parallel implementations of the same process. Each has its own rules, its own exception handling, its own reporting and its own upgrade path. The vendor list grows, and so does the number of places where a policy change has to be made.

The subtler cost is governance. If accounts payable behaves one way in one system and another way elsewhere, the control environment is no longer uniform. Internal audit finds this quickly, and the remediation is rarely cheap.

Separating what varies from what does not

The useful observation is that the business process is far more consistent across an estate than the technology is. A three-way match is conceptually the same exercise regardless of platform. Vendor onboarding asks for broadly the same evidence and the same checks. What differs is the mechanics: the object model, the interface style, the terminology, the way an approval is represented.

That split suggests the architecture. Model the process once, in terms the business recognises. Keep the platform-specific mechanics in a thin, replaceable layer underneath. The agent reasons about the invoice and the tolerance; the adapter knows how this particular system wants to be written to.

What this buys

  • Policy in one place. A tolerance or approval change is made once and applies everywhere, which is what auditors expect and what most estates cannot currently deliver.
  • Comparable reporting. Exception rates and cycle times mean the same thing in every entity, so they can be compared without a reconciliation exercise.
  • Consolidation stops being a blocker. If a platform is eventually retired, the process definition survives and only the adapter is replaced.

The honest caveats

This is not free. A shared process model requires the organisation to agree what the process actually is, and that agreement is often the hardest part of the programme because it surfaces genuine regional differences that had been comfortably invisible. Some of those differences are legitimate, driven by statutory requirements, and the model has to accommodate them rather than flatten them.

It also demands real depth in each underlying platform. An adapter written by people who have not run a live implementation on that system will be wrong in ways that only appear at volume.

But the alternative, rebuilding the same process once per ERP and governing each separately, is a cost that compounds quietly for years. Estates do not get simpler on their own.