Hvad I skal vide om datamigrering ved platformskifte
Der er en grund til, at så mange logistikansvarlige udskyder beslutningen om at skifte fragtsystem. Det er ikke prisen. Det er ikke engang implementeringen. Det er tanken om, hvad der sker med alt det data, I har bygget op gennem årene. Kundekartoteker, faste ruter, fragtaftaler, gamle bookinger man stadig kigger tilbage på.
Platformskifte og integration i praksis handler altså langtfra kun om at sætte et nyt system op. Det handler om at flytte en virksomhed fra ét fundament til et andet, uden at noget vigtigt forsvinder undervejs.
Og det er der ingen, der rigtig taler ærligt om. Så lad os gøre det her.
Hvad I rent faktisk kan tage med jer
Først det vigtigste. Det meste data fra et gammelt system kan flyttes. Bare ikke nødvendigvis 1:1, og ikke uden eftertanke.
Stamdata på kunder, modtagere og leveringsadresser er som regel lige til. De ligger i strukturerede felter i jeres nuværende system, og de kan eksporteres til CSV eller via API. Det samme gælder produktdata, varenumre, faste pakkemål og standardvægte. Den slags er hverdagskost for en migrering.
Historiske bookinger er en anden snak. Selve transaktionerne kan typisk eksporteres som rådata, men spørgsmålet er, hvad I vil bruge dem til. Skal de være søgbare i det nye system? Skal de bare arkiveres som dokumentation? Det er to forskellige opgaver med to forskellige prisniveauer.
Fragtaftaler og rateark er måske det mest værdifulde, I har. Hvis I har forhandlet jer til særlige priser med DSV, GLS eller en lokal vognmand, så ligger de aftaler ofte spredt over PDF’er, e-mails og manuelle indtastninger i det gamle system. Dem skal nogen sætte sig ned og strukturere igen. Det er bare sådan det er.
Den vigtige sondring mellem data og opsætning
Her bliver det interessant, for det er her de fleste platformskifter går skævt.
Data er det indhold, I har genereret. Kunder, bookinger, fakturalinjer, historik.
Opsætning er det, der får data til at flyde. Brugerroller, godkendelsesflows, automatiske regler, integration til ERP, regler for hvilken transportør der vælges hvornår.
Data kan migreres. Opsætning skal som regel genopbygges. Det lyder voldsomt, men tænk lige på det. Hvornår har I sidst gennemgået jeres bookingflows og spurgt, om de stadig giver mening? De fleste virksomheder vi taler med har lag på lag af workarounds, der er bygget oven på systemets begrænsninger gennem fem-ti år. Når I skifter platform, får I muligheden for at starte forfra med flows, der passer til jeres forretning, sådan som den ser ud i dag.
Det er jo egentlig en gave, selvom det ikke føles sådan i øjeblikket.
Det her må I ikke springe over
Jeg vil sige det lige ud. Tag backup af jeres gamle system, før I gør noget som helst. Ikke kun en eksport af stamdata. En fuld backup af alt, hvad I kan trække ud. Bookinghistorik, fakturaer, kommunikationslog, alt.
Grunden er enkel. I 9 ud af 10 tilfælde går migreringen fint. Men den dag, jeres bogholder pludselig skal finde en faktura fra 2022 til en momsrevision, og jeres gamle system er lukket ned, så er det for sent.
De fleste fragtsystemer giver jer 30-90 dage efter opsigelse til at trække data ud. Brug den tid. Brug den hele.
Hvordan en realistisk migreringsplan ser ud
Der findes ikke én skabelon, fordi ingen to virksomheder har den samme situation. Men der er en rækkefølge, der virker bedre end andre.
Begynd med stamdata. Kunder, adresser, produkter. Det er fundamentet, og det er den nemmeste del. Når det ligger rent og struktureret i det nye system, kan I begynde at teste reelle bookinger på rigtige modtagere.
Derefter integrationer. ERP-koblingen er typisk det mest kritiske. Hvis jeres bookinger skal trække data fra et ordresystem og sende fakturalinjer tilbage, så skal den forbindelse stå knivskarpt, før I går live. Test den med dummy-ordrer. Test den igen. Og test den en tredje gang med jeres regnskabsansvarlige kiggende over skulderen.
Til sidst fragtaftaler og automatiseringsregler. Det er her, I genopbygger logikken. Hvilken transportør vælges til hvilken type forsendelse? Hvornår skal en booking godkendes af en leder? Hvad sker der, hvis en pakke overstiger en bestemt vægt?
Den del tager længere tid, end I tror. Sæt to uger af, og vær glad hvis I bliver færdige på halvanden.
En kort bemærkning om historisk data
Mange virksomheder ønsker at have alle deres gamle bookinger søgbare i det nye system. Det er forståeligt, men det er sjældent det rigtige valg.
Historiske bookinger er låst data. De ændrer sig ikke, og de bliver kun brugt til opslag en gang imellem. At importere flere års bookinger ind i et nyt system gør platformen tungere og rodede, uden at give jer reel værdi i hverdagen.
Et bedre alternativ er ofte at arkivere det gamle data som en eksport, gemme det sikkert, og kun trække det frem ved behov. Jeres nye system bør være rent og bygget til det, I gør fremover. Ikke et museum over alt det, I har gjort.
Hvor det typisk går galt
Der er tre mønstre, der går igen, når et platformskifte løber af sporet.
Det første er undervurdering af tiden til opsætning. Folk regner med, at fordi datamigreringen er hurtig, så er hele projektet hurtigt. Men datamigreringen er måske 20% af arbejdet. Resten er opsætning, test og oplæring.
Det andet er manglende ejerskab internt. Hvis ingen i organisationen har ansvaret for at sige “sådan skal vores bookingflow se ud”, så bliver det den nye platforms standardopsætning, der vinder. Og så ender I med et generisk system, der ikke matcher jeres forretning. Det er præcis dét, I prøver at komme væk fra.
Det tredje er for tidlig udfasning af det gamle system. Lad de to systemer køre parallelt i mindst to uger, gerne fire. Ikke fordi I skal lave dobbeltarbejde, men fordi I skal kunne falde tilbage, hvis noget kritisk viser sig først efter en uge i drift.
FAQ
Kan vi få alt vores data med over fra det gamle system?
Stamdata på kunder, adresser og produkter, ja. Bookinghistorik, typisk ja, men ofte som arkiv frem for aktiv data. Fragtaftaler og opsætning skal som regel genopbygges manuelt, fordi de er for unikke til at kunne mappes automatisk.
Hvor lang tid tager en realistisk migrering?
For en virksomhed med 10-50 ansatte og 3-5 transportører taler vi typisk 4-8 uger fra beslutning til fuld drift. Selve datamigreringen er hurtig. Det er opsætningen og oplæringen, der tager tid.
Hvad sker der med vores ERP-integration?
Den skal bygges på ny. De fleste moderne fragtplatforme har standardintegrationer til de gængse ERP-systemer (Business Central, e-conomic, SAP), men jeres specifikke flow skal stadig konfigureres. Sæt en uge af alene til ERP-test før go-live.
Skal vi køre det gamle og nye system parallelt?
Ja. I mindst to uger, helst fire. Ikke som permanent løsning, men som sikkerhedsnet. Det giver jer mulighed for at fange fejl tidligt, uden at jeres daglige drift ryger ned.
Et platformskifte er ikke en teknisk øvelse. Det er en forretningsbeslutning, der kræver, at I tænker over, hvad I egentlig vil have ud af det nye system, før I begynder at flytte data ind i det. Den del er der ingen migreringsplan, der kan tage fra jer.