Tankeledere

Den neste AI-skillet: Hvorfor mellomstore logistikkbedrifter må fikse infrastrukturen sin før de kan utnytte AI

mm
Legg til Unite.AI blant dine foretrukne kilder på Google

Diskusjonen rundt AI handler ofte fokuserer på tilgang, med antakelsen om at når et selskap har tilgang til de rette modellene og verktøyene, er den neste utfordringen å finne ut hvordan de skal brukes. For mellomstore logistikkbedrifter er det ikke nødvendigvis der problemet begynner.

På tvers av mange lager og tredjepartslogistikkleverandører (3PL) er gapet sjelden et manglende system. De fleste har allerede et lagerstyringssystem (WMS), en programvare for bedriftsressursplanlegging (ERP) eller regnskapspakke, transportørtilkoblinger og EDI med sine større kunder. Problemet er hva som skjer mellom disse systemene.

Punkt-til-punkt-tilkoblinger akkumuleres over tid. En kunde eller handelspartner blir koblet på én måte, en annen partner blir koblet på en annen måte, og til slutt har ingen en fullstendig oversikt over hvem som snakker med hvem. Integrasjon avhenger også av mennesker, som når noen manuelt taste inn bestillinger fra en kundeportal eller avstemmer gårsdagens forsendelser i et regneark hver morgen. En 3PL kan oppdage at en transaksjon har feilet først når en kunde ringer og spør hvor bestillingen er.

Ingen av disse tingene vises på en IT‑eiendeliste, og det er derfor så lett å undervurdere problemet. 

Problemet ligger i overleveringene

De største driftsproblemene oppstår vanligvis ved overleveringene, der en bestilling, mottak eller forsendelse går fra ett system eller selskap til et annet:

  • En innkommende bestilling som kommer for sent eller er feilformatert kan medføre en tapt bølge og en tapt avsendelsesdato. 
  • En forhåndsvarsel om forsendelse som ikke stemmer overens med det som fysisk ankommer, kan stoppe mottak mens ansatte undersøker hver pall. 
  • En forsendelsesbekreftelse som aldri når kundens system kan skape en faktureringsforsinkelse og føre til en tilbakebetaling, der en forhandler trekker et gebyr for en overholdelsesfeil.

For en 3PL multipliseres disse problemene fordi hver kunde har sine egne formater, regler og forventninger. Lagergulvet fungerer vanligvis bra, men informasjonsflyten rundt det bryter sammen. 

Dette skillet blir viktigere når selskaper introduserer AI i driften, fordi AI kun kan arbeide med den informasjonen som er tilgjengelig for den. Å koble en chatbot eller en copilot til ett system kan være en god demonstrasjon, men det gir ikke det systemet innsikt i en operasjon som spenner over flere systemer.

Innen logistikk krysser de nyttige spørsmålene ofte disse grensene, så et svar om en bestilling kan kreve informasjon fra WMS, ERP og et transport- eller kundesystem. Et AI-verktøy som kun ser én del av prosessen, arbeider med et ufullstendig bilde.

Det er et økende gap mellom selskaper hvis infrastruktur lar AI jobbe med den informasjonen den trenger og selskaper hvis systemer fortsatt er frakoblet, og det er her den neste AI-skillet oppstår. 

AI trenger et grunnlag den faktisk kan arbeide med

En virkelig AI-klargjort infrastruktur bør beskrives i operasjonelle termer snarere enn teknologiske termer. Hver viktig hendelse, som en bestilling, mottak, lagerbevegelse eller forsendelse, bør gå gjennom en felles hub i stedet for en samling av separate tilkoblinger. Formatet en handelspartner sender, bør ikke lenger være lagerets problem. X12, EDIFACT, XML eller JSON bør normaliseres til samme bestilling før noen nedstrøms må tenke på formatet.

Teamene må vite når noe feiler innen minutter, før problemet når en kunde. Den samme informasjonen ansatte bruker for å identifisere og løse disse problemene, bør også være tilgjengelig for programvare og AI‑agenter via rene API‑er som opprettholder eksisterende tillatelser. Det må også finnes en oversikt over hva som skjedde, slik at når AI foreslår noe, kan en person sjekke hvorfor. 

Når disse betingelsene er på plass, blir det mye enklere å legge til AI. Det betyr ikke at en mellomstor bedrift må erstatte hele teknologisk stack. Faktisk trenger en mellomstor 3PL nesten aldri et nytt WMS eller ERP bare for å bli AI‑klar. Den mest praktiske tilnærmingen er å la kjerne­systemene være urørt og fikse tilkoblingene mellom dem.

En enkelt hub som alle systemer og partnere kobler seg til, er mye enklere å administrere enn et nett av enkeltstående lenker.

AI kan hjelpe med å bygge infrastrukturen

Dette er også hvor AI kan være spesielt nyttig for mellomstore selskaper. Tradisjonelt har integrasjon krevd at folk leser partneres spesifikasjoner, kartlegger felter manuelt og tester disse kartleggingene én handelspartner om gangen. En enkelt partnerkart kan ta uker med praktisk arbeid, testing samt frem og tilbake med partneren.

Nåværende AI-modeller er i stand til å lese spesifikasjoner og eksempelfiler, foreslå kartlegging og teste den mot reelle transaksjoner. En person kan deretter gjennomgå og godkjenne resultatet.

AI kan redusere det manuelle arbeidet som kreves for å lage den første versjonen av en EDI-mapping. Spesialisten kan starte med et utkast, deretter gjennomgå og korrigere det før det sendes gjennom partnerens eksisterende gjennomgangssyklus, slik at spesialister bruker mindre tid på å bygge mappinger felt for felt samtidig som de beholder kontrollen over sluttresultatet.

Men det er en viktig forskjell mellom å bruke AI for integrasjon og å stole på AI med integrasjon.

Når jeg gjør dette, bruker jeg en tilnærming jeg kaller «Propose, Ground, Verify, Confirm».

AI foreslår partneroppsettet og felttilordningen. Det er forankret i den faktiske spesifikasjonen og prøvefilene i stedet for å finne på felter eller koder. En separat verifiseringsprosess sammenligner mappingen felt for felt mot et ekte dokument. Deretter bekrefter en person resultatet før det når en live kundestrøm. 

Vi lærte hvorfor den disiplinen er viktig ved å teste AI-genererte mappinger mot ekte produksjonsdokumenter.

I en test leste en AI-generert mappe et lageroverføringsdokument uten feil, men dro fortsatt alle 15 linjeposter. I en annen beholdt den alle seks parter på en fraktordre, men mistet koden som identifiserte hvilken part som var mottaker, samt gateadressen. Vår automatiserte sjekk kalte mappingen ren, og en EDI-spesialist oppdaget gapet.

Selv referansedata kan være feil. En standardfil som hevdet å ha blitt kryssjekket, var i strid med den publiserte standarden på hvert omstridt segment vi testet.

Leksen er at et delvis resultat kan være vanskeligere å oppdage enn et helt savnet. Verifisering må sammenligne hvert felt i et ekte dokument med det mappingen fanget. Å bekrefte at et dokument kan parses er ikke nok. 

Pålitelige resultater avhenger av disiplinen rundt modellen, fra hvordan den brukes til hvordan resultatene gjennomgås.

Verdien starter før AI tar en beslutning

Infrastrukturarbeid har også verdi lenge før en AI‑agent begynner å gi operasjonelle anbefalinger. En 3PL vi samarbeidet med kjørte SAP ved siden av lagerstyringssystemet. Hver innkommende mottakelse tok tre til fem minutter med manuell registrering, og lagerbeholdningen i SAP lå omtrent 20 minutter bak dokken.

Når de to systemene ble koblet direkte, ble den forsinkelsen nesten sanntid. Operasjonen sparte mer enn 980 arbeids timer per år, inkludert 775 timer på utgående arbeid. Regnearksporing forsvant, mens etiketter, fraktbrev og pakningslister begynte å genereres automatisk. Lageret beholdt sine eksisterende arbeidsflyter, så ingen på gulvet måtte omskoleres. 

Leksen vi tok fra det prosjektet var større enn arbeidsbesparelsene. Når to systemer deler ett oppdatert bilde, er det samme bildet det en AI‑agent trenger for å være nyttig.

Å koble dem sammen er steget som gjør alt etterpå mulig. 

AI‑beredskap starter med integrasjon

For selskaper som bestemmer seg for hvor de skal begynne, bør integrasjon komme først, med AI som gjør mesteparten av integrasjonsarbeidet. Altfor ofte gjør operasjoner feilen å behandle AI som noe som kun hører til på slutten av prosessen. Det kan bidra til å gjøre integrasjonsarbeidet raskere og billigere i starten, deretter hjelpe med beslutninger når den grunnleggende strukturen er på plass. 

Mellomstore logistikkselskaper trenger ikke nødvendigvis mer teknologi. Mange har allerede systemene de trenger. Muligheten ligger i å få disse systemene til å samarbeide. Det er her AI kan spille en rolle som går utover å bare generere et nytt svar på en skjerm. 

Suresh Chappidi er President og administrerende direktør i SC Codeworks, der han bygger programvare etter ett prinsipp: kunstig intelligens bør være produktet, ikke en funksjon som er festet på et.