Hoe zie je dat het datamodel het probleem is?
De signalen zijn herkenbaar als je ze eenmaal ziet. Orders worden gedupliceerd omdat het systeem geen suborders kent, dus iemand maakt er twee aparte orders van en houdt de samenhang bij in zijn hoofd. Er verschijnen Excel-bestanden naast het systeem: één voor de actuele status van een order, één voor de afwijkingen die niet in een veld passen, één voor de uitzonderingen die de planner handmatig bijhoudt. Rapportages kloppen niet meer met de werkvloer, want de werkelijkheid van een productieorder heeft inmiddels drie lagen die het systeem als één regel ziet. Dit zijn geen gebruikersproblemen. Dit zijn ontwerpproblemen. Het datamodel beschrijft een order als een plat object: artikelnummer, aantal, leverdatum. Maar een productieorder in de praktijk heeft subassemblages, halffabricaten, tussenstappen met eigen doorlooptijden, afhankelijkheden per machine of ploeg, en revisies die de planning wijzigen zonder dat het systeem dat bijhoudt. Als het model dat niet aankan, gaat de organisatie ernaast werken.
Waarom is het datamodel bij maatwerk productiesoftware te smal opgezet?
De oorzaak is bijna altijd hetzelfde: het systeem is gebouwd op het productieproces van dat moment. Bij de start was een order eenvoudig. Vijf jaar later zijn er tien productlijnen bijgekomen, levert het bedrijf aan klanten die specifieke configuraties eisen, en worden orders soms halverwege het proces gewijzigd. Maar het datamodel heeft die ontwikkeling niet bijgehouden. Elke keer dat er een nieuwe behoefte was, loste iemand het op met een extra veld, een workaround of een koppeling naar een tweede tabel. Zo ontstaat een model dat technisch functioneert maar conceptueel niet meer klopt. De tabel 'order' bevat inmiddels velden die voor tachtig procent van de orders leeg zijn, en de uitzonderingen worden opgeslagen in vrije tekstvelden die niet doorzoekbaar zijn. Dat is geen softwarefout. Het is het resultaat van incrementele aanpassingen zonder een herontwerp van de onderliggende structuur.
Wanneer helpt een AI-laag en wanneer niet?
Een eerlijk antwoord: een AI-laag helpt als het probleem zit in het verwerken van informatie die binnenkomt, zoals documenten, e-mails of orders van klanten die je wilt inlezen en matchen. Een AI Worker kan die stroom afhandelen en koppelen aan het bestaande systeem. Maar als het probleem zit in wat het systeem daarna doet met die order, dan lost een AI-laag niets op. Als het datamodel een order niet kan splitsen in suborders, geen revisiehistorie bijhoudt en geen afhankelijkheden kent tussen bewerkingsstappen, dan kun je er een AI-laag omheen bouwen en blijf je dezelfde problemen houden. De workarounds verplaatsen zich dan van Excel naar een API-aanroep die alsnog geen antwoord krijgt. Een AI-laag is zinvol bovenop een model dat de werkelijkheid dekt. Het is geen reparatie voor een model dat de werkelijkheid niet meer dekt.
Welke principes helpen bij het herontwerpen van het datamodel voor productiesoftware?
Het goede nieuws: je hoeft niet alles weg te gooien. Een datamodel herontwerpen begint met het in kaart brengen van de echte entiteiten in je proces. Wat is een order in de werkelijkheid van jouw productie? Is het een enkelvoudig object of een hiërarchie? Welke statussen bestaan er, en hangen die per fase af van een andere entiteit? Vanuit die beschrijving bouw je een nieuw model dat de werkelijkheid dekt. Drie principes die daarbij helpen. Eerste: modelleer de hiërarchie zoals die in de operatie bestaat, niet zoals die in het oude systeem zat. Als een order uit suborders bestaat, maak die dan expliciet als aparte entiteit met een relatie. Tweede: sla mutaties op als events, niet alleen de eindsituatie. Een order die wijzigt, moet een revisiehistorie hebben die je later kunt reconstrueren. Derde: houd vrije tekstvelden buiten het operationele model. Als iets relevant genoeg is om bij te houden, is het relevant genoeg om een eigen veld of entiteit te krijgen. Wat historisch in vrije tekst staat, geeft aan welke entiteiten er ontbreken in het bestaande model. Die ontbrekende entiteiten zijn precies waar het herontwerp moet beginnen.
Is een volledig nieuw systeem nodig of kan het bestaande worden uitgebreid?
Dat hangt af van hoe ver het huidige model afwijkt van wat nodig is. Als de kern nog klopt en de uitbreidingen beperkt zijn, kun je het bestaande systeem refactoren: nieuwe tabellen toevoegen, relaties herschikken, de applicatielaag aanpassen. Dat is een technische klus, maar haalbaar zonder opnieuw te beginnen. Als het fundament zelf niet klopt, dat wil zeggen als de centrale entiteiten verkeerd zijn benoemd of als relaties structureel missen, dan is refactoring een lapoplossing die over twee jaar weer vastloopt. In dat geval is een herbouw de eerlijkere keuze. Niet alles hoeft tegelijk: je kunt beginnen met de kern van het datamodel, de meest kritische entiteiten en hun relaties, en de applicatielaag stap voor stap migreren. Wat je niet wilt, is een nieuw model bovenop een oud model plakken. Dan heb je twee modellen die elkaar tegenspreken, en de workarounds komen terug in de synchronisatielaag.