Feltmobilitet er annerledes enn kontormobilitet
Å bygge en SAP-applikasjon for en lageroperatør med en rugget Android-enhet i hånden, under dårlig belysning, med skitne hansker, er fundamentalt annerledes enn å bygge en Fiori-app for en kontorbruker med god internettforbindelse og en 24-tommers skjerm. Dette grunnleggende poenget overses overraskende ofte i SAP-mobilprosjekter.
Vi har rullet ut mobile SAP-løsninger til over 4000 enheter i logistikkmiljøer, og vi har lært hva som skiller prosjekter som lykkes fra de som ikke gjør det.
Velg riktig teknologiplattform for feltmobilitet
For rene felt-applikasjoner med offline-krav er Neptune DXP SAP Edition vårt klare valg. Grunnen er enkel: Neptune har bygget offline-funksjonalitet som en kjernefunksjon, ikke som en tilleggsmodul.
Neptune DXP offline-arkitektur baserer seg på:
- Lokal datalagring i IndexedDB (nettleser) eller native app-storage
- Delta-synkronisering: kun endringer synkroniseres, ikke hele datasett
- Konflikthåndtering ved gjenoppretting av nettverksforbindelse
- Native app-pakking via Neptune App Store for iOS og Android
Design offline-arkitekturen tidlig – ikke etterpå
Den vanligste feilen i offline SAP-prosjekter er å tenke på offline som en funksjon som legges til etter at applikasjonen er bygget. Offline-arkitektur er fundamentalt i systemdesignet og påvirker:
Dataomfang: Hva skal caches lokalt? Alle materialdata? Kun det som trengs for dagens skift? Offline-dataomfanget er en avgjørende arkitekturveivalg. For stor scope gir lange synkroniseringstider og store datatransfer. For liten scope fører til "offline-feil" når data ikke finnes lokalt.
Synkroniseringsstrategi: Synkroniserer vi ved innlogging (batch), kontinuerlig i bakgrunnen, eller trigger-basert (f.eks. ved skannet strekkode)? Svaret avhenger av datamengde, nettverkskvalitet og brukerscenario.
Konflikthåndtering: Hva skjer hvis to operatører har skannet og oppdatert samme item offline, og begge synkroniserer når de er online igjen? Det finnes ikke et universelt riktig svar – det er en forretningsregel, og den må defineres eksplisitt.
UX for feltbruk: enkelt er bedre
Feltapplikasjoner skal brukes av operatører som ikke er SAP-eksperter. Brukervennlighet i felt betyr:
- Store berøringsflater: Knapper og elementer store nok for engrossister med hansker
- Minimal navigasjon: Én oppgave per skjermbilde, ingen dype menystrukturer
- Strekkodeskanning som primær input: Reduser manuell inntasting til et minimum
- Tydelige feilmeldinger: "Varenummer 12345 ikke funnet i system" er bedre enn "Error 404"
- Offline-indikator: Brukerne skal alltid vite om de er online eller offline
Integrasjonsarkitekturen mot SAP
Mobile SAP-applikasjoner kommuniserer mot SAP backend via OData. For lagerstyring betyr det typisk:
- SAP WM/EWM Transfer Order API for lagerbevegelser
- SAP MM Material Document API for varemottak og utlevering
- SAP PM Notification API for feilmeldinger fra felt
Alle disse API-ene bør konfigureres med riktig autorisasjon for servicebruker, og du bør planlegge for at alle API-kall kan feile (timeout, SAP-nedetid) og håndtere dette i applikasjonslogikken.
Utrulling: planlegg for stor skala fra starten
For utrullinger over 100 enheter er manuell installasjon ikke et alternativ. Du trenger:
- MDM (Mobile Device Management) løsning: Microsoft Intune, Jamf eller tilsvarende
- Automatisk app-distribusjon via Neptune App Store og MDM-integrasjon
- Prosess for app-oppdateringer uten produksjonsstans
- Enhetshåndteringsprosedyrer for tap, skade og erstatning
Vi anbefaler alltid en pilot-fase med 10-20 enheter i produksjonsmiljø før full utrulling. Pilotenedgir muligheten til å oppdage uforutsette problemer uten å forstyrre full drift.