Test før I skifter, kør en pilot med den nye bookingplatform
De fleste logistikansvarlige, jeg har set kigge på en ny bookingplatform, har samme tøven. De ved godt, at den nuværende løsning koster timer hver uge. De kan også se, at en ny platform kunne fjerne en stor del af det manuelle arbejde. Alligevel udskyder de beslutningen. Ikke fordi de er i tvivl om, at der er noget at hente, men fordi alternativet ser ud som et stort skifte med risiko for driften.
Det er en rimelig bekymring. Når bookingen står stille, står forsendelserne stille. Og når forsendelserne står stille, ringer kunderne.
Den gode nyhed er, at platformskifte og integration i praksis ikke behøver foregå som et stort sving fra én dag til den næste. I kan teste det hele i et kontrolleret format, mens den gamle løsning kører videre. Det kaldes en pilot, og det er sandsynligvis den billigste forsikring, I kan tegne, før I træffer en beslutning, der påvirker hele driften.
Hvad en pilot egentlig er
En pilot er en afgrænset test af den nye platform i jeres eget setup, med jeres egne forsendelser, jeres egne transportører og jeres egne medarbejdere. Den kører parallelt med den eksisterende løsning i en aftalt periode. I bruger den nye platform til en del af bookingerne, mens resten fortsætter som hidtil.
Formålet er ikke at bevise, at platformen virker generelt. Det ved leverandøren godt. Formålet er at finde ud af, om den virker hos jer. Det er to forskellige ting.
En pilot giver svar på spørgsmål, ingen demo kan besvare. Hvordan håndterer platformen lige præcis den fragttype, I sender mest af? Hvordan reagerer jeres medarbejdere, når de selv skal bruge den under tidspres? Hvor mange klik koster en typisk booking sammenlignet med i dag? Hvad sker der, når en transportør melder forsinkelse?
Sådan afgrænser I piloten
En pilot, der skal give brugbare svar, har klare rammer fra start. Uden rammer bliver det enten en uforpligtende leg eller et halvt projekt, der trækker ud.
Vælg en konkret del af forretningen. Det kan være en enkelt transportør, en enkelt afdeling eller en bestemt type forsendelser. Et godt valg er det område, hvor I har mest manuelt arbejde i dag. Dér mærker I forskellen tydeligst.
Sæt en tidsramme. Fire til seks uger er typisk nok til, at nyhedens interesse er drevet ud, og I ser den reelle hverdag. Kortere, og I tester kun overfladen. Længere, og piloten bliver til drift uden beslutning.
Udpeg dem, der skal bruge platformen. Ikke nødvendigvis de mest erfarne, men dem, der repræsenterer den daglige bruger. Hvis kun superbrugere tester, får I et skævt billede af, hvordan resten af teamet vil opleve den.
Aftal hvad I måler. Det skal stå på papir, før I starter. Ellers ender diskussionen efter piloten i mavefornemmelser.
Hvad I bør måle
Tid pr. booking er det mest oplagte. Tag stikprøver i den eksisterende løsning før piloten, og sammenlign med den nye. Det giver et tal, I kan regne på.
Fejlrate er det næste. Hvor mange bookinger skal rettes, fordi noget er gået galt undervejs? Hvor mange fakturaer afviger fra det aftalte? Den slags fejl koster mere end folk regner med, fordi de skaber dobbeltarbejde og forklaringer over for kunden.
Brugeroplevelsen tæller også, selv om den er sværere at sætte tal på. Spørg de medarbejdere, der bruger platformen, hvad der virker, og hvad der irriterer dem. Skriv det ned undervejs, ikke først til sidst, hvor detaljerne er glemt.
Endelig integrationen til det øvrige setup. Hvordan spiller den nye platform sammen med jeres økonomisystem, jeres ERP, jeres lager? Det er her, mange platformsskift løber ind i de problemer, der ikke kunne ses i demoen.
Hvor de fleste piloter fejler
En typisk fejl er at lade piloten køre uden ejerskab. Hvis ingen har ansvaret for at samle erfaringerne op, bliver piloten en samling enkeltindtryk, der ikke peger nogen vegne. Udpeg én person, der står for opsamlingen.
En anden fejl er at vælge det forkerte testområde. Hvis I tester på de allernemmeste forsendelser, lærer I ikke noget om, hvordan platformen klarer det svære. Vælg et område, der har reel kompleksitet, men hvor konsekvensen af en fejl er til at håndtere.
En tredje fejl er at sammenligne med en idealiseret version af den nuværende løsning. Husk hvor lang tid I faktisk bruger på fakturakontrol, manuelle opslag og opfølgning hos transportørerne i dag. Det er den reelle baseline, ikke en pæn version af den.
Når piloten er slut
Tag stilling baseret på data, ikke på stemning. Hvis tid pr. booking er faldet, fejlraten er lavere, og brugerne kan se sig selv i den nye løsning, har I jeres svar. Hvis tallene ikke flytter sig, eller hvis integrationen halter, har I sparet jer selv for et fuldt skifte under forkerte forudsætninger.
Tag også stilling til, hvordan udrulningen skal foregå. En pilot, der er gået godt, er ikke det samme som en organisation, der er klar til fuld drift. Planlæg overgangen i etaper. Tag den næste transportør, den næste afdeling, den næste forsendelsestype. På den måde bevarer I kontrollen hele vejen, og I undgår det store skifte, I prøvede at komme udenom fra start.
FAQ
Hvor stor en del af vores bookinger bør køre gennem piloten?
Som tommelfingerregel mellem 10 og 30 procent. Stort nok til at give reelle data, lille nok til at I kan rulle tilbage uden problemer, hvis noget ikke fungerer.
Skal vi betale for piloten?
Det afhænger af leverandøren. Nogle tilbyder en gratis prøveperiode, andre opkræver et reduceret beløb for opsætning og support. Vær opmærksom på, at en helt gratis pilot kan betyde mindre opmærksomhed fra leverandørens side. En modest investering sikrer ofte bedre opfølgning.
Hvad gør vi, hvis pilotresultaterne er blandede?
Forstå hvorfor, før I beslutter. Hvis problemerne ligger i integration til et bestemt system, kan det ofte løses. Hvis problemerne ligger i, at platformen grundlæggende ikke passer til jeres forretningslogik, er det et tegn på at kigge videre.
En pilot er ikke en garanti for, at alt går glat ved et fuldt skifte. Men den er det tætteste, I kommer på et reelt svar, før I binder driften til en ny løsning. Og den koster langt mindre end at fortryde et skifte, der blev truffet på baggrund af en god demo.