Risicobeheer in contracten voor de bouw van speciale machines: wanneer een vaste prijs het budget beschermt en wanneer die de kosten van een fout verhoogt

Bij contracten voor de bouw van speciale machines wordt de discussie over een vaste prijs versus een iteratieve aanpak meestal op de verkeerde plaats gevoerd. Het succes van een project wordt zelden alleen door de contractvorm bepaald. Veel belangrijker is het moment waarop partijen de technische uitgangspunten als voldoende uitgewerkt beschouwen om prijs, planning en verantwoordelijkheden vast te leggen. Gebeurt dat te vroeg, dan verdwijnt het risico niet. Het verschuift naar de fase van engineering, inbedrijfstelling, acceptatie en einddocumentatie.

In de praktijk is een speciale machine geen repeteerbaar product, maar een antwoord op een specifiek proces, een concreet werkstuk, de beperkingen van de hal, de werkwijze van de operator en de onderhoudsomstandigheden. Daarom begint risicobeheersing in zo’n project niet bij de keuze van een contractlabel, maar bij het bepalen welke beslissingen nog veilig kunnen worden bijgestuurd en welke na inkoop en prefabricage uitmonden in kostbare aanpassingen. Pas vanuit dat perspectief is het zinvol te beoordelen wanneer een contract met vaste prijs werkt en wanneer gecontroleerde iteratie nodig is in projecten voor speciale machines.

Niet het contract is het probleem, maar het moment waarop de uitgangspunten worden vastgelegd

De bron van risico in projecten voor de bouw van speciale machines is meestal niet het commerciële model zelf, maar het te vroeg vastleggen van prijs, planning en verantwoordelijkheden terwijl de technische uitgangspunten nog onvoldoende zijn uitgewerkt. Als partijen nog geen gezamenlijk, operationeel begrip van de machinefunctie hebben, brengt het contract geen orde in het project, maar verschuift het het conflict alleen naar een later moment.

In de praktijk volstaat een algemene beschrijving van het technologische doel niet. Voordat de scope wordt vastgelegd, moet worden afgestemd hoe de machine in de werkelijke omgeving moet functioneren: welke functies zij moet hebben, welke capaciteit zij moet halen, welke productvarianten zij moet verwerken, waar de interfaces met de omgeving liggen en hoe omstellingen, handmatige bediening, servicetoegang en herstel na stilstand eruit moeten zien. Even belangrijk zijn de grenzen van de automatisering, de verdeling van de levering, de veiligheidseisen, de uitgangspunten voor onderhoud en de volledigheid van de acceptatiedocumentatie. Zonder deze afspraken neemt een vaste prijs de onzekerheid niet weg, maar verandert die in een discussie over de vraag of een bepaalde correctie een nadere precisering van de eisen is of een scopewijziging.

Dat onderscheidt juist een goed gestructureerd project van een project dat alleen schijnbaar voorspelbaar is. In dat laatste proberen partijen het project commercieel af te sluiten voordat de technische beslissingen zijn genomen die later toch terugkeren. Dat gebeurt het vaakst op punten die in het begin als “uitvoeringsdetails” worden gezien: de werkvolgorde, instel- en handmatige modi, vergrendelingen, afhankelijkheden van bovenliggende systemen, voorwaarden voor omstelling of de manier waarop de operator kan ingrijpen. Pas later blijkt dat juist deze kwesties bepalend zijn voor de besturingsarchitectuur, de beschermingsmaatregelen, de cyclustijd en de acceptatiecriteria.

Daarom moet een iteratieve aanpak niet worden opgevat als toestemming voor gebrek aan discipline. In een goed geleid project betekent zij dat onzekerheden gecontroleerd zichtbaar worden gemaakt op een moment waarop het wegnemen ervan nog goedkoop is en organisatorisch nog kan worden teruggedraaid. Als eerst de proceslogica, bedieningsscenario’s, bedrijfsmodi, afhankelijkheden van de lijn en het gedrag van de machine na stilstand worden geverifieerd, kunnen veel onjuiste aannames nog worden gecorrigeerd voordat de mechanica, de besturingskasten en de acceptatiedocumentatie worden gerealiseerd.

• Vóór een offerte met vaste aanneemsom moeten ten minste de volgende punten zijn vastgelegd: de functie van de machine, de vereiste capaciteit, de productvariatie, de interfaces met de omgeving, de werkomgeving, de veiligheidseisen, de uitgangspunten voor onderhoud en de scope van de acceptatiedocumentatie.

In veel projecten is het daarom verstandiger om eerst de conceptfase, de risicoanalyse en de engineeringsfase in te kopen, en pas na bevestiging dat de uitgangspunten voldoende zijn uitgewerkt over te gaan naar uitvoering tegen een vaste prijs. Dat is geen uiting van overdreven formalisme, maar een manier om de kosten van te vroeg genomen beslissingen te beperken.

Dit is ook van belang voor een heldere verdeling van verantwoordelijkheden. Een opdracht voor het bereiken van een bepaald technologisch resultaat is iets anders dan een opdracht voor een machine als product waarvoor een conformiteitsbeoordeling en CE-markering vereist zijn. In de praktijk lopen die kaders vaak door elkaar, maar ze mogen niet met elkaar worden vereenzelvigd. Als het project betrekking heeft op een machine of een samenstel van machines, moet al aan het begin worden vastgesteld wie verantwoordelijk is voor de veiligheidseisen, de risicoanalyse, de volledigheid van de technische documentatie en de voorwaarden voor overdracht voor gebruik; ook de planning van conformiteitsbeoordeling en CE-markering moet dan duidelijk zijn.

Waar kosten en risico echt toenemen

Kosten en risico nemen toe wanneer bij een te lage mate van uitwerking van de uitgangspunten beslissingen worden vastgelegd die later niet meer goedkoop kunnen worden teruggedraaid. In de conceptfase betekent een correctie meestal een wijziging van de werkingslogica, de interfaces of de veiligheidsuitgangspunten. Nadat het ontwerp is bevroren, wordt diezelfde correctie een wijziging van reeds ingekochte componenten, een mechanische aanpassing, een ombouw van besturingskasten, een softwarecorrectie, nieuwe tests en uitstel van de acceptatie.

Na de prefabricage, na het programmeren van de besturingslogica en vooral na de FAT-tests is de kost van een wijziging niet langer alleen een technische kost. Daar komen planning, de organisatie van de inbedrijfstelling, hernieuwde validatie en de verdeling van verantwoordelijkheden tussen de partijen bij. Daarom is het zinvol een project niet alleen op de eindprijs te beoordelen, maar ook op de wijzigingskosten per projectfase. In het begin overheersen de kosten van engineering. Daarna komen de kosten van materiaal en uitvoering erbij. Helemaal aan het einde wordt verstoring van de oplevering, de inbedrijfstelling en de werking van de fabriek het duurst, inclusief de verborgen kosten van conformiteit en opleveringen in het machineproject.

Die verschuiving heeft een eenvoudige consequentie voor het project. Als de functionele architectuur, de belangrijkste interfaces, de bedrijfsomstandigheden, de vereiste prestaties en de manier waarop de kwaliteit van de cyclus wordt gemeten niet tijdig zijn vastgelegd, brengt het contract geen structuur meer in het project. Het verschuift dan alleen nog de gevolgen van laat beschikbare kennis van de ene partij naar de andere. In een model met een vaste prijs bewaakt de opdrachtnemer de grenzen van de afgesproken scope, omdat elke onduidelijkheid in de inputgegevens een reële kost betekent. De opdrachtgever probeert op zijn beurt het beoogde procesresultaat te behouden, terwijl kennis over het detail, de utilities, de omgeving van de lijn en de werkelijke gebruiksomstandigheden vaak pas tijdens het project rijpt.

Meestal gaat het daarbij niet om één duidelijke fout. Het probleem bouwt zich op door een reeks kleine onduidelijkheden: wie levert de signalen van aangrenzende installaties, wie is verantwoordelijk voor de utilities en hun parameters, wie voorziet in de toegangsgebieden voor operator en technische dienst, hoe wordt de prestatie gemeten, op welke productbatch wordt de werking getest en volgens welk criterium wordt de kwaliteit van de cyclus beoordeeld. Elk van die punten lijkt op zichzelf onschuldig. Samen kunnen ze de verantwoordelijkheid, de planning en de oplevervoorwaarden ingrijpend veranderen, zeker wanneer prestatie-indicatoren en meetmethoden niet eenduidig zijn afgesproken.

Vooral het veiligheidsrisico neemt snel toe wanneer de productiefunctie pas laat wordt uitgewerkt. Dan vloeien de beschermingsmaatregelen niet voort uit het concept, maar worden ze aangepast aan een bestaande of bijna afgewerkte constructie. Dan ontstaan de bekende spanningen: afschermingen hinderen het omstellen, vergrendelingen bemoeilijken het verhelpen van blokkades, de stoplogica wordt ondergeschikt gemaakt aan de bestaande aandrijfconfiguratie en instelmodi en toegang tot gevarenzones worden ad hoc opgelost. Zo’n project kan nog altijd tot inbedrijfstelling komen, maar de kosten om afwijkingen en gebruiksbeperkingen weg te werken zijn dan onvergelijkbaar veel hoger dan in de conceptfase en bij de identificatie van gevaren volgens ISO 12100.

Als het voorwerp van de bestelling een machine of een samenstel van machines is, hebben late wijzigingen niet alleen gevolgen voor de uitvoering, maar ook voor de conformiteitsbeoordeling, de volledigheid van de technische documentatie, de handleiding en de voorwaarden voor ingebruikname. Daarom moeten afspraken over FAT-tests en hun criteria, SAT en oplevercriteria vanaf het begin de functionele eisen koppelen aan de veiligheidseisen. Die twee sporen van elkaar loskoppelen eindigt er meestal mee dat het probleem bij de oplevering terugkomt.

Een iteratieve aanpak kan foutieve aannames eerder zichtbaar maken, maar lost op zichzelf de kwestie van kosten en verantwoordelijkheid niet op. Als een project geen harde beslismomenten heeft, geen afgestemde inputgegevens en geen meetbare acceptatiecriteria voor de opeenvolgende fasen, gaat het over in een toestand van voortdurende verfijning. Dan betaalt de opdrachtgever voor aanhoudende onzekerheid, terwijl de opdrachtnemer niet meer kan aantonen wanneer aan de eisen is voldaan.

Hoe kiest u het juiste model en legt u beslissingen vast

De keuze tussen een vaste prijs en een iteratieve aanpak mag niet voortkomen uit overtuigingen, maar uit een beoordeling van de volwassenheid van de uitgangspunten. Bij projecten voor de bouw van speciale machines is een gemengd model vaak het veiligst: een korte, afzonderlijk betaalde conceptfase om risico’s af te bakenen en af te sluiten, en pas daarna een uitvoeringscontract met een vaste prijs voor een scope die daadwerkelijk de vereiste volwassenheid heeft bereikt.

Zo’n opzet verzwakt de budgetcontrole niet. Ze verschuift alleen het moment waarop de prijs wordt vastgezet naar een fase waarin al duidelijk is wat er moet worden gerealiseerd, welke procesbeperkingen er zijn en waar de grens van de verantwoordelijkheid ligt. Als de technologische eisen stabiel zijn, de interfaces bekend zijn en de oplevercriteria meetbaar kunnen worden beschreven, brengt een vaste prijs structuur in het project en maakt die de afrekening eenvoudiger. Als de onzekerheid daarentegen betrekking heeft op functie, ergonomie, veiligheid, integratie met de lijn of het procesgedrag aan de kant van de gebruiker, is gecontroleerde iteratie nodig vóór de start van inkoop en uitvoering.

Essentieel is het onderscheid tussen omkeerbare en onomkeerbare beslissingen. Iteratie wordt anders aangepakt voor operatorschermen, werksequenties, rapporten, extra uitrusting of de organisatie van de bediening dan voor de veiligheidsarchitectuur, afmetingen, toegangsgebieden, service-uitgangspunten, aflegpunten en interfaces met aangrenzende installaties. Dat onderscheid moet al worden vastgelegd in de specificatie van gebruikersvereisten en in het register van projectrisico’s. Daarvan hangt af welke uitgangspunten formeel moeten worden goedgekeurd vóór de bestelling van componenten, en welke kunnen worden overgelaten aan functionele tests, ondersteund door een risicobeoordeling volgens ISO 12100.

Vanuit het perspectief van de opdrachtgever betekent dit dat niet alleen de levering, maar ook het besluitvormingsproces moet worden gestructureerd. Er is een eigenaar van de eisen nodig aan de kant van de investeerder, een afgesproken ritme van projectreviews, een transparant risicoregister en formele goedkeuring van uitgangspunten vóór de overgang naar inkoop, prefabricage en inbedrijfstelling. Zonder dat volstaat zelfs een goed contract niet, omdat de partijen dan nog steeds verschillend begrijpen wat al is afgesproken.

De meeste geschillen ontstaan door onduidelijke contractbepalingen. In de uitvoeringsovereenkomst moet ondubbelzinnig zijn vastgelegd wat de leveringsomvang is, welke inputgegevens door de opdrachtgever worden aangeleverd, hoe de wijzigingsprocedure verloopt, wat de acceptatiemomenten zijn, onder welke voorwaarden deeloplevering en eindoplevering plaatsvinden en welke documentatie na afronding van de werkzaamheden volledig moet worden overgedragen. Vóór ondertekening moeten in elk geval de volgende zaken gereed zijn: procesbeschrijving, materiaalstroom, prestatie-eisen, omgevingscondities, interfacebeschrijving, verwachtingen vanuit onderhoud, veiligheidsuitgangspunten en acceptatiecriteria.

Als een van deze elementen nog niet is vastgesteld, moet dat expliciet worden ondergebracht in een conceptfase met een aparte verrekeningswijze en een beslismoment, waarna pas een vaste prijs kan worden afgegeven. Het is net zo belangrijk om de grens te beschrijven tussen inbedrijfstelling en latere procesoptimalisatie. Zonder dat onderscheid wordt de opdrachtnemer verantwoordelijk voor een resultaat dat bij oplevering niet objectief kan worden afgebakend.

• lage onzekerheid in de uitgangspunten, bekende interfaces, meetbare oplevering: overeenkomst met vaste prijs;
• grote onzekerheid over functies, veiligheid of integratie: eerst een concept- en iteratiefase, daarna pas prijsbepaling voor de uitvoering;
• gedeeltelijk uitgewerkte scope: een gefaseerd model, waarbij afgeronde onderdelen overgaan naar uitvoering tegen een vaste prijs en open punten binnen een gecontroleerde wijzigingsprocedure blijven.

Uiteindelijk komt ook de ordening van conformiteit en verantwoordelijkheid terug. Technische beslissingen moeten vanaf het begin worden gekoppeld aan de latere conformiteitsbeoordeling van machines en niet uitsluitend als ontwerpkwesties worden behandeld. Als in de conceptfase de veiligheidsuitgangspunten, leveringsgrenzen en de verdeling van verantwoordelijkheid voor de technische documentatie niet zijn vastgelegd, komt dat later terug bij de risicoanalyse, de oplevering en het opstellen van de einddocumenten. Het gaat hier niet om extra formaliteiten, maar om beheersbaarheid van het project.

Praktijkvoorbeeld en heldere verantwoordelijkheidsverdeling

De eenvoudigste praktische conclusie is deze: in een project voor een speciale machine moet de verantwoordelijkheid voor de uitvoering niet definitief worden verdeeld voordat duidelijk is wie verantwoordelijk is voor de technische beslissingen. Wanneer de opdrachtgever alleen een capaciteitsdoel of een algemeen proceseffect beschrijft, terwijl bedrijfsmodi, omstellogica, vereiste operatoringrepen en beperkingen van de bestaande installatie nog niet zijn vastgesteld, dekt een vaste prijs in feite alleen de beschrijving van verwachtingen en niet een uitvoeringsscope die al voldoende is uitgewerkt.

Het typische verloop is bekend. Een fabriek bestelt een niet-standaard cel voor de verwerking van meerdere productvarianten en gaat uit van een bepaalde uurcapaciteit. In eerste instantie lijkt de procesbeschrijving toereikend: aanvoer van het product, bewerking, afvoer en statussignalering. Tijdens het project blijkt echter dat een deel van de batches handmatig moet worden gepositioneerd, dat omstellen meerdere keren per ploeg nodig is, dat de operator periodiek in de werkzone moet reiken en dat de bestaande lijn beperkingen oplegt qua beschikbare ruimte, aanvoerhoogte en stoplogica.

In de variant waarbij de prijs te vroeg is vastgelegd, voert de opdrachtnemer letterlijk uit wat in de scope is opgenomen. Elke later aan het licht gekomen behoefte keert terug als wijziging: extra afschermingen, een andere bewegingsvolgorde, nieuwe vergrendelingen, aanpassing van de besturing, uitbreiding van de interfaces met de lijn. Het project verliest zijn voortgang en opleveringen zijn niet langer een verificatie van de werking, maar veranderen in een discussie over de interpretatie van de eisen. De risicoanalyse en documentatie proberen dan een architectuur te onderbouwen die niet is ontworpen voor de werkelijke gebruikswijze.

In een gefaseerde aanpak ziet het begin er anders uit. Eerst worden de functie van de werkplek, de leveringsgrenzen, de interfaces met de omgeving, de belangrijkste bedieningsscenario’s en de basisveiligheidsuitgangspunten vastgelegd, inclusief de verantwoordelijkheid voor integratie met de bestaande lijn. Pas na deze fase worden de uitvoeringsscope, planning en acceptatiecriteria bepaald. Dat neemt wijzigingen niet volledig weg, maar vermindert het aantal discussiepunten duidelijk, omdat dan al bekend is welke beslissingen een nadere uitwerking zijn en welke een nieuwe scope creëren.

Dit voorbeeld laat goed zien dat veiligheid niet achteraf mag worden aangepast aan oplossingen die al zijn besteld of gerealiseerd. Veiligheid moet gelijktijdig worden ontwikkeld met de machinefunctie, de bedieningsscenario’s, het omstellen, reinigen en servicen. Anders herstelt zelfs een formeel correcte rolverdeling de verkeerde volgorde van beslissingen niet; ook zaken als Lockout Tagout-procedures moeten immers aansluiten op de feitelijke werkwijze.

Pas in deze fase komt ook de formele structuur in beeld die geldt voor Polen en de Europese Unie. Bij een project voor een speciale machine moet vanaf het begin duidelijk zijn wie optreedt als fabrikant in de zin van de regelgeving, wie verantwoordelijk is voor de volledigheid van de technische documentatie, wie de conformiteitsbeoordeling uitvoert en wie de CE-markering aanbrengt, als die vereist is. Ook moet worden vastgesteld of het project betrekking heeft op een nieuwe machine, een samenstel van machines of een ingrijpende wijziging van een bestaande installatie, omdat daarvan niet alleen afhangt welke documenten nodig zijn, maar ook hoe de verantwoordelijkheden tussen de integrator, deelleveranciers en de eindgebruiker zijn verdeeld.

Juist daarom mogen vragen over de verdeling van verantwoordelijkheid tussen het procesdeel en het machinedeel, over de zin van een voorwaardelijke oplevering bij ontbrekende documentatie, instructies of een niet-afgeronde risicoanalyse, en over de aanpak van modernisering niet pas bij de oplevering opkomen. Als ze pas zo laat terugkomen, betekent dat meestal dat het contract eerder is afgerond dan het project.

De praktische conclusie is dus vrij eenvoudig. Bij de bouw van speciale machines hoeft u niet te kiezen tussen volledige starheid en volledige openheid. Het gaat erom te bepalen welke onderdelen van het project al voldoende zijn uitgewerkt om binnen een vaste prijs te worden vastgelegd, en welke nog gecontroleerde iteratie vereisen. Een goed aangestuurd project sluit wijzigingen niet volledig uit. Het beperkt alleen die wijzigingen die te laat opduiken, het meeste kosten en de verantwoordelijkheid voor veiligheid, functionaliteit, conformiteitsbeoordeling en planning in het machineproject vertroebelen.