Hoe organiseer je de samenwerking tussen een integrator, een software house en de technische dienst binnen één project?

Waarom dit onderwerp vandaag relevant is

De samenwerking tussen de integrator, het softwarebedrijf en de technische dienst is allang niet meer alleen een kwestie van organisatorisch gemak. In de praktijk bepaalt die vandaag of een project zonder discussies over de scope kan starten, of een wijziging in de software de technische oplevering niet blokkeert en of de fabriek de oplossing na implementatie veilig kan beheren. Hoe meer proceslogica naar de softwarelaag verschuift en hoe minder daarvan in standaardfuncties van besturingen en apparaten overblijft, hoe belangrijker een duidelijke afbakening van verantwoordelijkheden wordt. Als die niet vanaf het begin wordt vastgelegd, stijgen de projectkosten meestal niet lineair, maar via correcties op de verkeerde plek: de integrator past interfaces aan, het softwarebedrijf bouwt de bedrijfslogica om en de technische dienst brengt pas aan het einde operationele eisen naar voren die eerder door niemand zijn vastgelegd.

Dit is ook een budgetkwestie en niet uitsluitend een technisch onderwerp. In veel projecten verandert de vraag naar de samenwerking tussen partijen al snel in de vraag wat maatwerksoftware voor de industrie binnen het investeringsbudget eigenlijk is: een investeringsonderdeel, een onderhoudskost of een combinatie van beide. Als de architectuur van de oplossing ervan uitgaat dat cruciale functies voor het proces, rapportage, recepten, batchtracering of integratie met fabriekssystemen buiten de standaardscope van de automatisering worden ontwikkeld, moet dat vóór de bestelling worden onderkend en niet pas na het eerste prototype. Het praktische criterium is eenvoudig: als het ontbreken van één beslissingsverantwoordelijke voor de grens tussen automatisering, applicatie en exploitatie ertoe leidt dat eisen, tests en wijzigingskosten niet eenduidig kunnen worden toegewezen, dan bevindt het project zich al in een zone met verhoogd risico en moet het samenwerkingsmodel worden bijgestuurd.

Dat is het duidelijkst zichtbaar bij een modernisering van een lijn waarbij de integrator verantwoordelijk is voor de besturing en inbedrijfstelling, het softwarebedrijf voor de applicatielaag en de gegevensuitwisseling, en de technische dienst het systeem later voor continubedrijf moet overnemen. Als de technische dienst pas bij de oplevering wordt betrokken, komen meestal problemen aan het licht die geen “storingen” zijn, maar ontbrekende besluiten: geen procedure voor herstel na een storing, geen eisen voor serviceaccounts, geen vastgelegde updatevensters, een niet-voorziene afhankelijkheid van een externe leverancier of onvoldoende zicht op fouten. Dan gaat het geschil niet meer over de kwaliteit van de code of de juistheid van de besturingskast, maar over de vraag wie de kosten moet dragen om het systeem aan te passen aan de realiteit van de fabriek. Op dat punt sluit het onderwerp vanzelf aan bij de verborgen kosten van het project en de conformiteit, omdat vertraging van de oplevering of een late wijziging van veiligheidsfuncties, technische documentatie of validatie vaak juist het gevolg is van slecht georganiseerde samenwerking en niet van één afzonderlijke uitvoeringsfout.

Het conformiteitsaspect komt in beeld wanneer de taakverdeling invloed heeft op producteigenschappen, veiligheidsgerelateerde functies, documentatie of de manier waarop de oplossing in gebruik wordt genomen. Niet elke integratie van een applicatie met een machine leidt tot dezelfde verplichtingen, maar alleen al onduidelijkheid over wie verantwoordelijk is voor de beschrijving van functies, wijzigingsbeheer en de volledigheid van de documentatie is een waarschuwingssignaal. Dat geldt in het bijzonder voor projecten die in de eigen fabriek worden uitgevoerd, moderniseringen die gefaseerd plaatsvinden en oplossingen die voor eigen gebruik worden gebouwd, waarbij de grens tussen “onderhoudswerk” en vervaardiging of een ingrijpende verbouwing juridisch relevant kan zijn. Daarom moet de keuze voor het samenwerkingsmodel niet worden gemaakt wanneer het eerste conflict ontstaat, maar op het moment dat de scope wordt gedefinieerd: wie beschrijft de operationele eisen, wie keurt de architectuur goed, wie is verantwoordelijk voor tests tussen de verschillende lagen en wie neemt het systeem na de inbedrijfstelling over, inclusief de feitelijke capaciteit om het te onderhouden.

Waar kosten of risico het vaakst oplopen

In projecten die gezamenlijk worden uitgevoerd door een integrator, een softwarebedrijf en de technische dienst lopen de kosten zelden op door één grote fout. Meestal nemen ze toe op het snijvlak van verantwoordelijkheden, dus daar waar niemand de volledige plicht heeft om een zaak tot het einde af te ronden. Het duurst zijn niet de technische fouten op zich, maar besluiten die worden uitgesteld of zonder eigenaar worden genomen: geen afgestemde communicatiearchitectuur, niet beschreven grenzen tussen besturingslogica en de applicatielaag, geen vastgelegde testaanpak na een wijziging en overdracht van het systeem naar de exploitatie zonder reële onderhoudscapaciteit. In de praktijk betekent dit correcties die pas na de inbedrijfstelling worden uitgevoerd, discussies over de contractscope en het doorschuiven van verantwoordelijkheid voor stilstand naar de fase waarin elke wijziging het duurst is. Een eenvoudig criterium om de situatie te beoordelen is de vraag of voor elke kritieke functie één partij kan worden aangewezen die verantwoordelijk is voor de eis, één voor de uitvoering en één voor de oplevering. Als het antwoord luidt “dat hangt ervan af”, is het project al belast met organisatorisch risico.

Een tweede verliespost ontstaat wanneer ontwerpbeslissingen worden genomen zonder betrokkenheid van de technische dienst, of juist wanneer de technische dienst oplossingen oplegt die vanuit serviceoogpunt handig zijn, maar niet passen binnen de systeemarchitectuur. De integrator kijkt meestal vanuit de inbedrijfstelling en de samenwerking met apparatuur, het software house vanuit de bedrijfslogica en interfaces, en de technische dienst vanuit beschikbaarheid, diagnosemogelijkheden en hersteltijd. Als die perspectieven elkaar niet al bij het definiëren van de eisen ontmoeten, komen ze later terug als wijzigingskosten: extra signalen, herinrichting van autorisaties, het ontbreken van eventregistratie die voor diagnose nodig is, het niet veilig kunnen uitvoeren van updates of het ontbreken van een procedure om een storing te omzeilen. Op dat moment gaat het onderwerp vanzelf over in de rol van de engineering projectmanager, omdat het probleem dan niet langer één afzonderlijke technische beslissing is, maar het managen van afhankelijkheden, afstemmingstermijnen en verantwoordelijkheid voor escalatie.

Een typisch praktijkvoorbeeld is een implementatie waarbij de bovenliggende applicatie de opdrachten, receptuur en rapportage moet aansturen, terwijl de integrator verantwoordelijk is voor de PLC, aandrijvingen en de machinereeks. Als de verantwoordelijkheidsgrens alleen functioneel wordt beschreven, zonder tussenliggende toestanden, foutcondities en gedrag bij communicatieverlies te benoemen, bouwt elke partij haar eigen “veilige” aannames in. Het software house gaat ervan uit dat het uitblijven van een bevestiging betekent dat een commando opnieuw moet worden verstuurd, de integrator neemt aan dat een commando eenmalig is, en de technische dienst krijgt een systeem dat tijdens stilstand niet te diagnosticeren is. Het gevolg is voorspelbaar: een lange inbedrijfstelling, dubbelzinnige fouten, correcties aan interfaces en spanning rond de vraag wie verantwoordelijk is voor een ongeplande stilstand. Bij de beoordeling van zo’n situatie is het zinvol om niet alleen de opleverdatum te meten, maar ook het aantal interfacewijzigingen na projectgoedkeuring, het aantal storingen dat pas op locatie wordt ontdekt en de tijd die nodig is om de oorzaak van een storing te reconstrueren. Als deze indicatoren oplopen ondanks de voortgang van het werk, ligt het probleem meestal in de organisatie van de samenwerking en niet in de prestaties van één afzonderlijke leverancier.

Een aparte risicobron is het behandelen van tests en documentatie als een bijproduct van de inbedrijfstelling. Waar het systeem invloed heeft op de werking van de machine, de toegang van de operator, diagnose, procesparameters of veiligheidsgerelateerde functies, is een late wijziging geen gewone softwarecorrectie. Zo’n wijziging kan een herbeoordeling van de ontwerpuitgangspunten vereisen, een actualisering van de technische documentatie, herhaling van een deel van de beproevingen en, in bepaalde feitelijke situaties, ook een nieuwe analyse van de verplichtingen aan de zijde van de gebruiker of de partij die de wijziging doorvoert. Dat is niet voor elk project op dezelfde abstracte manier te beoordelen, maar de praktische regel is eenvoudig: hoe sterker een wijziging het gedrag van het systeem in normale en abnormale toestanden beïnvloedt, hoe minder je die “op basis van werkafspraken” mag doorvoeren. Hier begint ook het gebied van typische fouten die voorkomen bij de bouw en modernisering van machines: het ontbreken van blokkeringen tegen foutieve configuratie, het ontbreken van afdwinging van de juiste volgorde van handelingen en het ontbreken van mechanismen die vergissingen van operator of service voorkomen. Als zulke beveiligingen niet vanaf het begin in de scope zijn opgenomen, komen ze later terug als kostenpost, stilstand of een discussie over verantwoordelijkheid.

Hoe pak je dit in de praktijk aan

In de praktijk moet de samenwerking tussen integrator, software house en technische dienst niet worden georganiseerd rond bedrijven, maar rond de verantwoordelijkheidsgrenzen voor concrete technische beslissingen. Dat bepaalt wie verantwoordelijk is voor de besturingslogica, wie voor de applicatielaag en communicatie, en wie voor servicevoorwaarden, back-ups, herstel na storing en het veilig doorvoeren van wijzigingen op locatie. Als die grenzen alleen in algemene termen zijn beschreven, gaat het project op aannames draaien: de integrator veronderstelt dat de eisen voor exploitatie door de fabriek worden aangeleverd, het software house neemt aan dat de proceslogica al vastligt, en de technische dienst krijgt een systeem dat zonder de auteur van de code niet effectief te onderhouden is. Het gevolg is niet alleen organisatorisch. De kosten van de inbedrijfstelling lopen op, het oplossen van storingen duurt langer en bij een geschil is moeilijker vast te stellen of het probleem voortkomt uit een implementatiefout, onvolledige uitgangspunten of een ongecontroleerde wijziging na oplevering.

Daarom zou de eerste beslissing niet de keuze van een tool of de planning van workshops moeten zijn, maar het vaststellen van een gezamenlijk verantwoordelijkheidsmodel voor de volledige levenscyclus van de oplossing. Voor een manager is het praktische criterium eenvoudig: elke functie die invloed heeft op de werking van een machine of lijn moet een aangewezen eigenaar hebben in vier projectfasen — ontwerp, inbedrijfstelling, oplevering en onderhoud. Als voor een bepaalde functie niet eenduidig kan worden beantwoord wie de eis goedkeurt, wie de wijziging uitvoert, wie de gevolgen test en wie verantwoordelijk is voor het herstellen van de werking na een storing, dan is de scope niet klaar voor uitvoering. Hier komt de rol van de engineering projectmanager vanzelf naar voren: niet als iemand “van de planning”, maar als eigenaar van de besluitvormingsorde tussen disciplines en leveranciers.

De meeste problemen ontstaan op het raakvlak van besturing en maatwerksoftware. Een typisch voorbeeld is een applicatie die de manier van receptselectie wijzigt, de werkvolgorde parametriseert of invloed heeft op de rechten van de operator. Voor een software house kan dat eruitzien als een gewone functionele wijziging, maar voor de integrator en de technische dienst is het een ingreep in het gedrag van het systeem, de diagnose en de omstelprocedures. Als vóór de implementatie niet is vastgelegd waar de verantwoordelijkheid voor de interface eindigt en waar die voor de proceslogica begint, kan een aanpassing die “op de productie” wordt uitgevoerd nieuwe tests, een update van de instructies en soms zelfs een herziening van de serviceprocedures vereisen. Juist hier raakt het onderwerp ook het budget: de kosten van maatwerksoftware voor de industrie binnen het investeringsbudget vloeien niet alleen voort uit het schrijven van code, maar ook uit de mate waarin het project verantwoordelijkheid doorschuift naar validatie, documentatie en later onderhoud.

Om dit te voorkomen, is het verstandig de status van het project niet te beoordelen op basis van verklaringen van leveranciers, maar op basis van artefacten die verifieerbaar zijn. De minimale set bestaat uit een overeengekomen lijst van interfaces, een beschrijving van versiebeheer, een procedure voor het melden en autoriseren van wijzigingen, scenario’s voor acceptatietests en een onderhoudsplan voor na de ingebruikname. Een korte beslisfilter werkt hier goed:

• heeft de wijziging invloed op de proceslogica, bedrijfsparameters of het gedrag van de operator,
• kan zij worden gereproduceerd, getest en teruggedraaid zonder betrokkenheid van de auteur van de oplossing,
• maakt de documentatie na implementatie het voor de fabriek mogelijk het systeem in stand te houden zonder kennis die verborgen zit in de mailbox van de opdrachtnemer.

Als op een van deze vragen het antwoord “nee” luidt, moet de scope van het project worden verduidelijkt in plaats van het werk te versnellen. Pas in deze fase is een zinvolle verwijzing naar formele eisen aan de orde: niet om algemene voorbehouden aan het contract toe te voegen, maar om te toetsen of de aard van de wijzigingen al gevolgen heeft voor documentatieverplichtingen, acceptatie of de beoordeling van verantwoordelijkheden aan de kant van de gebruiker. Dat is vooral van belang waar de fabriek zelf meewerkt aan de oplossing, deze met eigen middelen doorontwikkelt of onderdelen van het systeem voor intern gebruik bouwt. Dan is de samenwerking tussen drie partijen niet langer alleen een kwestie van projectorganisatie, maar raakt zij ook aan de wettelijke verplichtingen van de fabriek.

Waar je op moet letten bij de implementatie

De meeste problemen ontstaan niet wanneer het team onvoldoende competenties heeft, maar wanneer de projectpartijen binnen hun eigen grenzen correct werken en niemand het raakvlak daartussen beheert. In een project waarin de integrator verantwoordelijk is voor de uitvoerende laag en de koppelingen met de automatisering, het software house voor de applicatielogica en de technische dienst voor de continuïteit van de bedrijfsvoering, eindigt een gebrekkige implementatieorganisatie er vrijwel altijd mee dat risico’s worden doorgeschoven naar de inbedrijfstellingsfase. Juist daar blijkt of ontwerpbeslissingen zijn genomen met het oog op de volledige levenscyclus van de oplossing, of alleen om de scope van afzonderlijke opdrachtnemers af te ronden. Voor het project betekent dit meestal een van drie dingen: kostbare correcties na de opstart, een geschil over de verantwoordelijkheid voor storingen of vertraging van de acceptatie omdat het systeem alleen onder laboratoriumomstandigheden werkt en niet in het echte proces.

De belangrijkste valkuil is dat implementatie vaak als een technische fase wordt gezien, terwijl dit in de praktijk het moment is waarop organisatorische beslissingen worden getoetst. Als de integrator wijzigingen in de besturing kan aanbrengen zonder volledig inzicht in de gevolgen aan de applicatiekant, het software house functies ontwikkelt zonder bevestiging van de beperkingen van apparatuur en industrieel netwerk, en de technische dienst pas bij de acceptatie wordt betrokken, dan ligt het probleem niet in de communicatie maar in een gebrekkige verdeling van verantwoordelijkheden. Het praktische beoordelingscriterium is eenvoudig: vóór aanvang op locatie moet elke partij kunnen aangeven welke wijzigingen zij zelfstandig mag uitvoeren, welke gezamenlijke autorisatie vereisen en wie beslist om het werk stil te leggen als er risico ontstaat voor het proces, de veiligheid of de reproduceerbaarheid van de configuratie. Als het antwoord afhangt van “afspraken gaandeweg”, is de implementatie nog niet voorbereid, ook al klopt de planning formeel.

Een typisch voorbeeld betreft een ogenschijnlijk kleine wijziging: een aanpassing van de werkvolgorde van een station, die vanuit het perspectief van het software house een correctie in de logica is, voor de integrator andere reactietijden van apparatuur betekent en voor de technische dienst gevolgen heeft voor diagnose en procedures na een storing. Als zo’n wijziging zonder gezamenlijke effectbeoordeling op locatie wordt doorgevoerd, is het na de opstart moeilijk vast te stellen of de oorzaak van het probleem in de code, de configuratie van de besturing, de aandrijfparameters of de bediening door de operator zit. Dan lopen de kosten niet alleen op door de correctie zelf, maar ook door stilstand, extra tests en de inzet van mensen die eerder niet bij de analyse betrokken hoefden te zijn. Daarom is het zinvol niet alleen de opleverdatum te meten, maar ook het aantal implementatiewijzigingen zonder volledige goedkeuringsroute, de tijd die nodig is om de vorige versie te herstellen en het aandeel storingen dat pas na overdracht van het systeem aan de exploitatie wordt ontdekt. Dat geeft een reëel beeld van de vraag of de samenwerking tussen drie partijen wordt aangestuurd of slechts ad hoc in stand wordt gehouden.

In deze fase wordt ook vanzelf de grens zichtbaar tussen een gewone implementatie en een situatie waarin de fabriek zelf mee vormgeeft aan de oplossing op een manier die gevolgen heeft voor haar formele verplichtingen. Als de afdeling technische dienst niet alleen advies geeft, maar zelf de logica wijzigt, onderdelen van het systeem selecteert of een deel van de ontwerpbeslissingen overneemt, gaat het onderwerp niet langer uitsluitend over de organisatie van de samenwerking, maar ook over machines die voor eigen gebruik worden gebouwd. Dat laat zich niet met één algemene regel voor alle projecten bepalen; doorslaggevend zijn de omvang van de ingreep, de mate van zelfstandigheid van de fabriek en wie de eigenschappen van de oplossing feitelijk bepaalt. Hetzelfde geldt voor de risicoanalyse: als een wijziging invloed heeft op de procesfunctie, het gedrag van de operator, de omstandigheden van service-interventies of de volgorde van noodtoestanden, dan gaat het niet meer alleen om de vraag “wel of niet implementeren”, maar ook om “moet het risico opnieuw worden beoordeeld en moeten de uitgangspunten voor de oplevering worden bijgewerkt”. In de praktijk wordt juist hier het duidelijkst wat de rol is van degene die het project leidt: niet als tussenpersoon voor statusupdates, maar als eigenaar van de beslissing wanneer een handige vereenvoudiging ophoudt en de technische en juridische verantwoordelijkheid begint. Zie ook de grens tussen “onderhoudswerkzaamheden” en het bouwen of ingrijpend verbouwen van een machine.