Et platformskifte går sjældent galt på go-live-dagen. Bookingerne går igennem, labels printes, og de første uger ser lovende ud. Problemet opstår to måneder senere, når en B2B-kunde ringer om en palle, der blev hentet i marts, og ingen kan finde bookingen, fordi den ligger i et system, der er lukket ned eller kun er tilgængeligt for én person med et gammelt login.

Det samme mønster gentager sig, når transportørernes fakturaer kommer. Skal I kontrollere en faktura for perioden op til skiftet, skal I bruge de bookingdata, der lå i den gamle platform. Er de ikke migreret i et søgbart format, bliver fakturakontrollen enten droppet eller håndteret manuelt af en medarbejder, der bruger timer på at rekonstruere noget, systemet burde have holdt styr på.

Integration og skift af bookingplatform i praksis handler derfor lige så meget om det, der ligger bagud, som om det, der skal bookes i morgen. Den nye platform kan være hurtigere og dække flere transportører, men hvis historikken bliver efterladt, har I blot flyttet ét problem og skabt et nyt.

Hvorfor historiske data bliver glemt

Når et skifte planlægges, er opmærksomheden rettet mod driften: Kan vi booke hos alle vores transportører? Taler platformen sammen med ERP og webshop? Hvor lang tid tager det at oplære lagerpersonalet? Det er de rigtige spørgsmål, og de fylder hele projektplanen.

Historiske data har ingen deadline. Ingen opdager i den første uge, at bookinghistorikken fra de seneste tre år ikke kom med. Behovet opstår først, når en reklamation, en fakturafejl eller en kundeklage skal spores tilbage, og på det tidspunkt er projektet lukket, konsulenttimerne brugt og den gamle aftale opsagt.

Der er også et ejerskabsproblem. Driften ejer bookingerne, økonomi ejer fakturaafstemningen, og kundeservice ejer reklamationerne. Historikken går på tværs af dem alle, og derfor ender den ofte på ingens liste.

Integration og skift af bookingplatform i praksis begynder med en datagennemgang

Før I beslutter, hvad der skal migreres, skal I vide, hvad I har. En datagennemgang er et enkelt overblik over, hvilke datasæt den gamle platform indeholder, hvem der bruger dem, hvor ofte de bruges, og hvor længe de skal være tilgængelige.

Øvelsen tager typisk en halv dag med de rigtige personer i rummet, og den bestemmer resten af projektet. Uden den bliver datamigreringen en teknisk opgave, som leverandøren definerer. Med den bliver den en forretningsbeslutning, hvor I selv sætter kravene.

Inddel datasættene efter deres formål:

Aktiv drift: Data, der bruges dagligt og skal virke fra dag ét. Kunde- og adressekartotek, faste afhentningsadresser, kundenumre hos transportørerne, kolli- og varetyper.
Opsætning og regler: Routingregler, servicemapping, tillæg, prisaftaler, brugere og rettigheder. Det er her, mange undervurderer indsatsen, fordi reglerne sjældent er dokumenteret andre steder end i selve systemet.
Compliance: Tolddokumenter, fragtbreve, leveringsbevis og fakturagrundlag. Her er det ikke jeres egne behov, men lovgivning og kundeaftaler, der bestemmer, hvor længe data skal være tilgængelige.
Arkiv: Bookinghistorik, afsluttede reklamationer og historiske afstemninger. Skal være søgbart, men behøver ikke ligge i det daglige arbejdsområde.

Inddelingen gør det muligt at prioritere. Ikke alt skal migreres ind i den nye platform. Nogle data kan ligge i et søgbart eksportarkiv, så længe I kan finde dem frem inden for rimelig tid.

De data, der oftest mangler bagefter

Erfaringen viser, at fire typer data skaber flest problemer efter et skifte, fordi de ikke bruges dagligt og derfor ikke bliver testet i implementeringsfasen:

Bookinghistorik med referencer: En booking uden ordrenummer, kundereference og transportørens trackingnummer er ikke til meget nytte. Migreres historikken uden referencefelterne, kan I se, at noget blev sendt, men ikke koble det til en ordre eller en faktura.
Fakturagrundlag: Afstemmer I transportørernes fakturaer mod bookinger, skal de underliggende data følge med i samme detaljeringsgrad. Ellers stopper afstemningen ved skæringsdatoen, og perioden før bliver en blind plet, hvor fejl passerer ubemærket.
Reklamationer og skadesager: Sager kan løbe i måneder. Åbne sager på tidspunktet for skiftet skal have et aftalt hjem, og lukkede sager skal kunne findes frem, hvis en kunde vender tilbage med et spørgsmål.
Dokumenter, ikke kun datalinjer: Et fragtbrev eller en tolddeklaration er en fil. Mange datamigreringer flytter databaserækkerne, men efterlader bilagene, fordi de ligger et andet sted.

Sådan strukturerer I migreringen

Frygten for, at et nyt system lammer driften i ugevis, er reel, og den er en af de bedste grunde til at planlægge datamigreringen i faser frem for som én stor overførsel natten før go-live.

Fastlæg skæringsdatoen og reglen for åbne forsendelser. Beslut, hvad der sker med bookinger, der er oprettet i den gamle platform, men endnu ikke afhentet. Den mest driftssikre model er at færdiggøre alt, der er oprettet før skæringsdatoen, i det gamle system, mens alle nye bookinger oprettes i den nye platform. Det forhindrer forsendelser med historik delt på to systemer.
Test på et udsnit først. Vælg én transportør, ét lager eller en bestemt kundegruppe, og kør hele migreringen på det udsnit. Det hjælper med at finde felter, der ikke matcher, forkerte datoformater og manglende referencer, mens det stadig er billigt at rette.
Kontrollér med tal, ikke mavefornemmelse. Sammenlign antal forsendelser, samlet vægt og fakturabeløb pr. måned mellem det gamle og det nye system. Stemmer tallene ikke, ved I præcis, hvilken periode og hvilket felt fejlen ligger i.
Kør parallelt i en begrænset periode. Behold læseadgang til den gamle platform, mens den nye håndterer driften. Det er i den periode, de fleste huller opdages, fordi nogen leder efter konkrete data. Sørg for en skriftlig aftale med den tidligere leverandør om, hvor længe adgangen er tilgængelig, og hvad der sker med data bagefter.
Frys og arkivér. Når parallelperioden slutter, laver I en fuld eksport i et format, I selv kan læse uden leverandørens brugerflade. Filerne skal placeres, hvor økonomi og kundeservice kan finde dem, ikke i en delt mappe, som kun én person ved, hvordan man får adgang til.

Sådan måler I, om migreringen lykkedes

Et platformskifte vurderes ofte alene på fragtprisen. Men datamigreringen påvirker de nøgletal, beslutningstagerne faktisk måles på.

Time-to-ship fra ordre til godkendt afhentning falder, når adresse- og kundestamdata er migreret korrekt, fordi ingen skal taste stamdata ind forfra. Fejlraten på bookinger følger samme mønster, da de fleste indtastningsfejl opstår, hvor data tastes manuelt i stedet for at blive hentet automatisk. Prisen pr. forsendelse påvirkes af de interne arbejdstimer, der går med at rekonstruere historik, som burde have været migreret. Og fastholdelsen af B2B-kunder afhænger blandt andet af, hvor hurtigt kundeservice kan svare på et spørgsmål om en forsendelse fra for flere måneder siden.

Derfor er det værd at fastsætte nogle få konkrete succeskriterier for datamigreringen, før projektet går i gang. For eksempel at kundeservice kan finde en vilkårlig forsendelse fra de seneste 24 måneder frem på under ét minut, og at en transportørfaktura fra perioden før skiftet kan afstemmes uden manuelt opslagsarbejde.

FAQ

Hvor mange års historik skal vi migrere?
Det afhænger af, hvordan data skal bruges. For compliance-data som tolddokumentation og fragtbreve fastlægger lovkrav til opbevaring og kundekontrakter grænsen. For bookinghistorik og afstemningsdata er et praktisk udgangspunkt at se på, hvor langt tilbage jeres reklamations- og faktureringsperioder reelt rækker, og så lægge en sikkerhedsmargin oveni. Data, der aldrig slås op, hører hjemme i et arkiv frem for i det daglige arbejdsområde.

Kan vi ikke bare beholde den gamle platform som arkiv?
Det kan fungere i en overgangsperiode, men det er en løsning med en udløbsdato, I ikke selv styrer. Aftaler skal fornyes, priser kan ændre sig, og adgangen forsvinder, hvis leverandøren udfaser den softwareversion. Brug den gamle platform til at kontrollere migreringen, og sørg for, at I ender med en eksport, som I ejer og kan læse uden at være afhængige af tredjepartssoftware.

Hvem skal eje datamigreringen internt?
Én person med mandat til at prioritere på tværs af drift, økonomi og kundeservice. Uddelegeres opgaven til de enkelte afdelinger, bliver de daglige driftsdata migreret, mens dokumentation og arkiv bliver glemt. Ejeren behøver ikke være teknisk, men skal kunne beslutte, hvilke datasæt der kommer med, og kontrollere, at kontroltallene stemmer.

Datamigrering er den del af et platformskifte, der ikke høster ros, når den gøres rigtigt, men som bliver pinligt tydelig, når den springes over. Den koster typisk et par dages planlægning og et par ugers paralleldrift. Til sammenligning koster manglende historik arbejdstimer i årene efter, hver gang nogen skal finde en forsendelse, som systemet ikke længere kender.

Vil du se, hvordan et skifte kan struktureres i faser med realistiske tidsplaner? Book en gratis demo, så gennemgår vi, hvordan et platformskifte ser ud for jeres setup, før I skriver under på noget.