Uw operationele team zit met een probleem. Een echt probleem: een handmatig proces dat tijd kost, fouten veroorzaakt of blinde vlekken in uw productiegegevens creëert. Ze zoeken een partner, stellen een oplossing op maat op en komen terug met iets dat daadwerkelijk aansluit bij de manier waarop uw bedrijfsvoering werkt.

Vervolgens bekijkt IT het. En het project loopt vast.

Klinkt dit bekend? Dit scenario speelt zich voortdurend af in industriële en hybride organisaties en het komt zelden neer op de kwaliteit van de oplossing. Het komt neer op een kloof die de meeste organisaties niet goed hebben aangepakt: de structurele spanning tussen OT en IT.

Twee teams, twee totaal verschillende definities van ‘werken’

OT leeft in de operationele realiteit. Uptime, doorvoer, reactievermogen. Wanneer een proces uitvalt of risico's oplevert, moet het worden opgelost en hebben ze een oplossing nodig die daadwerkelijk aansluit bij hoe hun omgeving werkt, geen generieke tool die is ontworpen voor de bedrijfsvoering van iemand anders. Maatwerksoftware is vaak het enige echte antwoord, omdat hun processen specifiek zijn, hun systemen vaak verouderd zijn en kant-en-klare platforms de praktijk vaak niet doorstaan.

IT bevindt zich in een andere realiteit. Beveiliging, compliance, onderhoud, governance. Ze hebben de technische schuld geërfd van elke ‘snelle oplossing’ die zonder deugdelijke beoordeling is geïmplementeerd. Ze weten wat er gebeurt als maatwerkcode tien jaar in productie blijft en de persoon die deze heeft geschreven het bedrijf heeft verlaten. Hun terughoudendheid is geen obstructie, maar een uiting van institutioneel geheugen.

Het probleem is dat beide teams rationeel reageren op legitieme druk. Maar wanneer die druk bij een specifiek project met elkaar botst, ziet OT IT als een belemmering, en ziet IT OT als een risico dat ze moeten beheersen.

Waar het misgaat

De knelpunten zijn voorspelbaar. Ze begrijpen is de eerste stap om ze te overwinnen.

Verantwoordelijkheid na de oplevering. Maatwerksoftware moet worden onderhouden. IT zal vragen: wie is hiervoor verantwoordelijk als de relatie met de leverancier eindigt? Wie installeert de beveiligingspatches? Wie lost het op als er iets aan de flow verandert? Dit zijn terechte vragen, maar als ze pas tijdens het beoordelingsproces voor het eerst aan de orde komen, voelen ze aan als obstakels in plaats van voorwaarden.

Beveiligingsbeoordelingscycli versus operationele urgentie. Het probleem van OT is prangend. De kosten van wachten, in de vorm van fouten, inefficiëntie of risico's, zijn reëel en voortdurend. Het beoordelingsproces van IT heeft zijn eigen tijdlijn, bepaald door nalevingsvereisten en het beleid voor change management. Geen van beide tijdlijnen is willekeurig, maar ze lopen zelden synchroon zonder bewuste coördinatie.

Code standaarden en overdracht. IT is verantwoordelijk voor de integriteit van het systeemlandschap. Wanneer er maatwerksoftware van een externe partij binnenkomt, moeten ze deze begrijpen, erop vertrouwen en uiteindelijk ondersteunen. Als de documentatie, architectuur en codekwaliteit niet aan hun normen voldoen, vertraagt de beoordeling niet alleen, maar kan deze volledig tot stilstand komen.

Controle en zichtbaarheid. IT wil weten wat er in hun omgeving draait. OT wil snel handelen en het probleem oplossen. Wanneer een maatwerkoplossing wordt opgezet en gebouwd zonder vroege betrokkenheid van IT, kan deze volledig uitgewerkt aankomen in de beoordelingsfase, wat het slechtst mogelijke moment is om fundamentele bezwaren aan te kaarten.

De werkelijke kosten van deze kloof

Vertragingen bij projecten zijn de zichtbare kosten. Maar de onderliggende kost is wat er in de loop van de tijd gebeurt met de relatie tussen OT en IT.

OT leert om IT te omzeilen door projecten kleiner op te zetten, ze anders te formuleren of manieren te vinden om ze te implementeren zonder dat er een volledige beoordeling nodig is. IT gaat zich steeds defensiever opstellen, omdat ze in de productie steeds weer zaken ontdekken waarover ze niet zijn geraadpleegd. Beide teams graven zich in. En de organisatie verliest het vermogen om digitale en operationele verbeteringen door te voeren in het tempo dat het bedrijf nodig heeft.

Voor het C-level management is dit het echte probleem. Niet één vastgelopen project, maar een dynamiek die uw vermogen om de bedrijfsvoering te verbeteren systematisch vertraagt.

Wat er moet veranderen

Het antwoord is niet om IT te omzeilen of IT vetorecht te geven over elke operationele verbetering. Het gaat erom een model te bouwen waarin beide teams vanaf het begin betrokken zijn en waarin hun zorgen worden meegenomen als onderdeel van de oplossing, niet erna.

Dat betekent dat IT moet worden betrokken bij de fase waarin het probleem wordt gedefinieerd, niet bij de goedkeuringsfase. Wanneer IT begrijpt waarom OT een oplossing nodig heeft, en wat de operationele kosten zijn van niets doen, verandert het gesprek. Ze zijn niet langer gatekeeper, maar worden mede-eigenaar van het resultaat.

Het betekent ook dat partners voor maatwerksoftware IT als een belanghebbende moeten behandelen, niet alleen OT. Overdrachtsdocumentatie, beveiligingsarchitectuur, onderhoud: dit is geen bijzaak. Ze maken deel uit van wat een oplossing inzetbaar maakt in een echte organisatie.

En dat betekent dat het management het besluitvormingskader duidelijk moet maken. Welke mate van IT-betrokkenheid is nodig, in welke fase, en voor welk type oplossing? Zonder die duidelijkheid moet bij elk project opnieuw over de regels worden onderhandeld, en dat is precies waar de wrijving ontstaat.

Het diepere structurele probleem

IT is meestal een kostenpost, wat betekent dat er chronisch te weinig middelen zijn in verhouding tot de eisen die eraan worden gesteld. Bedrijfseenheden die snelle innovatie willen, pleiten zelden voor verhogingen van het IT-budget die dat daadwerkelijk mogelijk zouden maken.

Er is ook een kenniskloof die in beide richtingen werkt: bedrijfsteams onderschatten de complexiteit van wat ze vragen, en IT-teams slagen er vaak niet in om duidelijk te maken waarom iets tijd kost, wat leidt tot wederzijdse frustratie en wantrouwen.

Wat daadwerkelijk helpt

Organisaties die hier goed mee omgaan, hebben de neiging om: “fast lane”-goedkeuringsproces in te stellen voor tools met een lager risico, IT- of beveiligingsmensen in te bedden in bedrijfsteams, de opdracht van IT expliciet te verschuiven naar facilitering, en schadow-IT te behandelen als een signaal van onvervulde behoefte in plaats van alleen maar een compliance-probleem.

De spanning is reëel en waarschijnlijk tot op zekere hoogte onvermijdelijk, maar hoe hiermee wordt omgegaan, is in hoge mate een keuze van leiderschap en cultuur.

Waar het op neerkomt

Maatwerksoftware bestaat omdat standaardplatforms niet elk probleem oplossen. OT heeft gelijk dat ze op zoek gaan naar oplossingen die aansluiten bij hun dagelijkse praktijk. En IT-teams hebben gelijk dat ze kritische vragen stellen over beveiliging, ownership en onderhoud op de lange termijn.

De kloof tussen beide is geen technologisch probleem. Het is een probleem van governance en samenwerking en het moet op leidinggevend niveau worden opgelost, voordat het volgende project de beoordelingsfase bereikt.

Want de echte verspilling is niet een geblokkeerd project. Het is een organisatie die de capaciteit blijft opbouwen om te verbeteren en zichzelf vervolgens belemmert om dat te doen.