Kennisbank

An integration plan is not a template that fits everywhere

An integration plan from a previous deal is often still around. The structure worked, the breakdown into functions and systems was correct, and it's tempting to reuse it. But reusing a plan is different from repeating an outcome. The question is not whether the plan was complete, but whether the assumptions in it still hold for this deal, these two organizations and this market.

Reuse works at the level of the question, not at the level of the answer. A previous plan had a sequence for systems, a breakdown of functions that would or would not be combined, and a list of dependencies. That sequence is useful as a checklist to make sure nothing is forgotten. It is not useful as an outcome to copy, because the reason something was combined last time says little about whether it should be this time.

How you can tell in advance whether reuse makes sense

There are a few signals to check before an old plan serves as a basis.

First: were the two previous organizations comparable to the current two, in size, in system landscape, in the extent to which customers notice the difference. A plan for two equivalent parties does not fit an acquisition where one party is a small supplementary team.

Second: is it known why certain parts remained separate at the time. If that reason was not recorded, it is impossible to judge whether they should now be combined. A plan that only shows what was merged, without the reasoning behind why something remained separate, is worth less for reuse than it seems.

Third: is the underlying system landscape comparable. Merging two ERP systems is a different task than letting two planning tools exist side by side. What was one of the first steps last time may this time be better left on the shelf because the systems themselves are not comparable.

The question that should apply to every part

Regardless of whether a plan is new or reused: for every part, the question of whether merging actually adds value should apply. This is not an exception question for doubtful cases. It is a standard step, even for parts that at first glance obviously belong together.

The reason is that integrating brings costs that are not always visible in advance: time from people who would otherwise be working on customers or growth, systems that are temporarily less reliable, teams that become uncertain about their role. If there is no demonstrable benefit to offset that, merging is a cost item without compensation. When integrating destroys value is therefore not an edge case but a structural risk in every plan that is adopted without this check.

There are parts that are usually better left separate: a brand with its own customer relationship, a team with a culture that was the reason for the acquisition, a system that has just been replaced and does not need to be adjusted again. What you deliberately keep separate is not a list of overdue tasks but a decision with its own reason, and that reason deserves to be documented just as much as the reason to merge something. See what you deliberately keep separate for what that choice looks like.

A decision per part, not a choice for the whole

It is rare for an entire acquisition to integrate as a whole or not at all. Usually the outcome is a mix: centralizing financial reporting, keeping customer systems separate, partially merging HR policy. Each part requires its own assessment, with its own timeline and its own risk. How you decide per part whether or not to integrate is therefore less a step-by-step plan than a fixed question that is asked separately for each part, with its own answer.

This assessment also differs per sector. In construction, an integration often gets stuck on project administration and subcontractor relationships that cannot simply be transferred to another system; see where an integration gets stuck in construction. In the installation industry, it is more often the planning systems and service contracts that do not merge one to one; see where an integration gets stuck in the installation industry. A reused plan that ignores these differences misses exactly the part where things went wrong before.

What this tool does

The generators for synergy baseline, Day 1 plan and Day 100 plan are not built on a template from the previous deal, but on the situation that is entered: which parts exist, what the dependencies are, and what reason there is per part to merge or not. The integration office then keeps track of which benefits have been identified, which dependencies are still open, and which parts have deliberately been kept separate. That is not proof that it works — there is no completed project to point to — but it is structure that forces the question to be asked per part instead of being skipped.

Mergerintegration.net is under construction. Anyone who wants to work with this as soon as it becomes available can join the waiting list.

The question of which part of this work costs time itself and which part can be taken over does not only apply to integration planning. The work scan from FTE TO AI calculates per task which part of the work can be taken over by AI, giving a picture of where capacity becomes available before an integration process starts.