In de eerste honderd dagen na een deal lijkt het probleem vaak een gebrek aan besluiten. Vaker is het probleem de volgorde. Een besluit over het gemeenschappelijke ERP-systeem blokkeert de inrichting van rapportagelijnen. Een besluit over wie het commerciële mandaat krijgt, blokkeert elk gesprek met gedeelde klanten. Zolang niemand die afhankelijkheid benoemt, wordt er in twee teams tegelijk gewacht op elkaar, zonder dat iemand het merkt.
Niet elk liggend besluit is een probleem. Sommige zaken kunnen wachten zonder dat de rest stilvalt — welke dat zijn en wie dat mag bepalen, staat beschreven op de pagina over wat kan wachten tot na Day 100. Een geblokkeerd besluit is iets anders: het is een besluit waarvan andere besluiten afhankelijk zijn, en dat die andere besluiten aantoonbaar vasthoudt. Het verschil is niet altijd zichtbaar vanuit één team. De financeafdeling ziet niet dat haar wachten op een systeemkeuze ook de HR-integratie ophoudt, omdat loonstroken aan hetzelfde systeem hangen. Die verbindingen worden pas zichtbaar als iemand ze expliciet in kaart brengt, los van de afdeling die toevallig het laatst aan de beurt is.
De kosten van een geblokkeerd besluit zijn zelden een vast bedrag per week. Ze hangen af van wat er stilstaat: een prijsafspraak die niet herzien kan worden zolang het productportfolio niet is samengevoegd, een sleutelmedewerker die vertrekt omdat niemand duidelijkheid geeft over zijn rol, een klant die naar een concurrent overstapt omdat twee accountteams elkaar tegenspreken. Dit zijn geen getallen die vooraf te berekenen zijn. Ze zijn wel te ordenen: welk besluit raakt hoeveel andere besluiten, en wat is de aard van de schade als het langer duurt. Die ordening — op onzekerheid en gevolg, niet op wie het hardst roept — komt aan bod op de pagina over het sorteren van besluiten op onzekerheidskosten.
Bij het in kaart brengen van blokkerende besluiten hoort een vraag die niet mag worden overgeslagen: moet dit onderdeel eigenlijk worden geïntegreerd. Een afhankelijkheid oplossen door twee systemen samen te voegen is niet automatisch beter dan ze naast elkaar te laten bestaan. Soms is de snelste manier om een blokkade weg te nemen, te besluiten dat integratie op dat punt geen waarde toevoegt. Dat besluit hoort niet stilzwijgend genomen te worden omdat niemand de vraag stelde; het hoort expliciet op tafel te liggen, naast de vraag wanneer en in welke volgorde.
Een lijst van blokkerende besluiten is op dag één van de integratie al onvolledig, en wordt dat sneller naarmate er meer besluiten worden genomen. Nieuwe afhankelijkheden ontstaan zodra oude worden opgelost: het systeem is gekozen, en nu blijkt de implementatie afhankelijk van een leverancierscontract dat nog loopt. Iemand moet die kaart actueel houden, niet als eenmalige oefening in de eerste week, maar als lopende taak — anders verschuift de blokkade alleen van plek. Wie die rol vervult en hoe die persoon voorkomt dat de kaart zelf een vertragende bureaucratie wordt, staat op de pagina over het werkbaar houden van het integratiekantoor.
Geblokkeerde besluiten zijn vaak de reden dat een Day 100-plan niet wordt gehaald, niet omdat het plan verkeerd was, maar omdat een afhankelijkheid werd onderschat. Welke besluiten sowieso in de eerste honderd dagen thuishoren en wie erop toeziet dat ze ook echt genomen worden, staat op de pagina over besluiten in de eerste honderd dagen. Wat te doen als de deadline toch niet wordt gehaald — welke besluiten dan opnieuw geprioriteerd worden en wie dat beslist — staat beschreven op de pagina over het niet halen van Day 100. Een blokkade signaleren is niet hetzelfde als hem oplossen, maar zonder signalering blijft de vertraging onzichtbaar tot het moment dat het rapport moet worden opgeleverd.
De generators en het integratiekantoor van mergerintegration.net structureren deze afhankelijkheden: ze brengen in kaart welk besluit op welk ander besluit wacht, en welk deel van de organisatie daardoor stilstaat. Dat is geen staat van dienst — er is geen uitgevoerd traject waarop dit gereedschap zich beroept, en dat wordt hier niet gesuggereerd. Het is een manier om de vraag scherp te stellen voordat de vertraging zichtbaar wordt in cijfers die niemand meer kan corrigeren. Wie hiermee wil werken, kan zich aanmelden voor de wachtlijst; de tool is in aanbouw.
Een deel van de tijd die verloren gaat aan geblokkeerde besluiten, gaat op aan werk dat mensen handmatig doen terwijl het ook automatisch kan: het samenvoegen van klantenlijsten, het vergelijken van contractvoorwaarden, het bijhouden van een afhankelijkhedenkaart die na elke vergadering verandert. De werkscan van FTE TO AI rekent per taak uit welk deel daarvan door AI is over te nemen, en maakt zo zichtbaar waar capaciteit vrijkomt die anders aan de integratie zelf had kunnen worden besteed.
Vraag maar wat er op Day 1 moet staan, of wat integreren juist kapotmaakt.
Antwoorden komen uit de kennisbank van deze site. Geen advies op maat, en geen scan van uw bedrijf.