An integration plan usually starts with the question of what you are going to merge. The question that should come before that is skipped more often: what are you specifically not merging, and why not. Systems are not an end in themselves. They carry a process, and that process has value that is not automatically preserved when the system changes.
The assumption that two organizations must run on one system often stems from habit, not from a calculation. Consolidation costs time, money and the attention of people who also have other work to do. Against that stands a return that is not in every case higher than the costs. At when does integrating destroy value you'll find the broader version of this question: what is the starting point, and when is not-doing the better answer.
The tool in the integration office helps make that trade-off. The decision list of what to integrate and what not to forces a choice and a reason per system, process or team, rather than an assumption that was never spoken out loud.
There are a few recurring situations where merging costs more than it delivers.
The system is closely intertwined with a way of working that makes the acquired company distinctive. If the system is the reason customers or employees choose the organization, then replacing it is a risk of losing exactly what was paid for.
The switching costs are large relative to what there is to gain. A system deeply embedded in reporting, customer integrations or regulatory requirements is expensive to replace. If the only return is a shared dashboard, that often doesn't outweigh the cost.
The team working with it has little capacity to also make a switch. Integration requires the attention of the same people doing the ongoing work. If those people are already at full capacity, the switch comes on top of the existing workload, resulting in error-proneness and delay.
There is no good reason except uniformity. One system for the whole group sounds tidy, but tidiness is not synergy. If no one can indicate which costs will fall or which revenue will increase by merging, that is a sign to ask the question again.
These signals are not always visible in the information memorandum. They become clear when you draw up the synergy baseline: every assumption about a synergy should come with the question of which system, process or team underlies it, and what happens if that doesn't change. Where the baseline names a synergy without being able to tie it to a concrete system, that is often a sign that the synergy is softer than it looks.
The same applies to the Day 1 plan and the Day 100 plan. Both generators work with dependencies: if system A only changes after process B has been adjusted, that becomes visible before it becomes a problem on the floor. A system that appears nowhere in that dependency chain is a candidate to leave separate, at least for now.
The distinction between deliberately keeping something separate and simply not having gotten to it yet, matters. What remains separate without a reason becomes a blind spot: no one monitors it, no one has it in benefit tracking, and a year from now it's no longer possible to determine whether it was a choice or an omission. At what do you deliberately leave separate you'll find how to record that distinction, so a later evaluation can refer back to the original consideration instead of to memory.
This matters more the more the acquisition is part of a series. At what does buy-and-build mean for your integration approach the question returns in a different form: what you leave separate now may still become relevant at the next acquisition, and conversely, what was merged at the previous acquisition may here be precisely a reason not to do so this time. Here too: reusing an earlier plan is no guarantee that the outcome should be the same. At how do you reuse an integration plan you'll find how to tell whether an earlier plan serves as a basis, or rather as a warning.
The three generators and the integration office with the decision list are currently being built. There is no completed project to refer to, and that is not suggested here: the tool structures the questions and the dependencies, it does not provide evidence of prior results. Anyone who wants to work with this as soon as it becomes available can sign up for the waiting list.
The question of which system stays in place ultimately touches on the question of what work is connected to it and whether that work needs the attention of people or could also be organized differently. Anyone who, after this trade-off, wants to know which part of the remaining work is eligible for takeover by AI will find at the work scan of FTE TO AI a calculation per task: not an estimate at the organizational level, but a breakdown showing where automation does and does not align with what is actually happening.
Vraag maar wat er op Day 1 moet staan, of wat integreren juist kapotmaakt.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.