Under de första hundra dagarna efter en affär verkar problemet ofta vara brist på beslut. Oftare är problemet ordningen. Ett beslut om det gemensamma ERP-systemet blockerar inrättandet av rapporteringslinjer. Ett beslut om vem som får det kommersiella mandatet blockerar varje samtal med delade kunder. Så länge ingen namnger det beroendet väntar två team samtidigt på varandra, utan att någon märker det.
Inte varje liggande beslut är ett problem. Vissa saker kan vänta utan att resten stannar upp — vilka det är och vem som får avgöra det beskrivs på sidan om vad som kan vänta till efter Day 100. Ett blockerat beslut är något annat: det är ett beslut som andra beslut är beroende av, och som påvisbart håller dessa andra beslut fast. Skillnaden är inte alltid synlig från ett enda team. Ekonomiavdelningen ser inte att dess väntan på ett systemval även försenar HR-integrationen, eftersom lönebeskeden hänger på samma system. De kopplingarna blir bara synliga när någon uttryckligen kartlägger dem, oberoende av vilken avdelning som råkar vara sist i tur.
Kostnaden för ett blockerat beslut är sällan ett fast belopp per vecka. Den beror på vad som står stilla: en prisöverenskommelse som inte kan omprövas förrän produktportföljen slagits samman, en nyckelmedarbetare som slutar eftersom ingen ger klarhet om hans roll, en kund som byter till en konkurrent eftersom två kundteam motsäger varandra. Det här är inga siffror som går att beräkna i förväg. De går däremot att ordna: vilket beslut påverkar hur många andra beslut, och vad är skadans karaktär om det drar ut på tiden. Den ordningen — utifrån osäkerhet och konsekvens, inte utifrån vem som ropar högst — behandlas på sidan om att sortera beslut efter osäkerhetskostnad.
Vid kartläggningen av blockerande beslut hör en fråga som inte får hoppas över: bör den här delen egentligen integreras. Att lösa ett beroende genom att slå samman två system är inte automatiskt bättre än att låta dem existera parallellt. Ibland är det snabbaste sättet att avlägsna en blockad att besluta att integration på just den punkten inte tillför något värde. Det beslutet ska inte fattas i tysthet bara därför att ingen ställde frågan; det ska ligga explicit på bordet, bredvid frågan om när och i vilken ordning.
En lista över blockerande beslut är redan ofullständig på integrationens första dag, och blir det snabbare ju fler beslut som fattas. Nya beroenden uppstår så snart gamla löses: systemet är valt, och nu visar det sig att implementeringen är beroende av ett leverantörskontrakt som fortfarande löper. Någon måste hålla kartan aktuell, inte som en engångsövning under första veckan, utan som en löpande uppgift — annars flyttas blockaden bara till en annan plats. Vem som fyller den rollen och hur den personen förhindrar att kartan själv blir en fördröjande byråkrati, beskrivs på sidan om att hålla integrationskontoret funktionsdugligt.
Blockerade beslut är ofta orsaken till att en Day 100-plan inte uppnås, inte eftersom planen var fel, utan eftersom ett beroende underskattades. Vilka beslut som under alla omständigheter hör hemma under de första hundra dagarna och vem som ser till att de verkligen fattas, beskrivs på sidan om beslut under de första hundra dagarna. Vad som ska göras om deadline trots allt inte nås — vilka beslut som då omprioriteras och vem som avgör det — beskrivs på sidan om att inte nå Day 100. Att signalera en blockad är inte samma sak som att lösa den, men utan signalering förblir förseningen osynlig ända tills rapporten måste levereras.
Generatorerna och integrationskontoret från mergerintegration.net strukturerar dessa beroenden: de kartlägger vilket beslut som väntar på vilket annat beslut, och vilken del av organisationen som därigenom står still. Det är inte en meritlista — det finns inget genomfört uppdrag som detta verktyg åberopar, och det antyds inte här heller. Det är ett sätt att ställa frågan skarpt innan förseningen blir synlig i siffror som ingen längre kan korrigera. Den som vill arbeta med detta kan anmäla sig till väntelistan; verktyget är under uppbyggnad.
En del av tiden som går förlorad på blockerade beslut går åt till arbete som människor gör manuellt trots att det också kan göras automatiskt: sammanslagning av kundlistor, jämförelse av kontraktsvillkor, underhåll av en beroendekarta som förändras efter varje möte. Arbetsscannen från FTE TO AI beräknar per uppgift hur stor del av den som kan tas över av AI, och gör därmed synligt var kapacitet frigörs som annars hade kunnat läggas på integrationen själv.
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.