Post Merger Integration Roadmap: van losse werkstromen naar één bestuurbaar integratieplan
Een goede Post Merger Integration Roadmap is voor mij geen verzameling tijdlijnen. Het is een besturingsinstrument. De roadmap moet zichtbaar maken:
- welke waarde de transactie moet realiseren;
- welke werkstromen daarvoor nodig zijn;
- welke mijlpalen echt kritisch zijn;
- welke besluiten andere activiteiten blokkeren;
- waar afhankelijkheden tussen werkstromen zitten;
- welke risico’s de voortgang of deal value bedreigen;
- wie waarvoor eigenaar is;
- wanneer management moet interveniëren.
Dat klinkt vanzelfsprekend. In de praktijk zie ik echter regelmatig dat iedere werkstroom een uitstekende eigen planning heeft, terwijl niemand goed kan uitleggen of de totale integratie nog op schema ligt.
- HR ligt groen.
- IT ligt groen.
- Finance ligt groen.
- Operations ligt groen.
En toch loopt de integratie vertraging op. Waarom? Omdat integraties meestal niet vastlopen binnen één werkstroom. Ze lopen vast tussen werkstromen. Daarom kijk ik bij een roadmap niet alleen naar activiteiten en deadlines. Ik kijk vooral naar: workstreams → dependencies → besluiten → mijlpalen → waarde. Dat is voor mij de kern van een goede Post Merger Integration Roadmap.
Een roadmap is geen projectplanning
Een projectplanning bevat activiteiten. Een roadmap moet management helpen beslissen. Dat verschil is belangrijk. Een planning kan bijvoorbeeld zeggen:
ERP-migratie gereed in september.
Een roadmap moet daarnaast duidelijk maken:
- welk organisatiebesluit daarvoor eerst nodig is;
- welke processen vóór configuratie moeten zijn vastgesteld;
- welke data moet zijn opgeschoond;
- welke businessunits afhankelijk zijn van de migratie;
- welke synergie verschuift als september niet wordt gehaald;
- welk besluit management nu moet nemen om vertraging te voorkomen.
Daarmee verandert de roadmap van een overzicht naar een sturingsmechanisme. Mijn praktische vraag bij iedere roadmap is daarom: “Welke managementbeslissing wordt door dit overzicht beter of sneller genomen?”. Als het antwoord onduidelijk is, bevat de roadmap waarschijnlijk te veel planning en te weinig besturingsinformatie.
Begin bij de deal rationale, niet bij de werkstromen
Een roadmap hoort niet te beginnen met:
- HR
- Finance
- IT
- Operations
- Sales.
Dat zijn organisatiestructuren. De eerste vraag is: Welke waarde moet deze overname realiseren? Bijvoorbeeld:
- schaalvoordelen;
- commerciële groei;
- technologie;
- kostenreductie;
- geografische uitbreiding;
- toegang tot klanten;
- operationele efficiency.
Pas daarna bepaal je welke integratie nodig is. Mijn voorkeursvolgorde is: deal rationale → integratieprincipes → Target Operating Model → werkstromen → mijlpalen → projecten. Niet andersom.
Mijn tip
Vertaal de deal rationale naar maximaal drie tot vijf concrete integratiedoelstellingen. Bijvoorbeeld:
- klantretentie boven 95%;
- één commercieel operating model;
- €X structurele kostenreductie;
- één ERP-platform;
- gecombineerde propositie binnen twaalf maanden.
Daarna moet iedere grote mijlpaal in de roadmap aantoonbaar bijdragen aan één van die doelstellingen. Doet hij dat niet? Dan vraag ik mij af of hij echt thuishoort in de bestuurlijke roadmap.
Werk met resultaten, niet alleen met activiteiten
Een veelgemaakte fout is dat roadmaps volstaan met activiteiten:
- analyse afronden;
- workshops uitvoeren;
- plan opstellen;
- systeem beoordelen;
- communicatie voorbereiden.
Dat zegt weinig over de werkelijke voortgang. Ik werk liever met resultaatgerichte mijlpalen.
- Niet: ontwerp organisatiestructuur. => Maar: organisatiestructuur goedgekeurd en managementrollen benoemd.
- Niet: CRM-selectie uitvoeren. => Maar: doel-CRM gekozen en migratiebesluit genomen.
- Niet: synergieanalyse uitvoeren. Maar: €X synergie toegewezen aan benoemde owners met gevalideerde baseline.
Mijn regel
Een goede mijlpaal beschrijft een veranderde toestand van de organisatie. Niet alleen dat een team iets heeft gedaan.
De echte waarde zit in dependencies
Dit is misschien wel het belangrijkste onderdeel van een integratieroadmap. Stel:
organisatiestructuur
→ bepaalt rollen
→ bepaalt autorisaties
→ bepaalt systeemconfiguratie
→ bepaalt rapportage.
Of:
procesontwerp
→ bepaalt ERP-configuratie
→ bepaalt datamigratie
→ bepaalt training
→ bepaalt go-live.
Als het eerste besluit twee weken schuift, verschuift de rest vaak mee. Maar in afzonderlijke workstreamplannen blijft dat soms onzichtbaar.
Mijn praktische tip
Laat iedere workstream expliciet drie vragen beantwoorden:
- Waar wacht ik op?
- Wie wacht op mij?
- Welk besluit kan mijn planning blokkeren?
Die drie vragen leveren vaak meer inzicht op dan tientallen extra planningsregels.
Maak een dependency map naast de roadmap
Bij complexe integraties werk ik graag met een apart overzicht van kritieke afhankelijkheden. Niet honderden. Alleen de dependencies die meerdere werkstromen of belangrijke mijlpalen kunnen raken. Bijvoorbeeld:
Target Operating Model
→ organisatiestructuur
→ procesownership
→ systeemrollen
→ data ownership
→ rapportage.
Of:
CRM-keuze
→ datamigratie
→ salesproces
→ account ownership
→ klantcommunicatie.
De roadmap moet vervolgens zichtbaar maken waar zulke ketens de kritieke route bepalen.
Mijn ervaring
De werkelijke integratiesnelheid wordt vaak niet bepaald door de langzaamste workstream. Hij wordt bepaald door de langste keten van afhankelijkheden.
Besluiten horen expliciet in de roadmap
Veel roadmaps bevatten activiteiten en mijlpalen, maar geen besluiten. Dat is een gemiste kans. Integratieprogramma’s produceren voortdurend keuzes:
- welk systeem blijft;
- welke organisatievorm wordt gekozen;
- welke businessunit wordt gecentraliseerd;
- welke processen worden leidend;
- welke locaties blijven;
- welk merk blijft bestaan;
- welke synergie wordt wel of niet gerealiseerd.
Wanneer zulke besluiten blijven liggen, ontstaat vertraging in meerdere werkstromen. Daarom vind ik een decision log gekoppeld aan de roadmap belangrijk. Per kritisch besluit wil ik minimaal zien:
- Besluit Wat moet worden besloten?
- Owner: Wie bereidt het besluit voor?
- Decision maker: Wie neemt het besluit?
- Needed by: Wanneer moet het besluit uiterlijk vallen?
- Dependencies: elke activiteiten wachten erop?
- Impact if delayed: Wat gebeurt er als het besluit niet op tijd valt?
Dat laatste veld maakt onmiddellijk duidelijk welke besluiten prioriteit hebben.
Mijn regel: een open besluit is soms belangrijker dan een achterstallige taak
Wanneer een taak een week achterloopt, kan dat vervelend zijn. Wanneer een besluit een week achterloopt en vijf workstreams erop wachten, kan dat veel ernstiger zijn. Daarom stuur ik bij integraties niet alleen op: achterstallige acties, maar vooral op: kritieke open besluiten. Dat verschil maakt een roadmap veel bestuurbaarer.
Prioriteer op vier criteria
Niet alles kan tegelijk. Ik kijk daarom graag naar vier criteria.
- Bedrijfscontinuïteit: Wat moet gebeuren om klanten en operatie te beschermen?
- Waardecreatie: Welke activiteit realiseert aantoonbaar deal value?
- Afhankelijkheden: Welke mijlpaal of beslissing maakt andere activiteiten mogelijk?
- Risico en urgentie: Welk risico wordt snel groter wanneer we niets doen?
Mijn tip
Gebruik deze criteria niet alleen bij de start. Herprioriteer iedere paar weken. Een integratie verandert voortdurend. Een activiteit die op dag 10 niet kritisch is, kan op dag 70 ineens de nieuwe bottleneck zijn.
De roadmap moet capaciteit zichtbaar maken
Dit onderdeel ontbreekt vaak. Een integratie kan inhoudelijk perfect gepland zijn en toch onuitvoerbaar. Waarom? Omdat dezelfde managers tegelijk verantwoordelijk zijn voor:
- dagelijkse operatie;
- medewerkers;
- klanten;
- budget;
- integratieprojecten;
- besluitvorming;
- escalaties.
Managementcapaciteit is daarom naar mijn mening een echte roadmapvariabele.
Mijn praktische vraag
Niet alleen: “Kan dit technisch in september?”. Maar: “Heeft de organisatie in september daadwerkelijk voldoende capaciteit om dit veilig uit te voeren?”. Een roadmap zonder capaciteitstoets kan een theoretisch perfecte maar praktisch onuitvoerbare planning opleveren.
Werk met een beperkt aantal bestuurlijke mijlpalen
Een roadmap moet overzicht geven. Duizenden taken horen in projectplannen. Voor de integrale roadmap wil ik vooral de mijlpalen zien die iets materieels veranderen. Bijvoorbeeld:
- Day 1 readiness bevestigd;
- leiderschap benoemd;
- Target Operating Model goedgekeurd;
- organisatiestructuur actief;
- één managementrapportage live;
- eerste synergie gerealiseerd;
- doelarchitectuur vastgesteld;
- CRM-keuze genomen;
- ERP-migratie afgerond;
- TSA beëindigd;
- lijnorganisatie neemt resterende acties over;
- IMO sluit.
Mijn regel
Als een mijlpaal geen betekenis heeft voor de directie of een andere workstream, hoeft hij waarschijnlijk niet op de hoofdroadmap.
Koppel synergie direct aan roadmapmijlpalen
Synergie mag niet naast de integratie bestaan als een aparte financiële spreadsheet. Voor iedere belangrijke synergie wil ik weten:
- Baseline: Waar staan we nu?
- Target: Wat willen we realiseren?
- Owner: Wie is verantwoordelijk?
- Enabling milestone: Welke integratiemijlpaal maakt de synergie mogelijk?
- Timing: Wanneer wordt het effect zichtbaar?
- Cost to achieve: Welke investering is nodig?
- Forecast: Wat verwachten we nu?
- Actual: Wat is aantoonbaar gerealiseerd?
Voorbeeld
Stel dat applicatierationalisatie €1 miljoen jaarlijkse besparing moet opleveren. Dan moet de roadmap laten zien:
doelarchitectuur vastgesteld
→ migratie afgerond
→ legacy-applicaties uitgezet
→ contracten beëindigd
→ synergie gerealiseerd.
Dan wordt onmiddellijk duidelijk dat “IT-migratie gereed” niet alleen een technische mijlpaal is. Hij draagt rechtstreeks bij aan deal value.
Maak risico’s onderdeel van de roadmap
Risico’s horen niet alleen in een apart risk register. Voor kritieke roadmapmijlpalen wil ik weten:
- welk risico de mijlpaal bedreigt;
- wat het early-warning signal is;
- wie owner is;
- welk besluit nodig kan zijn.
Een rood risico zonder relatie met planning blijft abstract. Een risico dat expliciet gekoppeld is aan: mijlpaal → businessimpact → synergie → besluit wordt bestuurbaar.
Gebruik de roadmap als gesprekstool
Een roadmap is niet bedoeld om één keer te presenteren en daarna maandelijks te actualiseren. Ik gebruik hem liever als onderdeel van de managementdialoog. Bijvoorbeeld:
- Welke drie mijlpalen bepalen de komende maand de meeste voortgang?
- Welke vijf besluiten moeten vóór de volgende stuurgroep vallen?
- Welke dependencies zijn verslechterd?
- Welke workstreams hebben onvoldoende capaciteit?
- Welke synergie loopt risico?
- Welke activiteiten kunnen we stoppen of later doen?
Dat laatste vind ik belangrijk. Een roadmap wordt vaak steeds voller. Er komen activiteiten bij. Er gaan zelden activiteiten af. Een goed bestuurd integratieprogramma durft ook te stoppen.
Mijn praktische roadmapstructuur
Voor grotere integraties zou mijn centrale roadmap minimaal deze elementen bevatten:
- Workstream: Bijvoorbeeld organisatie, HR, Finance, Operations, IT, Commercie.
- Strategic objective: Aan welk integratiedoel draagt dit bij?
- Critical milestone: Welke concrete uitkomst moet worden bereikt?
- Owner: Wie is verantwoordelijk?
- Target date: Wanneer moet dit gereed zijn?
- Dependencies: Waar wachten we op?
- Dependent workstreams: Wie wacht op ons?
- Critical decision: Welk besluit is nodig?
- Decision due date: Wanneer moet dat besluit vallen?
- Risk: Wat kan de mijlpaal blokkeren?
- Value impact: Welke klant-, financiële of operationele waarde wordt geraakt?
- Status / trend: Niet alleen groen, amber of rood, maar ook: verbeterend / stabiel / verslechterend. Dat geeft veel meer bestuurlijke informatie.
Day 1 en Day 100 horen in de roadmap, maar zijn niet de roadmap
Day 1 en de eerste 100 dagen zijn belangrijke mijlpalen. Maar ik zou deze pagina niet opnieuw gebruiken om uitgebreid uit te leggen wat er in iedere fase moet gebeuren. Daarvoor is een aparte Day 1/Day 100-pagina geschikter. In de roadmap zijn Day 1 en Day 100 vooral ankerpunten.
Day 1
Welke continuïteitsmijlpalen moeten gereed zijn?
Day 100
Welke structurele besluiten moeten zijn genomen om de rest van de integratie mogelijk te maken? De echte roadmapvraag is daarna: wat hangt van die besluiten af?
IT moet als geïntegreerde keten worden gepland
IT heeft vaak een eigen tijdlijn, maar mag geen losstaande roadmap worden. Een ERP-migratie kan bijvoorbeeld afhangen van:
- organisatiestructuur;
- procesontwerp;
- rollen;
- autorisaties;
- datadefinities;
- rapportage;
- training.
Daarom vind ik de vraag: “Wanneer kan IT starten?”, minder interessant dan: “Welke businessbesluiten moet IT eerst ontvangen?”
Mijn IT-roadmapregel
Plan technologie altijd vanuit: strategie → operating model → processen → verantwoordelijkheden → data → systemen. Niet andersom.
Het Target Operating Model is vaak een centrale roadmapmijlpaal
Bij complexe integraties is het Target Operating Model vaak één van de belangrijkste enabling milestones. Het bepaalt onder andere:
- wat centraal wordt georganiseerd;
- wat lokaal blijft;
- welke rollen nodig zijn;
- wie welke beslissingen neemt;
- welke processen leidend worden;
- welke systemen de organisatie moeten ondersteunen.
Zonder voldoende duidelijkheid hierover gaan workstreams hun eigen toekomstbeeld ontwerpen. Dat leidt later tot herwerk.
Mijn tip
Wacht niet tot ieder detail van het Target Operating Model perfect is. Bepaal vroeg genoeg de beslissingen die andere workstreams nodig hebben. Richting vóór detail.
De roadmap moet regelmatig veranderen
Een roadmap die na zes maanden nog exact hetzelfde is als op Day 1, vertrouw ik niet automatisch. Tijdens integraties ontstaan:
- nieuwe risico’s;
- veranderde klantreacties;
- IT-vertraging;
- nieuwe synergie-inzichten;
- capaciteitsproblemen;
- personeelswisselingen;
- nieuwe afhankelijkheden.
De roadmap moet daarop reageren. Dat betekent niet dat de strategie iedere maand verandert. Het betekent dat de route naar het doel wordt aangepast aan de werkelijkheid.
Mijn maandelijkse roadmap-reset
Bij complexe integraties zou ik periodiek vijf vragen stellen:
- Welke mijlpalen zijn nu werkelijk kritiek? Niet welke ooit als kritiek zijn aangemerkt.
- Welke besluiten blokkeren de meeste voortgang?
- Welke dependencies zijn veranderd?
- Welke deal value loopt hierdoor risico?
- Welke activiteiten kunnen stoppen, verschuiven of eenvoudiger?
Zo blijft de roadmap een actueel instrument in plaats van een historisch plan.
Veelgemaakte fouten bij een Post Merger Integration Roadmap
- Fout 1: de roadmap is te gedetailleerd: Duizenden taken geven geen overzicht. Gebruik onderliggende projectplannen voor detail.
- Fout 2: de roadmap toont alleen tijd: Een tijdlijn zonder dependencies en besluiten is slechts een kalender.
- Fout 3: iedere workstream plant afzonderlijk: Lokale optimalisatie kan de totale integratie vertragen.
- Fout 4: besluiten staan nergens: Daardoor wordt besluitvertraging pas zichtbaar wanneer deadlines al worden gemist.
- Fout 5: synergie staat in een aparte spreadsheet: Dan verdwijnt de relatie tussen integratieactiviteiten en deal value.
- Fout 6: capaciteit wordt genegeerd: Een theoretisch haalbare planning kan praktisch onmogelijk zijn.
- Fout 7: alle milestones zijn even belangrijk: Management verliest daardoor zicht op de kritieke route.
- Fout 8: de roadmap wordt alleen gerapporteerd: Een roadmap hoort gebruikt te worden om keuzes te maken.
- Fout 9: activiteiten worden toegevoegd maar nooit verwijderd: De integratie wordt steeds complexer.
- Fout 10: de roadmap eindigt bij projectafronding: De roadmap moet ook aangeven wanneer de lijnorganisatie het resultaat overneemt.
Wanneer is een roadmap goed?
Voor mij is een roadmap goed wanneer een directieteam in korte tijd kan zien:
- waar de integratie werkelijk staat;
- welke mijlpalen nu kritiek zijn;
- welke workstreams van elkaar afhankelijk zijn;
- welke besluiten direct nodig zijn;
- welke risico’s de meeste waarde bedreigen;
- welke synergie afhankelijk is van welke mijlpaal;
- waar capaciteit tekortschiet;
- wat bewust later kan.
Dat is veel belangrijker dan een perfect bijgewerkte planning.
Wanneer is de roadmap klaar?
Een roadmap is niet succesvol omdat alle vakjes op groen staan. De uiteindelijke vraag is of de integratie de oorspronkelijke businesscase realiseert. Dat betekent bijvoorbeeld dat:
- klanten behouden blijven;
- verantwoordelijkheden duidelijk zijn;
- processen stabiel functioneren;
- systemen de nieuwe organisatie ondersteunen;
- synergie aantoonbaar is gerealiseerd;
- de lijnorganisatie zelfstandig kan sturen;
- tijdelijke integratiestructuren kunnen verdwijnen.
De roadmap is dus nooit het doel. Hij is het middel waarmee management strategie, besluiten en uitvoering met elkaar verbindt.
Post Merger Integration Roadmap opstellen of herstellen
Staat uw organisatie voor een complexe integratie na een fusie of overname? Of bestaat er al een uitgebreid integratieplan, maar is onvoldoende duidelijk:
- welke mijlpalen werkelijk kritiek zijn;
- welke workstreams elkaar blokkeren;
- welke besluiten te lang openstaan;
- welke synergie door vertraging wordt geraakt;
- waar managementcapaciteit tekortschiet?
Ik ondersteun directies en managementteams als interim integratiemanager bij het opzetten en aanscherpen van Post Merger Integration Roadmaps. Mijn focus ligt daarbij niet op het maken van een zo uitgebreid mogelijke planning. Ik probeer vooral zichtbaar te maken:
wat moet wanneer gebeuren, waarvan is het afhankelijk, welk besluit is nodig en welke waarde staat op het spel?
Een goede roadmap maakt een complexe integratie niet eenvoudig. Maar hij maakt haar wel bestuurbaar.
Meer weten over interim programmamanagement voor complexe verandering?