I de første hundrede dage efter en aftale ser problemet ofte ud til at være en mangel på beslutninger. Oftere er problemet rækkefølgen. En beslutning om det fælles ERP-system blokerer indretningen af rapporteringslinjer. En beslutning om hvem der får det kommercielle mandat, blokerer enhver samtale med fælles kunder. Så længe ingen navngiver den afhængighed, venter to teams samtidig på hinanden, uden at nogen bemærker det.
Ikke enhver beslutning, der ligger stille, er et problem. Nogle ting kan vente uden at resten går i stå — hvilke det er, og hvem der må bestemme det, er beskrevet på siden om hvad der kan vente til efter Day 100. En blokeret beslutning er noget andet: det er en beslutning, som andre beslutninger afhænger af, og som påviseligt holder de andre beslutninger fast. Forskellen er ikke altid synlig fra ét team. Finansafdelingen ser ikke, at dens ventetid på et systemvalg også holder HR-integrationen tilbage, fordi lønsedler hænger sammen med det samme system. Disse forbindelser bliver først synlige, når nogen kortlægger dem eksplicit, uafhængigt af den afdeling, der tilfældigvis er sidst i køen.
Udgifterne ved en blokeret beslutning er sjældent et fast beløb pr. uge. De afhænger af, hvad der står stille: en prisaftale, der ikke kan revideres, så længe produktporteføljen ikke er samlet, en nøglemedarbejder, der forlader virksomheden, fordi ingen giver klarhed om hans rolle, en kunde, der skifter til en konkurrent, fordi to accountteams modsiger hinanden. Det er ikke tal, der kan beregnes på forhånd. De kan derimod ordnes: hvilken beslutning påvirker hvor mange andre beslutninger, og hvad er skadens karakter, hvis det tager længere tid. Denne ordning — efter usikkerhed og konsekvens, ikke efter hvem der råber højest — behandles på siden om at sortere beslutninger efter usikkerhedskostnader.
Når man kortlægger blokerende beslutninger, hører der et spørgsmål med, som ikke må springes over: skal denne del egentlig integreres. At løse en afhængighed ved at sammenlægge to systemer er ikke automatisk bedre end at lade dem eksistere side om side. Nogle gange er den hurtigste måde at fjerne en blokade på at beslutte, at integration på det punkt ikke skaber værdi. Den beslutning bør ikke tages tavst, fordi ingen stillede spørgsmålet; den bør ligge eksplicit på bordet, sammen med spørgsmålet om hvornår og i hvilken rækkefølge.
En liste over blokerende beslutninger er allerede ufuldstændig på integrationens første dag, og bliver det hurtigere, i takt med at flere beslutninger tages. Nye afhængigheder opstår, så snart gamle bliver løst: systemet er valgt, og nu viser det sig, at implementeringen afhænger af en leverandørkontrakt, der stadig løber. Nogen skal holde det kort ajour, ikke som en éngangsøvelse i den første uge, men som en løbende opgave — ellers flytter blokaden sig blot til et andet sted. Hvem der udfylder den rolle, og hvordan den person forhindrer, at kortet selv bliver et forsinkende bureaukrati, står på siden om at holde integrationskontoret funktionsdueligt.
Blokerede beslutninger er ofte grunden til, at en Day 100-plan ikke nås, ikke fordi planen var forkert, men fordi en afhængighed blev undervurderet. Hvilke beslutninger, der under alle omstændigheder hører til i de første hundrede dage, og hvem der sørger for, at de også faktisk bliver truffet, står på siden om beslutninger i de første hundrede dage. Hvad man gør, hvis deadline alligevel ikke nås — hvilke beslutninger der så bliver prioriteret på ny, og hvem der bestemmer det — er beskrevet på siden om ikke at nå Day 100. At signalere en blokade er ikke det samme som at løse den, men uden signalering forbliver forsinkelsen usynlig, indtil rapporten skal afleveres.
Generatorerne og integrationskontoret fra mergerintegration.net strukturerer disse afhængigheder: de kortlægger, hvilken beslutning der venter på hvilken anden beslutning, og hvilken del af organisationen der derved står stille. Det er ikke en track record — der er ikke noget udført forløb, som dette redskab kan henvise til, og det antydes ikke her. Det er en måde at stille spørgsmålet skarpt, før forsinkelsen bliver synlig i tal, som ingen længere kan rette. Den, der vil arbejde med dette, kan skrive sig på venteliste; værktøjet er under opbygning.
En del af den tid, der går tabt på blokerede beslutninger, går til arbejde, som folk udfører manuelt, mens det også kunne gøres automatisk: at samle kundelister, sammenligne kontraktvilkår, holde et afhængighedskort ved, der ændrer sig efter hvert møde. Arbejdsscanningen fra FTE TO AI beregner for hver opgave, hvilken del af den der kan overtages af AI, og gør dermed synligt, hvor der frigøres kapacitet, som ellers kunne være brugt på selve integrationen.
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.