Et deal team, der tidligere har integreret en overtagelse, har ofte en plan liggende. En Day 1-tjekliste, en liste med synergikategorier, et kommunikationsskema. Fristelsen er stor til at hente dette dokument frem, ændre navne og tal, og fortsætte. Det sparer tid. Det sparer også tænkearbejde, og det er netop problemet.
En integrationsplan er ikke en skabelon for en organisation, det er resultatet af valg, der er truffet ved en anden kombination af virksomheder. Hvilke systemer smelter sammen, hvilke teams fusionerer, hvilke kunderelationer forbliver separate — disse valg afhang af, hvad de forrige to virksomheder var, ikke af hvad disse to virksomheder er. At genbruge en plan uden at afprøve disse underliggende valg på ny betyder, at man overtager en struktur, der er bygget til en anden situation.
Risikoen ligger ikke i formen. Faseindeling, en benefit-tracker, en liste med afhængigheder — disse elementer er ofte fint genbrugelige. Risikoen ligger i det indhold, der umærkeligt følger med: antagelsen om, at afdeling X altid slås sammen, at system Y altid udfases, at kulturintegration altid gribes an på samme måde. Disse antagelser er ikke neutrale. De er præcedens, og præcedens føles som bevis, mens det ikke er det.
Tre ting rejser normalt godt med fra et projekt til et andet:
Disse elementer er metode, ikke resultat. De fortæller, hvordan man kommer til et svar, ikke hvad svaret er. Denne skelnen er kernen i ansvarlig genbrug: at overtage processen, ikke konklusionerne.
Det bliver risikabelt, så snart en tidligere plan springer selve spørgsmålet over. Hvis det tidligere projekt fastslog, at to salgsteams skulle sammenlægges, og dette automatisk overtages, fordi det "nu engang er sådan", afhænger sandsynligheden for, at det også er rigtigt denne gang, af tilfældighed, ikke af analyse. Mere om hvornår sammenlægning ødelægger værdi og hvordan man kan se det kan læses på en anden side, men det faste spørgsmål vender tilbage her: kunne dette element måske have haft det bedre ved at forblive separat.
Dette gælder i høj grad for systemer. En IT-migrering, der var logisk ved den forrige deal — fordi den overtagne virksomhed havde en forældet platform — er ikke automatisk logisk ved en virksomhed med et system, der lige er blevet fornyet og fungerer godt. Hvilke systemer man med fordel kan lade stå, og hvordan man kan se det, er en separat overvejelse pr. situation, ikke en regel, man overtager fra den forrige deal.
Også organisationsstruktur er sårbar for blindt genbrug. Hvis den forrige plan fastslog, at finansafdelinger altid fusioneres, forsvinder med denne automatik spørgsmålet om, hvorvidt det også er rigtigt her. Ved en buy-and-build-strategi, hvor en platform gentagne gange tilføjer virksomheder, er fristelsen til at køre én skabelon endnu større — og nødvendigheden af at se på hvert element igen endnu mere presserende. Hvad en buy-and-build-tilgang kræver af integrationsstrategien, og hvordan man kan se det, fortjener derfor en selvstændig afvejning pr. overtagelse, ikke én tilbagevendende plan.
En brugbar tilgang er at bruge den forrige plan som en tjekliste over spørgsmål, der skal stilles på ny, ikke som en liste over svar, der allerede er fastlagt. For hvert element, der blev integreret i den forrige plan, stiller man på ny spørgsmålet, om det også gælder her. For hvert element, der forblev separat, spørger man sig selv, om den grund også gælder her. Hvordan man strukturerer denne beslutning pr. element — integrere eller ikke, og efter hvilke kriterier — bestemmer i sidste ende mere for resultatet end hvor hurtigt planen kommer på papir. Se også, hvordan man opbygger denne beslutning pr. element, og hvordan man kan genkende det: hvordan man beslutter pr. element om integration eller ikke.
Det, der bevidst forbliver separat, fortjener i den genbrugte plan lige så meget opmærksomhed som det, der lægges sammen. En plan, der kun indeholder integrationsskridt og intet siger om, hvad der eksplicit ikke lægges sammen, mangler halvdelen af beslutningen. At synliggøre på forhånd, hvad der forbliver separat og hvorfor, forhindrer, at dette valg senere bliver forklaret som en fejl. Mere om dette: hvad man bevidst lader være separat, og hvordan man fastlægger det på forhånd.
De tre generatorer og integrationskontoret fra mergerintegration.net er bygget på denne skelnen: struktur, der følger med, ingen konklusioner, der lusker med. En synergibaseline, en Day 1-plan og en Day 100-plan opbygges på ny pr. situation ud fra de samme spørgsmål, med en benefit-tracker og en beslutningsliste, der tvinger til et svar pr. element. Dette er redskaber, der strukturerer, ikke erfaring, der garanterer — værktøjet er under udvikling, og den, der vil bruge det, kan tilmelde sig ventelisten.
En integrationsplan handler om, hvem der udfører hvilket arbejde, hvilke afdelinger lægges sammen, og hvilke processer forbliver bestående. Under dette spørgsmål ligger et mere præcist spørgsmål: hvor meget af det arbejde, der fremover udføres sammen eller separat, egentlig er opgavearbejde, der kan automatiseres. Arbejdsscanningen fra FTE TO AI beregner pr. opgave, hvilken del af den, der kan overtages af AI, og giver dermed et talmæssigt grundlag for et valg, der ellers hviler på antagelser — netop den risiko, der også lurer ved genbrugte integrationsplaner.
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.