Vad ett förvärv gör med systemlandskapet
Det förvärvade företaget kommer med en komplett och fungerande driftstack. Det har sitt eget affärssystem, sina egna lager- och produktionssystem, sin egen rapportering och personal som vet hur allt ska skötas. Inget av detta slutar fungera den dag affären avslutas.
Det som går sönder är allt ovanpå. Koncernens ekonomiavdelning kan inte konsolidera två kontoplaner som aldrig utformats för att stämma överens. Inköpsavdelningen kan inte se de sammanlagda utgifterna hos en leverantör som båda företagen använder. Ingen kan svara på hur stort det totala lagret av en delad komponent är, eftersom varje system räknar det under ett annat artikelnummer.
Detta är inga tekniska fel. Varje system är internt korrekt och rapporterar korrekt om sin egen halva av verksamheten. Problemet är att koncernen nu är en kommersiell enhet men två datalandskap, och endast det första är synligt för styrelsen.
Varför tar post-merger integration så lång tid?
Migreringsarbete begränsas av processkillnader, inte av datavolym. Att flytta över det förvärvade företaget till moderbolagets affärssystem innebär att man måste enas om en kontoplan, ett artikelnummersystem, ett kundregister och en uppsättning operativa processer. Varje punkt är en förhandling mellan team som båda redan har fungerande lösningar.
Tidsplanen drar ut på tiden när det förvärvade företaget fungerar annorlunda operativt. Ett moderbolag som kör lagerstyrd produktion och ett förvärv som kör orderstyrd produktion har ingen gemensam konfiguration som bara väntar på att hittas. En av parterna måste ändra sitt arbetssätt, vilket är ett projekt för förändringsledning snarare än en datamigrering.
Samtidigt kan verksamheten inte pausa. Ordrar ska skickas, månadsbokslut ska göras och kunder förväntar sig kontinuitet i servicen under en övergång de inte bett om. Det är av samma anledning som modernisering av affärssystem sker i faser snarare än som ett enda byte, och ett förvärv lägger till en hel organisations motstånd ovanpå det.
Kostnaden för att vänta på ett enhetligt system
Standardplanen håller förvärvets värde som gisslan i väntan på ett migreringsdatum. Vad det kostar, ungefär i den ordning koncernen känner av det:
- Manuell konsolidering vid varje bokslut: ekonomiavdelningen stämmer av två kontoplaner för hand varje kvartal tills det andra affärssystemet har fasats ut
- Besparingar som förblir outnyttjade: samordnade inköpsfördelar förblir outnyttjade medan leverantörsavtal förnyas med sina gamla villkor
- Nyckelpersoner upptagna: långdragna konsolideringsprogram tar i anspråk samma operativa personal som verksamheten behöver för den dagliga driften
- Kunskap som försvinner: personalomsättningen ökar när det förvärvade företaget varken är helt självständigt eller helt integrerat, och de som slutar var de som förstod systemen
- Styrelsens förtroende sviktar: varje kvartal med manuellt avstämda siffror gör det svårare att försvara affärscaset
Genom att koppla samman först vänder man på ordningsföljden. Rapporteringen fungerar tidigt, beslutet om konsolidering kan fattas i lugn och ro utifrån dess faktiska meriter, och i vissa fall upptäcker koncernen att det andra systemet är värt att behålla.
Vad post-merger integration måste leverera först
Det mesta av vad affärscaset lovade kräver faktiskt inte ett gemensamt system. Det kräver delad data mellan två.
- Konsoliderad finansiell rapportering: mappade kontostrukturer som flödar in i en gemensam koncernvy, utan att behöva vänta på en enhetlig kontoplan
- Sammanlagda leverantörsutgifter: inköpsdata från båda enheterna normaliserade mot ett gemensamt leverantörsregister, vilket är där de förhandlade besparingarna uppstår
- Synlighet för koncernens lager: delade komponenter matchade över två numreringssystem, så att lager i en enhet kan möta efterfrågan i den andra
- Kundöverlappning: en vy över konton som båda verksamheterna redan säljer till, vilket oftast är där synergier för korsförsäljning har prissätts
- Delad masterdata: en överenskommen definition av de entiteter som är viktiga, fastställd en gång och tillämpad på båda landskapen
Var och en av dessa kan levereras på några veckor utan att behöva flytta befintliga system. Det är kommersiellt viktigt, eftersom synergierna mäts mot affärsplanen, inte mot IT-färdplanen.
Hur en integrationsplattform kopplar samman flera entiteter
Alternativen är värda att nämna, eftersom de alla används och har sina begränsningar. Ett datalager kan konsolidera rapportering utan att påverka verksamheten, vilket besvarar styrelsens frågor men inte hjälper till med delad lager- eller leverantörsdata i det dagliga arbetet. Punkt-till-punkt-kopplingar mellan två affärssystem löser ett flöde men blir snabbt ohanterliga när fler behövs. Manuell konsolidering i kalkylblad är vad de flesta koncerner faktiskt gör, och det skalar med personalstyrkan snarare än med verktygen.
En integrationsplattform som tjänst (iPaaS) placeras mellan båda landskapen och låter båda fortsätta fungera medan delad data flyttas mellan dem. Det väcker en befogad fråga: om två entiteter nu delar ett lager, innebär en migrering i den ena en risk för den andra?
Svaret beror på hur lagret är strukturerat, vilket är vad modellen för flera entiteter är till för att lösa. Alumio Spaces för koncernbolag ger varje entitet en egen isolerad miljö medan det centrala teamet behåller en helhetsbild över koncernen. På Alumio iPaaS innebär den strukturen fyra fördelar för en koncern mitt i en integration:
- Isolering av entiteter: varje verksamhet körs i sitt eget Space med en dedikerad Data Engine, så att en migrering eller plattformsbyte i en entitet inte kan destabilisera de andra
- Enhetlig definition för hela koncernen: en Transformer normaliserar artikelnummer och leverantörsregister under överföringen, så att en delad komponent känns igen av båda entiteterna utan att något av systemen behöver ändras
- Central överblick och granskningsspår: realtidsstatus och hälsövervakning per Space i en instrumentpanel, med loggar över vad som flyttats mellan entiteter och när, så att internavstämningar förblir spårbara
- Fasvis utrullning med koncernstandarder: en ny entitet etableras med egna miljöer och rollbaserad åtkomst på några minuter, med hjälp av delade mallar där entiteterna matchar och lokal konfiguration där de skiljer sig åt
Dessa flöden konfigureras snarare än att byggas manuellt för varje systempar, med Code Transformer tillgänglig där konfiguration inte räcker till för att uttrycka en regel. Nästa förvärv ansluts till något som redan finns.
Post-merger integration som blir billigare för varje gång
Koncerner som gör förvärv regelbundet slutar se konsolidering som en självklarhet. De kopplar snabbt upp den nya entiteten, får rapportering och delad data att fungera, och beslutar sedan system för system om en migrering är värd kostnaden. Ibland är det uppenbart värt det, och ibland driver ett förvärvat bolag ett system som passar deras verksamhet bättre än moderbolagets.
Det omdefinierar syftet med integrationslagret. Det upphör att vara en bro som ska monteras ned när migreringen är klar och blir istället den permanenta plats där skillnader på entitetsnivå harmoniseras till en koncernövergripande vy.
Vad koncernen vinner på att bygga detta är rapportering som håller för styrelsens granskning redan under första kvartalet istället för under det andra året. Inköpsfördelar uppstår medan leverantörsavtalen fortfarande är värda att omförhandla. Och för en koncern som växer genom förvärv blir varje affär billigare att integrera än den föregående. Lagret som den tidigare entiteten anslot till står kvar när nästa anländer.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
