Vurdér om integrationen holder til næste års volumen

Holder jeres integration mellem webshop, ERP og transportør til næste års volumen?

En integration mellem webshop, ERP og transportør bliver sjældent bygget til den mængde, den skal bære om halvandet år. Den bliver bygget til den mængde, der lå på bordet, da beslutningen blev truffet. Det fungerer fint, indtil ordrerne stiger, et nyt marked kommer til, eller en transportør bliver skiftet ud midt i en højsæson.

Problemet er, at en integration sjældent falder om. Den begynder bare at kræve mennesker. En medarbejder retter en adresse, en anden retter en vægt, en tredje ringer til transportøren om en pickup, der ikke blev bekræftet. Hver enkelt opgave tager et par minutter, og derfor bliver den aldrig rapporteret som en fejl. Den bliver bare en del af dagen på lageret og i kundeservice.

Når man først lægger timerne sammen, er det typisk for sent at nå at gøre noget ved det inden peak. Derfor giver det mening at teste integrationen på de steder, hvor den erfaringsmæssigt giver efter først, mens der stadig er tid til at ændre noget.

Volumen afslører ikke nye fejl, den forstørrer de gamle

De fleste integrationer har en håndfuld undtagelser indbygget fra dag ét. Ordrer uden brugbar adresse, kolli uden mål, forsendelser til lande hvor den primære transportør ikke kører. Ved 40 forsendelser om dagen er det en overkommelig bunke, som én person tager sig af om formiddagen.

Ved 150 forsendelser om dagen er det ikke længere en bunke. Det er en funktion, som nogen skal bemande, og som bliver flaskehalsen mellem ordre og godkendt pickup. Andelen af problemforsendelser er den samme. Det er konsekvensen, der har ændret sig.

Det samme gælder fakturakontrollen. Når man booker 800 forsendelser om måneden, kan man stikprøve. Når man booker 4.000, kan man enten bruge markant flere timer på kontrollen eller lade være med at kontrollere. Begge dele koster penge, men kun den ene bliver synlig i regnskabet.

De fem steder dataflowet knækker først

Adressedata fra webshoppen

Kundeindtastede adresser er den mest almindelige kilde til bookinger, der ikke går igennem i første forsøg. Postnummer og by matcher ikke, husnummer mangler, eller et firmanavn står i feltet til modtagernavn. Hvis valideringen først sker hos transportøren, kommer fejlen tilbage som et afvist kald, og så skal en medarbejder ind og gætte, hvad kunden mente.

Test det ved at trække en måneds bookinger og tælle, hvor mange der krævede en manuel rettelse før de gik igennem. Gang andelen op med den volumen, I forventer næste år.

Godstyper, paller og dimensioner fra ERP

Her ligger forskellen mellem en webshopforsendelse og en B2B-forsendelse. Pakker er nemme. Paller, langgods, temperaturkrav og farligt gods kræver felter, som ERP-systemet ofte ikke har, eller har som fritekst. Hvis en speditør skal bruge pallepladser og stablingsinformation, og ERP leverer en vægt og en varelinje, så opstår resten af oplysningerne i hovedet på den, der booker.

Det skalerer ikke. Og det er præcis den slags viden, der forsvinder, når en erfaren medarbejder holder ferie eller skifter job.

Undtagelseshåndteringen

Spørg, hvad der sker, når et kald til transportøren fejler. I mange opsætninger er svaret, at ordren bliver liggende, indtil nogen opdager det. Det er acceptabelt ved lav volumen, fordi overblikket findes i hovedet på en person. Ved højere volumen skal der være en kø, man kan se, og en logik for genforsøg.

Et hurtigt tjek er at spørge den ansvarlige, hvordan de ville opdage, at 30 forsendelser ikke blev booket i går. Hvis svaret handler om, at kundeservice ringer, er det ikke en integration, der holder til vækst.

Antallet af transportører

Mange opsætninger er bygget omkring én transportør, med en håndfuld øvrige håndteret i hver sin portal. Når volumen stiger, stiger også behovet for at splitte flowet. Pakker til ét sted, paller til et andet, eksport til et tredje. Hvis hver ny transportør betyder et nyt udviklingsprojekt og endnu et login til medarbejderne, bliver transportørvalget styret af, hvad der er nemt i systemet, frem for hvad der er rigtigt for forsendelsen.

Det er en dyr måde at vælge fragt på, og omkostningen viser sig som fragtpris, ikke som it-gæld.

Afregningsdataene

Et bookingflow, der fungerer, men ikke gemmer de rigtige data, giver problemer i den anden ende. Hvis der ikke ligger en forventet pris på forsendelsen, kan fakturaen ikke kontrolleres automatisk, og så ryger timerne i bogholderiet i stedet for på lageret. Tjek om jeres nuværende opsætning kan svare på, hvad en given forsendelse burde have kostet, uden at nogen slår op i en prisaftale.

Sådan tester du det, inden volumen gør det for dig

Du behøver ikke et stort analysearbejde. Tre målinger giver et rimeligt billede.

Det første er fejlraten på bookinger. Hvor stor en andel af forsendelserne gik ikke igennem i første forsøg i sidste måned, og hvad var årsagerne fordelt. Hvis størstedelen skyldes manglende eller forkerte stamdata, ligger løsningen i integrationen, ikke hos transportøren.

Det andet er tid fra ordre til godkendt pickup. Mål den på de forsendelser, der gik glat, og på dem der krævede indgreb. Forskellen mellem de to tal er den reelle pris på undtagelserne, og den vokser lineært med volumen.

Det tredje er forsendelser pr. medarbejder pr. dag. Hvis det tal har været nogenlunde konstant, mens volumen er steget, betyder det, at I har skaleret ved at tilføje hænder. Det er en holdbar strategi op til et punkt, men det er værd at vide, hvor det punkt ligger, inden man rammer det.

Lav derefter en simpel fremskrivning. Tag næste års forventede volumen, hold den op mod den nuværende fejlrate, og regn på hvor mange timer undtagelserne vil kræve. Det regnestykke er ofte mere overbevisende end en diskussion om, hvorvidt integrationen er god nok.

Hvad der adskiller en integration, der kan vokse

En opsætning, der holder til stigende volumen, har nogle fællestræk. Stamdata valideres så tidligt som muligt i flowet, så fejlen opdages ved ordren og ikke ved labelen. Nye transportører kan lægges til uden at åbne et udviklingsprojekt, enten via et vedligeholdt plugin til det system I allerede bruger, eller via et API, der er dokumenteret godt nok til, at jeres egen udvikler eller leverandør kan arbejde med det. Og bookinger, der fejler, ender i en synlig kø frem for i en indbakke.

Indvendingen mod at gøre noget ved det nu er næsten altid den samme. Der er ikke ressourcer til et it-projekt lige nu. Det er en rimelig indvending, og den peger på det egentlige spørgsmål, som ikke er om integrationen er perfekt, men om den kan ændres uden at man skal rydde et kvartal i kalenderen.

FAQ

Hvornår er volumen høj nok til, at det her bliver et reelt problem?
Det afhænger mindre af antallet af forsendelser end af andelen, der kræver manuel håndtering. En virksomhed med 50 daglige forsendelser og 20 procent undtagelser har et større problem end en med 200 daglige forsendelser og 2 procent. Mål andelen, før du vurderer volumen.

Vi har allerede en integration til vores primære transportør. Skal den rives ned?
Ikke nødvendigvis. Spørgsmålet er, hvad der sker, når transportør nummer to og tre skal med, og om stamdataene fra ERP er gode nok til flere typer gods end dem, I sender i dag. En fungerende integration til én transportør er et godt udgangspunkt, ikke et argument for at lade resten ligge.

Kan en platform håndtere både pakker, paller og vores specifikke godstyper?
Det er det rigtige spørgsmål at stille, og det bør besvares konkret med jeres egne transportøraftaler og godstyper på bordet, ikke med en generel liste over understøttede transportører. Bed om at se, hvordan jeres mest besværlige forsendelsestype ser ud i praksis.

Integrationer bliver sjældent evalueret, før de gør ondt. Det er forståeligt, fordi de fungerer det meste af tiden. Men den dag volumen stiger, er det ikke integrationen, der melder fra. Det er lageret og kundeservice, der begynder at bruge dagen på at rette data, som burde have været rigtige fra starten.

Hvis I står foran at skulle vurdere eller ændre opsætningen, kan I hente tjeklisten “12 spørgsmål at afklare før integrationen sættes i gang”. Den kan bruges som udgangspunkt for samtalen internt og med jeres leverandør, inden der bliver brugt tid på en løsning.