Maatwerksoftware voor de industrie – wanneer een standaard MES-/ERP-systeem geen verstandige keuze meer is

Een standaardoplossing voor productie-uitvoering of ERP kan een verstandige keuze zijn, maar alleen als het werkelijke productieverloop zonder wezenlijke vereenvoudigingen kan worden weergegeven. Anders brengt het systeem wel orde in de registratie, maar ten koste van de bestuurbaarheid van het proces. Op dat moment verliest de vraag naar een functielijst haar betekenis. Dan moet worden beoordeeld of de fabriek haar eigen productie, kwaliteit en onderhoud nog steeds zelf aanstuurt, of het werk gaat aanpassen aan de beperkingen van het hulpmiddel. Als kritische beslissingen, uitzonderingen en blokkades vooral buiten het systeem functioneren, is maatwerksoftware voor de industrie geen luxe. Het wordt dan een manier om samenhang in data, verantwoordelijkheid en operationele controle te herstellen.

Niet elke productie laat zich eerlijk in een standaard­systeem vangen

Een standaard systeem voor productie-uitvoering of ERP werkt goed waar het proces echt herhaalbaar is, verantwoordelijkheden duidelijk zijn en het datamodel het beeld van de fabriek niet vertekent. Onder zulke omstandigheden brengt standaardisatie orde in de informatiestroom, beperkt zij het aantal lokale interpretaties en maakt zij besluitvorming mogelijk op basis van een consistente registratie van gebeurtenissen. Het probleem ontstaat al eerder dan op het niveau van ontbrekende functies. Het begint daar waar het werkelijke verloop van productie, kwaliteit, onderhoud en planning niet meer binnen de logica van het systeem past zonder verlies voor het proces.

Dat is de grens tussen verstandige standaardisatie en verlies van operationele controle. Als de organisatie haar eigen proces begint te omzeilen zodat de gegevens “kloppen in het systeem”, dient de informatiearchitectuur de productie niet langer. Ze gaat die vervormen. Een deel van de regels kan veilig worden geharmoniseerd via configuratie of procedure, maar er zijn ook technologische afhankelijkheden, controlepunten en verantwoordelijkheidslijnen die niet mogen vervagen zonder schade voor de productkwaliteit, de procesveiligheid of de herleidbaarheid van beslissingen. Daarom is de discussie “standaard of eigen oplossing” meestal verkeerd ingestoken. De betere vraag is: welke proceselementen zijn een gemeenschappelijke standaard, en welke vormen de kern van het concurrentievoordeel van de fabriek, een risicobron of een gebied van complianceverplichtingen en moeten dus getrouw worden weergegeven.

In de praktijk zijn niet de ontbrekende modules het duurst, maar de workarounds die ongemerkt de dagelijkse werkwijze worden. Overzichten die naast het systeem worden bijgehouden, handmatig overtypen van gegevens tussen ploeg en kantoor, aantekeningen van operators, informele afstemming van uitzonderingen en parallelle informatiestromen zijn geen kleine ongemakken. Het zijn signalen dat het model voor procesaansturing scheurt. Dan is het zinvol om niet het aantal functies te meten, maar het aantal handmatige punten waar gegevens worden overgeschreven tussen productie, kwaliteit, onderhoud en planning, het aantal kritische uitzonderingen dat buiten het systeem wordt afgehandeld en het aandeel operationele beslissingen dat wordt genomen op basis van gegevens die niet rechtstreeks uit de bronregistratie komen. Als deze indicatoren toenemen, ligt het probleem meestal niet aan een zwakke configuratie, maar aan de verkeerde aanname dat het proces zonder kosten naar het hulpmiddel kan worden omgebogen. In zulke situaties helpen KPI’s in de productieautomatisering om de werkelijke schaal van het probleem zichtbaar te maken.

Dat is goed zichtbaar in fabrieken waar het verloop van een order niet alleen afhangt van de technologische route, maar ook van de werkelijke toestand van de machine, de resultaten van tussentijdse controles, materiaalvrijgaven, chargepartijen, instelparameters en beslissingen die onder tijdsdruk gelijktijdig door meerdere afdelingen worden genomen. Als een standaardsysteem deze afhankelijkheden niet in één betrouwbare dataketen kan vasthouden, valt de waarheid over het proces uiteen over meerdere plaatsen. Een deel blijft in het systeem, een deel bij de machine, een deel in kwaliteitsdocumenten en een deel in de kennis van mensen. Zo’n situatie bemoeilijkt het in kaart brengen van het productieproces, maakt de verantwoordelijkheden van de uitvoerders van de implementatie complexer en vergroot het projectrisico bij integratie met automatisering en SCADA in de automatisering van productieprocessen en met systemen die invloed hebben op machineveiligheid. Maatwerksoftware is niet zinvol omdat een fabriek “iets eigens” wil, maar wanneer de eenheid van proces, brondata en beslissingen behouden moet blijven op plaatsen waar vereenvoudiging een reëel verlies van controle zou betekenen.

Vanuit het perspectief van compliance en operationeel toezicht is dit onderscheid fundamenteel. Als cruciale regels en controlepunten uitsluitend bestaan in de praktijk van het team en niet door het systeem worden afgedwongen of op zijn minst eenduidig worden weergegeven, wordt verantwoordingsplicht voorwaardelijk. In sommige sectoren is dat vooral een probleem van kwaliteit en reproduceerbaarheid van het partijverloop, in andere ook een kwestie van sectorspecifieke eisen, traceerbaarheid, wijzigingsbeheer of de grenzen van verantwoordelijkheid tussen de gebruiker van de fabriek, de integrator en de leverancier van de software. Daarom moet aan de beslissing om het proces ondergeschikt te maken aan het systeem, of het systeem aan het proces, geen functiedemonstratie voorafgaan maar een eerlijke analyse van uitzonderingen. Pas dan wordt zichtbaar welke daarvan organisatorische chaos zijn en welke een afspiegeling vormen van werkelijke technologische, informatie- en veiligheidseisen.

De kosten lopen op waar het systeem het werkelijke risico niet ziet

De hoogste kosten van een slecht passend systeem ontstaan niet in een eenvoudige orderstroom of in dagrapportages, maar op het raakvlak van productie, kwaliteit, onderhoud en procesveiligheid. Juist daar moet een beslissing snel worden genomen, gedocumenteerd zijn en steunen op de volledige context: de actuele machinestatus, batchparameters, de historie van interventies, de status van kwaliteitsvrijgave en de geldende blokkeringen. Als een standaardoplossing voor productie-uitvoering of ERP slechts een deel van dat beeld ziet, blijven de kosten niet beperkt tot gebruiksonvriendelijkheid. Dan ontstaat operationele variatie. Verschillende ploegen nemen vergelijkbare beslissingen op basis van andere gegevens, uitzonderingen worden naar eigen inzicht afgehandeld en de verantwoordelijkheid vervaagt tussen systeem, procedure en de praktijk op de werkvloer.

Het belangrijkste probleem begint wanneer het systeem de werkelijke volgorde van handelingen, de voorwaarden voor blokkeringen, de versiebeheer van technologische parameters of de verantwoordelijkheid voor het goedkeuren van een afwijking niet weerspiegelt. In de registratie kan alles correct lijken, terwijl de uitvoering anders is verlopen. Zo ontstaat een kloof tussen de gebeurtenis en haar digitale spoor. Dat dwingt tot heel concrete ontwerpkeuzes: moeten kritische procesblokkeringen systemisch werken of alleen procedureel; zijn machinegegevens operationeel bewijs of slechts ondersteunend materiaal; en moeten uitzonderingen via een ontworpen beslistraject worden afgehandeld of aan beoordeling naar eigen inzicht worden overgelaten. Als een fabriek steunt op handmatige aanvullingen, extra spreadsheets of interfaces die voortdurend menselijke tussenkomst vereisen, moet de betrouwbaarheid van gegevens niet worden beoordeeld op de vraag of een eindrapport kan worden gegenereerd, maar op de vraag of het verloop van één afwijking, klacht of lijnstilstand zonder discussie kan worden gereconstrueerd.

Een bijzonder risico doet zich voor in fabrieken met een uitgebreid machinepark, waar het systeem moet samenwerken met automatisering, operatorstations en meet- en controleapparatuur. Als de integratie met apparaten slechts gedeeltelijk is, de verzameling van procesgegevens inconsistent verloopt en de wijzigingshistorie verspreid is over controller, paneel, productiedatabase en servicenotities, worden batchtracering en productgenealogie voorwaardelijk. Hetzelfde geldt voor het beheer van technologische wijzigingen. Een wijziging van receptuur, tolerantiedrempel of omstellogica kan formeel zijn goedgekeurd, maar zonder consistent versiebeheer en archivering is later niet meer aan te tonen welke configuratie op het moment van de gebeurtenis daadwerkelijk van kracht was. Dat is geen kwestie van esthetiek van de systeemarchitectuur, maar van reproduceerbaarheid, het vaststellen van grondoorzaken en de afbakening van verantwoordelijkheden tussen productie, onderhoud, kwaliteit en integratieleveranciers.

De kosten van zo’n mismatch zijn zelden zichtbaar in het implementatiebudget. Ze worden pas later merkbaar als diagnostische stilstanden, meer handmatig werk, klachten, discussies over de oorzaak van een gebeurtenis en het verlies van de mogelijkheid om het procesverloop eenduidig te reconstrueren. Daarom volstaat het bij de beoordeling van een oplossing niet om te vragen of het systeem “de productie ondersteunt”. Er moet worden nagegaan hoeveel interfaces handmatige correctie vereisen, hoeveel kritische parameters niet automatisch van versiebeheer worden voorzien of niet consistent worden gearchiveerd, en hoeveel tijd het kost om één operationeel incident te reconstrueren. Als het antwoord luidt: lang, inconsistent en met meerdere onafhankelijke bronnen, dan gaat het probleem niet over gebruiksgemak, maar over de beheersbaarheid van risico’s. Juist hier kan een eigen oplossing, of op zijn minst een dedicated laag boven op een standaardsysteem, gerechtvaardigd zijn: niet om het verleden beter te rapporteren, maar om veilige operationele beslissingen te ondersteunen op het moment dat de fabriek onder tijdsdruk en verantwoordelijkheid draait.

Vanuit compliance-oogpunt betekent dit nog iets anders. Waar software invloed heeft op het verloop van beslissingen die van belang zijn voor kwaliteit, traceerbaarheid of procesveiligheid, moet de reikwijdte van kritische functies voortkomen uit een werkelijke risicoanalyse, en niet uit een catalogus met standaardmodules. Dat geldt in het bijzonder voor integratie met machines, de afhandeling van uitzonderingssituaties en de punten waar het systeem een bepaalde volgorde van handelingen moet afdwingen of de overgang naar de volgende fase moet blokkeren. In zulke gebieden is het zinvol om registratiefuncties te scheiden van functies die onderdeel worden van de operationele beheersing en een zwaardere ontwerpverantwoording vereisen, ook in de context van machineveiligheid en de verantwoordelijkheid van de integrator.

Eerst het beslisontwerp, daarna de code

Een verstandige beslissing over de doorontwikkeling van een systeem in een fabriek begint niet met een functielijst, maar met een kaart van de operationele beslissingen die de software moet ondersteunen of afdwingen. Er moet worden vastgesteld wie de beslissing neemt, op basis van welke gegevens, binnen welke tijd en met welk effect op productie, kwaliteit, traceerbaarheid of procesveiligheid. Pas tegen die achtergrond wordt zichtbaar of een standaardoplossing voor productie-uitvoering of ERP de kern van het probleem afdekt, of alleen achteraf de registratie ordent. Als niet de registratie van de gebeurtenis zelf kritisch is, maar de blokkering van de start van de volgende bewerking, de voorwaarde voor batchvrijgave, de bevestiging van de juistheid van machine-instellingen of de afhandeling van een afwijking, dan luidt de vraag niet “heeft het systeem dit”, maar “kan het op het juiste moment de juiste beslissing afdwingen”.

Deze manier van denken brengt ook orde in het ontwerp van de architectuur. In de praktijk werkt een hybride opzet meestal het best. Een standaard ERP of productie-uitvoeringssysteem moet blijven waar het proces gemeenschappelijk, herhaalbaar en goed beschreven is door een volwassen datamodel: in planning, productieverantwoording, magazijnbeheer en de basisregistratie van orders en batches. Een dedicated laag is zinvol wanneer die de logica overneemt die kritisch is voor een specifieke fabriek: integratie met machines, validatie van gebeurtenissen uit meerdere bronnen, afhandeling van uitzonderingen, goedkeuringsroutes, audittrail en de koppeling van beslissingen aan een concrete batch, machine en verantwoordelijke persoon. Voorwaarde voor succes is wel dat de verantwoordelijkheidsgrenzen vooraf worden vastgelegd. Het team moet bepalen wat tot het technologische proces behoort en aan de kant van automatisering of besturing blijft, wat het domein is van ERP of het productie-uitvoeringssysteem, wat de integratielaag uitvoert en wat nog steeds in organisatorische procedures moet blijven.

Zonder zo’n verdeling ontstaat kostbare improvisatie. Dezelfde voorwaarde wordt dan op meerdere plekken vastgelegd, uitzonderingen worden handmatig afgehandeld en na enkele maanden kan niemand nog eenduidig aanwijzen welk systeem verantwoordelijk is voor een beslissing die het proces blokkeert of vrijgeeft. Een goed dedicated ontwerp bestaat dus niet uit het kopiëren van een kant-en-klare oplossing op kleinere schaal. Het doel is een concrete besliskloof te sluiten. Daarom is het al in de ontwerpfase zinvol om een lijst op te stellen van kritische beslissingen die vandaag geen systeemondersteuning of afdwinging hebben, en die vervolgens af te zetten tegen het aantal procesuitzonderingen dat de oplossing vanaf de eerste ingebruikname moet afhandelen. Dat is belangrijker dan een uitgebreide specificatie van schermen.

Een praktisch voorbeeld is eenvoudig. Een kant-en-klaar systeem kan de productie, het materiaalverbruik en de magazijnontvangsten correct verwerken, maar geen rekening houden met specifieke kwaliteitsblokkades die samenhangen met de voorwaardelijke vrijgave van een batch. Een batch kan formeel geproduceerd en geboekt zijn, en toch niet naar de volgende stap mogen zonder bevestiging van bepaalde testresultaten, de omstelstatus van de lijn of het opheffen van een afwijking uit de vorige bewerking. Als zo’n voorwaarde nu wordt bewaakt via telefoon, een spreadsheet of een handtekening op een afdruk, dan is dat geen kwestie van procesesthetiek maar een lacune in de sturing van verantwoordelijkheden. In zo’n situatie is een volledige verbouwing van het ERP of productie-uitvoeringssysteem meestal niet gerechtvaardigd. Een dedicated laag volstaat, die gegevens ophaalt uit machines en bronsystemen, de volledigheid van gebeurtenissen controleert, de juiste goedkeuringsroute start en een eenduidige batchstatus doorgeeft aan het bovenliggende systeem. De standaard blijft standaard, en de kritische logica wordt vastgelegd waar die daadwerkelijk beheerd en onderhouden kan worden.

Als de fabriek nog geen kostengegevens heeft, hoeft u die niet te raden. Het volstaat om te beginnen met meten hoeveel tijd handmatige omwegen, extra afstemmingen, batchcorrecties en de verificatie van verschillen tussen het systeem en de werkelijke processtatus maandelijks kosten. Dergelijk materiaal maakt het mogelijk om een gerechtvaardigde dedicated laag te onderscheiden van een project dat “voor de zekerheid” wordt gebouwd. Het helpt ook bij een juiste rolverdeling aan de businesskant. Over de omvang van de in het systeem vastgelegde logica mag niet alleen de IT-afdeling of de integrator beslissen, maar gezamenlijk productie, kwaliteit, onderhoud, de verantwoordelijken voor digitalisering en, waar dat relevant is, de samenwerking tussen integrator, software house en onderhoudsafdeling, evenals machineveiligheid en operationele conformiteit.

Vanuit het oogpunt van ontwerpverantwoordelijkheid heeft dit nog een consequentie. Hoe dichter software komt bij procesovergangen, operationele blokkades, de juistheid van de volgorde van handelingen of gegevens die rechtstreeks van de machine afkomstig zijn, hoe minder die als een neutrale IT-toevoeging kan worden behandeld. In dat bereik zijn expliciete ontwerpuitgangspunten nodig, een beschrijving van de grenzen van werking en onderhoud, regels voor wijzigingsbeheer en een verifieerbaar spoor van wie de kritische logica heeft goedgekeurd en op welke basis. Daarom is het verstandig om vóór de eerste regel code wordt geschreven niet alleen de functionele eisen goed te keuren, maar vooral ook het beslisontwerp: wat het systeem moet afdwingen, wat het niet mag toestaan en op welk punt de mens de laatste verantwoordelijke instantie blijft.

Conformiteit is het resultaat van een goed ontwerp, geen decoratie na de implementatie

In een industriële fabriek is software geen neutrale aanvulling op het proces, maar onderdeel van de manier waarop het wordt uitgevoerd. Ze kan de volgorde van handelingen bepalen, de overgang naar de volgende stap blokkeren, de volledigheid van gegevens afdwingen, de goedkeuringsroute sturen en bepalen of na een gebeurtenis het besluitvormingsverloop en de verantwoordelijkheid kunnen worden gereconstrueerd. Daarom begint conformiteit niet met het achteraf toevoegen van formele eisen aan het einde van de implementatie. Ze begint bij het ontwerp, waarin bewust wordt vastgelegd welke beslissingen het systeem zelfstandig neemt, welke het alleen ondersteunt, welke gegevens als bindend worden beschouwd en wie eigenaar is van de regels, uitzonderingen en wijzigingen.

Als die ordening niet al in de architectuurfase van de oplossing wordt aangebracht, is later verwijzen naar kwaliteitseisen, procesveiligheid of documentatieverplichtingen in feite slechts schijn. Dat is vooral van belang wanneer het systeem invloed heeft op beslissingen die cruciaal zijn voor de productkwaliteit, de procesveiligheid of de samenwerking met machines en installaties. In zo’n context moeten conformiteitseisen operationeel worden opgevat: als de noodzaak van consistente werking, traceerbaarheid, wijzigingsbeheer en geschiktheid van de oplossing voor het werkelijke gebruik. Het gaat er niet alleen om dat een functie beschikbaar is, maar ook dat kan worden aangetoond waarom zij juist zo werkt, wie de logica ervan heeft goedgekeurd en hoe de gevolgen van wijzigingen worden beoordeeld.

De meeste problemen komen doorgaans niet aan het licht bij de ingebruikname, maar pas na enkele maanden gebruik. De fabriek voegt een nieuwe productievariant toe, wijzigt de acceptatiecriteria, sluit een extra werkstation aan of verlegt een deel van de verantwoordelijkheid van de operator naar het systeem. Als vooraf niet is vastgelegd welke categorieën beslissingen en registraties een audittrail moeten achterlaten, ontstaat al snel discussie over wiens wijziging invloed had op de kwaliteit, een stilstand of een onjuiste reactie van het systeem. Dan wordt pas duidelijk wat het verschil is tussen een oplossing die werkt en een oplossing die beheersbaar is. Bij die laatste is vooraf duidelijk welke onderdelen van de logica een formeel goedkeuringstraject vereisen, wie de referentiegegevens beheert, wie de integratie met de automatisering onderhoudt en of de projectdocumentatie toereikend is voor audit, onderhoud en een veilige overdracht van het systeem aan een andere opdrachtnemer.

• welke beslissingen het systeem neemt of mede vormgeeft op het gebied van kwaliteit, veiligheid en samenwerking met de machine,
• welke gebeurtenissen, wijzigingen en goedkeuringen een reproduceerbaar spoor moeten achterlaten,
• wie eigenaar is van de bedrijfsregels, gegevens en uitzonderingen en wie wijzigingen daarin goedkeurt.

Pas na zo’n ordening heeft het zin om het project te toetsen aan de wettelijke en normatieve eisen die gelden voor de specifieke fabriek, het product, de branche en de wijze van integratie met machines of installaties. In de Nederlandse en Europese praktijk luidt de vraag niet alleen of de oplossing werkt, maar ook of de organisatie kan aantonen waarom zij op deze manier werkt, op basis waarvan de regels zijn goedgekeurd en hoe wijzigingen worden beheerd zonder afbreuk te doen aan de traceerbaarheid. De reikwijdte van deze analyse hangt altijd af van de toepassing: een rapportagesysteem wordt anders beoordeeld dan logica die het procesverloop beïnvloedt, en weer anders dan een integratie die raakt aan de werking van de machine, de risicobeoordeling of de verantwoordelijkheden van de integrator.

De conclusie is eenvoudig. Maatwerksoftware is zinvol wanneer zij verantwoordelijkheden ordent en risico’s beperkt, precies daar waar een standaardoplossing voor productie-uitvoering of ERP kostbare compromissen zou vergen in de proceslogica, het wijzigingstoezicht of de traceerbaarheid van handelingen. Het gaat er dus niet om alles vanaf nul op te bouwen, maar om standaardfunctionaliteit en kritische logica zó van elkaar te scheiden dat het systeem het werkelijke proces in de fabriek ondersteunt in plaats van het te vereenvoudigen ten koste van kwaliteit, veiligheid en traceerbaarheid.