Choosing one ERP does not decide how two businesses will operate as one. It leaves important questions unanswered: whose approval rules apply, who owns shared data, and which local practices should survive the merger?
If those questions reach the implementation team unresolved, configuration becomes the place where business disagreements surface. A request that looks technical may actually require a leadership decision about authority, accountability, or the way the combined organization will work.
ERP implementation support should therefore begin by separating what the business has decided from what the system is being asked to decide for it. That distinction gives project framing its purpose: establish a workable mandate before committing to execution.
Start with the merger objective, not the application choice
“Bring the businesses together” expresses a strategic intention. “Move to one ERP” proposes a system direction. Neither is a sufficient project brief.
The missing link is the business requirement: what the combined organization needs to do, under which rules, and within which constraints. Before translating the merger ambition into specifications, leadership and the project team should address four questions:
- What must become common? Identify the process rules, reporting definitions, approval responsibilities, and shared-data ownership that require a group-wide approach.
- What can legitimately remain different? Separate operational or regulatory requirements from preferences inherited from existing systems. A difference needs a reason; uniformity does too.
- What must keep working during the transition? Identify the activities whose continuity should shape sequencing and acceptance conditions.
- What is outside this project's mandate? State exclusions explicitly, particularly where the merger creates expectations that extend beyond the ERP program.
The aim is not to settle the entire future operating model in advance. It is to identify which parts of that model the ERP project depends on—and prevent an application choice from becoming an unspoken organizational decision.
Test apparent agreement before building the backlog
A combined requirements list is not necessarily an agreed requirements list. Two teams can request “standardized reporting” while expecting different definitions, levels of detail, and approval rights. Shared wording can conceal incompatible expectations.
For each major process, a useful framing exercise is to record the proposed common rule, any justified variation, the accountable decision-maker, and the question still to be resolved. This decision map complements the application view: it shows where convergence is agreed and where it remains an intention.
Consider a proposed common purchasing process. Before treating it as a configuration request, ask who may approve a purchase, how exceptions should work, and who is responsible for supplier records. The right answer need not be identical across every entity. What matters is that the variation is deliberate, justified, and owned.
This is an illustrative test of a requirement, not a description of a client engagement or a prescription for one purchasing model.
Only then does feature prioritization become meaningful. Distinguish requirements that enable a necessary business capability from those that depend on an unresolved policy choice, and from those that can wait. An urgent request may still be unready for implementation if no one has authority to approve the rule behind it.
Design governance for disagreement, not attendance
A stakeholder list tells the project who should participate. It does not tell the project who can decide. Regular meetings cannot compensate for an unclear route to resolving disagreements between business functions, IT, and the combined leadership.
OLING's AMOA practice identifies poorly expressed needs between business and IT, and difficult trade-offs without explicit priorities, as recurring problems. It identifies explicit sponsorship and shared priorities as success factors. In a merger-related ERP program, these principles should translate into practical decision rules:
- Decision rights: who proposes the business rule, who assesses its implications, and who approves it.
- Escalation: where an issue goes when the project team cannot resolve it within its authority.
- Decision evidence: which assumptions, dependencies, and consequences must be understood before approval.
- Reopening conditions: what new information would justify revisiting an agreed choice.
Not every clarification needs executive attention. Governance should distinguish working-level questions from trade-offs that change scope, priorities, or responsibilities. For each unresolved choice, name an owner and state what cannot proceed until it is resolved.
That last point makes governance useful to delivery. “Awaiting a decision” is too vague to guide a plan; an identified decision with a clear consequence gives the team something it can manage.
Use AMOA to turn the mandate into a path toward execution
OLING's AMOA practice provides upstream support for structuring business needs, project scope, and the path toward execution. It applies before a project begins or when existing project framing has become unclear. The focus is preparation and stakeholder alignment, not a guarantee of implementation success.
The approach moves through three steps: frame the need and objectives; identify stakeholders and the decisions required; then formalize the roadmap and expected deliverables. OLING frames the problem, clarifies expectations, and documents the work to support progression in stages.
Its usual AMOA deliverables include a project framing note, a backlog or roadmap, and a governance summary. For an ERP program following a merger, each should serve a distinct management purpose.
The framing note: establish the mandate
Set out the business problem, objectives, scope boundaries, constraints, and assumptions. Make visible the unresolved matters that could change the project's direction. A reader should be able to distinguish an approved objective from a proposed solution and an assumption from a decision.
The backlog or roadmap: establish the sequence
Connect work to business priorities and dependencies. Distinguish what is ready to proceed from what still requires agreement. Where a common process depends on an unsettled business rule, show that dependency rather than treating the process as ready for configuration.
The governance summary: establish accountability
Record sponsorship, stakeholder responsibilities, approval routes, and the treatment of cross-functional disagreements. Participation and approval authority should not be interchangeable.
Read these documents together, not as separate deliverables. If the roadmap assumes a common process that the framing note still treats as undecided, there is no consistent basis for execution. If a milestone depends on approval but has no accountable approver, putting it on a schedule does not resolve the dependency.
These are recommended uses of the deliverables in a merger context. The upstream scope described here does not, by itself, assign or resolve every subsequent delivery responsibility.
Recognize two forms of false readiness
OLING's AMOA practice highlights two points of vigilance: confusing a business need with a tool choice, and allowing unresolved decisions to accumulate. Both can be obscured by detailed specifications and delivery plans.
A system answer presented as a business requirement. “Retain this workflow” or “use the existing module” may be a reasonable conclusion. Neither explains the need on its own. Ask what operational outcome is required, which constraint applies, and why the proposed solution is necessary. The intention is not to reject existing tools, but to make the reasoning behind their use explicit.
A delivery plan that assumes agreement. A schedule can appear complete while process ownership, scope boundaries, or target rules remain disputed. Mark those decisions and their dependencies openly. Otherwise, the plan asks the implementation team to deliver against assumptions that leadership has not approved.
Neither warning means every detail must be resolved before work starts. The useful distinction is between uncertainty that can be managed within an agreed mandate and uncertainty that could change the mandate itself.
Authorize the next commitment—not an assumption of certainty
Before authorizing execution, leadership should be able to explain what the ERP program must enable, which convergence choices are agreed, what remains unresolved, and who has authority to decide. The level of detail should match the commitment being requested.
A practical readiness discussion should connect each open question to its consequence. Can work proceed without prejudging the answer? Would a different answer change the scope or sequence? Is the decision owner identified? This avoids treating every unknown as a blocker while keeping consequential uncertainty visible.
If the team cannot explain that distinction, further specification may be premature. Renewed framing may be the more useful next step. OLING's AMOA practice supports that upstream work by structuring needs, clarifying expectations, and formalizing the roadmap and expected deliverables.
The objective is not a claim that all uncertainty has disappeared. It is a credible basis for the next commitment: what is decided, what remains open, and what must be resolved before the organization goes further.