Capability maps in mergers, acquisitions and divestitures

Why the capability map comes first

In a merger every other view is contested. Each company describes its work through its own departments, its own process names and its own systems, so comparing them line by line turns into an argument about vocabulary. A capability map sidesteps that: it says what each business must be able to do, which is the one thing both sides can agree to compare.

Keep the joint map broad and shallow. Two or three levels are enough to place every application and team; the detail can wait until a specific capability is being integrated. Start from a shared reference such as this catalog so neither company's model wins by default.

Before the deal: due diligence

During Deal Evaluation & Due Diligence the map answers three questions quickly: where the two companies overlap, where the target fills a gap the buyer has, and which capabilities the target performs that the buyer has never run. The first is where savings come from, the second is often the reason for the deal, and the third is where risk hides.

• Place each company's Business Applications against the map with the Capability-to-Application Matrix; overlap shows up as two applications on one capability.
• Note which application masters each core data concept, such as Customer, Product and Supplier. Two masters for the same concept is the integration cost most often underestimated.
• Shade the map by importance and readiness with the Capability Heat Map, so the deal team sees the few capabilities that decide the value of the deal.

After close: deciding capability by capability

Integration planning (Integration & Separation Planning) is a series of small decisions rather than one big one. For each capability with overlap, decide whether to keep one side's way of working and systems, keep the other's, run both for a time, or replace both. Record the decision, its owner and its date in the Gap Analysis Matrix, which groups the moves into work packages.

Sequence the moves the way any modernization should be sequenced: one capability at a time, with the old and new running side by side until each slice is proven, as the principle Strangle, Do Not Rewrite describes. A single cut-over date for everything is the riskiest plan available.

Divestitures run the same map in reverse

When part of a business is sold, the question becomes what has to leave with it. Tag the capabilities that transfer, then the applications, data and contracts that support them. Shared applications are the hard part: the seller usually keeps running them for the buyer for a period under a transition service agreement, and each one needs an exit date and a plan for separating its data.

• Capabilities that transfer whole are the easy case; capabilities split between the two businesses need a decision on which side keeps the system of record.
• Data is the long pole: customer, supplier and employee records have to be separated, and the system-of-record principle says who must own each copy afterward.
• Every transition service needs an owner, a cost and an end date; open-ended ones become permanent.

Common mistakes

• Mapping by organization instead of capability, so the map breaks the day the new organization is announced.
• Choosing applications before agreeing which capabilities matter most to the deal.
• Treating data migration as a technical task at the end rather than a design decision at the start.
• Letting the joint map grow deep before the first integration decisions are made.