WMS-integrasjon hos Constellation Cold Logistics: fra direkte databaseskriving til én datamodell

Ett filområde, skrevet rett inn i databasen

Utgangspunktet var ett felles SFTP-filområde på en lokal server, knyttet til AS/400. Alle kundene leverte filer på samme sted, og filene ble hentet og skrevet rett inn i databasetabellene, melding for melding. Det fantes ikke noe felles lag og ingen felles struktur. Hver kundes særegenheter lå i koden som skrev filene inn i tabellene, og en ny kunde betydde at alt måtte bygges på nytt. Noen kunder brukte ikke EDI i det hele tatt.

Det skjulte problemet

Det var ikke bare datamodellen som var udokumentert. Det samme gjaldt rørleggerarbeidet.

• Hver ny kundekobling reiste de samme spørsmålene: henter vi filen, eller leverer de den? SFTP eller et API vi selv må hente fra? Og hvilket format ligger egentlig i filen?
• Kunnskapen satt hos enkeltpersoner, ikke i dokumentasjon. De opprinnelige integrasjonene var bygget av noen få, svært erfarne folk, og når de går videre, forsvinner begrunnelsene med dem.
• Gamle kundeprofiler ble beholdt som maler, bare fordi neste onboarding skulle ha noe å kopiere fra.
• AS/400-tabellene som alt ble skrevet inn i, var like udokumenterte som filene som kom inn.

Det er som å arve et hus uten tegninger, der halvparten av rørene sitter inne i veggene. Før man kan legge nye rør, må man finne ut hvor de gamle faktisk går.

Én intern modell per meldingstype

Kjernen i løsningen er én kanonisk datamodell, på engelsk en canonical data model eller CDM, for hver meldingstype: ordrer, forsendelsesvarsler, varemottak, lagerjusteringer og flere. Det er ett standardisert internt format som Constellation selv har full kontroll over. Modellen ble definert ut fra store mengder ekte produksjonsdata på tvers av kundene, analysert ved hjelp av AI, slik at den fungerer generelt og ikke er formet etter én kundes særegenheter. Den fastsetter hvilke felter som minst må være med for at en kunde i det hele tatt kan kobles på.

Tenk på det som et felles arbeidsspråk i diplomatiet. I stedet for at hvert land må ha en tolk til hvert annet land, har hvert land én tolk: fra eget språk til det felles og tilbake. Kommer det et nytt land til, kommer det én tolk til. De andre trenger man ikke røre.

Slik ser en ordre ut i modellen

To nivåer i linjene, pall og under den kolli, gjør at sporbarheten kan ligge på det nivået den enkelte kunde spores på. Onboarding består i å gjøre denne øvelsen én gang: kundens felter til modellen, inn og ut. Alt nedstrøms finnes allerede.

Slik sender kundene det, og slik krever modellen det

Hver melding kan spores, og hver særegenhet er kapslet inn

Hver melding i modellen har med seg sine egne metadata: kildesystem, modellversjon, status og tidsstempel. Går noe galt, enten det er dårlige data fra en kunde, et manglende felt eller en feilet levering, kan det spores til nøyaktig hvilken melding, hvilken kunde og hvilket punkt i kjeden. Muligheten til å bevise og spore hva som skjedde med dataene, og ikke bare flytte dem, var en av de viktigste grunnene til at Constellation valgte Lobster som mellomlag.

• Kundespesifikk logikk ligger i kundens egen profil, ikke spredt utover kjerneprosessen. Én kundes unntak kan ikke velte en annens flyt, og kjernen forblir lesbar.
• En ny kunde er en mappingoppgave: kundens format til og fra modellen, pluss transporten. Resten av flyten finnes allerede, med de obligatoriske feltene definert.
• Ingen binding til ett lagersystem. I dag er det Infor WMS. Byttes det, endres bare mappingen fra modellen til lagersystemet, og et ekstra lagersystem fra et oppkjøp er et tillegg, ikke en migrering.

Målet: onboarding på rundt to måneder

Før betydde onboarding av en enkelt kunde måneder med frem og tilbake, typisk seks til åtte måneder. Med modellen på plass er målet for en ny kobling rundt to måneder, og den første kunden kobles nå på etter den nye modellen. Planen er flere danske kundekoblinger og deretter konsernets andre land. Det første lageret går etter planen i drift på Infor WMS i november 2026, og etter måneder med testing fungerer både standardprosessene og unntakene rundt dem.

Bort fra den lokale serveren og ut som API-er

Alt ovenfor er bygget og i drift. Det som følger nå, er retningen videre, ikke noe som er levert.

• Kundene flyttes bort fra det AS/400-bundne filområdet og over på Lobster: SFTP i Lobster som minimum, HTTP direkte for dem som kan API. Poenget er ikke å avskaffe SFTP, for Lobster snakker nesten enhver protokoll. Poenget er å komme bort fra den lokale serveren.
• Modellen og rapportene eksponeres som eksterne API-er med Lobsters egen OAuth2-tjeneste og tilgangsstyring i API Manager, slik at kundene selv kan hente dataene sine når de vil.
• Onboarding via Trading Partner Manager, der partneroppsett, transport og tilganger samles på ett sted, slik at en API-klar kunde blir et oppsettstrinn i stedet for et utviklingsprosjekt.
• Ikke alle kunder trenger eller har kapasitet til full EDI-integrasjon. Visjonen er en WebEDI-portal for de mindre, der ordre- og lagerdata vises i nettleseren uten EDI-oppsett.

Løsningen var fra starten tenkt for flere lagre og flere land, med kundene holdt atskilt som en del av selve strukturen, ikke som et tillegg. Hvert oppkjøp i konsernet kommer med sine egne systemer og sin egen utgave av AS/400, akkurat som Danmark gjorde. Mønsteret herfra er ikke en dansk løsning, men en gjenbrukbar tegning for det neste oppkjøpet.