Dostawa oprogramowania dla Urzędu Miejskiego w Olsztynku w ramach projektu pn. „Cyberbezpieczny samorząd”

1) Przedmiot zamówienia stanowi realizacja dostawy w ramach część I postępowania pn. Dostawa i wdrożenie oprogramowania do zarządzania infrastrukturą IT Urzędu Miejskiego w Olsztynku w ramach projektu pn. „Cyberbezpieczny samorząd”.
2) Szczegółowy opis przedmiotu zamówienia (dalej: OPZ) zawierający minimalne wymagania, które musi spełniać oferowany przedmiot zamówienia stanowi załącznik nr 1A do SWZ.
3) Wykonawcy planujący złożyć ofertę w przedmiotowym postępowaniu zobowiązani są do śledzenia zmian i modyfikacji SWZ w szczególności w zakresie zmian OPZ i załączników.

Dostawa i konfiguracja oprogramowania do bezpiecznego logowania w systemie dziedzinowym w Urzędzie Miejskim w Olsztynku w ramach projektu pn. „Cyberbezpieczny samorząd”. 2) Szczegółowy opis przedmiotu zamówienia (dalej: OPZ) zawierający minimalne wymagania, które musi spełniać oferowany przedmiot zamówienia stanowi załącznik nr 1B do SWZ. 3) Wykonawcy planujący złożyć ofertę w przedmiotowym postępowaniu zobowiązani są do śledzenia zmian i modyfikacji SWZ w szczególności w zakresie zmian OPZ i załączników.

W postępowaniu o udzielenie zamówienia publicznego pn. „Dostawa oprogramowania dla Urzędu Miejskiego w Olsztynku w ramach projektu pn. „Cyberbezpieczny samorząd” dla część I: Dostawa i wdrożenie oprogramowania do zarządzania infrastrukturą IT Urzędu Miejskiego w Olsztynku w ramach projektu pn. „Cyberbezpieczny samorząd” w wymaganym terminie, tj. do dnia 23 lutego 2026 r. do godz. 10:00 wpłynęły 3 oferty:
Oferta 1 cena: 25 184,34 zł
Oferta 2 cena: 34 845,90 zł
Oferta 3 cena: 27 694,68 zł
Kwota jaką Zamawiający zamierzał przeznaczyć na sfinansowanie części I zamówienia, udostępniona na stronie internetowej prowadzonego postępowania bezpośrednio przed otwarciem ofert wynosiła: 20 339,28 zł.Zamawiający podjął czynności badania i oceny ofert złożonych w postępowaniu, ale wobec zachodzących przesłanek unieważnienia postępowania, zamawiający odstąpił od podejmowania dalszych związanych z tym czynności.
Przede wszystkim Zamawiający dokonał analizy wysokości środków zabezpieczonych w budżecie Gminy Olsztynek przewidzianych na realizację przedmiotowego zadania. Stwierdzono, iż nie dysponuje obecnie wkładem finansowym pozwalającym na zwiększenie kwoty na realizację przedmiotowego zadania do wartości wskazanej w ofercie z najniższą ceną.
W związku z powyższym zdecydowano o unieważnieniu przedmiotowego postępowania stosownie do art. 255 pkt 3 ustawy Pzp, który stanowi, iż Zamawiający unieważnia postępowanie o udzielenie zamówienia, jeżeli cena lub koszt najkorzystniejszej oferty lub oferta z najniższą ceną przewyższa kwotę, którą Zamawiający zamierza przeznaczyć na sfinansowanie zamówienia, chyba że Zamawiający może zwiększyć tę kwotę do ceny lub kosztu najkorzystniejszej oferty.

Dla część II postępowania wpłynęły 2 oferty. W trakcie badania i oceny ofert oraz ponownej weryfikacji OPZ sprawdzono możliwości realizacji funkcjonalności integracji mechanizmu bezpiecznego logowania z wykorzystywanym oprogramowaniem dziedzinowym. W wyniku tego badania stwierdzono, iż realizacja przedmiotu zamówienia możliwa jest tylko przez jednego wykonawcę lub poprzez zaproponowanie tylko jednego konkretnego oprogramowania, gdyż oprogramowanie dziedzinowe objęte jest prawami wyłącznymi wynikającymi z odrębnych przepisów. W związku z zaproponowaniem przez jednego z wykonawców rozwiązania typu Open Source wykorzystującego wbudowane mechanizmy konfiguracyjne systemów (interfejsów API/standardów wymiany tokenów) zwrócono się do producenta oprogramowania dziedzinowego o wskazanie: czy oprogramowanie dziedzinowe posiada wbudowane mechanizmy konfiguracyjne systemów w celu integracji mechanizmu logowania oparciu o technologię SSO oraz czy licencja na oprogramowanie dziedzinowe przewiduje wykorzystanie tych mechanizmów w celu przeprowadzenia integracji z oprogramowaniem typu Open Source. W odpowiedzi producent oprogramowania poinformował, iż system ten nie udostępnia publicznych interfejsów integracyjnych w zakresie procesu uwierzytelniania i autoryzacji użytkownika. Mechanizmy logowania, autoryzacji oraz zarządzania sesją użytkownika stanowią element wewnętrznej architektury systemu. W związku z powyższym wykorzystanie rozwiązań klasy IAM lub innych mechanizmów opartych na standardach wymiany tokenów nie jest możliwe bez dostosowania mechanizmów uwierzytelniania funkcjonujących w samym systemie RESPONS. Zastosowanie zewnętrznych systemów zarządzania tożsamością, bram uwierzytelniających lub mechanizmów przekazywania tokenów może stanowić element architektury rozwiązania, jednak ich wykorzystanie wymaga uprzedniego dostosowania mechanizmów uwierzytelniania funkcjonujących w aplikacji. Zgodnie z warunkami licencji na oprogramowanie RESPONS licencjobiorca korzysta z systemu wyłącznie na potrzeby własne i nie jest uprawniony w szczególności do dekompilacji, modyfikacji ani ingerencji w oprogramowanie lub jego mechanizmy funkcjonalne. W konsekwencji wszelkie prace integracyjne wymagające zmian w mechanizmach uwierzytelniania systemu powinny być realizowane w sposób uwzględniający postanowienia licencyjne oraz prawa autorskie do oprogramowania. Zamawiający stwierdził,że realizacja przedmiotu zamówienia uzależniona jest od ingerencji w mechanizmy funkcjonalne oprogramowania objętego prawami wyłącznymi producenta. Wykonanie zamówienia możliwe byłoby wyłącznie przez jeden podmiot posiadający prawa do modyfikacji oprogramowania lub przez podmiot działający za jego zgodą. Brak dostępu do kodów źródłowych lub autorskich praw majątkowych do oprogramowania powoduje uzależnienie zamawiającego od podmiotu posiadającego te prawa i może uniemożliwiać wykonanie prac rozwojowych lub integracyjnych przez innych wykonawców. Powyższa okoliczność stanowi wadę postępowania polegającą na wadliwym określeniu możliwości realizacji przedmiotu zamówienia, która ujawniła się dopiero na etapie badania ofert oraz weryfikacji technicznych możliwości integracji systemu. Wada ta ma charakter niemożliwy do usunięcia, ponieważ wymagałoby zasadniczej zmiany OPZ oraz założeń funkcjonalnych zamówienia, co w praktyce oznaczałoby konieczność ponownego przeprowadzenia postępowania. W związku z powyższym Zamawiający stwierdził, że realizacja zamówienia przez podmiot nie posiadający uprawnień do ingerencji z oprogramowaniem dziedzinowym nie jest możliwa, a Zamawiający nie zawarł w OPZ informacji o tych okolicznościach które, miałyby istotne znaczenia wykonawców, co uzasadnia unieważnienie postępowania.