| Wymagania formalne (obligatoryjne)1 | |||
| Lp. | Nazwa wymagania | Dlaczego należy to weryfikować | Praktyczny sposób weryfikacji |
| O.1 | Możliwość elektronicznej obsługi procesu udzielenia zamówienia we wszystkich dostępnych trybach udzielania zamówień, w tym obsługa procesu unieważniania czynności wyboru i ponownej oceny. |
To najważniejszy element weryfikacji każdej platformy zakupowej – jeżeli wybierzemy system, który nie spełnia wszystkich trybów to w przypadku konieczności skorzystania z takich trybów w przyszłości możemy być „zablokowani” z przeprowadzeniem postępowania do momentu „zbudowania” przez dostawcę odpowiedniej funkcjonalności i możemy narazić się na dodatkową płatność. |
Link do strony internetowej wykonawcy, na której znajdują POLECAMY Udostępnienie przez dostawcę filmów instruktażowych na przeprowadzenie przetargów w następujących trybach:
|
| O.2 | Funkcjonalność wsparcia elektronicznego przesyłania oświadczeń, w tym JEDZ od dnia 18 kwietnia 2018 r. |
W takiej sytuacji albo decydujemy się na stosowanie instrukcji UZP, która według niektórych ekspertów niesie wiele ryzyk (np. brak pewności, że wysłany pocztą elektroniczną JEDZ dotrze na czas), albo musimy w zasadzie już używać tej funkcjonalności platform zakupowych. Dla zamawiających wykonujących dużo postepowań jest to na dziś kluczowa sprawa. |
Link do strony wykonawcy, na której znajdują się zasady świadczenia umowy wraz z odnośnikiem do punktu, w którym wykonawca opisuje sposób przekazywania JEDZ drogą elektroniczną w okresie 18 kwietnia 2018 r. do 18 października 2019 r. Udostępnienie przez wykonawcę filmów instruktażowych z przedstawionym procesem obsługi elektronicznego przesłania JEDZ. |
| O.3 | Dostosowywanie oprogramowania do zmian prawnych. |
Bez takiej gwarancji zamawiający naraża się na jedno z następujących negatywnych konsekwencji: albo konieczność dopłaty za zmiany w systemie w związku ze zmianami prawnymi, albo zmiany platformy, albo braku obsługi wymagań legislacyjnych. Należy pamiętać, że jedną z takich „szybkich i koniecznych zmian” będzie integracja z systemem budowanym przez Ministra Cyfryzacji – e-Zamówienia. |
Link do strony internetowej wykonawcy, na której znajdują się zasady świadczenia umowy wraz z odnośnikiem do punktu, w którym wykonawca deklaruje dostosowywanie oprogramowania do zmian prawnych w cenie usługi, w tym do systemu budowanego przez Ministra Cyfryzacji – e-Zamówienia. Zapisy umowy gwarantujące takie dostosowywanie do zmian prawnych. |
| Wymagania funkcjonalne (fakultatywne) | |||
| F.1 | Posiadanie ról w systemie, które definiują możliwe do przeprowadzenia przez użytkownika z odpowiednią rolą akcje:
|
Jeżeli platforma zakupowa posiada role zdefiniowane w ustawie Pzp (np. kierownika zamawiającego, przewodniczącego komisji, sekretarza komisji, członka komisji, biegłego), to zamawiający ma pewność, że tylko wybrane osoby mogą podejmować niektóre czynności w systemie. Szczególnie jest to ważne dla zmiany terminów składania ofert i wniosków, aby osoba nieuprawniona nie wykonała w systemie akcji, która zostanie upubliczniona. |
Dla zweryfikowania należy zażądać opisu ról zastosowanych w systemie. Praktycznie można też wykorzystać udostępnione filmy/materiały e-learningowe. |
| F.2 | System ma zdefiniowany kontekstowy katalog pism generowanych w systemie, które mogą zostać użyte w trakcie postępowania przez zamawiającego, poddane edycji i załączone do postępowania – jako korespondencja do wszystkich wykonawców lub jako korespondencja do pojedynczych wykonawców. |
Platforma zakupowa poprzez „podpowiadanie” pisma w kontekście danej czynności zamawiającego może znacznie ułatwić działanie. Oczywiście pisma powinny mieć możliwość edycji – ale zawsze podpowiedź systemu będzie upraszczała pracę zamawiającego. |
Dla zweryfikowania należy zażądać opisu takiej funkcjonalności w systemie. Praktycznie można też wykorzystać udostępnione filmy/materiały e-learningowe. |
| F.3 | Platforma zakupowa tworzy na bieżąco protokół postępowania na obowiązujących wzorach, zawierający niezbędne dla każdego trybu i wartości postępowania informacje. |
Platforma zakupowa może ułatwić prowadzenie postępowania poprzez pomoc jej użytkownikom w opracowaniu niezbędnej dokumentacji, z której protokół postępowania jest najistotniejszy. |
Dla zweryfikowania należy zażądać opisu takiej funkcjonalności w systemie. Praktycznie można też wykorzystać udostępnione filmy/materiały e-learningowe. |
| F.4 | Platforma zakupowa automatycznie tworzy chronologiczny katalog czynności wykonywanych w postępowaniu, dostępny jako raport z danego postępowania. | Dzięki takiej funkcjonalności zamawiający będzie mógł kontrolować prawidłowy przebieg procesu postępowania o zamówienie publiczne – np. kontrola powinna mieć dostęp do odczytu pełnej dokumentacji danego postępowania oraz umieć przeglądać właśnie taki chronologiczny dziennik czynności podejmowanych przez pracowników zamawiającego i wykonawców dla skontrolowania procesu. |
Weryfikacją może być opis funkcjonalności. Praktycznie można też |
| F.5 | Zamawiający wymaga certyfikatu TED e-Sender powalający na publikacje zamówień w TED z systemu. | Dzięki temu zamawiający uniknie podwójnej pracy – obecnie musi wpisać dane do Biuletynu Zamówień Publicznych i/lub Europejskiego Biuletynu TED, a później opisać w systemie platformy zakupowej. TED umożliwia przyjęcie pliku w formacie .xml i automatyczne publikowanie ogłoszeń, dlatego warto wymagać certyfikatu e-Sender. |
Dostawca powinien przedstawić certyfikat na stronie TED. |
| Wymagania niefunkcjonalne – spełnianie wymagań innych ustaw niż Pzp | |||
| L.1 | Obsługa części jawnej i niejawnej (zastrzeżonej jako tajemnica przedsiębiorstwa) w komunikacji z wykonawcami. | Taka funkcjonalność zapewni zamawiającym spełnianie wymogów ustawy o zwalczaniu nieuczciwej konkurencji poprzez zapewnienie poszanowania tajemnicy przedsiębiorstwa, m.in. przy udostępnianiu ofert innym wykonawcom. |
Należy oczekiwać od dostawcy platformy zakupowej krótkiego opisu funkcjonalności przesyłania plików z tajemnicą przedsiębiorstwa i udostępniania treści ofert z poszanowaniem tej tajemnicy. Zamawiający powinien oczekiwać zrzutów ekranu z systemu potwierdzającego taką funkcjonalność. |
| L.2 | System uwzględnia standard WCAG 2.0. dla osób słabo widzących i niedowidzących WCAG 2.0. | Zgodnie z rozporządzeniem w sprawie krajowych ram interoperacyjności2 publiczne systemy informatyczne powinny obsługiwać standard WCAG 2.0. |
Należy oczekiwać od dostawcy platformy zakupowej krótkiego opisu funkcjonalności dostosowania systemu do standardu WCAG 2.0 Zamawiający powinien oczekiwać zrzutów ekranu z systemu potwierdzającego taką funkcjonalność. |
| L.3 | Interfejsy graficzne platformy zakupowej muszą uwzględniać wymagania stawiane wersjom przeznaczonym dla telefonów komórkowych i tabletów zgodnie z zasadami RWD (ang. Responsive Web Design). |
Zgodnie z rozporządzeniem w sprawie krajowych ram interoperacyjności3 publiczne systemy informatyczne powinny obsługiwać standard RWD. |
Należy oczekiwać od dostawcy platformy zakupowej krótkiego opisu funkcjonalności dostosowania systemu do standardu RWD. Zamawiający powinien oczekiwać zrzutów ekranu z systemu potwierdzającego taką funkcjonalność. |
| L.4 | Jak platforma zakupowa obsługuje dane osobowe i czy spełnia wymagania rozporządzenia RODO. | Tego wymogu nie trzeba nikomu dzisiaj uzmysławiać – powstaje szereg artykułów o wysokich karach dla podmiotów niestosujących znowelizowanych wymogów ochrony danych osobowych. Należy pamiętać, że w platformie zakupowej przetwarzane będą dane osobowe w najtrudniejszej postaci – dostępne w załączonych przez wykonawców dokumentach. Każdorazowo otwarcie takiego dokumentu stanowi „przetworzenie danych osobowych” dostępnych na dokumencie – jeśli platforma zakupowa nie będzie wspierała zamawiającego w przygotowywaniu odpowiednich raportów, to będzie on musiał prowadzić odrębną dokumentację, co w przypadku zamawiających prowadzących wiele postępowań będzie wielkim wyzwaniem. |
Należy oczekiwać od dostawcy opisu funkcjonalności zapewnienia zgodności platformy zakupowej z wymogami rozporządzenia RODO. Zamawiający powinien oczekiwać zrzutów ekranu z systemu potwierdzającego taką funkcjonalność. |
| Inne wymagania niefunkcjonalne | |||
| N.1 | Obsługa różnych standardów podpisów kwalifikowanych w szczególności PaDES, XaDES – w tym wbudowanej funkcjonalności wyświetlania szczegółów podpisu. |
Zamawiający powinien zadbać o to, aby wykonawcy mogli wykorzystać różne standardy dostępnych podpisów na rynku. Trzeba pamiętać, że ograniczenie np. do formatu PaDES umożliwi przesyłanie tylko podpisanych elektronicznie plików PDF, a czasem może być konieczne przesłanie innych formatów plików i wtedy standard XaDES jest niezbędny. | Weryfikacją może być opis funkcjonalności. |
| N.2 | System powinien korzystać z zaufanego serwera czasu (usługa świadczona przez certyfikowanych zewnętrznych dostawców), który w sposób obiektywny określi moment złożenia dokumentu w systemie – niezbędne dla oceny, czy dokument został złożony w terminie. Po upływie zdefiniowanego terminu system uniemożliwia złożenie wniosków/ofert. | System musi w sposób jednoznaczny i niebudzący wątpliwości określić moment wpłynięcia oferty/wniosku/ /oświadczenia (w tym JEDZ), i to nie poprzez powołanie się na czas serwera zamawiającego czy dostawcy, tylko na obiektywne źródło czasu. |
Należy oczekiwać od dostawcy platformy zakupowej opisu, w jaki sposób jego rozwiązanie zapewnia „pewne źródło czasu”. |
| N.3 | Zapewnienie szyfrowania przez co najmniej dwa klucze szyfrujące o odpowiedniej sile przechowywane na nośnikach zewnętrznych uniemożliwiających „wyciągnięcie klucza deszyfrującego” posiadanego przez dwóch członków składu oceniającego. Przy czym klucze dwóch dowolnych członków składu oceniającego powinny mieć możliwość odszyfrowania i otwarcia ofert/wniosków/oświadczeń (w tym JEDZ). Certyfikat kwalifikowany może być używany jedynie do weryfikacji podpisu elektronicznego. Szyfrowanie ofert/wniosków/oświadczeń w tym JEDZ musi być zapewnione z użyciem klucza publicznego certyfikatu komercyjnego – zgodnie z wytycznymi o stosowaniu odpowiednich certyfikatów do odpowiednich celów. | Należy pamiętać, że platforma zakupowa jest newralgicznym systemem i najważniejszym elementem tego systemu jest zapewnienie, że nikt (w tym pojedynczy pracownik zamawiającego, administrator systemu czy bazy danych) nie będzie w stanie podejrzeć ofert przed terminem ich otwarcia. Zarzut „wycieku” danych może mieć bardzo negatywne konsekwencje dla zamawiającego wraz z koniecznością unieważnienia postępowania czy sankcji z tytułu naruszenia przepisów o ochronie danych osobowych lub o zwalczaniu nieuczciwej konkurencji. |
Należy oczekiwać od dostawcy platformy zakupowej przekonującego dla ekspertów ds. bezpieczeństwa danych opisu, w jaki sposób jego rozwiązanie daje gwarancję, że nie ma możliwości zapoznania się z treścią ofert/wniosków przed terminem ich otwarcia. |
| N.4 | System powinien mieć wbudowany skaner antywirusowy sprawdzający wszystkie pliki, jakie użytkownicy próbują wgrać do systemu, pod kątem wirusów oraz innego złośliwego oprogramowania. System powinien informować użytkownika, w którym pliku znalazł się wirus. | Pliki przesyłane do systemu będą pobierane przez różnych użytkowników. Zamawiający powinien zapewnić platformę odporną na zagrożenia płynące z internetu nie tylko na poziomie bezpieczeństwa samej platformy, ale także umieszczanych w nim treści. Platforma powinna mieć skaner antywirusowy pozwalający przeskanować wszystkie pliki, jakie umieszczane są w systemie, oraz prezentować użytkownikowi powód nieprzyjęcia przez system określonego załącznika. | Należy oczekiwać od dostawcy platformy zakupowej opisu, w jaki sposób rozwiązanie weryfikuje brak wirusów. Należy poprosić o film instruktażowy lub zrzuty ekranu pokazujące raport „zawirusowanego” pliku, który przesyłał użytkownik. |
| N.5 | Infolinia: podstawową formą wsparcia użytkowników jest infolinia telefoniczna dostępna w godzinach 8–18 w dni robocze. Dodatkowo należy wymagać również możliwości komunikacji z dostawcą rozwiązania za pomocą e-mail. |
Użytkownicy zamawiającego będą mieli i tak duże wyzwanie z elektronizacją – dostawca platformy zakupowej musi zapewnić im pomoc w postaci infolinii telefonicznej jako podstawowego kanału komunikacyjnego. | Zamawiający powinien oczekiwać linku do strony internetowej z zasadami świadczenia usług przez wykonawcę i odniesienia do zapisów gwarantujących dostępność infolinii. |
| N.6 | Dostawca musi zagwarantować dostępność oprogramowania na poziomie co najmniej 99,5%, liczone w cyklach miesięcznych w oknie świadczenia usług zdefiniowanym jako 6–20. |
Nikogo nie trzeba przekonywać, że platforma zakupowa musi działać cały czas” i podpisując umowę, należy zweryfikować, czy dostawca to gwarantuje. Kluczowe jest, aby dokładnie zweryfikować parametr, który określa tzw. dostępność systemu, czyli gwarantowany przez dostawcę procent czasu mierzony w jakimś oknie, kiedy system jest na pewno dostępny. Dla przykładu: jeżeli dostawca gwarantuje 95% dostępności mierzonej w skali roku, w dni robocze, w godzinach 9–17, to nawet cały tydzień braku dostępności systemu w tych godzinach jest w zgodzie z umową (!) | Zamawiający powinien oczekiwać linku do strony internetowej z zasadami świadczenia usług przez wykonawcę i odniesienia do zapisów gwarantujących dostępność systemu (najlepiej ewentualną dostępność mierzyć w skali miesiąca i nie powinna ona być wyższa niż kilkanaście minut). |
| N.7 | Dostawca musi zagwarantować sprawne usuwanie błędów: dla awarii uniemożliwiającej korzystanie z serwisu czas usuwania awarii nie może przekroczyć 4 h roboczych, dla błędów krytycznych blokujących przeprowadzenie pojedynczego postępowania maks. 1 dzień roboczy. | Analogicznie jak dostępność systemu, która oznacza możliwość zalogowania do niego, należy zadbać o szybkie usuwanie błędów. | Zamawiający powinien oczekiwać linku do strony internetowej z zasadami świadczenia usług przez wykonawcę i odniesienia do zapisów gwarantujących czas usuwania błędów o różnych priorytetach. |
| Wymagania formalne (obligatoryjne)4 | ||||
| lp | Dostawca MarketPlanet | Dostawca OpenNexus | Dostawca eB2B | Dostawca SmartPZP |
| O.1 | wzór rubryka 0.1 | wzór rubryka 0.1 | wzór rubryka 0.1 | tak |
| O.2 | wzór rubryka 0.1 | wzór rubryka 0.1 | wzór rubryka 0.1 | tak |
| O.3 | wzór rubryka 0.1 | wzór rubryka 0.1 | wzór rubryka 0.1 | tak |
| Wymagania funkcjonalne (fakultatywne) | ||||
| F.1 | wzór rubryka 0.1 | wzór rubryka 0.1 | wzór rubryka 0.1 | tak |
| F.2 | wzór rubryka 0.1 | wzór rubryka 0.1 | wzór rubryka 0.1 | tak |
| F.3 | wzór rubryka 0.1 | wzór rubryka 0.1 | wzór rubryka 0.1 | tak |
| F.4 | wzór rubryka 0.1 | wzór rubryka 0.1 | wzór rubryka 0.1 | tak |
| F.5 | wzór rubryka 0.1 | wzór rubryka 0.1 | wzór rubryka 0.1 | tak |
| Wymagania niefunkcjonalne – spełnianie wymagań innych ustaw niż Pzp | ||||
| L.1 | wzór rubryka 0.1 | wzór rubryka 0.1 | wzór rubryka 0.1 | tak |
| L.2 | wzór rubryka 0.1 | wzór rubryka 0.1 | wzór rubryka 0.1 | tak |
| L.3 | wzór rubryka 0.1 | wzór rubryka 0.1 | wzór rubryka 0.1 | tak |
| L.4 | wzór rubryka 0.1 | wzór rubryka 0.1 | wzór rubryka 0.1 | tak |
| Inne wymagania niefunkcjonalne | ||||
| N.1 | wzór rubryka 0.1 | wzór rubryka 0.1 | wzór rubryka 0.1 | tak |
| N.2 | wzór rubryka 0.1 | wzór rubryka 0.1 | wzór rubryka 0.1 | tak |
| N.3 | wzór rubryka 0.1 | wzór rubryka 0.1 | wzór rubryka 0.1 | tak |
| N.4 | wzór rubryka 0.1 | wzór rubryka 0.1 | wzór rubryka 0.1 | tak |
| N.5 | wzór rubryka 0.1 | wzór rubryka 0.1 | wzór rubryka 0.1 | tak |
| N.6 | wzór rubryka 0.1 | wzór rubryka 0.1 | wzór rubryka 0.1 | tak |
| N.7 | wzór rubryka 0.1 | wzór rubryka 0.1 | wzór rubryka 0.1 | tak |
