RozstrzygniętyPrzetarg nieograniczony · PN420041-2026
Dostawa serwerów z oprogramowaniem – Warszawa
Centrum e-Zdrowia3 aktualne · 53 w archiwum·NIP 5251575309·mazowieckie
Rozstrzygnięcie
Kto wygrał, za ile i ilu było chętnych.
WygrałaApex.IT Sp. z o.o.
NIP zwycięzcy5213617218
Kwota oferty14 072 000,00 zł
Złożonych ofert3
Przedmiot zamówienia
AI- Część 1 (dostawa): 3 serwery (z montażem, instalacją i konfiguracją) + 192 licencji VMware Cloud Foundation + 3 licencji Red Hat Enterprise Linux for Virtual Datacenters z Satellite Add-On, na okres 60 miesięcy.
- Część 2 (dostawa opcjonalna): 7 serwerów + 448 licencji VMware Cloud Foundation + 7 licencji Red Hat Enterprise Linux for Virtual Datacenters z Satellite Add-On, na okres 60 miesięcy (realizacja w terminie do 14 miesięcy od umowy).
Trudność: wysoka
Zamówienie obejmuje serwery z bardzo szczegółowymi wymaganiami technicznymi (procesory 64 rdzeni, 1 TB RAM DDR5, 5 dysków NVMe vSAN ESA, karta zarządzająca itp.) oraz złożony stack oprogramowania (wirtualizacja VMware, SDS, Kubernetes, monitoring, automatyzacja), co wymaga głębokiej wiedzy zintegrowanej infrastruktury IT.
Terminy realizacji
termin_realizacji
60 dni od podpisania umowy
60 dni od podpisania umowy
opcja
do 14 miesięcy od podpisania umowy
do 14 miesięcy od podpisania umowy
gwarancja_miesiące
60
60
Warunki udziału
AI1Polityka bezpieczeństwa — zgodność z Polityką Bezpieczeństwa Informacji dla Wykonawców Centrum e-Zdrowia (ZSZ.SZBI.ISO.P.A.15), w tym szkolenie personelu i podpisanie zobowiązania do zachowania poufności danych przed uzyskaniem dostępu do infrastruktury IT Centrum
2Konflikt interesów — brak konfliktu interesów wobec Wykonawcy, członków jego władz oraz personelu/podwykonawców; obowiązkowe pisemne lub elektroniczne zgłoszenie potencjalnego konfliktu wraz z wyjaśnieniem
Pozostałe 1 warunek po założeniu darmowego konta.
Czerwone flagi
AISygnały, na które warto zwrócić uwagę przed startem.
Brak istotnych sygnałów ostrzegawczych.
Kary i sankcje
AI- Sankcje za naruszenie Polityki Bezpieczeństwa: kary karne, cywilne oraz wynikające z art. 107 i 108 ustawy o ochronie danych osobowych
- Kary umowne, wadium i zabezpieczenie: w projekcie umowy (Rozdz. XI, XIII SWZ)
Pytania i odpowiedzi
45Wyodrębnione z wyjaśnień treści SWZ.
1W OPZ występuje zwrot „„Subskrypcje Red Hat Learning Subscription Premium powinny posiadać okres ważności 60 miesięcy od dnia wskazanego przez Zamawiającego. Termin powinien być liczony oddzielnie dla każdej uruchomionej subskrypcji.” Nigdzie jednak Zamawiający nie wskazał konieczności dostarczenia subskrypcji Red Hat Learning Subscription Premium. Prosimy o wyjaśnienie.
Zamawiający wykreśla z Opisu przedmiotu zamówienia powyższy zapis.
1Zamawiający w Załączniku nr 1 „Opis Przedmiotu Zamówienia”, w części 5. Dostawa oprogramowania Red Hat Enterprise Linux, w pkt 5.1, Zamawiający wskazał wymaganie:
„Dostawa oprogramowania Red Hat Enterprise Linux for Virtual Datacenters + Satellite Add-On”.
Prosimy o doprecyzowanie, jaki dokładnie produkt/subskrypcję Red Hat Satellite Add-On Zamawiający ma na myśli:
Red Hat Satellite 2 Sockets or 2 Guests,
czy
Red Hat Satellite 2 Sockets Unlimited Guests?
Doprecyzowanie jest niezbędne do prawidłowej wyceny i przygotowania oferty zgodnej z wymaganiami OPZ.
Zamawiający doprecyzowuje, że oczekuje dostawy subskrypcji Red Hat Enterprise Linux for Virtual Datacenters with Satellite lub oprogramowania równoważnego.
2Zamawiający w Załączniku nr 1 „Opis Przedmiotu Zamówienia”, w części „5. Dostawa oprogramowania Red Hat Enterprise Linux”, w podpunkcie 5.1, w tabeli, poz. Lp. 1, wskazał czas obowiązywania licencji/subskrypcji wynoszący 14 miesięcy.
Czy Zamawiający dopuści zaoferowanie licencji/subskrypcji na okres 12 miesięcy, z opcją przedłużenia o kolejne 2 miesiące po zakończeniu podstawowego 12-miesięcznego okresu obowiązywania?
Dopuszczenie powyższego modelu licencjonowania pozwoli na zachowanie pełnego, wymaganego przez Zamawiającego okresu 14 miesięcy, przy jednoczesnym dostosowaniu sposobu licencjonowania do standardowych modeli subskrypcyjnych producenta. Rozwiązanie takie może zwiększyć konkurencyjność postępowania, umożliwić złożenie ofert przez szerszy krąg wykonawców oraz potencjalnie przełożyć się na korzystniejszą kalkulację cenową. Jednocześnie model 12 miesięcy + 2 miesiące przedłużenia zapewni ciągłość wsparcia, aktualizacji i dostępu do poprawek bezpieczeństwa przez cały wymagany okres.
Zamawiający dokonał zmiany dokumentacji postępowania w zakresie okresu obowiązywania subskrypcji. Aktualnie wymagany okres subskrypcji wynosi 60 miesięcy.
3Zamawiający w Załączniku nr 1 „Opis Przedmiotu Zamówienia”, w części „5. Dostawa oprogramowania Red Hat Enterprise Linux”, w podpunkcie 5.1, w tabeli w pozycji Lp. 3 wskazał czas obowiązywania licencji/subskrypcji wynoszący 46 miesięcy.
Czy Zamawiający dopuści zaoferowanie licencji/subskrypcji na okres 36 miesięcy, z opcją przedłużenia o kolejne 10 miesięcy po zakończeniu podstawowego okresu obowiązywania?
Dopuszczenie powyższego modelu licencjonowania pozwoli na zachowanie pełnego, wymaganego przez Zamawiającego okresu 46 miesięcy, przy jednoczesnym dostosowaniu sposobu licencjonowania do standardowych modeli subskrypcyjnych producenta. Rozwiązanie takie może zwiększyć konkurencyjność postępowania, umożliwić złożenie ofert przez szerszy krąg wykonawców oraz potencjalnie przełożyć się na korzystniejszą kalkulację cenową. Jednocześnie model 36 miesięcy + 10 miesięcy przedłużenia zapewni ciągłość wsparcia, aktualizacji i dostępu do poprawek bezpieczeństwa przez cały wymagany okres.
Zamawiający dokonał zmiany dokumentacji postępowania w zakresie okresu obowiązywania subskrypcji. Aktualnie wymagany okres subskrypcji wynosi 60 miesięcy.
4Ze względu na globalny problem z dostępnością oraz stabilnością cen komponentów serwerowych prosimy o skrócenie terminu, w którym Zamawiający może skorzystać z prawa opcji do jednego miesiąca.
Zamawiający podtrzymuje zapisy dokumentacji postępowania w zakresie terminu realizacji prawa opcji i nie wyraża zgody na jego skrócenie.
5Czy Zamawiający dopuszcza dostarczenie licencji RedHat zakupionych w kanale producenta dostarczanych serwerów (OEM)?
Zamawiający nie dopuszcza dostarczenia licencji w modelu OEM, jeżeli skutkowałoby to świadczeniem wsparcia wyłącznie przez partnera producenta. Zamawiający wymaga, aby wsparcie dla dostarczonego oprogramowania było świadczone bezpośrednio przez producenta oprogramowania, zgodnie z zapisami OPZ.
1Załącznik nr 1 - OPIS PRZEDMIOTU ZAMÓWIENIA, Rozdział 3. Serwery - wymagania, 3.2 – Wymagania minimalne dla serwera, Tabela nr 1, parametr – Dyski twarde, pkt 3.2
Zamawiający w powyższym punkcie zawarł następujący zapis:
„3.2. Zainstalowane 5 dysków mixed use, Endurance Class: ≥ 1 DWPD, Performance Class: F (100 k–349 k writes/s) lub wyższej, min. 1,9 TB, NVMe TLC każdy. Dyski kompatybilne z vSAN ESA (Express Storage Architecture), HOT-PLUG.”
Wskazać należy, iż wymagania zawarte w zapisie są ze sobą sprzeczne. Zamawiający wskazał dyski Mixed Use, które cechują się parametrem DWPD na poziomie 3 oraz podał parametr DWPD na poziomie 1, który jest charakterystyczny dla dysków Read Intensive.
W związku z powyższym zwracamy się do Zamawiającego z prośbą o doprecyzowanie czy wymaga dysków Mixed Use cechujących się parametrem DWPD 3, czy dysków Read Intensive cechujących się parametrem DWDP 1?.
Zamawiający wyjaśnia, że w OPZ wskazano parametry minimalne dla dysków pojemnościowych NVMe przeznaczonych dla warstwy danych VMware vSAN Express Storage Architecture (ESA). Wymaganie „Mixed Use, Endurance Class: ≥ 1 DWPD” należy rozumieć jako wymóg minimalnej trwałości (≥ 1 DWPD), a nie jako bezwzględny wymóg klasyfikacji producenta (Mixed Use vs Read Intensive).
Zamawiający wymaga, aby oferowane dyski spełniały co najmniej Endurance Class ≥ 1 DWPD oraz wskazaną Performance Class F lub wyższą, posiadały pojemność min. 1,9 TB i były NVMe TLC, hot-plug, były kompatybilne z vSAN ESA, tj. oferowany model dysku musi posiadać potwierdzoną kompatybilność w Broadcom Compatibility Guide w sekcji vSAN SSD, w podsekcji TIER: vSAN ESA Storage Tier.
Dyski o wyższej trwałości (np. DWPD ≥ 3) są dopuszczalne, o ile spełniają pozostałe wymagania i są zgodne z vSAN ESA.
2Załącznik nr 1 - OPIS PRZEDMIOTU ZAMÓWIENIA, Rozdział 3. Serwery - wymagania, 3.2 – Wymagania minimalne dla serwera, Tabela nr 1, parametr – Dyski twarde, pkt 3.1 oraz 3.3 – Wymagania minimalne – szczegółowe dla serwera, Tabela nr 2, parametr – Kontroler, pkt 4.1
Zamawiający w powyższych punktach zawarł następujące zapisy:
„3.1. Zainstalowane minimum 2 dyski Read Intensive (RI) min. 240GB SATA SSD Hot-Plug, działające redundantnie (RAID1), służące do uruchamiania systemu lub dodatkowa karta z zainstalowanymi 2 dyskami m.2, o pojemności min. 240GB każdy, zapewniająca tą samą funkcjonalność.”
oraz
„4.1. Serwer musi być wyposażony w kontroler sprzętowy z min. 2 GB cache z mechanizmem podtrzymywania zawartości pamięci cache w razie braku zasilania, zapewniający obsługę dysków boot’ujących.”
W związku z powyższym zwracamy się do Zamawiającego z prośbą o potwierdzenie, że w przypadku zaoferowania konfiguracji opartej o „dodatkową kartę z zainstalowanymi 2 dyskami m.2, o pojemności min. 240GB każdy” opisaną w punkcie 3.1 Tabeli nr 1, Zamawiający nie wymaga kontrolera opisanego w punkcie 4.1 Tabeli nr 2.
Zamawiający potwierdza, że celem wymagań w pkt 3.1 oraz 4.1 OPZ jest zapewnienie redundantnego uruchamiania systemu (RAID1 / mirroring) oraz właściwej obsługi dysków bootujących. Jednocześnie Zamawiający wskazuje, że docelowa architektura dyskowa środowiska danych ma wykorzystywać VMware vSAN ESA, a dyski NVMe przeznaczone dla vSAN ESA muszą być podłączone zgodnie z wymaganiami tej architektury (bez wymuszania pośrednictwa kontrolera RAID dla warstwy danych vSAN ESA). W przypadku zaoferowania rozwiązania w postaci dodatkowej karty z dwoma dyskami M.2 (min. 240 GB każdy), zapewniającej równoważną funkcjonalność względem wymogu z pkt 3.1, tj. pracę redundantną (mirroring/RAID1) dla dysków bootujących, Zamawiający nie wymaga odrębnego spełnienia wymogu kontrolera z pkt 4.1, o ile: redundancja boot (RAID1/mirroring) jest zapewniona przez tę kartę w sposób równoważny, rozwiązanie jest zgodne z wymaganiami OPZ a dyski NVMe przeznaczone dla vSAN ESA pozostają kompatybilne z vSAN ESA.
3Załącznik nr 1 - OPIS PRZEDMIOTU ZAMÓWIENIA, Rozdział 3. Serwery - wymagania, 3.3 – Wymagania minimalne – szczegółowe dla serwera, Tabela nr 2, parametr – Interfejsy sieciowe Ethernet i FC, pkt 5.1, 5.2 oraz 5.3
Zamawiający w powyższych punktach zawarł następujące zapisy:
„5.1. „Minimum 6 porty Ethernet SFP28 każdy 10/25 Gb/s. Wszystkie porty wraz z wkładkami SFP-25GSR. Karty muszą umożliwiać podział na wirtualne interfejsy za pomocą technologii NPAR.”
„5.2. „Minimum 1 port Ethernet 1 Gb/s.”
oraz
„5.3. Wszystkie porty ethernet muszą wspierać protokół LACP.”
W związku z powyższym zwracamy się do Zamawiającego z prośbą o potwierdzenie, że port Ethernet 1 Gb/s opisany w punkcie 5.2 jest portem sieciowym karty zarządzającej oraz, że wymagane wsparcie dla protokołu LACP z punktu 5.3 dotyczy jedynie portów Ethernet SFP28 10/25 Gb/s opisanych w punkcie 5.1.
Zamawiający potwierdza, że port Ethernet 1 Gb/s, o którym mowa w pkt 5.2, może stanowić port zarządzający. Wymaganie wsparcia protokołu LACP, o którym mowa w pkt 5.3, dotyczy portów Ethernet wykorzystywanych do transmisji danych dla środowiska produkcyjnego, w szczególności portów SFP28 10/25 Gb/s wskazanych w pkt 5.1.
Jednocześnie Zamawiający wskazuje, że rozwiązanie ma być zgodne z zakładaną architekturą środowiska (w tym VMware vSAN ESA) oraz wymaganiami OPZ w zakresie redundancji i agregacji łączy dla portów danych.
1Załącznik nr 1 - OPIS PRZEDMIOTU ZAMÓWIENIA, pkt 3 – Serwery – wymagania
Czy Zamawiający dopuści rozwiązanie udostępniające minimum 3 nieobsadzone gniazda PCIExpress
generacji 4 z dostępem zewnętrznym, w tym min. 2 sloty x16 (szybkość slotu – bus width),
po spełnieniu wszystkich wymagań opisanych w niniejszym OPZ.
Zamawiający podtrzymuje zapis pkt 3.3.Wymagania minimalne - szczegółowe dla serwera, ppkt. 2.1 OPZ.
2Załącznik nr 1 - OPIS PRZEDMIOTU ZAMÓWIENIA, pkt 3 – Serwery – wymagania
Zamawiający w punkcie 3.2 opisuje wymagania dla dysków pojemnościowych NVMe. Zamawiający wymaga dysków Mixed Use, jednocześnie zaniżając parametry dysku typowego dla Mixed Use do nieprawidłowej wartości.
W związku z powyższym prosimy o skorygowanie parametrów szczególnie w odniesieniu właśnie do właściwości dysku Mixed Use i korektę parametru DWPD do minimum 3.
Zamawiający informuje, że w OPZ wskazał parametry minimalne. Dostarczone rozwiązanie ma spełniać wymagania Endurance Class dla dysków Mixed Use , NVMe stosowanych w vSAN ESA. Wyniki dla oferowanego modelu dysku muszą być dostępne na stronie Broadcom Compatibility Guide – sekcja _vSAN SSD- podsekcja TIER: https://compatibilityguide.broadcom.com → kafelek vSAN SSD -> TIER: vSAN ESA Storage Tier.
1Czy Zamawiający potwierdza, że kluczowym celem wymagania procesorowego jest osiągnięcie określonej wydajności obliczeniowej, a nie preferencja konkretnej architektury producenta?
Zamawiający wskazuje, że wymagania dotyczące procesorów mają charakter parametryczno-wydajnościowy, określony poprzez minimalną liczbę rdzeni, taktowanie oraz wynik testu SPECrate2017_int_base ≥ 800.
2Czy Zamawiający dopuści procesory AMD EPYC, które spełniają wymagania liczby rdzeni oraz wyniku SPECrate2017_int_base ≥ 800, nawet jeśli częstotliwość bazowa pojedynczego rdzenia jest niższa niż 3,8 GHz, ale łączna wydajność systemu spełnia lub przewyższa wymagany poziom?
Zamawiający dopuszcza zaoferowanie procesorów różnych producentów (w tym AMD EPYC), pod warunkiem jednoczesnego spełnienia wszystkich wymagań OPZ, w tym częstotliwości bazowej ≥ 3,8 GHz oraz wyniku wydajnościowego. Zamawiający podtrzymuje wymóg dotyczący częstotliwości bazowej i nie dopuszcza jego zastąpienia wyłącznie sumaryczną wydajnością.
Historia zmian
05.05.2026 — ogłoszenie o zamówieniu
27.05.2026 — sprostowanie (Zmiana terminu składania i otwarcia ofert, zmiana terminu związania ofertą)
03.06.2026 — sprostowanie (zmiana terminu składania i otwarcia ofert, zmiana terminu związania ofertą)
11.06.2026 — sprostowanie (Zmiana terminu i składania ofert, zmiana terminu związania ofertą, zmiana w zakresie zamówienia opcjonalnego)
18.06.2026 — sprostowanie (zmiana terminu składania i otwarcia ofert, zmiana terminu związania ofertą)
25.06.2026 — upływ terminu składania ofert
25.09.2026 — rozstrzygnięcie