Affärssystemet vid ett plattformsbyte: fyra saker som faktiskt går sönder

Det finns en tystnad i branschen kring den här kombinationen. Det skrivs mycket om att byta e-handelsplattform, och det skrivs mycket om att integrera affärssystem. Nästan ingenting skrivs om vad som händer när man gör båda samtidigt — vilket är exakt vad ett plattformsbyte i ett B2B-bolag innebär.

Så här ser det ut när det går sönder.

Affärssystemet är inte en integration. Det är sanningen.

I en ren B2C-butik är affärssystemet en mottagare. Ordern skapas i butiken och skickas dit. Går kopplingen ner en timme köar ordrarna och skickas sedan.

I ett B2B-bolag är förhållandet omvänt. Kundens avtalade pris, kreditgräns, rabattstege och betalningsvillkor bor i affärssystemet, och butiken måste fråga för att kunna visa något alls. Går kopplingen ner kan den inloggade kunden inte se sitt pris. Butiken är inte långsam — den är obrukbar.

Det är den skillnaden som gör ett B2B-byte till något annat än ett B2C-byte, och den syns sällan i en kravspec.

Fyra saker som faktiskt går sönder

Artikelnumren matchar inte. Affärssystemet har en artikelidentitet, den gamla butiken har en annan, och någonstans finns ett kalkylblad som översätter mellan dem. Det bladet är oftast inte dokumenterat och ofta inte komplett.

Prislogiken finns på två ställen. Grundpriset kommer från affärssystemet, men rabatten har byggts in i butiken för att det gick snabbare den gången. Efter bytet ska den logiken finnas på ett ställe, och någon måste bestämma vilket.

Lagersaldot är cachat och ingen minns hur ofta. Det fungerade så länge samma personer skötte det. Efter ett byte blir varje antagande om uppdateringsfrekvens synligt, i form av översäljningar.

Kundnumret är kopplingen mellan två världar. En inloggad B2B-kund är ett konto i butiken och en kund i affärssystemet, och de måste hänga ihop utan glapp. Det är den enda mappningen som absolut inte får gå fel, eftersom felet betyder att någon ser någon annans priser.

Vad som gör det hanterbart

Ordningen. Integrationen ska verifieras före datamigreringen, inte efter.

Den vanliga instinkten är den motsatta: flytta produkterna först, eftersom det känns som grunden, och koppla affärssystemet sist eftersom det är svårast. Det innebär att man migrerar 12 000 artiklar mot en artikelidentitet man ännu inte har bekräftat. Upptäcks felet efteråt får allt göras om.

Gör det i den här ordningen istället:

• bekräfta artikelidentiteten mellan affärssystem och ny plattform, på ett dussin artiklar
• bekräfta kundnummer-mappningen, på ett dussin kunder, med prislistor
• bestäm var prislogiken ska bo — ett ställe, skriv ner det
• kör då datamigreringen, och kör den flera gånger

De två första stegen tar dagar och räddar månader.

Vi har byggt kopplingar mot Business Central, Navision, Visma och Fortnox och beskriver hur de fungerar under integrationer. Är ditt affärssystem inte med i listan finns ett öppet API att bygga mot.