Jak zweryfikować certyfikaty, raporty z badań i projekty referencyjne

Oferta dostawcy może zawierać teczkę z certyfikatami, raportami z badań oraz prezentację dotychczasowych projektów, ale żadna z tych rzeczy nie odpowiada na najważniejsze pytanie: czy te dokumenty mają zastosowanie do systemu, którego dotyczy oferta. Ocena dokumentacji nie polega na analizie ilości przedłożonych dokumentów, lecz na sprawdzeniu, czy każdy z nich odnosi się do danego podmiotu prawnego, konkretnej konfiguracji oraz warunków projektu porównywalnych z tymi, które są planowane. Związek ten należy dokładnie zweryfikować, ponieważ dokument może być autentyczny, a mimo to nie mieć zastosowania.

Co można, a czego nie można udowodnić za pomocą poszczególnych rodzajów dowodów

Certyfikaty, raporty z badań i projekty referencyjne odpowiadają na różne pytania, a traktowanie ich jako zamiennych dowodów gotowości powoduje powstanie luk, które ujawniają się w późniejszej fazie projektu. Certyfikat potwierdza, że dana organizacja lub instytucja dokonała oceny określonego podmiotu, produktu lub obiektu w określonych warunkach; nie opisuje on jednak, jak konkretna jednostka sprawdziła się w praktyce, ani nie potwierdza, że certyfikowany zakres obejmuje oferowaną konfigurację. Raport z testów opisuje, co się wydarzyło podczas testowania konkretnej konfiguracji zgodnie z określoną metodą; nie potwierdza on jednak, że testowana jednostka odpowiada temu, co otrzyma projekt, chyba że zgodność konfiguracji zostanie potwierdzona. Projekt referencyjny opisuje, co dostawca dostarczył gdzie indziej; nie potwierdza on jednak, że ta sama struktura zagrożeń, granic i odpowiedzialności ma zastosowanie do rozpatrywanego projektu.

Jeżeli nabywca potrzebuje dowodu ogólnej zdolności do realizacji zamówienia, certyfikat może służyć temu celowi w ramach określonego w nim zakresu. Jeżeli nabywca potrzebuje dowodu wydajności w odniesieniu do oferowanej konfiguracji, raport z testów dotyczący tej konfiguracji spełnia ten cel w sposób bardziej bezpośredni. Jeżeli nabywca musi ocenić, czy doświadczenie dostawcy ma zastosowanie w nowym projekcie, projekt referencyjny dostarcza dowodów bardziej przydatnych przy podejmowaniu rzeczywistej decyzji o zakupie niż certyfikat, pod warunkiem że kontekst operacyjny i zakres projektu są opisane wystarczająco szczegółowo, by umożliwić porównanie.

Czynnikiem, który wpływa na tę ocenę, jest to, jak wąsko lub szeroko sformułowano zakres dokumentu. Certyfikat obejmujący całą firmę zazwyczaj nie obejmuje konkretnej linii produktów, a raport z badań dotyczący jednej konfiguracji nie obejmuje wariantu, chyba że w raporcie lub u dostawcy potwierdzono, że wariant ten został uwzględniony. Osoby sprawdzające, które akceptują dokument tylko dlatego, że istnieje, nie zapoznając się z jego rzeczywistą treścią, przenoszą tę lukę do projektu. EudraLex Tom 4 Załącznik 15 popiera praktykę polegającą na weryfikacji dokumentacji dostawcy pod kątem z góry określonych kryteriów akceptacji oraz odnotowywaniu odstępstw, zamiast uznawania oświadczeń dostawcy za kompletne w momencie ich przedłożenia; ta logika weryfikacji odnosi się do sposobu, w jaki zespół projektowy powinien traktować każdy z trzech rodzajów dowodów, zanim się na nich oprze.

Sprawdzanie certyfikatów pod kątem wystawcy, podmiotu, zakresu i ważności

Certyfikat to oświadczenie wydane przez określony organ dotyczące konkretnego podmiotu, produktu lub zakładu, ważne pod określonymi warunkami, przy czym każdy z tych elementów może odbiegać od założeń nabywcy, nie co oznacza, że sam certyfikat jest fałszywy. Najczęstsza rozbieżność występująca podczas weryfikacji handlowej dotyczy podmiotu posiadającego certyfikat a podmiotu przedstawiającego go w ofercie: certyfikat wydany na spółkę dominującą, zakład produkcyjny lub inny podmiot prawny w ramach tej samej struktury korporacyjnej nie obejmuje automatycznie podmiotu, który będzie ponosił odpowiedzialność umowną za projekt.

Ta sama logika dotyczy zakresu certyfikatu. Certyfikat może być dokładny i aktualny, obejmując klasę urządzeń, system zarządzania lub obiekt, bez konieczności uwzględniania konkretnej konfiguracji systemu zaproponowanej dla danego projektu. W przypadku gdy zakres certyfikatu określa rodzinę produktów w sposób ogólny, zadaniem zamawiającego jest potwierdzenie, że proponowany system mieści się w tej rodzinie zgodnie z przeprowadzonymi testami lub ocenami, a nie zakładanie przynależności do tej rodziny wyłącznie na podstawie nazwy produktu. Podobna zasada dotyczy terminów ważności: certyfikat aktualny w momencie zamknięcia przetargu może stracić ważność przed dostawą lub testami odbiorczymi, a w przypadku projektu obejmującego długi okres dostawy należy monitorować, czy certyfikat pozostaje ważny na wszystkich etapach, na których się na niego powołuje.

Jeżeli jakikolwiek z następujących elementów: wystawca, podmiot, zakres, produkt, lokalizacja lub data ważności nie zgadza się z informacjami podanymi w ofercie, certyfikat nie traci od razu ważności, ale przestaje pełnić funkcję samodzielnego dowodu i staje się kwestią wymagającą wyjaśnienia, zanim będzie mógł stanowić poparcie dla dokumentacji projektu.

Raport z badań obejmuje sprawdzenie konfiguracji, metody, kalibracji, wyników oraz zatwierdzenia

Raport z testów jest przydatny tylko wtedy, gdy pozwala wykazać, że podany wynik pochodzi z określonego testu przeprowadzonego na określonej konfiguracji przy użyciu przyrządów, których pomiary można prześledzić. Stwierdzenie o pozytywnym wyniku bez tych elementów uzupełniających informuje czytelnika jedynie o tym, że coś przeszło test, nie wskazując jednak, co zostało przetestowane ani w jaki sposób uzyskano ten wynik. Zgodność konfiguracji jest pierwszym warunkiem, który należy potwierdzić: w przypadku gdy dostawca przedkłada raport dotyczący poprzedniego projektu lub wcześniejszej wersji produktu, nabywca musi wiedzieć, czy różnice między tą konfiguracją a oferowaną mają znaczenie dla przytoczonego wyniku, ponieważ raport dotyczący innej konfiguracji nie stanowi podstawy dla wyników w odniesieniu do bieżącej oferty.

Metoda badawcza i oprzyrządowanie wiążą się z pewnymi warunkami. Brak informacji o metodzie oznacza, że czytelnik nie jest w stanie ocenić, czy podejście badawcze odpowiada wymaganiom projektu, a pominięcie protokołów kalibracji oznacza, że podane pomiary nie mają identyfikowalnej podstawy. Kryteria akceptacji pełnią rolę standardu, względem którego ocenia się wynik; raport przedstawiający wynik bez podania kryteriów służących do jego oceny zmusza czytelnika do zaakceptowania wniosków dostawcy zamiast ich niezależnej weryfikacji.

Surowe obserwacje i udokumentowane odchylenia wpływają na wagę, jaką można przypisać wynikowi podsumowującemu. Raport oparty wyłącznie na stwierdzeniu o pozytywnym wyniku podsumowującym, bez uwzględnienia podstawowych obserwacji, nie pozwala czytelnikowi sprawdzić, czy wyniki brzegowe zostały zaokrąglone na korzyść, czy też wystąpiło odchylenie, które zostało usunięte przed zatwierdzeniem. W przypadku gdy odchylenie zostało udokumentowane, ale nie odnotowano sposobu jego usunięcia, odchylenie pozostaje otwarte i wymaga weryfikacji, zanim raport będzie mógł stanowić podstawę do przyjęcia projektu. Zatwierdzenie zamyka łańcuch dowodowy raportu, potwierdzając, kto dokonał przeglądu i zatwierdził podany wynik; raport pozbawiony zatwierdzenia nie zakończył swojego wewnętrznego procesu, niezależnie od tego, co stwierdza się w treści raportu.

Kontrole te mają największe znaczenie na etapie przeglądu poprzedzającym testy akceptacyjne, kiedy to zespół projektowy podejmuje decyzję, czy wcześniej zgromadzone dane mogą zastąpić lub ograniczyć zakres testów zaplanowanych dla konkretnego dostarczanego modułu; podejście do przeglądu opisane w [Jakie dokumenty potwierdzające powinien dostarczyć dostawca urządzeń zabezpieczających przed przeprowadzeniem testów FAT i SAT?] dotyczy tej samej granicy dowodowej z punktu widzenia dokumentów przedkładanych przez dostawców.

Weryfikacja projektów referencyjnych pod kątem porównywalnych zagrożeń, granic i zakresu dostawców

Projekt referencyjny stanowi dowód doświadczenia, a nie dowód wyników w odniesieniu do bieżącego zamówienia, a różnica między tymi dwoma aspektami zależy od tego, na ile przytoczony projekt przypomina ten, który jest planowany. Pierwszym kryterium selekcji jest porównywalność zagrożeń: doświadczenie dostawcy w zakresie jednej klasy zagrożeń nie przekłada się wprost na inną klasę zagrożeń, ponieważ ciśnienia projektowe i testowe różnią się w zależności od tego, przed czym sprzęt chroni i co chroni. W przypadku gdy główny cel przytoczonego projektu różni się od głównego celu bieżącego projektu, projekt referencyjny świadczy raczej o ogólnym doświadczeniu w realizacji zleceń niż o przydatności do osiągnięcia konkretnego, aktualnego celu ochronnego.

Porównywalność granic zakresu wyposażenia pozwala ustalić, czy projekt odniesienia opisuje ten sam zakres odpowiedzialności fizycznej i funkcjonalnej, jaki jest obecnie proponowany. Projekt referencyjny, w ramach którego dostawca dostarczył wyodrębniony element wyposażenia w ramach większego systemu zbudowanego przez inne podmioty, opisuje węższą rolę dostawcy niż ten, w którym ten sam dostawca ponosił odpowiedzialność za interfejsy, integrację lub odbiór w ramach szerszego zakresu. Jeśli obecna propozycja przypisuje dostawcy szerszy lub węższy zakres niż cytowany projekt referencyjny, projekt ten nie potwierdza zdolności dostawcy do działania w ramach obecnie proponowanego zakresu.

Zakres testów i kontekst eksploatacyjny wprowadzają dodatkowe warunki. Projekt referencyjny przetestowany w warunkach zbliżonych do planowanego środowiska eksploatacyjnego ma większe znaczenie niż ten przetestowany w innych warunkach, a projekt referencyjny, w którym zakres odpowiedzialności dostawcy wynikający z umowy odpowiadał obecnej propozycji, ma większe znaczenie niż ten, w którym odpowiedzialność była inaczej podzielona między wiele stron. Jeśli zespół projektowy nie jest w stanie określić zakresu testów, kontekstu eksploatacyjnego ani zakresu odpowiedzialności dostawcy na podstawie dostarczonych informacji, projekt referencyjny pełni raczej funkcję deklaracji doświadczenia niż porównywalnego dowodu.

Logo i liczba projektów odzwierciedlają zasięg, a nie dopasowanie. Lista dotychczasowych klientów lub liczba zrealizowanych instalacji nie daje zespołowi oceniającemu informacji, czy którykolwiek z tych projektów przypominał pod względem zagrożeń, ograniczeń i struktury odpowiedzialności projekt, który jest planowany, a poproszenie o te szczegóły w odniesieniu do mniejszej liczby rzeczywiście porównywalnych referencji dostarcza bardziej przydatnych dowodów niż prośba o dłuższą listę.

Działania wyjaśniające w przypadku brakujących, niezgodnych lub niemożliwych do zweryfikowania dowodów

Gdy certyfikat, raport z badań lub projekt referencyjny nie spełnia jednego z powyższych kryteriów, zespół projektowy staje przed decyzją dotyczącą tego, jak postąpić w przypadku stwierdzenia nieścisłości, a nie tego, czy taka nieścisłość w ogóle występuje. Dostępne działania można zasadniczo podzielić na trzy kategorie: zwrócenie się o ponowne przedłożenie poprawionych lub kompletnych dowodów, wymaganie przeprowadzenia badań lub kontroli w obecności niezależnego świadka lub wymaganie powtórzenia badań w warunkach, które zespół projektowy może bezpośrednio zweryfikować.

To, jakie działanie należy podjąć, zależy od rodzaju wykrytej rozbieżności. Problem z certyfikatem zawierającym niezgodną nazwę podmiotu można rozwiązać poprzez ponowne złożenie dokumentacji, w ramach którego dostawca może przedstawić równoważny certyfikat wystawiony na właściwy podmiot lub wyjaśnić, w jaki sposób wymieniony podmiot jest powiązany z podmiotem składającym ofertę. Raport z badań, w którym brakuje zapisów kalibracyjnych lub surowych danych pomiarowych, można również rozwiązać poprzez ponowne złożenie, o ile istnieją odpowiednie zapisy, a po prostu nie zostały one uwzględnione. W przypadku gdy rozbieżność dotyczy tego, czy przetestowana konfiguracja odpowiada oferowanej konfiguracji, samo ponowne złożenie nie rozwiązuje problemu, jeśli przetestowana i oferowana konfiguracja rzeczywiście się różnią; w takim przypadku zespół projektowy potrzebuje albo nowego raportu dotyczącego prawidłowej konfiguracji, albo decyzji o włączeniu testów specyficznych dla tej konfiguracji do własnego planu weryfikacji projektu.

Obecność świadka ma znaczenie w sytuacjach, gdy nie chodzi o sam wynik, ale o pewność co do sposobu jego uzyskania. Zespół projektowy, który nie ma pewności, czy wewnętrzne praktyki testowe dostawcy są zgodne z wymaganiami projektu, może poprosić o to, aby powtórny lub przyszły test odbył się w obecności niezależnego świadka, zamiast powtarzać cały zakres testów. Powtórne testowanie staje się konieczne, gdy nie ma wcześniejszych wyników dla prawidłowej konfiguracji, gdy odchylenia pozostały nierozwiązane lub gdy nie można wystarczająco dobrze ustalić zagrożenia lub porównywalności granicznej wcześniejszych dowodów, aby zastąpić nimi bezpośrednie testy.

Każda nierozwiązana niezgodność wykryta podczas przeglądu dowodów powinna zostać odnotowana jako prośba o wyjaśnienie, z dokładnym wskazaniem, która kontrola zakończyła się niepowodzeniem, jakie dowody pozwoliłyby ją rozwiązać oraz czy dowody te muszą zostać ponownie przedłożone, poświadczone lub powtórzone, zanim projekt będzie mógł się na nich oprzeć. Brak udokumentowania niezgodności – nawet jeśli zespół projektowy zamierza poruszyć tę kwestię ustnie – uniemożliwia zapewnienie identyfikowalności, od której zależą późniejsze etapy projektu przy potwierdzaniu, że otwarte pozycje zostały zamknięte przed odbiorem. Podejście porównawcze opisane w [Jak porównać dostawców sprzętu o wysokim poziomie zabezpieczeń pod kątem jakości odpowiedzi URS i zakresu dowodów] traktuje tę samą zasadę wyjaśniania jako element oceny odpowiedzi dostawców w trakcie procesu selekcji, a nie tylko podczas ostatecznego odbioru.

Określenie granic akceptacji przed wprowadzeniem dokumentacji dostawcy do dokumentacji projektu

Określenie, kiedy dowód jest wystarczająco dobry, by zostać uwzględniony w dokumentacji projektu, to kwestia oceny odrębna od ustalenia, czy taki dowód w ogóle istnieje. Certyfikat, raport z badań lub projekt referencyjny mogą być autentyczne, aktualne i dokładnie opisane, a mimo to nie spełniać wymagań dokumentacji projektowej, jeśli ich zakres nie odpowiada podmiotowi, konfiguracji lub zagrożeniom i warunkom brzegowym dokonywanego zakupu. Granica akceptacji nie jest pojedynczym progiem stosowanym jednolicie; zależy ona od tego, do spełnienia jakiego wymogu dokument ten miał służyć oraz jakie konsekwencje wynikają z polegania na nim.

W przypadku gdy certyfikat służy do potwierdzenia, że dostawca działa w ramach uznanego systemu jakości lub zarządzania, zakres obejmujący poziom przedsiębiorstwa może być wystarczający dla tego ograniczonego celu, nawet jeśli ten sam certyfikat nie wystarczyłby do potwierdzenia, że konkretny proponowany system spełnia wymagania eksploatacyjne. W przypadku gdy raport z badań jest wykorzystywany w celu ograniczenia lub zastąpienia badań zaplanowanych na etapie weryfikacji w ramach samego projektu, próg akceptacji jest wyższy, ponieważ dokumentacja projektu opiera się na tym raporcie tak, jakby został on sporządzony pod nadzorem samego projektu; niezgodność konfiguracji, nieudokumentowane odstępstwo lub brak zatwierdzenia – każda z tych sytuacji z osobna uniemożliwia nadanie raportowi odpowiedniej wagi do czasu ich rozwiązania. W przypadku gdy projekt referencyjny jest wykorzystywany do wsparcia decyzji o wyborze dostawcy, a nie w celu zastąpienia bezpośrednich testów, granica akceptacji może tolerować większą ilość informacji niekompletnych, pod warunkiem że luki te są uznane, a nie traktowane jako rozwiązane.

Warunkiem, który zmienia te granice, jest to, co reprezentują dowody. Dowody wykorzystywane do opisania ogólnych możliwości dostawcy mogą mieć szerszy zakres niż dowody służące do spełnienia konkretnego wymogu weryfikacyjnego. Gdy informacje o projekcie są przekazywane do przeglądu konfiguracji QUALIA lub oferty, obowiązuje to samo rozróżnienie: ogólne certyfikaty i materiały referencyjne stanowią podstawę wstępnej oceny zgodności, natomiast dowody testowe dotyczące konkretnej konfiguracji stają się istotne dopiero wtedy, gdy zakres przeglądanego projektu zawęża się do konkretnego proponowanego systemu. Zespół projektowy, który jasno określa to rozróżnienie, unika zarówno nadmiernego polegania na dokumentach ogólnych, jak i niedostatecznego wykorzystywania ich do celów, do których mogą one słusznie służyć. Przekształcenie celu ochronnego projektu w kryteria akceptacji, na podstawie których można sprawdzić dostawcę, zgodnie z opisem w [Jak przekształcić wymagania projektowe BSL i OEB w kryteria odbioru, które dostawca może zweryfikować], zapewnia zespołowi projektowemu jasno określony standard, według którego można oceniać każdy przedłożony dowód, zamiast rozpatrywać go doraźnie.

Często zadawane pytania

Q: Co powinniśmy przygotować przed przejrzeniem dokumentacji dostawcy?
A: Należy sporządzić listę śledzenia, która łączy proponowaną konfigurację, zagrożenie, granice sprzętu, zakres testów i kryteria akceptacji z dokumentacją oczekiwaną dla każdego z tych punktów. Dzięki temu brakujące lub niezgodne dowody stają się widoczne, zanim zostaną uznane za potwierdzenie realizacji projektu.

Q: Czy certyfikat wydany na poziomie przedsiębiorstwa może stanowić podstawę do zatwierdzenia proponowanego systemu zabezpieczającego?
A: Nr. Należy sprawdzić zgodność podmiotu prawnego, organu wydającego, numeru certyfikatu, zakresu, wymienionego produktu lub zakładu oraz daty ważności z treścią oferty; wszelkie rozbieżności powinny pozostać przedmiotem wyjaśnienia ofertowego do czasu ich wyjaśnienia.

Q: Jak powinniśmy postąpić w przypadku raportu z testów dotyczących konfiguracji, która jest podobna do tej z oferty, ale nie jest z nią identyczna?
A: Nie należy zakładać, że wynik ten ma zastosowanie do proponowanej konfiguracji. Należy odnotować różnice, potwierdzić metodę badania, przyrządy i ich kalibrację, kryteria akceptacji, surowe dane pomiarowe, odchylenia oraz zatwierdzenie, a następnie określić, czy przed akceptacją konieczne jest ponowne przedłożenie dowodów, ich poświadczenie przez świadków lub powtórzenie badań.

Q: A co, jeśli klient referencyjny nie może wyrazić zgody na pełne ujawnienie szczegółów projektu?
A: Traktuj tę informację jako niekompletny dowód, a nie jako potwierdzenie zgodności. Poproś o szczegóły, które można udostępnić, dotyczące zagrożenia, granic sprzętu, zakresu testów, warunków eksploatacji oraz odpowiedzialności dostawcy, a także odnotuj wszelkie punkty porównawcze, których nie da się zweryfikować.

Q: Czy każdą lukę dowodową należy uzupełnić na tym samym etapie?
A: Nie. Należy oddzielić rozbieżności uniemożliwiające rzetelne porównanie ofert od dowodów, które można ponownie przedłożyć, poświadczyć lub powtórzyć przed przyjęciem projektu, a także odnotować wymagane działania i warunki przyjęcia dla każdej nierozwiązanej rozbieżności.