Eliminering af manuelt hverdagsarbejde.

En mellemstor dansk webshop med to-tre tusinde ordrer om måneden bruger typisk mellem femten og femogtyve arbejdstimer om ugen på at flytte data mellem systemer: ordrer ud af shoppen, ind i ERP’et, lagerbeholdninger den anden vej, fragtlabels hos transportøren, sporingsnumre tilbage til kunden. Ingen af opgaverne er svære. De er bare mange, og de skal gøres hver dag.

Regnestykket er brutalt, når man ganger timerne op: over et år er det en fuldtidsstilling, eller mere, brugt på at være bindeled mellem systemer, der aldrig blev forbundet. Og mens arbejdet udføres, opstår der fejl: en lagerbeholdning, der blev rettet for sent, en ordre der blev tastet forkert, en kunde der fik en sporingsmail uden indhold.

Løsningen er ikke at give shoppen adgang direkte til ERP’et og omvendt. Det er et mellemlag, middleware, der oversætter mellem systemerne, håndterer fejl og ejer sandheden om, hvad der er sket. Kommercielle integrationsværktøjer kan flytte data, men sjældent udtrykke forretningens regler. Det skal der kode til.

Principperne i et stabilt integrationslag

• Hændelsesdrevet frem for batch: en ordre behandles, når den opstår, ikke når en fil bliver læst klokken syv.
• Idempotens: hver hændelse bærer en nøgle, så en genforsoeg ikke opretter ordren to gange.
• Retry med backoff og en dead-letter-kø, hvor fejl lander med hele konteksten intakt.
• En oversættelsesmodel: shop, ERP og transportør har hver deres datamodel, og middlewaren ejer mappingen.
• Observabilitet: logs, metrics og alarmer på hvert step, ikke kun på det sidste.

Det er den slags arkitektur, der ikke ser imponerende ud på et diagram. Den ser bare ikke fejl i en kampagneuge.

1. Ordren oprettes i shoppen og udløser en hændelse med ordrenummer, linjer, kunde og valgt levering.
2. Lageret reserveres i samme sekund, ikke når fakturaen køres. Det er den ene detalje, der forhindrer oversalg.
3. ERP’et modtager ordren med en idempotent nøgle og kvitterer; først derefter markerer shoppen ordren som bekræftet.
4. Fulfillment får en pickliste; transportøren får sin booking. Fejler et kald, prøver køen igen, indtil det lykkes, eller lægger sagen til menneskelig behandling med fuld historik.
5. Sporingsnummeret flyder tilbage til ordren og ud i den mail, kunden får, automatisk, med korrekt link.
6. Afslutningsvis afstemmes dagens ordrer på tværs af systemer, så eventuelle afvigelser findes, før nogen opdager dem i regnskabet.

En integration, der ikke fejler, findes ikke. Netværk falder ud, API’er ændrer version, ERP’et kører vedligeholdelse en lørdag nat. Det afgørende er, om fejlen bliver et problem for kunden eller et punkt på en liste, nogen rydder op i. Det kræver, at hvert step er bygget til at kunne fejle: forsoeg gentages med stigende pause, hændelser kan afspilles igen, og der findes en afstemningsrapport, der hver dag sammenligner de tre systemer.

Uden det lag bliver fejlen i stedet et telefonopkald fra en kunde, et hul i lagerbeholdningen eller en ordre, ingen kan finde. Det er den forskel mellem integrationer, der gør driften lettere, og integrationer, der gør den sværere at gennemskue.

Når flowet kører, skal det vedligeholdes som den infrastruktur, det er: overvågning, alarmer, dokumentation og en ejer. Koden skal ligge på din platform og være skrevet, så den kan læses af andre end den, der byggede den. Til gengæld forsvinder de manuelle timer for altid, data bliver korrekte i kilden, og forretningen kan vokse uden at ansætte nogen til at taste hurtigere.

Det er ikke en besparelse på en overskrift i et regnskab. Det er en kapacitet, der bliver ved med at betale sig, hver morgen, uden at nogen åbner to systemer og flytter data i hånden.