Gestionarea riscurilor în contractele pentru construcția de mașini speciale: când prețul fix protejează bugetul și când mărește costul erorii

În contractele pentru construirea de mașini speciale, disputa dintre prețul fix și abordarea iterativă mută, de regulă, problema în locul greșit. Reușita proiectului este rareori decisă de formula contractuală în sine. Mult mai important este momentul în care părțile consideră că ipotezele tehnice sunt suficient de mature pentru a fixa prețul, termenul și răspunderea. Dacă acest lucru se întâmplă prea devreme, riscul nu dispare. El se mută în faza de proiectare, punere în funcțiune, recepție și documentație finală.

În practică, o mașină specială nu este un produs repetitiv, ci răspunsul la un proces concret, la o anumită piesă, la constrângerile halei, la modul de lucru al operatorului și la condițiile de mentenanță. De aceea, gestionarea riscului într-un astfel de proiect nu începe cu alegerea etichetei contractului, ci cu identificarea deciziilor care mai pot fi corectate în siguranță și a celor care, după achiziții și prefabricație, devin modificări costisitoare. Abia în acest context se poate evalua realist când funcționează un contract cu preț fix și când este necesară o iterație controlată în proiectele de mașini speciale.

Problema nu este contractul, ci momentul închiderii ipotezelor

Sursa riscului în proiectele de construire a mașinilor speciale nu este, de cele mai multe ori, modelul comercial în sine, ci închiderea prea devreme a prețului, a calendarului și a răspunderii, pe baza unor ipoteze tehnice insuficient maturizate. Dacă părțile nu au încă o înțelegere comună, operațională, a funcțiilor mașinii, contractul nu pune proiectul în ordine, ci doar amână conflictul.

În practică, nu este suficientă o descriere generală a obiectivului tehnologic. Înainte de închiderea domeniului trebuie convenit cum va funcționa mașina în mediul real: ce funcții va avea, ce productivitate trebuie să atingă, ce variante de produs trebuie să poată gestiona, unde sunt interfețele cu mediul din jur, cum trebuie să arate schimbările de format, operarea manuală, accesul pentru service și reluarea funcționării după oprire. La fel de importante sunt limitele automatizării, împărțirea livrării, cerințele de siguranță, ipotezele privind mentenanța și setul complet al documentației de recepție. Fără aceste clarificări, prețul fix nu elimină incertitudinea, ci o transformă într-o dispută privind faptul dacă o anumită corecție reprezintă o precizare a cerințelor sau o schimbare de domeniu.

Aceasta este diferența dintre un proiect bine structurat și unul doar aparent previzibil. În al doilea caz, părțile încearcă să închidă comercial proiectul înainte de a fi luate deciziile inginerești care, ulterior, oricum vor reveni în discuție. Cel mai des se întâmplă în zone considerate la început „detalii de execuție”: secvența de lucru, modurile de reglaj și manuale, interblocările, dependențele față de sistemele superioare, condițiile de schimbare de format sau modul de intervenție al operatorului. Abia mai târziu se constată că tocmai aceste aspecte decid arhitectura de comandă, măsurile de protecție, timpul de ciclu și criteriile de recepție și FAT.

De aceea, abordarea iterativă nu ar trebui înțeleasă ca o acceptare a lipsei de disciplină. Într-un proiect bine condus, ea înseamnă scoaterea la iveală, în mod controlat, a incertitudinilor atunci când eliminarea lor este încă ieftină și reversibilă din punct de vedere organizațional. Dacă mai întâi sunt verificate logica procesului, scenariile de operare, modurile de lucru, dependențele față de linie și modul în care se comportă mașina după oprire, multe ipoteze greșite pot fi corectate înainte de realizarea mecanicii, a tablourilor electrice și a documentației de recepție.

• Înainte de o ofertă cu preț forfetar ar trebui să fie închise cel puțin: funcția mașinii, productivitatea cerută, varietatea produselor, interfețele cu mediul înconjurător, mediul de lucru, cerințele de siguranță, ipotezele de mentenanță și domeniul documentației de recepție.

În multe proiecte este, așadar, mai rațional să se achiziționeze mai întâi conceptul, analiza riscurilor în proiect și faza de proiectare, iar abia după confirmarea maturității ipotezelor să se treacă la execuție cu preț fix. Nu este o manifestare de formalism excesiv, ci o modalitate de a limita costul deciziilor luate prea devreme.

Acest lucru contează și pentru claritatea răspunderii. Una este o comandă pentru obținerea unui anumit efect tehnologic și alta este o comandă pentru o mașină ca produs care necesită evaluarea conformității și marcaj CE. În practică, aceste două planuri se suprapun adesea, dar nu trebuie confundate. Dacă obiectul proiectului este o mașină sau un ansamblu de mașini, atunci încă de la început trebuie stabilit cine răspunde pentru cerințele de siguranță, analiza riscurilor, caracterul complet al documentației tehnice și condițiile de predare pentru utilizare.

Unde cresc cu adevărat costul și riscul

Costul și riscul cresc atunci când, pe baza unor ipoteze insuficient maturizate, sunt închise decizii care ulterior nu mai pot fi inversate ieftin. În etapa de concept, o corecție înseamnă de regulă schimbarea logicii de funcționare, a interfețelor sau a ipotezelor de siguranță. După înghețarea proiectului, aceeași corecție devine schimbarea componentelor deja achiziționate, modificare mecanică, refacerea tablourilor electrice, corectarea software-ului, repetarea testelor și amânarea recepțiilor.

După prefabricare, după scrierea logicii de comandă și mai ales după testele FAT, costul unei modificări nu mai este doar un cost tehnic. El include deja termenul, organizarea punerii în funcțiune, revalidarea și repartizarea responsabilității între părți. De aceea, proiectul merită evaluat nu doar prin prisma prețului final, ci și a costului modificării în funcție de etapă. La început predomină costul muncii de proiectare. Ulterior se adaugă costul materialelor și al execuției. La final, cel mai costisitor devine impactul asupra recepției, punerii în funcțiune și funcționării unității.

Această deplasare are o consecință simplă în proiectare. Dacă arhitectura funcțională, interfețele principale, condițiile de lucru, performanța cerută și modul de măsurare a calității ciclului nu au fost stabilite suficient de devreme, contractul încetează să mai ordoneze proiectul. El începe doar să transfere de la o parte la alta efectele informațiilor apărute târziu. În modelul cu preț fix, executantul apără limitele domeniului convenit, deoarece orice ambiguitate în datele de intrare înseamnă un cost real. La rândul său, beneficiarul încearcă să păstreze rezultatul de proces așteptat, deși înțelegerea detaliilor, a utilităților, a mediului liniei și a condițiilor reale de exploatare se maturizează abia pe parcursul lucrărilor.

Cel mai adesea, nu este vorba despre un singur defect evident. Problema crește printr-o serie de neclarități minore: cine furnizează semnalele de la echipamentele învecinate, cine răspunde de utilități și de parametrii acestora, cine prevede zonele de acces pentru operator și pentru mentenanță, cum se măsoară performanța, pe ce lot de piese se verifică funcționarea și după ce criteriu se evaluează calitatea ciclului. Fiecare dintre aceste aspecte, luat separat, pare inofensiv. Împreună însă pot schimba responsabilitatea, termenul și condițiile de recepție.

Riscul de securitate crește deosebit de repede atunci când funcția de producție este detaliată târziu. În acest caz, măsurile de protecție nu mai rezultă din concept, ci sunt adaptate la o construcție deja finalizată sau aproape finalizată. Apar tensiuni tipice: protecțiile incomodează schimbarea de format, interblocările îngreunează eliminarea blocajelor, logica de oprire este subordonată sistemului de acționare existent, iar modurile de reglaj și accesul în zonele periculoase sunt rezolvate provizoriu. Un astfel de proiect poate ajunge la punerea în funcțiune, dar costul eliminării neconformităților și al limitărilor de utilizare este atunci incomparabil mai mare decât în etapa de concept și de identificare a pericolelor conform ISO 12100.

Dacă obiectul comenzii este o mașină sau un ansamblu de mașini, modificările târzii influențează deja nu doar execuția, ci și evaluarea conformității, caracterul complet al documentației tehnice, instrucțiunile și condițiile de predare pentru utilizare. De aceea, stabilirile privind testele FAT, SAT și criteriile de recepție ar trebui să lege de la început cerințele funcționale de cerințele de securitate. Separarea acestor două planuri se încheie, de regulă, cu reapariția problemei la recepție.

Abordarea iterativă poate scoate mai devreme la iveală ipotezele greșite, dar nu rezolvă de la sine problema costului și a responsabilității. Dacă proiectul nu are puncte de decizie ferme, date de intrare convenite și criterii măsurabile de acceptare pentru etapele succesive, el intră într-o stare de clarificare continuă. Într-o astfel de situație, beneficiarul plătește pentru o incertitudine prelungită, iar executantul pierde posibilitatea de a demonstra când au fost îndeplinite cerințele.

Cum alegi modelul și cum consemnezi deciziile

Alegerea între prețul fix și abordarea iterativă nu ar trebui să rezulte din convingeri, ci din evaluarea gradului de maturitate al ipotezelor. În proiectele de construcție a mașinilor speciale, cel mai sigur este adesea un model mixt: o fază scurtă, plătită separat, pentru concept și închiderea riscurilor, iar abia după aceasta un contract de execuție cu preț fix pentru un domeniu care a atins în mod real maturitatea necesară.

Un astfel de aranjament nu slăbește controlul asupra bugetului. El mută doar momentul înghețării prețului într-o etapă în care se știe deja ce trebuie realizat, care sunt constrângerile procesului și unde se află limita responsabilității. Dacă cerințele tehnologice sunt stabile, interfețele sunt cunoscute, iar criteriile de recepție pot fi descrise în mod măsurabil, prețul fix ordonează proiectul și facilitează decontarea. Dacă însă incertitudinea privește funcția, ergonomia, securitatea, integrarea cu linia sau comportamentul procesului de partea utilizatorului, este necesară o iterație controlată înainte de lansarea achizițiilor și a execuției.

Esențială este diferențierea dintre deciziile reversibile și cele ireversibile. Într-un fel se conduce iterația pentru ecranele operatorului, secvențele de lucru, rapoarte, echiparea suplimentară sau organizarea deservirii și în alt fel pentru arhitectura de securitate, gabarite, zonele de acces, ipotezele de service, punctele de depunere și interfețele cu echipamentele învecinate. Această diferențiere ar trebui consemnată încă din specificația cerințelor utilizatorului și în registrul riscurilor de proiect. De ea depinde care ipoteze trebuie aprobate formal înainte de comandarea componentelor și care pot fi lăsate pentru testele funcționale.

Din perspectiva beneficiarului, aceasta înseamnă nevoia de a ordona procesul decizional, nu doar livrarea în sine. Este necesar un responsabil al cerințelor din partea investitorului, un ritm convenit al analizelor de proiect, un registru transparent al riscurilor și aprobarea formală a ipotezelor înainte de trecerea la achiziții, prefabricare și punere în funcțiune. Fără acestea, nici măcar un contract bun nu este suficient, pentru că părțile vor continua să înțeleagă diferit ce anume a fost deja convenit.

Cele mai multe dispute apar din cauza formulărilor contractuale neclare. Contractul de execuție ar trebui să definească fără echivoc domeniul livrării, datele de intrare furnizate de beneficiar, procedura de modificare, punctele de acceptare, condițiile de recepție parțială și finală, precum și caracterul complet al documentației predate după încheierea lucrărilor. Înainte de semnare, ar trebui să fie pregătite cel puțin: descrierea procesului, fluxul de materiale, cerințele de performanță, condițiile de mediu, descrierea interfețelor, așteptările privind mentenanța, ipotezele de siguranță și criteriile de recepție și FAT.

Dacă unul dintre aceste elemente nu este încă stabilit, el ar trebui inclus explicit în faza de concept, cu o modalitate separată de decontare și cu un punct de decizie după care se trece abia apoi la ofertarea cu preț forfetar. La fel de importantă este și definirea clară a limitei dintre punerea în funcțiune și optimizarea ulterioară a procesului. Fără această distincție, executantul începe să răspundă pentru un rezultat care nu poate fi închis în mod obiectiv la recepție.

• incertitudine redusă a ipotezelor, interfețe cunoscute, recepție măsurabilă: contract cu preț fix;
• incertitudine ridicată privind funcțiile, siguranța sau integrarea: fază de concept și iterații înainte de ofertarea execuției;
• domeniu parțial matur: model etapizat, în care elementele închise trec la execuție forfetară, iar cele deschise rămân într-o procedură controlată de modificare.

La final revine și ordinea conformității și a responsabilității. Deciziile tehnice trebuie corelate de la început cu evaluarea conformității mașinilor, nu tratate exclusiv ca aspecte de proiectare. Dacă în etapa de concept nu au fost închise ipotezele de siguranță, limitele livrării și împărțirea responsabilității pentru documentația tehnică, problema va reapărea la analiza riscurilor în proiect, la recepție și la pregătirea documentelor finale. Nu este vorba despre multiplicarea formalităților, ci despre controlul proiectului.

Exemplu din practică și clarificarea responsabilităților

Cea mai simplă concluzie practică este următoarea: într-un proiect de mașină specială, responsabilitatea pentru execuție nu ar trebui împărțită definitiv înainte de a fi clarificate responsabilitățile pentru deciziile tehnice. Când beneficiarul descrie doar obiectivul de productivitate sau efectul general al procesului, dar nu sunt încă stabilite modurile de lucru, logica schimbărilor de serie, intervențiile necesare ale operatorului și constrângerile sistemului existent, prețul fix acoperă în realitate o descriere a așteptărilor, nu un domeniu de execuție matur.

Desfășurarea tipică este bine cunoscută. Fabrica comandă o celulă nestandardizată pentru manipularea mai multor variante de piesă și presupune o anumită productivitate orară. La început, descrierea procesului pare suficientă: alimentarea piesei, operația de lucru, preluarea, semnalizarea stărilor. Pe parcursul proiectului se constată însă că o parte din loturi necesită poziționare manuală, schimbarea de serie trebuie făcută de câteva ori pe schimb, operatorul pătrunde periodic în zona de lucru, iar linia existentă impune limitări de spațiu, de înălțime a alimentării și de logică a opririi.

În varianta în care prețul este închis prea devreme, executantul realizează literal ceea ce a fost înscris în domeniu. Fiecare nevoie apărută ulterior revine sub formă de modificare: protecții suplimentare, altă secvență de mișcări, noi interblocări, corectarea comenzii, completarea interfețelor cu linia. Proiectul își pierde fluiditatea, iar recepțiile încetează să mai fie o verificare a funcționării și se transformă într-o dispută privind interpretarea cerințelor. Evaluarea riscului conform ISO 12100 și documentația încearcă atunci să justifice o arhitectură care nu a fost proiectată pentru modul real de utilizare.

În varianta etapizată, începutul arată diferit. Mai întâi se închid funcția postului, limitele livrării, interfețele cu mediul înconjurător, principalele scenarii de operare și ipotezele de bază privind siguranța, inclusiv responsabilitatea pentru integrarea cu linia existentă. Abia după această etapă se stabilesc domeniul de execuție, calendarul și criteriile de recepție. Acest lucru nu elimină complet modificările, dar reduce clar numărul punctelor litigioase, pentru că se știe deja care decizii reprezintă o detaliere și care creează un domeniu nou.

Un astfel de exemplu arată bine că siguranța nu ar trebui adaptată ulterior la soluții deja comandate sau executate. Ea trebuie dezvoltată împreună cu funcția mașinii, scenariile de operare, schimbarea de serie, curățarea și service-ul. În caz contrar, chiar și o împărțire formal corectă a rolurilor nu va repara ordinea greșită a deciziilor.

Abia în această etapă apare în mod justificat cadrul formal specific Poloniei și Uniunii Europene. Într-un proiect de mașină specială trebuie știut de la început cine acționează ca producător în sensul reglementărilor, cine răspunde pentru caracterul complet al documentației tehnice, cine efectuează evaluarea conformității și cine aplică marcajul CE, dacă acesta este necesar. De asemenea, trebuie stabilit dacă obiectul proiectului este o mașină nouă, un ansamblu de mașini sau o modificare substanțială a sistemului existent, deoarece de acest lucru depind nu doar setul de documente, ci și însăși ordinea responsabilităților între integrator, furnizorii parțiali și utilizatorul final.

Tocmai de aceea, întrebările privind împărțirea responsabilității pentru partea de proces și partea de mașină, sensul unei recepții condiționate în cazul lipsurilor din documentație, instrucțiuni sau al unei analize de risc nefinalizate, precum și modul de desfășurare a modernizării nu ar trebui să apară abia la recepție. Dacă revin atât de târziu, de regulă înseamnă că contractul a fost închis înaintea proiectului.

Concluzia practică este, așadar, destul de simplă. În construcția de mașini speciale, nu este nevoie să alegi între rigiditate totală și deschidere totală. Trebuie identificat care elemente ale proiectului sunt deja suficient de mature pentru a fi închise într-o formulă cu preț forfetar și care mai necesită încă iterații controlate. Un proiect bine gestionat nu elimină complet schimbările. El doar limitează acele schimbări care apar prea târziu, costă cel mai mult și diluează responsabilitatea pentru siguranța, funcționarea și conformitatea mașinii.