WMS-integration hos Constellation Cold Logistics: fra databaseskrivninger til én datamodel

Én fildeling, skrevet direkte ind i databasen

Udgangspunktet var én fælles SFTP-fildeling på en lokal server, bundet til AS/400. Alle kunder afleverede filer samme sted, og filerne blev hentet og skrevet direkte ind i databasetabellerne, besked for besked. Der var intet fælles lag og ingen fælles struktur. Hver kundes særheder boede i den kode, der skrev deres filer ind i tabellerne, og en ny kunde betød, at den leg blev bygget igen. Nogle kunder var slet ikke på EDI.

Den skjulte smerte

Det var ikke kun datamodellen, der var udokumenteret. Rørføringen var det også.

• Hver ny kundeforbindelse rejste de samme spørgsmål: henter vi filen, eller leverer de den? SFTP eller et API, vi selv skal trække fra? Og hvilket format er der egentlig i filen?
• Viden sad hos enkeltpersoner, ikke i dokumentation. De oprindelige integrationer var bygget af få, meget erfarne folk, og når de går videre, går begrundelserne med dem.
• Gamle kundeprofiler blev bevaret som skabeloner, alene fordi den næste onboarding skulle have noget at kopiere fra.
• AS/400-tabellerne, som alt blev skrevet ind i, var lige så udokumenterede som filerne, der kom ind.

Det svarer til at arve et hus uden tegninger, hvor halvdelen af rørene sidder inde i væggene. Før man kan lægge nye rør, må man finde ud af, hvor de gamle faktisk går.

Én intern model pr. beskedtype

Kernen i løsningen er én kanonisk datamodel, på engelsk en canonical data model eller CDM, for hver beskedtype: ordrer, forsendelsesadviser, modtagelser, reguleringer og flere. Det er ét standardiseret internt format, som Constellation selv har fuld kontrol over. Modellen blev defineret ud fra store mængder rigtige produktionsdata på tværs af kunderne, analyseret med hjælp fra AI, så den holder generelt og ikke er formet efter én kundes særheder. Den fastlægger de felter, der som minimum skal være der, for at en kunde overhovedet kan kobles på.

Tænk på det som et fælles arbejdssprog i diplomati. I stedet for at hvert land skal have en tolk til hvert andet land, har hvert land én tolk: fra eget sprog til det fælles og tilbage. Kommer der et nyt land til, kommer der én tolk til. De andre rører man ikke.

Sådan ser en ordre ud i modellen

To niveauer i linjerne, palle og derunder kolli, gør, at sporbarheden kan hænge på det niveau, den enkelte kunde spores på. Onboarding er denne øvelse, én gang: kundens felter til modellen, ind og ud. Alt nedstrøms findes allerede.

Sådan sender kunderne det, og sådan kræver modellen det

Hver besked kan spores, og hver særhed er indkapslet

Hver besked i modellen bærer sine egne metadata: kildesystem, modelversion, status og tidsstempel. Går noget galt, dårlige data fra en kunde, et manglende felt, en fejlet levering, kan det spores til præcis hvilken besked, hvilken kunde og hvilket punkt i kæden. Muligheden for at bevise og spore, hvad der skete med data, og ikke kun flytte dem, var en af de vigtigste grunde til, at Constellation valgte Lobster som mellemlag.

• Kundespecifik logik bor i kundens egen profil, ikke spredt gennem kerneprocessen. Én kundes undtagelse kan ikke vælte en andens flow, og kernen forbliver læselig.
• En ny kunde er en mappingopgave: deres format til og fra modellen, plus transporten. Resten af flowet findes allerede, med de obligatoriske felter defineret.
• Ingen binding til ét lagersystem. I dag er det Infor WMS. Skiftes det, ændres kun mappingen fra modellen til lagersystemet, og et ekstra lagersystem fra et opkøb er en tilføjelse, ikke en migrering.

Målet: fra måneder til uger

Før betød en enkelt kundes onboarding måneders frem og tilbage, typisk seks til otte måneder. Med modellen på plads er målet for en ny forbindelse omkring to måneder, og den første kunde bliver koblet på efter den nye model i øjeblikket. Planen er flere danske kundeforbindelser og derefter koncernens andre lande. Det første lager går efter planen i drift på Infor WMS i november 2026, og efter måneders test holder både standardprocesserne og undtagelserne omkring dem.

Væk fra den lokale server og ud som API'er

Alt ovenfor er bygget og i drift. Det følgende er retningen, ikke leverancen.

• Kunderne flyttes væk fra den AS/400-bundne fildeling og over på Lobster: SFTP hostet i Lobster som minimum, HTTP direkte for dem, der kan API. Pointen er ikke at afskaffe SFTP, for Lobster taler næsten enhver protokol. Pointen er at forlade den lokale server.
• Modellen og rapporterne udstilles som eksterne API'er med Lobsters egen OAuth2-tjeneste og adgangsstyring i API Manager, så kunderne selv kan hente deres data, når de vil.
• Onboarding via Trading Partner Manager, hvor partneropsætning, transport og adgange samles ét sted, så en API-parat kunde bliver et opsætningstrin frem for et udviklingsprojekt.
• Ikke alle kunder har brug for eller kapacitet til fuld EDI. Visionen er en WebEDI-portal til de mindre, hvor ordre- og lagerdata ses i browseren uden EDI-opsætning.

Løsningen var fra starten tænkt til flere lagre og flere lande, adskilt pr. kunde som en egenskab ved strukturen, ikke som en tilføjelse. Hvert opkøb i koncernen kommer med sine egne systemer og sin egen udgave af AS/400, præcis som Danmark gjorde. Mønstret herfra er ikke en dansk løsning, men en genbrugelig tegning til det næste opkøb.