Schenker får ny app til sine nye håndterminaler
Du har kanskje sett DB Schenker lastebiler kjørende rundt om i landet? Med disse lastebilene hentes og leveres tusenvis av pakker hver eneste dag. Sjåførene er helt avhengig av å jobbe effektivt, og bruker håndholdte terminaler for å skanne sendinger og kollier, registrere avvik, motta signaturer ute hos kunder og mye mer.
Handlingene sjåførene gjør resulterer i observasjoner som sendes inn til et stort og komplekst kjernesystem. Et problem som har kommet snikende på DB Schenker i Norge, er at de håndholdte terminalene begynner å bli utdaterte. De kjører Windows, med en gammel terminal-app som er vanskelig å vedlikeholde, i tillegg til at selve hardwaren begynner å skrante. Dermed ble det høyt prioritert å få byttet ut de gamle håndterminalene.
De nyinnkjøpte håndterminalene kjører Android, og det ble derfor også nødvendig å utvikle en ny app. Det er her vi i XLENT kom inn i bildet.
Appen lytter til håndterminalens skanner
Håndterminalene har en innebygd skanner, og en av de viktigste oppgavene til appen var å sømløst kobles sammen med skanneren slik at det å lese strekkoder skal gå så effektivt som mulig for sjåførene.
Zebra-teknologien som brukes i håndterminalene, kommer med en app kalt DataWedge. Gjennom DataWedge API-et oppretter vi en såkalt profil som fungerer som broen mellom skanneren og vår app. Vi setter skanner-innstillinger i profilen, og det er gjennom profilen vi får notifikasjoner fra skanneren til appen når en gyldig skann har blitt gjort. Profilens skanner-innstillinger er blant annet hvilke type strekkode-formater som skal godkjennes, og antall tegn i strekkoden som vi skal anse som gyldige/relevante for vår app.
Vi ønsket for eksempel at skanneren skulle ignorere alle strekkoder som var under 10 karakterer, siden postkode-strekkoder (fire karakterer) gjerne befant seg rett ved siden av kollinumrenes strekkoder, og disse skulle ikke appen håndtere. Skanneren skulle altså ignorere disse for å unngå unødvendige feilskanninger for sjåføren. Strekkodene kom også i mange ulike formater og måtte dermed pre-prosesseres litt både i skanner-innstillingene (DataWedge-profilen) og i ettertid i appen, slik at de ble sendt videre inn i kjernesystemet med et format som ble akseptert der.
.NET MAUI
.NET MAUI som teknologi for å lage appen ble et naturlig valg da både IT-avdelingen i Schenker og XLENT jobber daglig med .NET. Det var viktig at appen både skulle være enkel og rask å utvikle, samtidig som at videre vedlikehold ikke skulle bli smertefullt.
Når du velger MAUI som app-teknologi, kan du velge mellom XAML og Blazor som markup. Vi gikk for Blazor, da dette er mest likt en web-tilnærming, og dermed lettere for Schenker-ansatte å vedlikeholde (vi kan vel trygt si at XAML-filer som markup filer er hakket særere).
Det har vært en fornøyelse å jobbe med MAUI fremfor Xamarin (se artikkel: overgang fra Xamarin til MAUI). Utviklingstiden som kreves er betydelig kortere, og det har vært en stor fordel å kunne gjenbruke CSS fra andre web prosjekter i Schenker. Det å utvikle en app i MAUI føles egentlig veldig som å utvikle en webside. Det er lite app-spesifikk kode. Den største forskjellen er kanskje at vi jobber mye med å lagre data lokalt i en SQLite database, for at appen skal føles raskere og for at den skal kunne fungere offline. Dersom en forespørsel ut fra appen krasjer, mellomlagrer vi dataen og forsøker igjen så snart vi er på nett.
Innlogging og tilgangsstyring
Brukere og tilgangsstyring til appen håndteres av en tredjepart, SIMS, som er et internt selskap i Schenker. Tilganger innad i appen styrer vi selv. Brukere i SIMS med riktig app-rolle synkroniseres til oss. For å styre hvilke sjåfører som har tilgang til hvilke transportmidler i appen, har vi laget en webportal for administratorer. Her kan administratorene på terminalene rundt om i Norge styre tilgangene til sjåførene de har ansvar for. Etter to uker i produksjon har vi nå 500 registrerte brukere fordelt på 28 terminaler rundt om i Norge.
Sjåførens tur
Sjåførens turer består vanligvis av fire deler.
- Terminallasting
- Utlevering
- Innhenting (+ uplanlagt henting)
- Retur
Sjåførens dag med håndterminalen starter med terminallasting. Her skanner sjåfør kollinummer. Dersom ikke strekkoden er lesbar for skanneren, kan han også skrive den inn manuelt. Sendingen som kolliet hører til, dukker da opp i appen med informasjon om mottaker og alle kolliene på sendingene. Sjåfør ser om det er meldt skade på noen av kolliene hen skal ta med, og om noen kolli ikke har ankommet terminalen enda. Kolliene som skal tas med, skannes og blir markert i grønn. Når alle kolli på alle sendingene som skal med er skannet, bekrefter sjåfør lasting.
Etter at terminallasting er ferdig, genereres utkjøringslisten som appen henter fra kjernesystemet. Resultatet i appen blir en stoppliste - en oversikt over hvilke stopp som står på planen for transportmiddelet som sjåførens bruker er koblet til.
Utleverings-stopp består av å kjøre kolli ut til kundene som skal motta. Mottakelse består som regel av at kunden signerer på at sendingen er mottatt, men det kan også være andre utleveringsavtaler som gjør at kunden slipper å signere. Appen håndterer de ulike scenarioene og gjør det enkelt for sjåfør å justere utleveringene. Dersom kunde ikke kan eller vil motta registreres det som avvik, og sendingen tas med tilbake for retur.
Motsatt består innhenting av å hente inn pakker. Innhenting-stopp er stort sett planlagte, men det kan også skje at sjåføren blir oppringt og bedt om å hente inn kolli på ekstra stopp. Disse stoppene kaller vi uplanlagte hentestopp. Når sjåfør ankommer et hentestopp, skanner hen alle kolli som skal med. Kolli kan enten være frittstående, eller tilhøre en sending. Sjåfør kan også registrere i appen om det er en skade på et kolli, eller om kolliet er temperatur-sensitivt.
Retur er det siste stoppet på en tur, som består av å levere pakker tilbake til terminal, enten det er fordi kunde ikke ville eller kunne motta, eller om de er blitt hentet inn og skal sendes videre.
Testing
Med et gammelt og komplekst kjernesystem, var det nødvendig med mye testing fra real life scenarioer for å forsikre seg om at observasjoner og skanninger ble riktig registrert. Produkteier Erik Magne Sandvik sitter i Stavanger og har hatt daglig kontakt med sjåfører gjennom hele test-fasen. Etter hver arbeidsdag ga sjåfører tilbakemelding til produkteier, som igjen hadde daglig kontakt med oss utviklere. På den måten fikk vi kontinuerlig tilbakemeldinger om hva som fungerte både teknisk og med tanke på brukervennlighet i appen. Prosessen har vært veldig effektiv, og vi er veldig fornøyde med å ha hatt en så engasjert og nyttig produkteier, som har vært veldig lav-terskel å holde kontakt med hele veien.
Robusthet
Det hender at sjåførene må skanne sendinger eller kolli på plasser der det er lite eller ingen mobildekning. I disse tilfellene har det vært veldig viktig å mellomlagre data slik at mislykkede sendinger fra appen blir sendt så snart appen har tilgang til nett igjen. Å få på plass en robust app har vært veldig viktig i denne prosessen. Det skaper mye trøbbel og manuelt arbeid dersom observasjoner forsvinner, eller dersom kunders signaturer ikke kommer frem til riktig system.
SOTI
I tidligere apputviklingsprosjekter har vi vært vant med å jobbe med App Store Connect og Google Play Console for å gi ut apper og påfølgende nye versjoner. Dette gjelder altså apper som er tilgjengelige for alle å laste ned på sin mobil. Dette prosjektet har vært annerledes da det kun er sjåfører ansatt hos Schenker som skal bruke appen, og den skal kun være tilgjengelig gjennom Schenker sine håndterminaler.
For utrulling, feilsøking og feilhåndtering har vi brukt et verktøy som heter SOTI. Det er et kjempekraftig verktøy der vi som utviklere har tilgang til å lese all data om enhetene, det gjelder logger, innstillinger, tilganger og nedlastet programvare. I vårt tilfelle har appen vært det eneste håndterminalen skal vise, og dermed er alt annet på android-systemet “låst” for brukeren. Så lenge håndterminal er på nett, kan vi fjernstyre enhetene, oppdatere programvare, endre innstillinger og så videre. Det gjør det veldig enkelt for oss å hjelpe sjåfører dersom feil oppstår. Selv om SOTI er et stort og kraftig verktøy, der det kan være lett å gå seg “vill” fordi det er enormt med muligheter, har vi veldig positive erfaringer. Apper har en tendens til å være vanskelige å feilsøke, men SOTI har gjort den jobben veldig mye lettere. Det å kunne hjelpe terminaler rundt om i hele landet med bare noen få tastetrykk, er gull verdt.
Kort om DB Schenker i Norge
DB Schenker Norge, er en ledende logistikk- og transporttjenesteleverandør i Norge. Selskapet tilbyr et bredt spekter av logistikktjenester inkludert frakt, transport, lagerhåndtering og distribusjon.
DB Schenker Norge er en del av DB Schenker, som er en global logistikkgigant og en del av Deutsche Bahn Group. Schenker Norge jobber med å tilby skreddersydde logistikkløsninger for bedrifter på tvers av ulike bransjer, og fokuserer på effektivitet, pålitelighet og bærekraft i sine tjenester.
Kunde
DB SchenkerProsjekttype
MobilutviklingKontakt
Kontor
Kundens ord:
“Da har jeg vært med på alle innføringer av håndterminaler i selskapet siden 80 tallet og denne gang har det vært en herlig flyt i både rettinger og tilbakemeldinger og aldri har vi hatt så lite frustrasjon i testinnføringen.”