Ruttplanering som överlever mötet med en vanlig tisdag

Klockan 07:00 är planen vacker. Fjorton turer, varje bil i arbete, den långa sträckan ut först och stadsjobben staplade bakom. Klockan 09:30 har en förare sjukanmält sig, en mottagares lastkaj är stängd till efter lunch, och en kund som normalt bokar tre pallar i veckan vill ha elva hämtade i dag.

Planen är inte produkten. Omplaneringen är det. De flesta planeringsverktyg säljs på den första planen — optimeraren, kartan, de prydliga färgblocken — och utvärderas på den också, i en demo där ingenting går snett. Det som avgör om verktyget är värt att ha är kostnaden för den andra planen, och den tredje, en helt vanlig tisdagseftermiddag med telefonen igång.

Vad som gör den andra planen dyr

Titta på en trafikledare som planerar om, så kan du räkna kostnaden i det som måste göras för hand. En bokning flyttas från tur 12 till tur 9. Flyttar verktyget den, eller tar du bort den från den ena och knappar in den på nytt i den andra? Räknas stoppordningen, sträckan och ankomsttiderna om, eller behåller tur 9 gårdagens siffror med ett extra stopp påhängt på slutet? Ser föraren ändringen i appen utan att någon ringer? Följer pappersarbetet med — fraktsedeln tillhör nu ett annat fordon och kanske en annan förare.

Var och en av de sakerna, gjord för hand, är en minut och en chans att bli fel. Tio ändringar före lunch är en timmes inknappande och en handfull små fel som dyker upp klockan 16:00 som en leverans ingen gjorde.

Så det första man ska testa i ett planeringsverktyg är inte optimeraren. Det är det här: ta en planerad bokning, flytta den till en annan tur och räkna vad du var tvungen att röra efteråt.

Tillgänglighet är en fråga med fler än ett svar

Det andra som gör en omplanering långsam är att inte veta vad man har. Vilka bilar är lediga klockan 11:00 låter som en fråga och är minst fyra:

• Inte redan på en tur. Den självklara, och den enda vissa verktyg svarar på — returlasten inräknad, inte bara utlasten.
• Inte ur drift. Ett fordon som blev underkänt i morgonens kontroll är inget fordon, vad tavlan än säger. Om kontrollresultaten och planeringstavlan är två skilda system kommer tavlan glatt att erbjuda dig en bil som verkstaden redan tagit ur trafik.
• Inte på verkstad, och inte på väg in. En service inbokad till 13:00 gör bilen tillgänglig för ett förmiddagsjobb men inte för ett på eftermiddagen.
• Laglig för hela jobbet. Kontrollbesiktning och färdskrivarkalibrering som går ut mitt i turen; ADR-intyg, bakgavellyft, kylaggregat som just den här lasten kräver.

Och sedan föraren: kvarvarande körtid, behörigheter, och om hen över huvud taget är i tjänst.

Ett verktyg som bara svarar på den första frågan är inte så mycket felaktigt som ofullständigt, och ofullständigheten landar alltid likadant — som en plan som ser bra ut och inte går att köra. Det användbara beteendet är att neka redan vid planeringen, med skälet med sig: ur drift sedan 06:40, underkänd bromskontroll. En varning som går att klicka förbi är en varning du kommer att klicka förbi klockan 15:00 en dålig dag.

En avvägning värd att säga högt: nekandena måste vara smala. Ett system som stoppar dispatchen för allt det är osäkert på blir ett system planerarna går runt — de planerar i kalkylbladet och matar in det efteråt, vilket är sämre än inget system alls. En försvarbar gräns är att lagkrav som gör fordonet olagligt att köra, och säkerhetsavställningar, nekar; att försäkringen förnyas om nio dagar, en oåtgärdad mindre defekt, ett datum som går ut nästa månad — varnar, och låter planeraren avgöra. Var ett verktyg drar den gränsen är en rimlig fråga i en upphandling, och en dålig sak att upptäcka i vecka tre.

Att berätta det, utan telefonkedjan

Omplaneringen är inte klar när skärmen är rätt. Tre parter ska få veta, och som standard får de veta per telefon: föraren som fått ett stopp, föraren som blivit av med ett, och kunden vars 14:00 just blev 16:30.

Den kedjan är där eftermiddagen faktiskt tar vägen. Det som ersätter den är odramatiskt:

• Föraren ser dagens stopp som de nu ser ut, med ändringen som en push-avisering i stället för ett samtal — och med den nya adressen och kontaktpersonen på stoppet, inte bara ett företagsnamn.
• Kunden ser ändringen själv. En portal eller en spårningslänk slår ett telefonsamtal av samma skäl som ett spårbart paket slår ett leveransfönster: den svarar på frågan i det ögonblick kunden har den, vilket sällan är ett ögonblick då du är ledig.
• Kontoret — den som äger kunden — vet att löftet har flyttat innan kunden ringer och frågar.

Den ärliga brasklappen är att automatisk avisering bara hjälper om den är selektiv. Ett system som skickar en uppdatering varje gång någon rör planen lär alla att ignorera den, och då ignoreras även det enda meddelandet som betydde något. Färre och meningsfulla: stoppet flyttades till en annan dag, tidsfönstret ändrades på riktigt, leveransen misslyckades. Vi har skrivit separat om vad en ärlig leveranstid är värd och om statussamtalen en kundportal tar bort.

Lastbilsanpassad ruttplanering får ett stycke

Ja, rutten måste veta att den är en lastbil: total- och axelvikter, höjd och längd, broar, tunnlar med restriktioner för farligt gods, miljözoner och tillträdesregler, och variationen land för land i högsta tillåtna vikter och mått inom EU. Det spelar roll — en bilrutt skickar ett fyra meter högt ekipage under en bro som inte släpper fram det. Men det är en löst och köpbar förmåga, den ställs in en gång och ändras sällan, och det är inte den som gör tisdagen svår. Ett verktyg med utmärkt lastbilsruttning och en dyr omplanering kostar dig eftermiddagen ändå. Vill du ha detaljerna finns de i en egen artikel.

Optimering, och omdöme

Ett ord om automatisk optimering, eftersom det är vad de flesta planeringsverktyg leder med. Optimerare är bra på den version av problemet som går att skriva ner: sträckor, tidsfönster, kapaciteter, kostnader. De är sämre på versionen i planerarens huvud — den här mottagaren lossar fortare om du kommer före lunchrasten; den här föraren kan platsen och grindkoden; den här kunden håller vi på att vinna och hen får ingen 17:00-tid den här veckan.

Upplägget som håller är att optimeraren föreslår och planeraren bestämmer. Med det följer ett konkret krav: det måste gå att köra över ett förslag och få överstyrningen att sitta kvar, i stället för att tyst göras ogjord nästa gång planen räknas om. Ett förslag man inte kan nåla fast är ett förslag man slutar be om.

Vad du ska prova i en demo

Be om en helt vanlig morgon på er egen data, och ha sedan sönder den:

1. Flytta en planerad bokning från en tur till en annan. Räkna de manuella stegen, och kontrollera att ordning, sträcka och tider räknades om.
2. Underkänn en kontroll på ett fordon och försök sedan planera in det. Nekar tavlan, varnar den, eller erbjuder den bilen som om ingenting hänt?
3. Släpp in en akut order klockan 11:00 och hitta kapacitet. Hur lång tid tar det innan du vet vilka bilar som kan ta den — och på vilket underlag?
4. Ställ in ett stopp mitt i en tur och se vad förarappen och kunden ser, och hur snart.
5. Fråga vad kunden får veta när planen ändras och ingen gör något aktivt åt det.
6. Gör alltihop en gång till. Det är den andra omplaneringen som visar om verktyget hjälper eller bara dokumenterar.

Var navichain står i allt detta

navichain planerar på en dispatchtavla och ett planeringsblad: bokningar dras till bilarna, och det som inte går ihop flaggas innan du bokar. Tillgängligheten tar hänsyn både till bilar som redan går på en tur och till dem verkstaden har tagit ifrån dig — en underkänd kontroll ställer av fordonet i samma system som planerar det, och en kritisk defekt håller det avställt. Ändringar når förarappen och kundens egen portal utan telefonkedja, och aviseringar går till den som berörs i stället för till alla. Ruttplanering är obegränsad i varje plan; det är ingen förmåga man uppgraderar sig till. Priserna är publika, från 995 kr i månaden, med månadsvis fakturering och ingen bindningstid — plattformssidan visar vad som ingår, och är du tidigare i processen är vår checklista för att välja TMS stället att börja på.