Vad som hamnar på driftchefens bord efter ett grossistförvärv
Inom grossistverksamhet är ERP-systemet den operativa kärnan. Det innehåller kundregister, prisavtal, sortiment som varje kund har rätt att beställa ur samt det lager som varje order är beroende av. Efter ett förvärv finns allt detta dubbelt, ofta med olika struktur.
Order fortsätter att komma in via båda verksamheternas kanaler: en B2B-portal, EDI från större kunder och säljare som lägger in order manuellt. Varje kanal är kopplad till sitt eget ERP, och varje ERP till sitt eget lagerhanteringssystem (WMS). Kunder som handlar från båda verksamheterna förekommer i båda systemen med olika kundnummer, och samma produkt kan ha två artikelnummer och två priser.
Ett företag som köpts från en större koncern kommer med en tidsfrist. Enligt ett TSA kan det förvärvade företaget endast använda säljarens system fram till ett visst datum. Varje order-, pris- och leverantörsflöde måste flyttas till en ny miljö innan dess. I en buy-and-build-modell upprepas detta M&A-integrationsarbete vid varje affär.
Var går en "big bang"-ERP-konsolidering fel?
En fullständig övergång till koncernens ERP är oftast rätt på lång sikt, men fel som ett första steg. Som slutmål är ett gemensamt ERP enklare att driva och granska.
Risken ligger i själva övergången. Varje kundspecifikt prisavtal, rabattstruktur och sortiment måste återskapas i målsystemet och testas före driftsättning. Inom grossistverksamhet innebär ett misstag här att kunden får fel pris på en order, att en produkt saknas i portalen eller att en EDI-order avvisas.
En TSA-deadline pressar in testningen i den tid säljaren tillåter. Migreringen är också beroende av de få personer som förstår båda ERP-systemen, samma personer som behövs för att hålla orderflödet igång. Att undvika den risken börjar med vad koncernen behöver medan båda ERP-systemen fortfarande är i drift.
Vad en grossistkoncern behöver medan båda ERP-systemen körs
Fram till dess att ERP-konsolideringen är klar måste de två verksamheterna fungera som en enhet utåt mot kunder och det centrala teamet. Order som läggs via koncernens portal måste nå det ERP som innehåller kundens prisavtal. Kundspecifika priser och sortiment måste visas korrekt i alla orderkanaler. Lager från båda systemen måste summeras till en gemensam vy, och EDI-order måste fortsätta att komma in i det format som varje handelspartner redan använder. Om verksamheten köpts från en större koncern måste alla dessa flöden dessutom lämna säljarens system innan TSA-avtalet löper ut.
De vanliga sätten att lösa detta på räcker inte till. Nattliga exporter och kalkylblad fungerar bara tills volymerna växer. Punkt-till-punkt-kopplingar mellan de två ERP-systemen fungerar, men varje koppling är unik, beroende av sin utvecklare och behöver byggas om när något av systemen ändras. Att bygga kopplingarna direkt i målsystemet låser fast dem vid en migrering som koncernen ännu inte är klar med.
Vad koncernen behöver är ett integrationslager: ett separat system som ligger mellan ERP-systemen, WMS, portalen och EDI-flödena, snarare än inuti något av dem. Då kan båda ERP-systemen fortsätta köras medan verksamheten fungerar som en enhet.
Hur Alumio stöttar en grossistkoncern genom ERP-konsolidering
En iPaaS är en molnbaserad, central hubb som system ansluter till. Den omvandlar varje systems data till det format som de andra systemen förväntar sig och automatiserar utbytet i realtid eller enligt ett schema.
För en grossistkoncern spelar det också roll hur integrationsplattformen är organiserad. En delad miljö gör att ett företags migrering kan störa allas flöden. Separata uppsättningar per företag lämnar koncernen utan överblick och innebär att samma anslutningar måste byggas om vid varje affär.
Medan integrationsplattformar vanligtvis fokuserar på att koppla samman system och automatisera utbytet mellan dem, har Alumio, en config-first-integrationsplattform, utvecklat ett erbjudande specifikt för företagsgrupper. Med Alumio Spaces Core kör varje företag sina integrationer i en egen isolerad miljö, medan ett centralt team övervakar dem alla. För ett förvärv inom grossistledet innebär detta fyra saker:
- Det förvärvade företaget får en egen miljö: dess ERP-, WMS-, portal- och EDI-flöden ansluts via en av 180+ kopplingar eller en anpassad anslutning. En senare migrering eller separation stannar inom den miljön, avskilt från resten av koncernen.
- En översättning mellan företagen: varje ERP förblir huvudsystem för sin egen data. Alumio tillhandahåller Transformers som mappar kundkonton, artikelnummer och prislistor under överföringen, så att ordrar når det ERP som innehåller kundens specifika prisavtal.
- Koncernövergripande överblick, enhet för enhet: det centrala teamet ser status, loggar och övervakning av varje enhets integrationer på ett och samma ställe. Rollbaserad åtkomst, en granskningslogg och konfigurationshistorik visar vem som ändrat vilket flöde och när, och plattformen är ISO 27001-certifierad.
- Gemensamma standarder med lokal flexibilitet: flöden som byggs för denna affär blir mallar för nästa förvärv eller lagerställe. Mappningen kan skilja sig åt per enhet eller partner medan arkitekturen förblir densamma, och utrullningen sker i etapper.
Koncernen behöver inte längre välja mellan en förhastad migrering och två företag som inte kan se varandras ordrar.
Var ska man börja när det förvärvade företaget fortfarande kör sitt eget ERP?
För en driftchef är det ofta att ansluta nu i stället för att migrera nu som skiljer ett smidigt första kvartal från ett som stannar av. Kunderna bedömer affären utifrån om deras nästa order kommer fram till rätt pris, och en TSA-deadline går inte att flytta.
Den praktiska starten är de flöden som kunderna märker av först: ordrar och kundspecifik prissättning för delade konton, följt av lagerstatus. Anslut det förvärvade företaget i dess egen miljö och flytta eventuella flöden som fortfarande ligger kvar i säljarens system medan TSA-avtalet löper. På en integrationsplattform som Alumio går integrationer vanligtvis live på veckor, inte månader.
ERP-konsolidering förblir ett öppet val. Koncernen kan migrera ett företag i taget utan att utsätta de andra för risk, eller behålla två ERP-system där de tjänar olika marknader väl. Nästa förvärv ansluts sedan till ett integrationslager och mallar som redan finns.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
