En plattformsstrategi är inte en serie fristående affärer som råkar ha samma ägare, och det är heller inte en sammanslagning mellan jämbördiga parter. Det gör integrationsfrågan annorlunda jämfört med ett enskilt förvärv. Vid varje ny add-on upprepas samma val: vad slår ni samman med plattformen, och vad låter ni medvetet stå separat. Buy-and-build belönar inte maximal integration. Det belönar ett konsekvent, upprepbart sätt att göra det valet, affär efter affär.
I en plattformsstrategi är frestelsen stor att så snabbt som möjligt pressa in varje add-on i plattformens system, processer och kultur. Det kan verka effektivt, men det är också där värde försvinner. En add-on som köpts för en specifik kundrelation, en nischkapacitet eller lokal marknadskännedom förlorar just det om integrationen går för långt. Frågan om något bör slås samman är vid buy-and-build inte undantaget från regeln. Det är regeln. Vissa delar stärker plattformen genom sammanslagning, andra delar försvagas just av den samma rörelsen. På när förstör integration värde och vad avgör det beskrivs var den gränsen oftast ligger.
Vid ett enskilt förvärv ställer ni integrationsfrågan en gång, grundligt, med stor uppmärksamhet på det specifika tillfället. Vid buy-and-build ställer ni en liknande fråga upprepade gånger, ofta under tidspress från nästa affär som redan finns i pipelinen. Det kräver en ansats som kan upprepas utan att hjulet uppfinns på nytt varje gång. En synergibaslinje, en Day 1-plan och en Day 100-plan är då inga engångsdokument, utan en mall som ni fyller i för varje förvärv. Hur det fungerar i praktiken framgår på hur återanvänder ni en integrationsplan. Upprepbarheten ligger inte i att kopiera resultat, utan i att på nytt gå igenom samma struktur av frågor.
Vid buy-and-build finns några återkommande kategorier där det är vanligare att låta stå separat än att slå samman. Kundrelationer som är byggda kring en person eller ett specifikt team tål liten störning. Operativa system som just anpassats till ett specifikt arbetsflöde kostar ofta mer att byta ut än de ger i skalfördelar. Varumärken med egen igenkänning inom en specifik nisch förlorar värde om de försvinner in i plattformsvarumärket. Detta är ingen fullständig lista och ingen fast regel, eftersom det beror på varför add-onen köptes och vad förvärvet ska fortsätta göra inom den större helheten. På vad låter ni medvetet stå separat och hur avgör ni det i förväg beskrivs hur ni känner igen detta per fall i förväg, istället för att upptäcka det efteråt.
Inom en plattformsstrategi finns ett ständigt tryck att konsolidera system: ett ERP, ett CRM, en rapporteringsstruktur. Det trycket är förståeligt, eftersom förvaltning av flera system tar tid och överblick. Men konsolidering är inget mål i sig. Ett system som passar väl in i en specifik affärsprocess hos add-onen kan förstöra mer värde genom att bytas ut än det ger i förvaltningsmässig enkelhet. Frågan är inte om konsolidering är möjlig, utan om den underliggande processen faktiskt är densamma. När så inte är fallet är det ibland bättre att låta ett system stå kvar, även om det vid första anblicken känns ineffektivt. Se vilka system kan ni bättre låta stå kvar och hur avgör ni det för de överväganden som spelar in där.
Kärnan i en fungerande buy-and-build-ansats är att beslutet om integration inte fattas på affärsnivå, utan på komponentnivå. Finans, IT, försäljning, HR, varumärke, kundrelationer: varje komponent förtjänar sin egen bedömning, med sina egna argument för sammanslagning eller separat hantering. En beslutslista som fastställer detta komponent för komponent förhindrar att ett argument för integration automatiskt drar med sig alla andra komponenter. Hur ni bygger upp den listan och var bedömningarna typiskt skiljer sig åt beskrivs på hur beslutar ni per komponent om ni ska integrera eller inte. För det bredare plattformssammanhanget, inklusive hur upprepning och skräddarsydda lösningar förhåller sig till varandra, finns även en fördjupande sida på vad innebär buy-and-build för er integrationsansats, i detalj.
De tre generatorerna och integrationskontoret som beskrivs här är verktyg för struktur: de ställer frågan om integration eller inte på nytt för varje komponent, de håller reda på vilka synergier som antagits och vilka som faktiskt uppstår, och de dokumenterar beroenden mellan komponenter. Det finns inget genomfört projekt som detta verktyg åberopar; det ordnar era egna bedömningar, det ersätter dem inte. Detta verktyg är under uppbyggnad. Den som vill arbeta med det så snart det blir tillgängligt kan anmäla sig till väntelistan.
Inom en plattformsstrategi är inte bara integrationsfrågan upprepbar, utan ofta även själva det underliggande arbetet: sammanställa rapporter, göra dataroom-jämförelser, gå igenom checklistor vid varje ny add-on. Den som vill veta vilken del av det återkommande arbetet som kan överlåtas till AI hittar hos FTE TO AI:s arbetsanalys en uppgiftsbaserad beräkning som per uppgift anger vilken andel av den som kan tas över av AI.
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.