The case for harmonisation is usually sound. The question is whether the design underneath it is.

The Business Case Is Convincing. The Operating Reality Often Is Not.

Every group-level board that approves an SAP harmonisation programme is making a rational decision. Having a single shared SAP template, shared master data, and consistent shared reporting across a conglomerate’s Business Units (BU) should significantly lower operating model costs across the group.

Hard to argue with that logic. The allure of one development round and a single Systems Integrator (SI) only strengthens it. 

The key issue is not the goal. It is an assumption buried in the business case: that all the Business Units share enough operational logic to use a single process template. 

It’s very rare that they do.

Regardless, harmonisation programmes often proceed anyway, and without a strong governance structure and programme management, they quickly derail.

One Template Across Multiple Businesses Rarely Produces One Outcome

Consider a leading global group in the aerospace industry running three very different business units side by side: 

Business Unit A – Makes complex engineered products to customer order. 

In this BU, Lead Times are long, every order is different, and planning logic is driven by the contract rather than by stock.

Business Unit B – Assembles products from components on a six-week cycle. 

Here, demand is predictable and follows its own rhythm in production planning, capacity management, and component procurement.

Business Unit C – Sells spare parts.

This BU is characterised by high SKU count, seasonal fluctuations, and customer expectations shaped by consumer goods, where customers expect their orders to be delivered ASAP, usually services from current inventory.

Three businesses. Three fundamentally different planning models. Three different relationships between demand, production, and inventory.

The template reflected the operating logic of Business Unit A – the dominant BU, as is often the case – pushing the assembly business into a planning model built for something else entirely, and forcing the spare parts business to work with a near-inverse planning logic of what it needs. Both businesses may have been live on SAP, but neither was being served by it. 

Within months, manual workarounds were layered on top of the SAP template to try to remedy deteriorating service. The result: non-standard workflows hardwired into daily operations, and a system that staff had already learned not to trust.

This was not an implementation failure. It was a design flaw, and a visible one, before a single line of code was written.

When Shared Foundations Become Structural Constraints

TThe problem does not stop at process design. It moves into the system’s shared foundations: the common rules, data structures, and configuration that different business units now depend on. This is no longer just a process “misfit”, but rather a structural engineering problem that compounds with every passing month.

BRF+ rules, Business Partner data, and planning settings stop being local design choices. A change made for one unit can constrain another. Customisations introduced to make the template work for Business Unit A begin to limit Business Unit B. Design decisions drift towards the lowest common denominator, not because that is right, but because it is the only answer no one will block.

This shared-foundation problem is more acute in S/4HANA than in earlier SAP versions. The simplified data model consolidates business logic into fewer, more central objects. When the template is right, this is an efficiency gain. When it is not, the blast radius of any shared-object change is larger, and the interdependencies run deeper.

Then there is the shared build-and-release path. When one business unit is mid-development, another may be unable to make an urgent change without affecting work already underway. In programmes where business units are live, building, and rolling out simultaneously, this is not an exception. It is a routine operating constraint. Queues build, timelines slip, and each unit begins to experience the others as a source of delay.

This is exactly where governance matters. It cannot turn incompatible operating models into a coherent shared template after the fact. Its value is earlier and more consequential: recognising where process logic genuinely differs, forcing the right architectural boundaries before configuration begins, and keeping those decisions intact across business units, providers, and rollout phases.

Where Design Weakness Becomes Programme Cost

Most programme business cases treat go-live as the point where value is realised. In reality, it is the moment the controlled test conditions give way to operational reality, when design decisions that looked manageable in workshops become expensive in production.

Once the first unit is live, the same structural weakness reappears in a different form. A live business unit may need an urgent correction, but the relevant change sits inside a shared release path still being used by another unit that is not yet live.

In rollout, the risk shifts again. A configuration change required for the next BU go-live can break a process that another unit has been running cleanly for six months. Cross-BU regression testing only happens if someone designed it, resourced it, and owns accountability for it. 

That accountability does not sit with the SI provider. They deliver what they have been contracted to deliver. The cross-programme view belongs to the governance layer, and in programmes that fail, that layer is either absent or lacks the authority to enforce anything.

We have seen this dynamic before, the tendency of large programmes to treat SI providers as both architect and implementer, and the structural blind spot that creates (Blind Spot Ahead: The Iceberg That Sinks SAP Projects and Businesses [Hyperlink]). 

The consequences follow a predictable pattern: scope grows quietly, the SI provider’s interest in complexity drifts away from the client’s need for simplicity, and by the time the problem is visible, the programme is already tipping into ballooning costs, unmanageable timelines, deteriorating service levels, and, in the worst cases, write-off territory.

What Successful Harmonisation Requires in Practice

There are clear benefits to harmonisation:

• Purchasing: Standardised procurement processes enable consolidated spend visibility, preferred supplier agreements, and group-level leverage on pricing and contract terms.
• Financial Consolidation: Common chart of accounts and organisational structures accelerate period-end close, simplify intercompany reconciliation, and reduce audit risk across legal entities.
• Master Data Governance: Standardised data definitions and input processes, enforced through a central governance function, prevent the data fragmentation that typically undermines reporting accuracy and cross-BU integration, and consolidating that governance centrally reduces the cost of data management by eliminating duplicated effort across business units.

The mistake is extending that logic to operational processes that are not actually similar.

The correct sequence is the reverse of what most programmes do. Each business unit should first design its process model from its own operating logic outward. Where that produces two or three genuinely different supply chain templates, those differences should be preserved. What is shared, what runs in parallel, and where the boundaries sit should then be decided architecturally, above the business units and above the SI providers, before configuration begins. That is not a one-off design decision. It is a governance responsibility that must be upheld through contracting, configuration, testing, rollout, and support.

SI providers implement. They do not design, and they certainly cannot govern design across multiple business units, each managed by a different SI provider with its own commercial interests and its own definition of done.

The question most boards do not ask before signing SI contracts is simple: Who is responsible for the overall solution being right, not just for each workstream being delivered? In many programmes that collapse, the answer is effectively no one.

A PMO with genuine cross-programme authority is not there to report status. It is the mechanism by which an architecture decision made in week four is still being honoured in month eighteen, by a different SI provider, in a different business unit, under a different programme manager.

What Successful Harmonisation Requires in Practice

When a programme fails at first industrial deployment after years of design and heavy investment, that is rarely just a project-management failure. It is usually a sign that the architecture was wrong from the start, and that no one had either the authority or the brief to correct it. 

The deterrent is usually the cost of doing the hard thinking early: stronger governance, more architectural challenges, and more difficult decisions before delivery gains momentum. But that cost is modest. It is measured in weeks of senior design work and governance discipline. The cost of getting it wrong is measured very differently: in ballooning delivery spend, unmanageable timelines, service deterioration, emergency workarounds, and, in the worst cases, write-offs or suspended programmes.

The value in harmonisation is real. The question is whether the design reflects operating reality or only the assumptions buried in the business case.

This is where programmes need independent design authority: before configuration hardens the wrong assumptions, across provider boundaries, and well beyond go-live. 

It requires people who can align business and IT around the same operating reality, challenge design decisions early, and carry that discipline through governance, rollout, and support. ABA brings that perspective through senior advisors with hands-on experience in large, complex organisations and a pragmatic approach to getting the design, governance, and delivery model right. 

If you are pressure-testing a harmonisation programme, selecting an SI, or trying to stabilise a rollout already under strain, ABA can provide an independent view before the cost of correction rises further.