Hver synergibaseline har poster der halter bagefter. Det er ikke en fejl i modellen, det er hvad der sker når antagelser møder praksis. Spørgsmålet er ikke om det sker, men hvad De gør i det øjeblik De ser det — og om De ser det i tide.
Før De reparerer noget, står der et spørgsmål der ofte springes over: burde denne synergi egentlig have været der. Ikke enhver synergi på baseline er værd at forfølge. Nogle koster mere i integrationsindsats, opmærksomhed fra nøglepersoner og forstyrrelse af eksisterende processer end de indbringer. En synergi der ikke lander, er nogle gange et signal om at antagelsen var for optimistisk. Nogle gange er det et signal om at synergien aldrig burde have været forfulgt på den måde der var forudset. De to ting er ikke det samme, og skelnen afgør hvad De gør derefter.
Hvert synergibeløb hviler på en antagelse: et volumenestimat, en prisforventning, en indkøbsbesparelse, en reduktion i overhead. Hvis en synergi ikke lander, er det første skridt ikke at justere beløbet, men at finde antagelsen bagved. Var antagelsen for optimistisk, eller er udførelsen kommet bagud i forhold til en antagelse der i sig selv var rimelig? Den skelnen afgør om De reviderer beløbet, reviderer tilgangen, eller stiller ejeren til ansvar for udførelsen. Hvordan De finder og afprøver den antagelse, er beskrevet i hvilken antagelse der ligger under et synergibeløb ved en buy-and-build. Uden at gøre den antagelse eksplicit forbliver enhver diskussion om en skuffende synergi et gæt om hvem der har ret.
En synergi uden ejer er et ønske. En synergi med en ejer der ikke aflægger regnskab, er også et ønske, blot med et navn på. Hvis en synergi ikke lander, er det andet spørgsmål hvem der kan stilles til ansvar for det, og om den person havde beføjelsen til at få synergien til at lande. Nogle gange ligger forsinkelsen ikke hos ejeren men hos en afhængighed der ikke var løst — et system der endnu ikke er koblet sammen, en kontrakt der stadig løber, et team der endnu ikke er sammenlagt. Hvordan ejerskab tildeles, og hvorfor det ofte er sværere end det ser ud til ved en buy-and-build, er forklaret på hvem der ejer en synergi ved en buy-and-build.
En synergi der ikke lander, er mindre et problem hvis De så det komme tre måneder tidligere, og langt mere et problem hvis det først dukker op ved årsafslutningen. Forskellen ligger i hvordan De følger op. En synergi der kun står som et beløb i et regneark, giver intet signal før det er for sent at styre. En synergi der følges pr. fase — planlagt, under udførelse, delvist realiseret, gået i stå — giver det signal langt tidligere. Hvordan en sådan inddeling fungerer, og hvad den giver af styringsinformation, er beskrevet i hvordan De følger synergier med trafiklys. Pointen med et sådant system er ikke at det får synergier til at lykkes. Pointen er at det lader Dem se tidligere hvilke der ikke gør, så De stadig kan justere eller beslutte at opgive synergien.
Ved en buy-and-build gentages synergier ofte pr. opkøb: de samme indkøbsfordele, den samme overheadreduktion, gang på gang antaget uden at der på ny prøves om den underliggende logik stadig holder for netop denne tilføjelse. En synergi der ikke lander ved det tredje opkøb, er nogle gange et udførelsesproblem, men oftere et tegn på at underbygningen blev tyndere for hver ny aftale. Hvordan De underbygger en synergi ved en buy-and-build mere solidt end med en kopi af sidste gang, står på hvordan De underbygger en synergi ved en buy-and-build.
En synergi der ikke lander, behøver ikke reddes. Det er en gyldig beslutning at opgive en synergi hvis omkostningerne ved alligevel at realisere den er højere end udbyttet, eller hvis det at holde fast i beløbet koster mere opmærksomhed end det er værd. Den beslutning hører lige så meget med som beslutningen om at fortsætte. Værktøjet der understøtter denne slags afvejninger, fører ingen track record og hævder ikke at integrationen lykkes derved — det strukturerer spørgsmålet, det beviser ikke erfaring.
En synergi der ikke lander, hænger ofte sammen med noget der ikke blev sat ordentligt op på Day 1: et system, en kontrakt, et ansvar der dengang ikke blev fastlagt. Hvad der kræver opmærksomhed dér, står på hvad der skal være på plads på Day 1, og hvilke kontrakter der ofte overses i den forbindelse, står på hvilke kontrakter der kræver Day 1-opmærksomhed.
En synergi der stemmer på papiret men ikke lander, handler ofte om mennesker og tid: hvem der udfører arbejdet nu, hvor meget tid det tager, og om det stadig skal være sådan efter opkøbet. Den der ønsker at undersøge dette før synergien kommer på baseline eller efter den er gået i stå, kan med FTE TO AI's arbejdsscan pr. opgave få beregnet hvilken del af arbejdet der kan overtages af AI — en måde at se om antagelsen bag en synergi om arbejdskraft stadig er realistisk, eller om den tid nogen bruger på en opgave, er ved at forskyde sig.
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.