De keuze van een automatiseringsintegrator: 5 criteria die echt bepalend zijn voor de veiligheid en de totale projectkosten

De keuze voor een automatiseringsintegrator wordt zelden uitsluitend op technisch niveau beslist. In de praktijk draait het om de vraag in welke fase van het project risico’s aan het licht komen: al tijdens de conceptfase en de afstemming, of pas na de montage, wanneer de lijn opnieuw in productie moet. Vanuit het perspectief van de fabriek zijn niet afzonderlijke programmeerfouten het duurst, maar onjuiste uitgangspunten: een onduidelijk afgebakende wijzigingsscope, overgeslagen interfaces met de bestaande installatie, het ontbreken van overeengekomen tests, gebrekkige documentatie en verantwoordelijkheid die naar de eindgebruiker wordt doorgeschoven.

Daarom zou de prijs van een offerte slechts één van de beoordelingscriteria moeten zijn. De werkelijke projectkosten worden meestal bepaald door de vragen die de integrator vóór de opdracht stelt, de manier waarop de inbedrijfstelling wordt uitgevoerd en de kwaliteit van het projectdossier dat na afronding van de werkzaamheden achterblijft. Juist op dat punt zijn veiligheid en kosten niet langer twee afzonderlijke onderwerpen.

De prijs van integratie is niet de projectkost

De waarde van een offerte is het gemakkelijkst te vergelijken, maar is meestal ook het zwakste selectiecriterium. De kosten van de ingekochte dienst vormen slechts een deel van de totale kosten van de projectbeslissing. Het resultaat van de investering wordt vaker bepaald door problemen die pas na de inbedrijfstelling zichtbaar worden: aanpassingen aan afschermingen, wijzigingen in de veiligheidslogica, een conflict tussen de vereiste prestaties en de werkelijke voorwaarden voor veilig werken, ontbrekende documentatie voor de oplevering en vertragingen bij het opnieuw opstarten van de installatie. Daarom blijkt de goedkoopste offerte zelden de goedkoopste over de volledige levenscyclus van de oplossing.

Bij moderniseringsprojecten wordt het verschil tussen een uitvoerder en een projectpartner al heel vroeg zichtbaar. Een uitvoerder realiseert wat in de specificatie staat. Een projectpartner verifieert eerst of die specificatie zelf geen aannames bevat die later een bron van kosten of aansprakelijkheid aan de kant van de fabriek worden. Zo’n partij kan de projectgrenzen, de interfaces met de bestaande lijn, de afhankelijkheden tussen mechanica, besturing en veiligheid en de invloed van wijzigingen op de status van de machine na modernisering en de conformiteitsbeoordeling herkennen. Dat is geen kwestie van werkstijl, maar van het vermogen om risico’s vanaf het begin van het project te beheersen.

De meeste kostbare noodoplossingen ontstaan al in de conceptfase. Een veelvoorkomend scenario ziet er als volgt uit: het project gaat uit van een eenvoudige vervanging van de besturing, maar zonder analyse van de invloed op de werkvolgorde, de servicetoegang en de veiligheidsfuncties. Na de inbedrijfstelling blijkt dat de operator extra handmatige handelingen moet uitvoeren, de technische dienst procedures nodig heeft om een zwak ontwerp te compenseren en de prestaties dalen omdat veilige toegang tot de werkzones niet goed is opgelost. Dan beginnen de correcties die niet in de offerte waren opgenomen: mechanische wijzigingen, aanvullende afschermingen, ombouw van veiligheidskringen, actualisering van de documentatie en nieuwe opleveringen. Het besturingsprogramma zelf is dan vaak het kleinste deel van het probleem.

Daarom is het zinvol om de offerte van een integrator niet alleen te lezen vanuit het perspectief van de investeringskosten, maar ook vanuit de kosten na de inbedrijfstelling en de vragen die aan het begin worden gesteld. Een goed signaal is een nauwkeurige beschrijving van de randvoorwaarden, het benoemen van risico’s op de raakvlakken met de bestaande installatie, voorbehouden over ontbrekende invoergegevens en de bereidheid om onjuiste verwachtingen van de opdrachtgever ter discussie te stellen. Een zwak signaal is de belofte van snelle uitvoering zonder analyse van interfaces, het ontbreken van een verwijzing naar de documentatie van de bestaande machine, het weglaten van opleveringsvoorwaarden en stilzwijgen over de verantwoordelijkheid voor veiligheid na de wijzigingen. Tegen die achtergrond is duidelijk dat veiligheid en verborgen kosten van het project en de CE-certificering geen toevoeging zijn die pas op het einde wordt meegenomen, maar een randvoorwaarde voor de volledige modernisering.

Vijf criteria die schijnbare besparingen eruit filteren

De duurste projecten zijn vaak niet die waarbij de integrator een hoger instaptarief hanteerde, maar die waarbij men de schijn van eenvoud heeft ingekocht. Daarom is het verstandig om de keuze van de uitvoerder te baseren op vijf criteria die al vóór ondertekening van het contract kunnen worden getoetst. Ze werken zowel in een technisch gesprek als in een offerteaanvraag of een beoordelingsmatrix voor offertes.

Het eerste criterium is projectvolwassenheid op het gebied van veiligheid. Een degelijke integrator kan niet alleen de besturingsarchitectuur beschrijven, maar ook de manier waarop gevaren worden geïdentificeerd, de randvoorwaarden, de verdeling van verantwoordelijkheden tussen de partijen en de logica achter de keuze van beschermingsmaatregelen. Als het gesprek blijft steken bij de keuze van een controller, lichtscherm of vergrendeling, en niet leidt tot de vraag wie verantwoordelijk is voor de risicobeoordeling na de wijzigingen, welke bedrijfsmodi er zijn en met welke afwijkingen van de normale bediening rekening moet worden gehouden, dan wordt het project te oppervlakkig benaderd.

Het tweede criterium betreft het vermogen om op het raakvlak van disciplines te werken. Werkelijke veiligheidsproblemen komen zelden voort uit één enkele elektrische fout. Ze ontstaan op interfaces: tussen mechanische beweging en afscherming, tussen de besturingsvolgorde en pneumatiek, tussen het resetten van het systeem en de zichtbaarheid van de gevarenzone, tussen de ergonomie van de bediening en de organisatie van het omstellen. Een integrator die deze afhankelijkheden niet ziet, schuift de kosten ervan meestal door naar de fase van de inbedrijfstelling.

Het derde criterium is de kwaliteit van de documentatie en de vastlegging van beslissingen. Al in het offertestadium moet duidelijk zijn of de opdrachtnemer voorziet in een veiligheidsconcept, schema’s, een in- en uitgangslijst, een functiebeschrijving, een testplan, een wijzigingsregister en acceptatievoorwaarden. Ontbreekt die documentatie, dan worden de kosten vrijwel altijd naar de fabriek doorgeschoven: de technische dienst verliest tijd met het reconstrueren van de besturingslogica, latere wijzigingen worden doorgevoerd zonder zekerheid over de gevolgen, en de conformiteitsbeoordeling na modernisering wordt lastiger omdat niet duidelijk is welke uitgangspunten zijn gehanteerd en wat er feitelijk is gewijzigd. Goede documentatie is geen administratieve bijzaak, maar een instrument om technische risico’s te beheersen.

Het vierde criterium is de manier waarop inbedrijfstelling en oplevering worden uitgevoerd. Voor de fabriek is niet alleen van belang of de machine gaat draaien, maar ook of de inbedrijfstelling zo is gepland dat objectief kan worden vastgesteld dat aan de functionele en veiligheidsvereisten is voldaan. De integrator moet vooraf de testscenario’s, acceptatiecriteria, voorwaarden voor overdracht naar gebruik en de werkwijze bij afwijkingen vastleggen. Als de oplevering uitsluitend neerkomt op het opstarten van de productie en het onderweg verhelpen van storingen, neemt de investeerder het risico over van discussies over de scope, vertragingen en kostbare correcties na stilstand. In dat verband zijn zowel een Factory Acceptance Test als een Site Acceptance Test direct relevant.

Het vijfde criterium is de onderhoudbaarheid en duurzaamheid van de oplossing. Een programma kan op de dag van inbedrijfstelling correct werken en tegelijk onleesbaar zijn geschreven, zonder zinvolle diagnosefuncties, zonder versiebeheer en zonder voorbereiding op toekomstige wijzigingen. Dan wordt elke storing, uitbreiding of vervanging van componenten een ingreep met verhoogd risico. Een goed voorbereide oplossing maakt het mogelijk de programmaversie te reconstrueren, de oorzaak van een stilstand vast te stellen, veiligheidsparameters te verifiëren en wijzigingen door te voeren zonder het beschermingsniveau te verlagen.

Deze criteria zijn snel te toetsen met een paar vragen:

• Hoe worden de gevarenidentificatie, de omvang van de wijzigingen en de verdeling van verantwoordelijkheden tussen integrator en gebruiker beschreven?
• Welke documenten zijn voorwaarde voor oplevering: schema’s, functiebeschrijving, testplan, protocollen, wijzigingsregister, programmakopieën en veiligheidsversies?
• Hoe worden functionele tests en veiligheidstests uitgevoerd en wie keurt afwijkingen en uitzonderingen goed?
• Hoe wordt de oplossing na een jaar en na een volgende modernisering onderhouden: diagnose, beschikbaarheid van onderdelen, overzichtelijkheid van het programma, herstel van versies?

Als de antwoorden algemeen blijven, zit het probleem niet in de communicatiestijl maar in de volwassenheid van het proces. Vanuit het oogpunt van kosten en conformiteit neemt dan juist het risico toe dat de fabriek verplichtingen overneemt waarmee noch in het budget, noch in de planning rekening is gehouden.

Waar de integrator kosten veroorzaakt of juist wegneemt

De kosten van het werk van een integrator beoordeel je het best aan de hand van het moment waarop problemen in het project zichtbaar worden. Als lastige beslissingen pas tijdens de inbedrijfstelling naar boven komen, worden de kosten vrijwel altijd naar de fabriek verschoven: in de vorm van extra stilstand, wijzigingen die onder productiedruk worden uitgevoerd en onduidelijke verantwoordelijkheid voor wat er feitelijk is aangepast. In een goed geleid project worden die kosten eerder weggenomen. Het conflict tussen de vereiste cyclustijd, toegang voor de operator, servicetoegang en beschermingsmaatregelen moet al in de conceptfase worden onderkend, niet pas op de werkvloer na de montage.

Juist hier is het verschil het duidelijkst tussen een opdrachtnemer die “de besturing vervangt” en een integrator die verantwoordelijk is voor de samenhang van de oplossing. De modernisering van een bestaande machine of een deel van een lijn komt zelden neer op het simpel vervangen van een PLC en enkele aandrijvingen. Een wijziging in de besturingslogica grijpt meestal in op het hele stelsel van afhankelijkheden: de bewegingsvolgorde verandert, reactietijden wijzigen en er ontstaat behoefte aan andere toegang bij omstellen, reinigen of het verhelpen van blokkades. Als de integrator dit niet analyseert voordat het ontwerp wordt bevroren, kan de besturing correct werken en toch het geheel nog niet klaar zijn voor veilig gebruik.

Een typisch voorbeeld is eenvoudig. Een fabriek plant de modernisering van een verpakkingsstation binnen een kort servicevenster. De uitgangspunten lijken aanvankelijk redelijk: vervanging van verouderde besturing, herstructurering van de aandrijvingen, enkele correcties in de sequentie, zonder mechanische ingrepen. Na de start blijkt echter dat de nieuwe logica vereist dat de operator vaker de materiaaltoevoerzone betreedt, terwijl de bestaande afschermingen en de plaatsing van beveiligingsvoorzieningen elke interventie verlengen tot een niveau dat voor de productie onaanvaardbaar is. De technische dienst gaat op zoek naar noodoplossingen, de arbodienst zet vraagtekens bij de wijze van toegang, de productie dringt aan op herstel van de cyclustijd en de integrator wijst erop dat het programma werkt volgens de afgesproken functie. In de volgende stap moeten de afschermingen worden aangepast, de wijze van bevestiging van interventies worden herzien, de omstelprocedure worden uitgewerkt en de instructies voor bediening en service worden aangevuld.

Elk van die wijzigingen afzonderlijk kan klein lijken, maar samen veroorzaken ze een cascade aan kosten: extra dagen waarin het station niet beschikbaar is, aanvullende afwijkingen bij de oplevering, nieuwe interventies na de productiestart en discussie over de vraag of het geconstateerde probleem een scopewijziging was of het gevolg van een onjuist concept. Dezelfde situatie ziet er, als die zorgvuldig wordt aangepakt, enkele weken eerder al anders uit. De integrator laat zien dat de vereiste cyclustijd en de beoogde bedieningswijze in conflict zijn met de huidige afschermingen en de servicetoegang. Hij verbergt het probleem niet achter de opmerking “dat komt bij de inbedrijfstelling wel naar voren”, maar presenteert varianten en hun gevolgen voor het proces, de veiligheid en de latere oplevering.

Juist op dat moment kan de fabriek een weloverwogen beslissing nemen: een volledige modernisering uitvoeren of de werkzaamheden faseren bij een nog onvolledige definitie van de eisen, maar wel met een duidelijk vastgelegde grens van de verantwoordelijkheid voor wijzigingen die tijdens de inbedrijfstelling aan het licht komen. In de praktijk is het daarom zinvol om niet alleen naar verklaringen te vragen, maar ook naar het verloop van eerdere projecten: hoeveel wijzigingen zijn er doorgevoerd nadat het ontwerp was bevroren, hoeveel afwijkingen kwamen er bij de oplevering naar voren, hoeveel interventies waren er na de opstart nodig en wat was de werkelijke tijd dat de werkplek niet beschikbaar was. Zulke vragen maken snel duidelijk of het gaat om een standaardprobleem bij de inbedrijfstelling, of om een ontwerpfout.

Tegen deze achtergrond wordt de rol van documentatie, tests en conformiteitsbeoordeling na de modernisering pas echt zichtbaar. Dat zijn geen bureaucratische toevoegingen aan een al voltooide machine. Ze zijn het resultaat van een goed ontwerpproces, waarin besturingslogica wordt verbonden met veiligheid, ergonomie van de bediening en de behoeften van onderhoud. Als deze elementen niet parallel worden uitgewerkt, neemt de fabriek het risico op het slechtst mogelijke moment over: na de montage, onder druk om de productie te hervatten en zonder zekerheid of de omvang van de wijzigingen niet tot extra verplichtingen aan de kant van de eindgebruiker leidt.

Hoe u verantwoord inkoopt voordat er een probleem ontstaat

Een goede inkoopbeslissing in de automatisering begint niet met het vergelijken van prijzen, maar met de kwaliteit van de input die aan de integrator wordt verstrekt. Als de aanvraag alleen het beoogde productieresultaat beschrijft, vult de opdrachtnemer zelf de projectgrenzen, de wijze van bediening, de servicevoorwaarden en de aannames over de bestaande lijn in. Dat betekent meestal dat de goedkoopste offerte alleen goedkoop is omdat kostenbepalende elementen ontbreken die pas bij de inbedrijfstelling zichtbaar worden, inclusief verborgen kosten die later in het project naar boven komen.

Daarom moet de fabriek niet alleen de functie van de machine of modernisering beschrijven, maar ook de procesbeperkingen, de bedieningseisen, de interfaces met systemen en apparaten die al in bedrijf zijn, de gewenste servicemodus, de omstandigheden van de stilstand en de omvang van de documentatie die nodig is voor onderhoud, opleidingen en latere wijzigingen. In deze fase moet ook worden bepaald of de werktuigbouwkundige en automatiseringsscope gezamenlijk of gescheiden worden uitgevoerd, en wie verantwoordelijk is voor de raakvlakken tussen disciplines. Hoe nauwkeuriger de input, hoe kleiner het risico dat de offerte kosten verbergt die naar een later moment worden doorgeschoven.

Bij de beoordeling van offertes moet niet de belofte “wij doen het compleet” worden beloond, maar datgene wat vóór de opdracht verifieerbaar is. Een goede offerte laat het werkplan zien, de lijst met aannames waarop de prijs is gebaseerd, de benoemde risico’s, de vereiste input aan de kant van de fabriek, de verdeling van verantwoordelijkheden en de manier van testen vóór levering en bij de inbedrijfstelling. Ook moet zij de oplevervoorwaarden duidelijk beschrijven: wat een noodzakelijke voorwaarde voor acceptatie is en wat op een lijst met open punten kan komen om na de opstart af te ronden. Als de integrator risico’s niet kan benoemen, acceptatiecriteria niet kan definiëren of ontbrekende informatie niet kan aanwijzen, verdwijnt het probleem niet na ondertekening van de opdracht. Het wordt alleen verschoven naar de stilstandsplanning en het wijzigingsbudget.

De meeste misverstanden ontstaan later niet door de techniek zelf, maar door een onnauwkeurige overeenkomst. Het commerciële document moet niet alleen de termijn en de prijs vastleggen, maar ook de werkwijze voor wijzigingsbeheer, de rechten op de broncode, het ontwerp en de documentatie, de verplichtingen van beide partijen bij de inbedrijfstelling, de acceptatiecriteria en de volledige lijst van materialen die bij oplevering worden overgedragen. Daaronder vallen programma’s van controllers en panelen, back-ups, schema’s, signaallijsten, instellingen, instructies, testresultaten en documenten die nodig zijn voor verdere exploitatie en een eventueel traject van conformiteitsbeoordeling. Het is goede praktijk om de definitieve oplevering en de laatste betaling afhankelijk te maken van de volledigheid van de documentatie en van de uitvoering van de overeengekomen tests, want juist dan blijkt het werkelijke voorbereidingsniveau van de integrator.

• in de aanvraag: functie, procesbeperkingen, interfaces, servicemodus, verwachte documentatie, projectgrenzen
• in de offerte: aannames, risico’s, testplan, verantwoordelijkheden van beide partijen, oplevervoorwaarden
• in de overeenkomst en bij oplevering: regels voor wijzigingen, rechten op code en documenten, volledige overdracht, acceptatiecriteria

De verwijzing naar formele eisen moet de beslissing afronden, niet vervangen. Alleen verwijzingen naar machineveiligheid, conformiteitsbeoordeling, technische documentatie, instructies of verificatie van veiligheidsfuncties herstellen geen slecht gedefinieerde scope en geen onduidelijke verdeling van verantwoordelijkheden. Als het project betrekking heeft op een nieuwe machine of op een modernisering die als een ingrijpende wijziging kan worden beschouwd, moet dat vroeg genoeg worden onderkend, nog vóór de opdracht en vóór de keuze van de uitvoeringswijze. Anders kan de eindgebruiker met verplichtingen blijven zitten waarmee in de offerte en in de planning geen rekening is gehouden.

De praktische conclusie is eenvoudig: het is goedkoper om meer tijd te steken in het voorbereiden van de aanvraag, het toetsen van de integrator en de veiligheidsbeoordeling vóór de productiestart dan correcties te moeten bekostigen wanneer de lijn al stilstaat en de verantwoordelijkheden van de betrokken partijen onduidelijk blijven. Bij de keuze van een automatiseringsintegrator is veiligheid geen bijkomende kostenpost. Het is de kortste weg om de kosten te beperken die ontstaan wanneer een project al in het begin verkeerd is gedefinieerd. In de praktijk helpt daarbij ook een goed georganiseerde samenwerking tussen de integrator en de technische dienst en een goede voorbereiding van de fabriek op automatisering van productieprocessen.