O ofertă a unui furnizor poate veni însoțită de un dosar cu certificate, rapoarte de testare și o prezentare cu proiecte anterioare, dar nimic din toate acestea nu răspunde la întrebarea esențială: se aplică aceste dovezi sistemului pentru care se face oferta? Analiza dovezilor nu ține de volumul documentelor depuse, ci de faptul dacă fiecare document are legătură cu această entitate juridică, cu această configurație și cu o situație de proiect comparabilă cu cea planificată. Această legătură trebuie verificată cu atenție, deoarece un document poate fi autentic și totuși să nu fie aplicabil.
Ce poate și ce nu poate dovedi fiecare tip de probă
Certificatele, rapoartele de testare și proiectele de referință răspund la întrebări diferite, iar tratarea lor ca dovezi interschimbabile ale gradului de pregătire creează lacune care ies la iveală ulterior în cadrul proiectului. Un certificat atestă faptul că un sistem sau un organism a emis o concluzie cu privire la o entitate, un produs sau un amplasament specific, în condiții definite; acesta nu descrie modul în care a funcționat o unitate specifică și nu confirmă faptul că domeniul de aplicare certificat acoperă configurația oferită. Un raport de testare descrie ce s-a întâmplat atunci când o configurație specifică a fost testată conform unei metode declarate; acesta nu stabilește că unitatea testată corespunde cu ceea ce va primi proiectul, cu excepția cazului în care se confirmă concordanța configurației. Un proiect de referință descrie ceea ce a livrat un furnizor în altă parte; acesta nu stabilește că aceeași structură de riscuri, limite și responsabilități se aplică proiectului supus evaluării.
În cazul în care un cumpărător are nevoie de o dovadă a capacității generale, un certificat poate îndeplini acest scop în cadrul domeniului de aplicare specificat. În cazul în care un cumpărător are nevoie de o dovadă a performanței pentru configurația oferită, un raport de testare care vizează acea configurație îndeplinește acest scop într-un mod mai direct. În cazul în care un cumpărător trebuie să evalueze dacă experiența unui furnizor este aplicabilă unui nou proiect, un proiect de referință oferă dovezi mai relevante pentru decizia efectivă de achiziție decât un certificat, cu condiția ca contextul operațional și limitele proiectului să fie descrise suficient de detaliat pentru a permite o comparație.
Condiția care modifică această apreciere este gradul de precizie sau de generalitate cu care este formulat domeniul de aplicare al documentului. Un certificat al cărui domeniu de aplicare se limitează la o companie nu se extinde, în general, la o linie specifică de produse, iar un raport de testare al cărui domeniu de aplicare se limitează la o singură configurație nu se extinde la o variantă, cu excepția cazului în care raportul sau furnizorul confirmă că varianta respectivă a fost inclusă. Evaluatorii care acceptă un document doar pentru că acesta există, fără a citi ceea ce prevede de fapt, transferă această lacună în cadrul proiectului. EudraLex Volumul 4 Anexa 15 susține practica de a verifica documentația furnizorului în raport cu criteriile de acceptare predefinite și de a consemna abaterile, în loc să se considere declarațiile furnizorului ca fiind complete încă de la momentul depunerii; această logică de verificare se aplică modului în care o echipă de proiect ar trebui să trateze oricare dintre cele trei tipuri de dovezi înainte de a se baza pe ele.
Verificarea certificatelor în ceea ce privește emitentul, entitatea, domeniul de aplicare și valabilitatea
Un certificat este o declarație emisă de un organism specific cu privire la o entitate, un produs sau un amplasament anume, valabilă în condiții specifice, iar fiecare dintre aceste elemente poate diferi de ceea ce presupune cumpărătorul, fără ca certificatul în sine să fie fals. Discrepanța care apare cel mai frecvent în cadrul evaluării comerciale este cea dintre entitatea care deține certificatul și entitatea care îl prezintă în cadrul ofertei: un certificat eliberat unei societăți-mamă, unei unități de producție sau unei alte entități juridice din cadrul aceleiași structuri corporative nu se extinde automat la entitatea care va deține responsabilitatea contractuală pentru proiect.
Aceeași logică se aplică și domeniului de aplicare. Un certificat poate fi corect și actual, acoperind o categorie de echipamente, un sistem de management sau o instalație, fără a acoperi configurația specifică a sistemului propusă pentru proiect. În cazul în care domeniul de aplicare al certificatului menționează o familie de produse în termeni generali, sarcina cumpărătorului este de a confirma că sistemul propus se încadrează în acea familie, așa cum a fost testat sau evaluat, și nu de a presupune apartenența la acea familie doar pe baza denumirii produsului. Datele de valabilitate implică o condiție similară: un certificat valabil la momentul închiderii licitației poate expira înainte de livrare sau de testele de acceptare, iar un proiect care se întinde pe o perioadă lungă de livrare trebuie să verifice dacă certificatul rămâne valabil pe parcursul etapelor în care se bazează pe acesta.
| Verificarea certificatului | Cu ce se asortează | Limita de decizie |
|---|---|---|
| Persoană juridică | Entitatea menționată în certificat și entitatea care îl prezintă | O neconcordanță între entități rămâne nerezolvată până la clarificarea acesteia |
| Organismul emitent | Organismul emitent menționat pe certificat | Verificați identitatea emitentului înainte de a considera certificatul drept dovadă |
| Numărul certificatului | Numărul certificatului indicat în document | Folosiți numărul pentru a identifica certificatul care face obiectul verificării |
| Domeniul de aplicare | Domeniul de aplicare declarat al certificatului și sistemul propus | Un certificat la nivel de companie nu este suficient pentru a justifica sistemul propus |
| Produs sau site | Produsul sau site-ul relevant menționat în certificat | Confirmați că certificatul se aplică produsului sau amplasamentului propus |
| Data de valabilitate | Data de valabilitate menționată pe certificat | Verificați valabilitatea înainte de a vă baza pe certificat |
În cazul în care unul dintre elemente – emitent, entitate, domeniu de aplicare, produs, amplasament sau data de valabilitate – nu corespunde cu informațiile declarate în ofertă, certificatul nu este invalidat în mod automat, dar încetează să mai funcționeze ca dovadă de sine stătătoare și devine un aspect care necesită clarificare înainte de a putea fi utilizat în sprijinul dosarului proiectului.
Raportul de testare verifică configurația, metoda, calibrarea, rezultatele și aprobarea
Un raport de testare este util doar în măsura în care poate demonstra că un rezultat declarat provine dintr-un test bine definit, efectuat pe o configurație bine definită, folosind instrumente trasabile. O mențiune de „conformitate” fără aceste elemente justificative indică cititorului doar faptul că ceva a îndeplinit o cerință, fără a identifica ce anume a fost testat sau cum s-a ajuns la rezultatul respectiv. Corespondența configurației este prima condiție care trebuie confirmată: în cazul în care un furnizor prezintă un raport referitor la un proiect anterior sau la o versiune anterioară a produsului, cumpărătorul trebuie să știe dacă diferențele dintre acea configurație și cea oferită în prezent sunt relevante pentru rezultatul menționat, deoarece un raport referitor la o configurație diferită nu stabilește rezultatele pentru oferta actuală.
Metoda de testare și echipamentele implică o condiție conexă. O metodă neprecizată înseamnă că cititorul nu poate evalua dacă abordarea de testare corespunde cerințelor proiectului, iar omiterea înregistrărilor de calibrare înseamnă că măsurătorile raportate nu au o bază trasabilă. Criteriile de acceptare servesc drept standard în raport cu care se evaluează rezultatul; un raport care prezintă un rezultat fără a menționa criteriile utilizate pentru evaluarea acestuia îl obligă pe cititor să accepte concluzia furnizorului, în loc să o verifice în mod independent.
Observațiile brute și abaterile documentate influențează ponderea pe care o poate avea un rezultat sumar. Un raport construit în întregime în jurul unei declarații sumare de conformitate, fără observațiile care stau la baza acesteia, nu permite cititorului să verifice dacă rezultatele marginale au fost rotunjite în mod favorabil sau dacă a avut loc o abatere care a fost rezolvată înainte de semnare. În cazul în care o abatere este documentată, dar rezolvarea acesteia nu este, abaterea rămâne deschisă și necesită revizuire înainte ca raportul să poată susține acceptarea proiectului. Aprobarea încheie lanțul de custodie al raportului, confirmând cine a revizuit și a aprobat rezultatul menționat; un raport fără aprobare nu și-a finalizat propriul proces intern, indiferent de ceea ce se menționează în corpul raportului.
| Verificarea raportului de testare | Ce trebuie verificat | Limita de decizie |
|---|---|---|
| Configurația oferită | Configurația testată corespunde cu cea oferită | Un raport referitor la o altă configurație nu stabilește rezultatele pentru ofertă |
| Metoda de testare | Se identifică metoda de testare | O instrucțiune „pass” fără metoda corespunzătoare nu arată cum a fost obținut rezultatul |
| Instrumente și etalonare | Instrumentele și calibrarea acestora sunt documentate | Lipsa unui instrument sau a unor detalii privind calibrarea limitează trasabilitatea măsurătorilor |
| Criterii de acceptare | Criteriile de acceptare sunt prezentate | Evaluează rezultatele în funcție de criteriile stabilite, nu doar pe baza unei simple mențiuni de „promovat” |
| Observații brute | Observațiile brute confirmă rezultatul raportat | Nu vă bazați doar pe o declarație sumară privind aprobarea |
| Deviații | Orice abateri sunt consemnate | Abaterile nerezolvate trebuie verificate înainte de acceptare |
| Aprobare | Raportul include aprobarea | Verificați semnătura de aprobare înainte de a considera raportul drept probă completă |
Aceste verificări sunt deosebit de importante în etapa de revizuire care precede testarea de acceptare, atunci când echipa de proiect decide dacă dovezile generate anterior pot înlocui sau reduce amploarea testării planificate pentru unitatea specifică care urmează să fie livrată; abordarea de revizuire descrisă în [Ce documente de validare trebuie să furnizeze un furnizor de echipamente de izolare înainte de testele FAT și SAT?] abordează aceeași limită a probelor din perspectiva informațiilor furnizate de furnizor.
Verificări ale proiectelor de referință privind riscurile comparabile, limitele și domeniul de aplicare al furnizorului
Un proiect de referință reprezintă o dovadă a experienței, nu o dovadă a performanței pentru achiziția actuală, iar diferența dintre aceste două aspecte depinde de cât de mult seamănă proiectul menționat cu cel planificat. Comparabilitatea riscurilor reprezintă primul filtru: experiența unui furnizor cu o anumită clasă de risc nu se transferă în mod direct la o altă clasă de risc, deoarece presiunile de proiectare și de testare diferă în funcție de ceea ce protejează echipamentul și de ceea ce este protejat. În cazul în care obiectivul principal al proiectului menționat diferă de obiectivul principal al celui actual, referința se referă mai degrabă la experiența generală de livrare decât la adecvarea pentru obiectivul specific de protecție în cauză.
Comparabilitatea limitelor echipamentului determină dacă referința descrie același domeniu de responsabilitate fizică și funcțională propus în prezent. Un proiect de referință în care furnizorul a livrat o componentă de echipament delimitată în cadrul unui sistem mai amplu construit de alții descrie un rol mai restrâns al furnizorului decât unul în care același furnizor a deținut responsabilitatea pentru interfețe, integrare sau acceptare într-un cadru mai larg. Dacă propunerea actuală atribuie furnizorului un cadru mai larg sau mai restrâns decât referința citată, referința nu confirmă capacitatea furnizorului de a-și îndeplini sarcinile în cadrul propus în prezent.
Domeniul de aplicare al testării și contextul operațional impun condiții suplimentare. Un proiect de referință testat în condiții similare cu mediul operațional planificat are o relevanță mai mare decât unul testat în condiții diferite, iar o referință în care responsabilitatea contractuală a furnizorului corespundea cu ceea ce se propune în prezent are o relevanță mai mare decât una în care responsabilitatea era împărțită diferit între mai multe părți. În cazul în care o echipă de proiect nu poate determina domeniul de aplicare al testării, contextul operațional sau responsabilitatea furnizorului pe baza informațiilor furnizate, referința servește mai degrabă ca o declarație de experiență decât ca o dovadă comparabilă.
| Punct de comparație | Întrebare de pus |
|---|---|
| Pericol | Referința respectivă implică un risc comparabil cu cel al achiziției planificate? |
| Limita echipamentului | Limita echipamentului de referință este comparabilă cu cea a achiziției planificate? |
| Domeniul de aplicare al testului | Proiectul menționat include un domeniu de testare comparabil? |
| Contextul operațional | Contextul de funcționare corespunde cu utilizarea prevăzută? |
| Responsabilitatea furnizorului | Răspunderea furnizorului este comparabilă cu cea propusă? |
| Detalii privind probele | Referința oferă suficiente detalii, dincolo de logo-uri sau numărul de proiecte, pentru a evalua compatibilitatea? |
Logo-urile și numărul de proiecte reflectă amploarea, nu gradul de adecvare. O listă a clienților anteriori sau numărul de instalări finalizate nu indică echipei de evaluare dacă vreunul dintre aceste proiecte a prezentat o structură similară din punct de vedere al riscurilor, limitelor și responsabilităților cu cea a proiectului planificat, iar solicitarea acestor detalii pentru un număr mai mic de referințe cu adevărat comparabile oferă dovezi mai utile decât solicitarea unei liste mai lungi.
Măsuri de clarificare în cazul probelor lipsă, neconcordante sau care nu pot fi verificate
Odată ce un certificat, un raport de testare sau un proiect de referință nu îndeplinește una dintre cerințele de mai sus, echipa de proiect trebuie să decidă ce măsuri să ia în legătură cu această neconformitate, mai degrabă decât să se întrebe dacă aceasta există sau nu. Măsurile disponibile se încadrează, în general, în trei categorii: solicitarea retransmiterea dovezilor corectate sau complete, solicitarea ca un test sau o inspecție să fie asistată de un martor independent sau solicitarea repetării testării în condiții pe care echipa de proiect le poate verifica direct.
Măsura adecvată depinde de tipul de neconcordanță constatată. O neconcordanță privind denumirea entității dintr-un certificat poate fi remediată prin depunerea unei noi cereri, în cadrul căreia furnizorul poate prezenta certificatul echivalent emis pe numele entității corecte sau poate clarifica legătura dintre entitatea menționată și cea care depune oferta. Un raport de testare din care lipsesc înregistrările de calibrare sau observațiile brute poate fi, de asemenea, remediat prin depunerea unei noi versiuni, dacă înregistrările de bază există și pur și simplu nu au fost incluse. În cazul în care neconcordanța se referă la faptul dacă o configurație testată corespunde cu configurația oferită, depunerea unei noi versiuni nu rezolvă problema dacă configurațiile testate și oferite diferă în mod real; în acest caz, echipa de proiect are nevoie fie de un nou raport pentru configurația corectă, fie de o decizie de a include testări specifice configurației în planul de verificare al proiectului.
Prezența unui martor devine relevantă atunci când problema nu este existența unui rezultat, ci încrederea în modul în care acesta a fost obținut. O echipă de proiect care nu este sigură dacă practicile interne de testare ale unui furnizor corespund cerințelor proiectului poate solicita ca un test repetat sau viitor să includă un martor independent, în loc să se repete întregul domeniu de testare. Testarea repetată devine necesară atunci când nu există un rezultat anterior pentru configurația corectă, când abaterile au rămas nerezolvate sau când comparabilitatea în ceea ce privește pericolul sau limitele dovezilor anterioare nu poate fi stabilită suficient de bine pentru a înlocui testarea directă.
Fiecare neconcordanță nerezolvată identificată în timpul revizuirii dovezilor trebuie înregistrată ca o solicitare de clarificare, precizând în mod specific care verificare a eșuat, ce dovezi ar rezolva problema și dacă respectivele dovezi trebuie retrimise, atestate sau repetate înainte ca proiectul să se poată baza pe ele. Nedorința de a documenta o neconcordanță, chiar și atunci când echipa de proiect intenționează să o semnaleze verbal, elimină trasabilitatea de care depind etapele ulterioare ale proiectului atunci când se confirmă că elementele deschise au fost închise înainte de acceptare. Abordarea comparativă descrisă în [Cum se pot compara furnizorii de echipamente de izolare de înaltă siguranță în funcție de calitatea răspunsurilor URS și de amploarea dovezilor] consideră această disciplină de clarificare ca făcând parte din modul în care sunt evaluate răspunsurile furnizorilor în timpul procesului de selecție, nu doar în momentul acceptării finale.
Limite de acceptare înainte ca dovezile furnizorului să fie înregistrate în dosarul proiectului
A decide când dovezile sunt suficient de solide pentru a fi incluse în dosarul proiectului reprezintă o apreciere distinctă de cea privind existența propriu-zisă a dovezilor. Un certificat, un raport de testare sau un proiect de referință poate fi autentic, actual și descris cu acuratețe, dar totuși să nu îndeplinească cerințele dosarului de proiect dacă domeniul său de aplicare nu corespunde entității, configurației sau condițiilor de risc și limită ale achiziției efectuate. Limita de acceptare nu este un prag unic aplicat în mod uniform; aceasta depinde de verificarea pe care documentul urma să o îndeplinească și de consecințele care decurg din bazarea pe acesta.
În cazul în care se utilizează un certificat pentru a demonstra că un furnizor își desfășoară activitatea în conformitate cu un sistem recunoscut de calitate sau de management, un domeniu de aplicare la nivel de companie poate fi suficient pentru acest scop limitat, chiar dacă același certificat nu ar fi suficient pentru a demonstra că un sistem specific propus îndeplinește o cerință de performanță. În cazul în care un raport de testare este utilizat pentru a reduce sau a înlocui testările planificate în cadrul etapelor de verificare proprii ale proiectului, pragul de acceptare este mai ridicat, deoarece dosarul proiectului se bazează pe acel raport ca și cum ar fi fost generat sub supravegherea proprie a proiectului; o neconcordanță de configurație, o abatere nedocumentată sau o aprobare lipsă împiedică, fiecare în mod independent, raportul să aibă acea pondere până la rezolvarea problemelor respective. În cazul în care un proiect de referință este utilizat pentru a susține o decizie de selecție a furnizorului, mai degrabă decât pentru a înlocui testarea directă, pragul de acceptare poate tolera mai multe informații parțiale, cu condiția ca lacunele să fie recunoscute, mai degrabă decât tratate ca fiind rezolvate.
Condiția care modifică aceste limite este ceea ce reprezintă dovezile. Dovezile utilizate pentru a descrie capacitatea generală a furnizorului pot avea un domeniu de aplicare mai larg decât dovezile folosite pentru a îndeplini o cerință specifică de verificare. Atunci când informațiile despre proiect sunt transmise pentru o revizuire a configurației QUALIA sau a ofertei, se aplică aceeași distincție: certificatele generale și materialele de referință susțin o evaluare inițială a compatibilității, în timp ce dovezile de testare specifice configurației devin relevante odată ce domeniul de aplicare al proiectului revizuit se restrânge la un sistem specific propus. O echipă de proiect care menține această distincție în mod explicit evită atât dependența excesivă de documentele generale, cât și utilizarea insuficientă a acestora în scopul pentru care pot servi în mod legitim. Transformarea obiectivului de protecție al unui proiect în criterii de acceptare pe baza cărora furnizorul poate fi verificat, așa cum este descris în [Cum se transformă cerințele proiectelor BSL și OEB în criterii de acceptare care pot fi verificate de furnizori], oferă echipei de proiect un standard bine definit pe baza căruia fiecare element de probă prezentat poate fi evaluat, în loc să fie judecat de la caz la caz.
Întrebări frecvente
Q: Ce ar trebui să pregătim înainte de a verifica documentele furnizorilor?
A: Elaborați o listă de trasabilitate care să coreleze configurația propusă, pericolul, limitele echipamentului, domeniul de aplicare al testării și criteriile de acceptare cu documentul așteptat pentru fiecare punct. Astfel, dovezile lipsă sau neconcordante devin vizibile înainte de a fi considerate dovezi ale proiectului.
Q: Poate un certificat emis la nivel de companie să certifice sistemul de izolare propus?
A: Nu. Asigurați-vă că entitatea juridică, organismul emitent, numărul certificatului, domeniul de aplicare, produsul sau amplasamentul menționat și data de valabilitate corespund cu cele din ofertă; orice neconcordanță trebuie tratată ca o solicitare de clarificare a ofertei până la rezolvarea acesteia.
Q: Cum ar trebui să tratăm un raport de testare referitor la o configurație similară, dar nu identică cu cea din ofertă?
A: Nu presupuneți că rezultatul acestuia se aplică și configurației propuse. Consemnați diferențele, confirmați metoda de testare, instrumentele și calibrarea, criteriile de acceptare, observațiile brute, abaterile și aprobarea, apoi precizați dacă, înainte de acceptare, este necesară retransmiterea dovezilor, prezența unui martor sau repetarea testării.
Q: Ce se întâmplă dacă un client de referință nu poate permite divulgarea integrală a detaliilor proiectului?
A: Considerați referința ca fiind o dovadă incompletă, mai degrabă decât o dovadă a compatibilității. Solicitați detalii care pot fi comunicate cu privire la pericol, limitele echipamentului, domeniul de aplicare al testului, contextul de funcționare și responsabilitatea furnizorului și consemnați orice punct de comparație care rămâne imposibil de verificat.
Q: Este necesar ca toate lacunele probatorii să fie completate în aceeași etapă?
A: Nu. Separați discrepanțele care împiedică compararea echitabilă a ofertelor de probele care pot fi prezentate din nou, atestate sau repetate înainte de acceptarea proiectului și consemnați măsurile necesare și limitele de acceptare pentru fiecare discrepanță nerezolvată.





















