Unified Namespace: Hoe metaalbedrijven af komen van hun spaghetti-integraties
Waarom point-to-point integraties je fabriek verlammen en hoe een Unified Namespace als centrale hub dat oplost, van architectuur tot eerste stappen.
Ieder metaalbewerkingsbedrijf dat serieus bezig is met digitalisering kent het verhaal. Je begint met een duidelijke visie, Smart Factory, Industry 4.0, alles connected, en ergens onderweg verandert die droom in een wirwar van koppelingen.
In deze editie leg ik uit waarom dat gebeurt, en hoe een Unified Namespace (UNS) je helpt om er structureel vanaf te komen.
Van droom naar spaghetti
Je begint met een duidelijke visie. Smart Factory. Industry 4.0. Alles connected. Dashboards met real-time data. Operators met tablets in plaats van papieren werkbonnen.
En je gaat aan de slag. Nieuw ERP, of een upgrade. Een koppeling met je lasersnijmachine. Software voor planning. Een dashboard erbij. Nieuwe kantbank, andere leverancier, weer een koppeling.
Ergens onderweg verandert de droom in iets anders.
Je laser koppelt naar je ERP, maar ook rechtstreeks naar je planning, want die ene interface werkt niet lekker. Van daaruit loopt weer een lijntje naar een dashboard. Er zijn koppelingen via XML, via CSV, via API’s. Meerdere leveranciers, elk met eigen consultants, die elkaars systemen niet helemaal snappen en naar elkaar wijzen zodra er iets niet werkt.
Je hebt tientallen lijntjes. Geen overzicht meer. Data die niet helemaal klopt. Mensen die dezelfde informatie op drie plekken invoeren. En ondanks al die systemen staat er toch weer iemand met Excel ernaast om het werkbaar te houden.
Dit is wat ik spaghetti noem.
En het probleem is: hoe meer je groeit, hoe erger het wordt. Elke nieuwe machine, of het nu een freesbank, een plasmasnijder of een lasrobot is, betekent weer meer lijntjes. Op een gegeven moment durf je niks meer aan te passen, want je weet niet wat er dan omvalt.
Waarom dit gebeurt
Het helpt om even uit te zoomen. Kijk naar wat een plaatwerkerij, verspaner of constructiebedrijf elke dag doet, de cyclus die zich steeds herhaalt:
- Verkopen, een klant vraagt iets aan, je maakt een offerte
- Plannen, de order komt binnen, je bepaalt wat wanneer gemaakt moet worden
- Productiebeheer, de planning wordt vertaald naar de werkvloer
- Produceren, machines draaien, operators werken
- Magazijnbeheer, materiaal komt binnen, product gaat naar voorraad
- Verzenden, het product gaat de deur uit
- Factureren, de rekening naar de klant
- Matchen, boekhouding koppelt factuur aan betaling
En dan begint het opnieuw.
Elke stap in die cyclus genereert data. En elke stap heeft data nodig van andere stappen. De vraag is: hoe stroomt die data door je organisatie?
Bij de meeste metaalbedrijven is het antwoord: van systeem naar systeem. Point-to-point. CRM naar ERP, ERP naar planning, planning naar machine, machine naar dashboard. Of erger: via papier, handmatig overtypen, Excel als tussenstation. (Klinkt bekend? Lees dan ook 3 shifts, papierloos, verbonden, real-time, over wat er nodig is om die papieren werkbonnen echt te vervangen.)
Dat is hoe spaghetti ontstaat. Niet door slechte intenties, maar door organische groei zonder onderliggende structuur.
Een andere aanpak: de centrale hub
Wat als je het fundamenteel anders aanpakt?
In plaats van dat systemen rechtstreeks met elkaar praten, laat je ze allemaal communiceren via één centraal punt. Een hub.
Je ERP publiceert data naar die hub. Je CNC-machines publiceren naar dezelfde hub. Je planning leest ervan. Je dashboards lezen ervan. Geen directe lijntjes meer tussen systemen. Alles loopt via dat ene punt.
Dit principe heet een Unified Namespace, een centrale plek waar de huidige staat van je hele operatie samenkomt. Het betekent ook dat je ERP niet langer het middelpunt van je IT-landschap hoeft te zijn, het wordt één van de systemen die publiceren en lezen, net als de rest. (Meer daarover in Waarom ERP niet meer het centrum van je fabriek hoeft te zijn.)
Wat een UNS wel en niet is
Hier ontstaat vaak verwarring, dus laat me het scherp stellen.
Een UNS is geen product. Je belt niet een leverancier om “een UNS te kopen”. Het is een architectuur, een manier van bouwen. Je kiest componenten die bij je situatie passen en zet ze op een bepaalde manier neer.
Een UNS is ook geen traditionele database. Een database is ontworpen om data op te vragen, je stelt een vraag, je krijgt een antwoord. “Geef me alle orders van vorige week.”
Een UNS werkt anders. Het is event-driven. Er gebeurt iets in je fabriek, een machine start, een order komt binnen, een status verandert, en dat wordt direct gepubliceerd naar de hub. Systemen die geïnteresseerd zijn in die informatie, luisteren mee. Ze hoeven niet te vragen, ze krijgen het vanzelf zodra er iets verandert.
Wat je in een UNS ziet is de huidige staat van je fabriek, nu, dit moment. Het is een live beeld, geen historisch rapport.
En als je wél terug wilt kijken?
Dan sluit je een historian aan.
Een historian is een systeem dat meeluistert op de UNS en alles wegschrijft in een tijdreeksdatabase. Elk event krijgt een timestamp. Later kun je terugkijken: wat was de situatie gisteren om 14:32? Hoe ontwikkelde dit proces zich over de afgelopen week?
Die combinatie, real-time status via de UNS, plus historische data via de historian, is precies wat je nodig hebt voor serieuze analyse. Process mining, het herkennen van patronen, en ja, ook AI-toepassingen in de fabriek.
Maar hier zit nog iets belangrijks: die historian staat buiten je andere systemen. Jij bepaalt hoe de tabellen eruitzien. Jij bepaalt hoe de kolommen heten. Jij bepaalt wat je met die data doet. Geen leverancier die voorschrijft hoe jouw data gestructureerd moet zijn.
Het is jouw data. Lokaal. In eigen beheer.
Hoe je data organiseert
Een UNS heeft structuur nodig. Je kunt niet zomaar alles door elkaar publiceren.
De standaard die hiervoor gebruikt wordt is ISA-95, en die volgt eigenlijk gewoon hoe je bedrijf is opgebouwd:
- Enterprise, je hele organisatie, de holding of groep
- Site, een fysieke locatie, een fabriek
- Area, een afdeling binnen die locatie (denk aan: lasersnijden, zetten, lassen, verspaning)
- Line, een productielijn of proces
- Cell, een specifieke machine of werkcel
Dat geeft je een logisch pad voor elke databron. Bijvoorbeeld:
metalfab/utrecht/lasersnijden/lijn-1/trulaser-5030/status
Het mooie is: zodra je dit één keer hebt gedefinieerd voor een bepaald type machine, kun je het herhalen. Nog een laser erbij? Zelfde structuur, andere plek in de hiërarchie. Het schaalt zonder extra complexiteit.
Wat dit oplevert
Drie dingen vallen op als je zo gaat werken.
Het voorkomt spaghetti. Een nieuwe machine, ander merk? Die publiceert naar dezelfde hub. Je hebt geen nieuw integratieproject nodig waarbij vijf partijen om tafel moeten. Eén verbinding naar de hub, en alles wat die data nodig heeft kan meelezen.
Je krijgt real-time overzicht. Je ziet wat er nu gebeurt, niet wat er gisteren in een rapport stond. Dat klinkt misschien als een detail, maar het verandert hoe je besluiten neemt. Je kunt niet verbeteren wat je niet ziet.
Je wordt onafhankelijk. Jouw data, jouw structuur, jouw keuzes. Je zit niet vast aan wat een leverancier heeft bedacht. Als je iets anders wilt doen met je data, kun je dat.
Waar begin je?
Er zijn verschillende manieren om een UNS op te zetten.
Je kunt zelf iets samenstellen met open source tools, de zogenaamde ‘MING’-combinatie. Gratis, flexibel, en je leert precies hoe alles werkt. Voor experimenteren en eerste stappen is dit een prima route.
Zodra je wilt opschalen, pak je door naar platformen die daar specifiek voor gebouwd zijn:
United Manufacturing Hub, open source, veel gebruikt in MKB-metaalbewerking. Dit is waar ik zelf mee werk en wat ik aanbeveel om te starten.
Ignition, enterprise platform met bewezen schaalbaarheid, meer gericht op grotere organisaties.
HiByte, DataOps platform voor data-gedreven organisaties.
FlowFuse, platform voor het beheren en schalen van Node-RED flows in productieomgevingen.
Een opmerking over databases: rondom AI is er veel hype van cloud databases. Blijf daar voorzichtig mee tenzij je ze gebruikt voor cloud applicaties, denk aan combinaties zoals Supabase met Lovable.
Mijn advies: begin klein. Kies één machine, één databron. Zet de structuur op. Bouw een simpel dashboard. Leer hoe het werkt. Dan de volgende stap.
De UNS als fundament voor MES en AI
Wat ik in de praktijk zie: bedrijven die eerst hun UNS op orde brengen, hebben het veel makkelijker als ze daarna een MES-systeem willen inrichten. Je productiebeheer sluit direct aan op de hub in plaats van weer nieuwe point-to-point koppelingen. Hetzelfde geldt voor AI, zonder gestructureerde, betrouwbare data is elk AI-project dweilen met de kraan open.
Verder lezen
Wil je dieper in de techniek duiken? Ik heb een uitgebreide gids geschreven die stap voor stap door de architectuur loopt:
De complete UNS-gids: Versnel de digitale transformatie van je fabriek
Daarnaast is de video-serie van Walker Reynolds een aanrader, de persoon van wie ik dit vakgebied heb geleerd.