De ontwikkeling van de fabriek en de IT/OT-architectuur: waarom keren geïmproviseerde integraties zich na enkele jaren tegen u?

Waarom dit onderwerp vandaag relevant is

De ontwikkeling van een fabriek betekent steeds minder vaak dat er simpelweg één machine wordt bijgeplaatst of een extra lijn los van de rest in bedrijf wordt genomen. Meestal gaat het om de uitbreiding van een omgeving waarin productiesystemen, technisch onderhoud, kwaliteit, planning, magazijn en managementrapportage gegevens moeten uitwisselen en elkaar onderling beïnvloeden in de beschikbaarheid van het proces. In zo’n opzet is de IT/OT-architectuur niet langer een technisch onderwerp “dat later nog wel wordt uitgewerkt”, maar een ontwerpbeslissing met financiële en organisatorische gevolgen. Tijdelijke integraties werken in de opstartfase, omdat ze een acuut probleem oplossen: ze koppelen snel een nieuwe machine aan, exporteren enkele signalen naar een rapport of omzeilen beperkingen van een oudere besturing. Na enkele jaren keren ze zich echter tegen de fabriek, wanneer die de capaciteit wil verhogen, aan nieuwe compliance-eisen moet voldoen of de werkwijze van de installatie veilig wil aanpassen. Dan blijkt dat niet één kabel of script het probleem is, maar het ontbreken van samenhangende afspraken over communicatie, verantwoordelijkheden en functiescheiding.

De grootste fout is om zulke oplossingen als kostenneutraal te beschouwen. Ze schuiven de kosten alleen door in de tijd, en meestal gebeurt dat op het slechtst denkbare moment: bij uitbreiding, een audit, een incident of een wisseling van leverancier. Vanuit projectperspectief leidt dit niet alleen tot een duurdere implementatie van de volgende fase, maar ook tot verlies van voorspelbaarheid. Het team weet niet meer welke afhankelijkheden kritisch zijn voor de continuïteit van de productie, waar de verantwoordelijkheid van de integrator eindigt en die van de fabriekseigenaar begint, en welke wijzigingen een nieuwe risicobeoordeling vereisen. In de praktijk begint hier precies het domein van de verborgen kosten van verkeerde ontwerpbeslissingen: extra stilstanden, ad-hoc servicewerk, herhaalde opleveringen, problemen bij het documenteren van wijzigingen en discussies over de reikwijdte van de garantie. Als de architectuur niet is beschreven als een bewust model voor de ontwikkeling van de fabriek, dan wordt elke volgende fase belast met technische en organisatorische schuld.

Een goede praktische toets is niet de vraag of een integratie “werkt”, maar of zij over twee of drie investeringsfasen nog veilig en voorspelbaar kan worden aangepast. Als een nieuwe lijn handmatige signaalmapping op meerdere plaatsen vereist, kennis over koppelingen verspreid is over verschillende leveranciers en het reconstrueren van de volledige datastroom analyse van besturingscode, tussenliggende databases en niet-gedocumenteerde diensten vraagt, dan bevindt het project zich al op een pad met verhoogd risico. Het is zinvol de situatie te beoordelen aan de hand van drie meetbare criteria: de tijd die nodig is om een gecontroleerde wijziging door te voeren, de mogelijkheid om voor elke gegevensuitwisseling eenduidig een eigenaar aan te wijzen en het vermogen om de impact van een storing of wijziging op productie en veiligheid te reconstrueren. Als deze drie zaken niet concreet vast te stellen zijn, gaat het probleem niet over het gemak van het team, maar over de beheersbaarheid van het hele project.

Een praktijkvoorbeeld dat steeds terugkomt: een fabriek neemt een nieuw productiegebied in gebruik en koppelt voor een snelle start procesgegevens aan bedrijfssystemen via tussenoplossingen die buiten de beoogde architectuur zijn opgebouwd. Een tijdlang lijkt alles goed te werken, omdat de gegevensstroom voldoende is voor rapportage en dagelijks toezicht. Het probleem ontstaat bij verdere automatisering, integratie met technisch onderhoud of bij een wijziging van de werklogica van de machine. Dan heeft één aanpassing in de operationele laag invloed op rapporten, alarmen, recepten of toegang op afstand, terwijl de onderlinge afhankelijkheden niet meer duidelijk zijn. Als de oplossing bovendien ingrijpt in functies die samenhangen met stoppen, energieafschakeling of het blokkeren van herstart, is het onderwerp niet langer uitsluitend een IT-kwestie. Het komt dan in het domein van functionele veiligheid terecht en vereist een afzonderlijke analyse, inclusief verificatie of de uitgangspunten voor beveiliging tegen onverwacht opstarten niet zijn aangetast. Op dit punt raakt de IT/OT-architectuur direct aan de risicoanalyse binnen het ontwikkelingsproject van de fabriek en aan beslissingen die later ook invloed hebben op de reikwijdte van de conformiteitsbeoordeling en de technische documentatie.

Daarom vraagt dit onderwerp nu om een beslissing, en niet pas na afronding van de inbedrijfstelling. Niet omdat elke integratie vanaf het begin uitgebreid moet zijn, maar omdat al bij de start onderscheid moet worden gemaakt tussen een tijdelijke oplossing en een oplossing die onderdeel moet worden van de blijvende architectuur van de fabriek. Dat onderscheid moet projectmatige gevolgen hebben: een aparte eigenaar van de beslissing, voorwaarden voor het uitfaseren van de workaround, documentatie-eisen en criteria voor herbeoordeling bij uitbreiding. Als de fabriek volgende investeringsfasen, modernisering van machines of voorbereiding op conformiteitsbeoordeling plant, leidt het ontbreken van zo’n onderscheid vrijwel altijd tot hogere wijzigingskosten en een bredere verantwoordelijkheid aan de zijde van de investeerder. Juist daarom is de IT/OT-architectuur vandaag geen toevoeging aan het project, maar een van de voorwaarden om grip te houden op kosten, planning en risico.

Waar de kosten of het risico het vaakst oplopen

De hoogste kosten bij de ontwikkeling van een fabriek zitten meestal niet in de interfaces tussen IT en OT zelf, maar in de gevolgen van beslissingen die “tijdelijk” zijn genomen en na enkele jaren feitelijk de vaste architectuur gaan vormen. Een voorlopige integratie wreekt zich dan niet omdat die technisch onvolmaakt was, maar omdat niemand de grenzen ervan heeft vastgelegd: wie verantwoordelijk is voor wijzigingen, welke gegevens als brongegevens gelden, hoe de configuratie na een storing wordt hersteld en op welk moment de workaround moet worden verwijderd. In de praktijk lopen de kosten op zodra een tijdelijke oplossing zonder formeel besluit onderdeel wordt van technisch onderhoud, productie, kwaliteit of managementrapportage, terwijl zij vanaf dat moment in feite een kritisch element is. Voor het project betekent dit later discussies over budget en scope, en voor de organisatie ook vervagende verantwoordelijkheden: een storing lijkt een technisch probleem, terwijl de oorzaak in werkelijkheid een niet-afgesloten architectuurbeslissing was. Een bruikbaar beoordelingscriterium is hier een eenvoudige vraag: is het na uitbreiding van de fabriek mogelijk om een proceseigenaar, een data-eigenaar en een procedure voor veilige wijziging aan te wijzen zonder de “enige persoon die weet hoe het werkt” erbij te halen? Zo niet, dan is het risico al in het project ingebouwd.

Een tweede bron van oplopende kosten is het ontbreken van een scheiding tussen de besturingslaag en de laag voor uitwisseling van bedrijfsgegevens. In de eerste fase van een investering is zo’n verkorte aanpak verleidelijk: dezelfde server verzorgt de communicatie met de machine, archiveert gegevens, voedt het rapport en ondersteunt externe servicetoegang. Bij één enkele lijn lijkt dat nog goed te werken, maar bij volgende uitbreidingsfasen heeft elke wijziging voor het ene doel ook gevolgen voor de andere. Een update die door een bedrijfssysteem wordt afgedwongen, kan de continuïteit van de productie verstoren, en de behoefte aan snellere rapportage kan ertoe leiden dat wordt ingegrepen in de configuratie van apparaten die eerder stabiel werkten. Dan bestaan de verborgen kosten van verkeerde projectbeslissingen niet alleen uit extra aanschaf van hardware of diensten van een integrator. Veel zwaarder wegen de kosten van stilstand, hertesten, nachtwerk tijdens implementaties en de noodzaak om kennis te reconstrueren die nergens is vastgelegd. Vanuit projectmanagement is het verstandige minimum daarom de beoordeling of een storing of wijziging in het IT-deel een operationele functie van de machine of lijn kan stilleggen. Als het antwoord daarop ja is, moet de architectuur worden gecorrigeerd, ook al “werkt het voorlopig nog”.

Een typisch voorbeeld doet zich voor bij het aansluiten van nieuwe machines op de bestaande infrastructuur van een fabriek. De leverancier stelt de installatie snel in bedrijf, omdat oplevering en productiestart nodig zijn, en realiseert de communicatie met de fabriekssystemen daarom via een extra computer, een script dat bestanden exporteert of een handmatig aangepaste signaalmapping. Na een jaar komt er nog een machine bij, na twee jaar verandert het bovenliggende systeem en na drie jaar blijkt dat niemand nog eenduidig kan beschrijven welke berichten kritisch zijn voor het proces, welke alleen voor rapportage dienen en welke van belang zijn voor diagnose of batchtraceerbaarheid. Op dit punt raakt het onderwerp deels ook aan het opstellen van machinehandleidingen, want als de operator, de technische dienst of de serviceorganisatie geen gedocumenteerde werkwijzen hebben voor communicatie-uitval, handmatige workarounds of het herstellen van parameters na vervanging van een component, dan is het probleem niet langer uitsluitend IT-gerelateerd. Het wordt dan onderdeel van de organisatie van een veilige exploitatie en van de latere verantwoordelijkheid voor de wijze van gebruik en voor wijzigingen.

Pas in deze fase wordt duidelijk waarom dit onderwerp ook terugkomt bij conformiteitsbeoordeling en technische documentatie en bij het budgetteren van wijzigingen. Als de integratie invloed heeft op machinefuncties, op de logica van vergrendelingen, op de manier waarop statussen worden bevestigd of op de informatie die aan de gebruiker wordt doorgegeven, kan een nieuwe risicoanalyse nodig zijn en moet worden nagegaan of de documentatie nog steeds overeenkomt met de werkelijke oplossing. De reikwijdte van die beoordeling hangt af van de aard van de wijziging en kan dus niet eerlijk met één universele zin worden vastgesteld, maar juist daarom zijn noodoplossingen zo kostbaar: ze maken het moeilijk om vast te stellen wat er feitelijk is gewijzigd en wat de juridische en operationele gevolgen zijn. Voor het besluitvormende team is het praktische criterium als volgt: als een wijziging in de integratie niet kan worden beschreven in de configuratiedocumentatie, de testprocedure en de exploitatieregels zonder terug te vallen op informele kennis, dan is het project al in een fase beland waarin niet alleen de technische kosten stijgen, maar ook de verantwoordelijkheid van de investeerder, de projectleider en de personen die de oplossing voor gebruik vrijgeven.

Hoe je dit in de praktijk aanpakt

In de praktijk is de vraag niet of IT en OT sneller moeten worden geïntegreerd, maar waar de grens ligt tussen een tijdelijke oplossing en een architectuurschuld die over enkele jaren de verdere ontwikkeling van de fabriek blokkeert. Voorlopige koppelingen ontstaan meestal onder druk van de ingebruikname: er moeten snel gegevens uit een machine worden gehaald, er moet een nieuwe lijn worden toegevoegd, een kwaliteitssysteem moet worden gekoppeld aan productieregistraties of er moet externe servicetoegang worden geregeld. Het probleem begint zodra een oplossing die “voor even” is ingevoerd, de basis wordt voor volgende projectbeslissingen. Het team verliest dan een duidelijke verdeling van verantwoordelijkheden en elke uitbreiding vereist dat kennis opnieuw wordt opgebouwd uit correspondentie, lokale instellingen en de praktijk van operators. Dat is geen klein technisch ongemak meer, maar een factor die invloed heeft op de planning, de wijzigingskosten en het vermogen om aan te tonen wie een bepaalde oplossing heeft vrijgegeven en op welke grondslag dat is gebeurd.

Daarom begint de juiste aanpak met een architectuurbeslissing, niet met de keuze van een tool. De manager of proceseigenaar moet eisen dat voor elke nieuwe integratie het operationele doel is vastgelegd, dat er aan beide kanten van de IT/OT-grens een eigenaar is aangewezen en dat de voorwaarden voor beheer na ingebruikname zijn bepaald. Als niet duidelijk is wie verantwoordelijk is voor de databron, wie een configuratiewijziging goedkeurt, wie de gevolgen voor het proces test en wie beslist over de noodmodus, dan wordt het risico in feite doorgeschoven naar de exploitatiefase. Juist hier begint vanzelf de rol van de projectmanager bij IT/OT-beslissingen: niet als coördinator van deadlines, maar als degene die afdwingt dat verantwoordelijkheden worden vastgelegd voordat een noodoplossing in budget en planning wordt opgenomen als “snelle workaround”. Een praktisch beoordelingscriterium is eenvoudig: als de geplande integratie na een leverancierswissel, vervanging van de besturing of uitbreiding van de lijn niet onderhoudbaar is zonder de auteur van de oorspronkelijke workaround, dan is het geen tijdelijke oplossing maar een toekomstige projectkost.

Een goede test is de uitbreiding van een bestaande lijn met een extra werkstation dat gegevens moet doorgeven aan het bovenliggende systeem en tegelijk moet reageren op statussen uit het al draaiende deel. Als het team kiest voor het rechtstreeks aankoppelen van signalen en een informele gegevensvertaling “omdat dat sneller is”, kan alles in eerste instantie correct werken. Na verloop van tijd ontstaan echter neveneffecten: het wordt lastiger vast te stellen of een fout voortkomt uit de machinelogica, de communicatielaag of de rapportageapplicatie; acceptatietests dekken alleen standaardscenario’s af; modernisering van één element dwingt tot aanpassingen op meerdere plaatsen tegelijk. Dan worden ook de verborgen kosten van verkeerde projectbeslissingen zichtbaar: extra stilstand voor diagnose, de kostbare aanwezigheid van de integrator bij elke wijziging, discussies over de garantieomvang en vertragingen in volgende investeringsfasen. Het is daarom zinvol niet alleen de inbedrijfstellingstijd te meten, maar ook het aantal integratiepunten dat handmatige configuratie vereist, de tijd die nodig is voor incidentanalyse na een wijziging en het aantal wijzigingen dat integraal in plaats van lokaal moet worden getest.

Pas tegen deze achtergrond is een verwijzing naar veiligheids- en conformiteitseisen zinvol. Als de integratie invloed heeft op machinetoestanden, vergrendelingen, signaalbevestigingen, de opstart- of stopvolgorde, dan is zij niet langer een neutrale IT-toevoeging. Afhankelijk van de aard van de wijziging kan dit aanleiding geven tot een herbeoordeling van de risico’s, actualisering van de technische documentatie en verificatie of de wijze van gebruik nog steeds overeenkomt met de uitgangspunten die voor de betreffende machine of lijn zijn gehanteerd. Dat is vooral duidelijk waar de integratielaag indirect invloed begint uit te oefenen op de voorwaarden voor veilige toegang, energieafschakeling of het voorkomen van onverwacht opstarten. In zo’n geval verschuift de architectuurbeslissing van het domein van implementatiegemak naar het domein van juridische en technische verantwoordelijkheid. Als het team niet kan aantonen welke verbindingen uitsluitend informatief zijn en welke het gedrag van de machine beïnvloeden, is dat een signaal dat het onderwerp uit het niveau van “systeemintegratie” moet worden gehaald en moet worden behandeld als een wijziging die relevant is voor veiligheid, budget en de verantwoordelijkheid van de personen die de oplossing goedkeuren. Dit raakt direct aan conformiteitsbeoordeling en technische documentatie.

Waar je bij de implementatie op moet letten

De meeste problemen komen niet voort uit de IT/OT-integratie zelf, maar uit het feit dat die in een project wordt behandeld als een snelle manier om een nieuwe functie te activeren, en niet als een duurzaam onderdeel van de fabrieksarchitectuur. Juist dan nemen tijdelijke koppelingen na enkele jaren wraak: bij uitbreiding van de lijn, vervanging van besturingen, wisseling van leverancier van het bovenliggende systeem of tijdens een veiligheidsaudit blijkt dat niemand eenduidig kan aangeven wie eigenaar is van de interface, volgens welke regels die werkt en wat de gevolgen van een storing zijn. Voor het project betekent dit niet alleen de kosten van technische schuld, maar ook organisatorische kosten: meer afstemming, langere integrale tests, lastigere opleveringen en een groter risico dat de vertraging pas aan het einde zichtbaar wordt, wanneer de planning al het minst flexibel is. Op dat punt gaat het onderwerp vanzelf over in de sfeer van verborgen kosten van verkeerde projectbeslissingen, omdat de bron van het probleem niet één uitvoeringsfout is, maar de beslissing om een degelijke architectuur uit te stellen tot later.

Bij de implementatie is het daarom verstandig een oplossing niet te beoordelen op de vraag of die “nu werkt”, maar of zij op een voorspelbare manier onderhoudbaar is en veilig kan worden gewijzigd. Het praktische criterium is eenvoudig: als voor de geplande integratie de verantwoordelijkheden, de storingsmodus, de regels voor versiebeheer en de testprocedure na wijzigingen niet zijn beschreven, dan is zij nog niet klaar voor productie, ook al werkt zij op een testopstelling. Dat is vooral belangrijk waar dezelfde interface zowel de huidige investeringsfase als een toekomstige uitbreiding moet ondersteunen. De ontwikkeling van een fabriek vergroot vrijwel altijd het aantal afhankelijkheden tussen systemen, en noodoplossingen werken juist het slechtst wanneer het aantal uitzonderingen, workarounds en lokale afspraken toeneemt. Vanuit het perspectief van de projectmanager betekent dit dat vroegtijdig moet worden beslist wie de grensbeslissingen goedkeurt tussen automatisering, technisch onderhoud, IT en conformiteit, want zonder die duidelijkheid vervaagt de verantwoordelijkheid precies daar waar later de grootste discussie ontstaat over kosten en planning.

Een typisch praktijkvoorbeeld is het toevoegen van gegevensuitwisseling tussen de lijn en het rapportagesysteem via een tussenscript of een niet-gedocumenteerde dienst die draait op een server die “toch al in de fabriek staat”. Tijdens de inbedrijfstelling lijkt zo’n oplossing logisch: er is geen wijziging nodig aan de kant van de machineleverancier, de implementatie gaat sneller en het zakelijke resultaat is snel zichtbaar. Het probleem ontstaat later. Na een update van het besturingssysteem, een wijziging in de adressering, het terugzetten van een back-up of de vervanging van een apparaat weet niemand nog zeker of de logica voor het mappen van signalen nog overeenkomt met de werkelijkheid van het proces. Als dit mechanisme betrokken is bij bevestigingen, vergrendelingen, het in de wachtrij zetten van orders of startvoorwaarden, is een storing niet langer alleen een IT-incident, maar heeft die gevolgen voor de beschikbaarheid van de lijn, de productkwaliteit en de verantwoordelijkheid voor het vrijgeven van de oplossing voor gebruik. Daarmee gaat het onderwerp naadloos over in de risicoanalyse binnen een ontwikkelingsproject van een fabriek, omdat niet alleen de kans op een storing moet worden beoordeeld, maar ook de gevolgen van onjuiste informatie, een onjuiste sequentie en een onjuiste reactie van de operator.

Pas tegen die achtergrond is een verwijzing naar formele eisen zinvol. Als de integratielaag uitsluitend informatief blijft en dat technisch kan worden aangetoond, is de reikwijdte van de verplichtingen anders dan wanneer zij het gedrag van de machine of lijn beïnvloedt. Als zij echter ingrijpt in de bedrijfslogica, startvoorwaarden, stopvoorwaarden, bevestigingen of omzeilingen, dan moet de implementatie worden behandeld als een wijziging met technische en mogelijk veiligheidsrelevante betekenis, en niet als een gewone systeemuitbreiding. Dat kan betekenen dat de uitgangspunten van de risicoanalyse, de technische documentatie en de conformiteitsvoorwaarden die voor deze oplossing zijn aangenomen, opnieuw moeten worden getoetst. In de praktijk luidt de veilige vraag niet “kunnen we dit aansluiten”, maar “kunnen we na de implementatie aantonen wat deze interface doet, wie ervoor verantwoordelijk is en hoe we de wijziging beheersen”. Als het antwoord daarop niet eenduidig is, komen de verborgen kosten van uitgestelde ontwerpbeslissingen meestal terug bij de volgende modernisering, certificering of een incident, en dan is het niet meer alleen een technisch probleem, maar ook een managementvraagstuk.