Procesautomatisering bij een staalhandel: de 18:30-grens

Het is dinsdag, 17:45, in een magazijnkantoor aan de rand van Mechelen. Karim, de senior inkoper, heeft nog 47 inkoop-bevestigingen openstaan op zijn tweede scherm. De VAN-provider stuurt het EDIFACT DESADV-bestand van de dag om 18:30 weg. Elke coil die buiten gaat zonder verzoende gewichten is drie weken later een factuurdispuut, en vier weken later een telefoontje met een Roemeense walserij.

Het bedrijf is een staalhandel van 33 man — een B2B-trader die koudgewalste coils op voorraad houdt, ze laat slitten en ze uitlevert aan fabrikanten in België en Zuid-Nederland. Ze verwerken zo'n 5.400 inkoop-bevestigingen per week. Op elke bevestiging staat een nominaal gewicht van de walserij, een tolerantieband, en, als de coil de kade al gepasseerd is, een werkelijke weegbrugmeting uit het magazijn. Het verzoenen van die drie cijfers met elkaar, elke dag, op weg naar de 18:30-cutoff, is het proces dat de trader ons heeft laten automatiseren.

Het verschil tussen die cijfers is de hele business.

Wat hieronder volgt is de procesautomatisering-opdracht die de wekelijkse rush rond dat verschil heeft veranderd in een loop van twaalf minuten, zonder dat iemand in Mechelen één van beide systems of record hoeft aan te raken.

Twee systemen die nooit met elkaar spraken

Het voorraadsysteem is een AS/400 van 16 jaar oud — IBM i, zoals het tegenwoordig heet. Verkooporders, klantenstamgegevens, grootboek: alles staat in DB2/400. Het team werkt in 5250-schermen, groen op zwart, en op de werkvloer vindt niemand dat raar. IBM brengt nog steeds nieuwe releases van het OS uit, dus dit is geen doodlopend platform. Het is een platform met een vocabulaire van vijfendertig jaar en geen enkel begrip van een coil.

De coiltraceability draait op een eigen SQL Server 2008-database, in 2011 gebouwd door een Vlaamse consultant en sindsdien stilletjes elk jaar uitgebreid. Elke coil heeft een charge-nummer, een producent, een charge-analyse, een walsroute en een keten van weegbrug-readings. De traceability-database weet welke coil van welke charge van welke walserij komt, en dat is wat de Europese walserij-veiligheidsregels eisen. De AS/400 weet dat niet, en zal het ook nooit weten.

Microsoft heeft de extended support voor SQL Server 2008 in juli 2019 beëindigd. De traceability-server draait nog omdat niemand anders in het gebouw eraan mag komen. We hebben tijdens het eerste scoping-gesprek afgesproken dat wij er ook niet aan zouden komen.

De grens van 1,8 procent

Europese walserijen garanderen op koudgewalste coils doorgaans plus of min 2 procent op het gewicht. Die tolerantie is reëel — een coil van 12 ton kan 200 kg lichter aankomen zonder dat één van de partijen iets fout doet. Het contract tussen de trader en zijn walserij zegt dat het nominale gewicht de basis is voor de bevestiging; het contract tussen de klant en de trader zegt dat de klant betaalt voor het weegbruggewicht op het moment dat het geslitte materiaal de kade verlaat.

Tussen die twee contracten zit een drempel van 1,8 procent — een getal dat hun controlling-team in 2017 heeft gekozen omdat eronder het papierwerk om het verschil terug te halen meer kost dan het verschil zelf. Erboven moet iemand op de werkvloer ernaar kijken.

Vóór we de agent bouwden, betekende "iemand op de werkvloer" Karim, drie collega's en een gedeeld Excel-bestand met de naam weegafwijking_2025_v3_FINAL.xlsx. Vrijdagmiddag had het bestand 70 tabbladen, hadden vier mensen het in hun hoofd zitten, en schoof de 18:30-cutoff minstens twee keer per week op naar 19:15.

De verzoeningsloop

De agent is een kleine Python-service. Hij draait elke twaalf minuten gedurende de werkdag en doet zeven dingen, in deze volgorde:

1. Haalt nieuwe bevestigingen op uit de EDI VAN-inbox (CONTRL-acknowledgements, ORDRSP, IFTMIN).
2. Matcht elke regel met een verkooporder in DB2/400 op basis van de klantreferentie en het ordernummer van de walserij.
3. Haalt de bijhorende charge-nummers en weegbrugmetingen op uit SQL Server.
4. Berekent de gewicht-afwijking ten opzichte van het nominale gewicht.
5. Als de absolute afwijking onder 1,8 procent ligt, schrijft de agent de verzoening terug naar DB2/400 en markeert de regel als clean.
6. Als de absolute afwijking op of boven 1,8 procent ligt, parkeert de agent de regel in de inkoper-queue, met alle drie de bronnen erbij.
7. Om 18:25 genereert de agent de DESADV-envelope voor alle clean lines en geeft die door aan de VAN.

De moeilijke stukken zijn niet de LLM-calls. De moeilijke stukken zitten op de randen. De classifier zelf is twintig regels:

THRESHOLD = 0.018  # 1,8% — controlling-memo, 2017

def classify(line, coil):
    if coil is None or coil.weighbridge_kg is None:
        return "park:no_weighbridge_yet"
    nominal = line.nominal_kg
    deviation = abs(coil.weighbridge_kg - nominal) / nominal
    if deviation < THRESHOLD:
        return "auto"
    return f"park:deviation_{deviation:.3%}"

De randen zijn waar het werk zit.

Lezen uit DB2/400 op een manier waar de IBM i-beheerders vertrouwen in hebben. We gebruiken de IBM i Access ODBC-driver tegen een read-only profiel, en schrijven alleen terug via één insert/update stored procedure die de in-house ontwikkelaar zelf geschreven en goedgekeurd heeft. Geen directe table-mutaties. Nooit.

De SQL Server-schema vertalen — waarin vier generaties conventies opgestapeld liggen — naar één canonieke coil-event view. Dat is tweehonderd regels SQL en één heel geduldige middag met de consultant die het ding gebouwd heeft.

De inkomende EDIFACT parsen. Elke walserij heeft zijn eigen dialect. De Roemeense walserij stuurt ORDRSP met gewichten in het QTY+12-segment; de Italiaanse zet ze in QTY+47; de Duitse stuurt een aparte IFTMIN. We hebben geen generieke EDIFACT-parser geschreven. We hebben drie walserij-specifieke parsers en een router gebouwd. Generieke parsers in dit domein zijn de manier waarop projecten doodlopen.

Elke parse-beslissing vanaf dag één in een versie-gecontroleerde audit-tabel loggen. Het controlling-team heeft een lang geheugen en de strikte gewoonte om maanden later "laat me die beslissing zien" te vragen. De audit-tabel staat in dezelfde SQL Server 2008-box waar we beloofd hadden niet aan te komen — we hebben er één nieuwe tabel voor uitonderhandeld, en die betaalt zichzelf elk kwartaaleinde terug.

Het 18:25-cutoff-venster. De UN/EDIFACT DESADV-envelope moet vóór 18:30 met marge op de server van de VAN-provider staan. Vijf minuten marge, dat hebben we afgesproken; in tweeëntwintig weken draaien heeft de agent het venster twee keer gemist, beide keren omdat de SQL Server-box midden in zijn backup van 18:00 zat. We hebben die backup naar 19:00 verschoven.

De inkoper-queue

De interessante design-vraag was niet hoe je de makkelijke gevallen verzoent. Het was wat je met de afwijkingen doet.

We hebben een kleine queue-interface gebouwd in hetzelfde interne portaal dat het team al gebruikte voor ploeg-planning. Elke geparkeerde regel verschijnt als een kaart met drie panelen: de bevestiging van de walserij, de verkooporder uit de AS/400, en de weegbrug-events uit de traceability-database. De inkoper ziet dezelfde drie cijfers die de agent zag, en dezelfde delta, en kiest één van vier dingen: de afwijking accepteren ten laste van de walserij, ten laste van de klant, een herweging op de kade aanvragen, of escaleren naar de mill-rep.

De queue laat de inkoper de onderliggende cijfers niet veranderen. Hij legt alleen een beslissing vast. Die beslissing is wat terug stroomt naar DB2/400 — via diezelfde stored procedure, met het badge-ID van de gebruiker eraan vast, zodat iemand twee maanden later kan vragen "wie heeft de afwijking van 2,4 procent op charge 81-44109 geaccepteerd?" en binnen twaalf seconden een antwoord krijgt.

Dit klinkt vanzelfsprekend. Het was niet vanzelfsprekend toen we het de eerste keer bouwden. De eerste versie van de queue had een "gewicht aanpassen"-veld dat we in week drie weggehaald hebben, nadat het controlling-team doorhad dat ze geen enkele beslissing van de voorgaande maand meer konden reconstrueren.

Een week in cijfers

Globaal, wat er per week binnenkomt en wat er geparkeerd wordt:

• 5.400 inkoop-bevestigingen ontvangen.
• Ongeveer 4.950 verzoenen netjes onder 1,8 procent.
• Ongeveer 370 belanden in de queue tussen 0,8 en 1,8 procent door een bekende walserij-specifieke kalibratiedrift — die markeren we en ze passeren automatisch zodra het maandelijkse correctiebestand van de walserij binnenkomt.
• Ongeveer 80 zijn echte afwijkingen die een beslissing van een inkoper vragen.
• Twee tot vier worden gemarkeerd als data-integriteitsfouten (een charge-nummer op de bevestiging dat niet in traceability bestaat) en gaan naar de ontwikkelaar die de SQL Server-box beheert.

De 80 per week die een mens nodig hebben, zijn de hele reden dat het team zijn vier inkopers behouden heeft. De 4.950 per week die zonder mens doorstromen, zijn de reden dat die inkopers nu om 17:30 naar huis gaan in plaats van om 19:15.

Vijf maanden verder

Het systeem draait sinds midden januari. Stand van vorige vrijdag:

• De 18:30 DESADV-cutoff is twee keer misgegaan, beide keren om de backup-reden hierboven.
• Het Excel-bestand is sinds week vier niet meer geopend.
• Het team van Karim logt ongeveer 6 uur per week in de queue, tegenover een geschatte 22 uur per week aan verzoeningswerk voorheen. We hebben dat vooraf niet rigoureus gemeten — we hebben ze in december gevraagd een week werk bij te houden als nulmeting.
• Twee factuurdisputen die wél in dispuut zijn gegaan, zijn in het voordeel van de trader beslecht, sneller dan ieder eerder dispuut dat het controlling-team zich kon herinneren, omdat de geparkeerde-regel-historie de boekhouder van de klant dezelfde drie cijfers gaf als de agent.

We hebben de AS/400 niet vervangen, en we hebben de SQL Server 2008-box niet vervangen. Beide blijven operationeel kritisch. De agent is lijm, geen vervanging, en dat was de afspraak van de opdracht.

Die vorm — de systems of record laten staan, de ontbrekende event-laag erbij bouwen — is waarom procesautomatisering in staal, voeding en de delen van logistiek die nog draaien op wat ze in 2008 draaiden, überhaupt werkt. De systemen zijn niet kapot. Ze zwijgen over de events waar de business eigenlijk over discussieert, en de agent geeft die events een stem die de systemen wél kunnen horen.

Drie dingen die we anders zouden doen

Ten eerste zouden we het werk aan de EDIFACT-dialecten vóór het offreren goed in kaart brengen. We zijn vier werkdagen langer bezig geweest met de drie walserij-specifieke parsers dan verwacht, omdat de Duitse walserij in februari zonder waarschuwing zijn IFTMIN-structuur veranderde en we onze discovery-tooling in productie hadden geschreven. Een volgende keer zijn de eerste twee weken een parse-and-log-only modus op live verkeer, zonder dat de verzoeningslogica al draait.

Ten tweede zouden we het backup-venster van SQL Server in week één verschuiven, niet in week tien. De backup van 18:00 was een ongeschreven conventie die niemand benoemde tot we erover struikelden. Een "wat draait er ergens op een cron"-audit op dag één had dat eruit gehaald.

Ten derde zouden we de queue-kaart bouwen vóór de verzoeningsloop. De vorm van de kaart dwingt elke moeilijke vraag af: wat moet de inkoper zien, welke beslissingen zijn legitiem, wat wordt teruggeschreven, wie tekent af. Als we die vragen eerst hadden beantwoord, had dat onze DB2/400 stored-procedure anders laten ontwerpen.

Wat je vandaag nog kunt doen

Als je een operatie draait met twee systemen die het nooit eens zijn geweest over hetzelfde cijfer, schrijf op vanaf welke drempel een mens ernaar kijkt. Niet de gemiddelde afwijking. Niet het worst case. De grens. Als die grens niet op papier staat, wordt de queue die je uiteindelijk bouwt drie keer herontworpen. Toen wij deze procesautomatisering-agent voor de Mechelse trader bouwden, was de grens — 1,8 procent — het enige getal waar we niet over hoefden te discussiëren. Het team had het in 2017 vastgelegd en het stond in een controlling-memo die niemand in vijf jaar gelezen had. Die memo bespaarde ons twee weken.