Wyrok KIO 2943/21

1. Oddala odwołanie.
2. Kosztami postępowania obciąża odwołującego PSI Polska Sp. z o.o. z siedzibą w Poznaniu i:
3. 1 zalicza w poczet kosztów postępowania odwoławczego kwotę 15 000 zł 00 gr (słownie: piętnaście tysięcy złotych 00/100), uiszczoną przez Odwołującego tytułem wpisu od odwołania, 2.2 zasądza od odwołującego - PSI Polska Sp. z o.o. z siedzibą w Poznaniu na rzecz zamawiającego - Polskich Sieci Elektroenergetycznych S.A. z siedzibą w Konstancinie-Jeziornej kwotę 3 600 zł 00 gr (trzy tysiące sześćset złotych 00/100) stanowiącą koszty postępowania odwoławczego poniesione przez zamawiającego z tytułu kosztów wynagrodzenia pełnomocnika.

Stosownie do art. 579 i 580 ustawy z 11 września 2019 r. - Prawo zamówień publicznych (Dz. U. z 2019 r., poz. 2019 ze zm.) na niniejszy wyrok - w terminie 14 dni od dnia jego doręczenia - przysługuje skarga za pośrednictwem Prezesa Krajowej Izby Odwoławczej do Sądu Okręgowego w Warszawie.

Sygn. akt

KIO 2943/21

Polskie Sieci Elektroenergetyczne S.A. z siedzibą w Konstancinie-Jeziornej (dalej:

Zamawiający) prowadzi na podstawie przepisów ustawy z 11 września 2019 r. Prawo zamówień publicznych (Dz. U. z 2019 r., poz. 2019, dalej: Pzp) postępowanie o udzielenie zamówienia publicznego w trybie z wolnej ręki pn.: „Aktualizacja (upgrade) oprogramowania podsystemów SCADA oraz EMS Systemu DYSTER”, numer: 2021/WNP-0168-DU-OP-AB, (dalej: postępowanie).

Ogłoszenie o dobrowolnej przejrzystości ex ante zostało zamieszczone 29 września 2021 r. w Dzienniku Urzędowym Unii Europejskiej pod nr 2021/S 189-492963.

4 października 2021 r. wykonawca PSI Polska Sp. z o.o. z siedzibą w Poznaniu (dalej:

Odwołujący), wniósł odwołanie, w którym zaskarżył niezgodne z przepisami czynności i zaniechania Zamawiającego zarzucając mu naruszenie następujących przepisów Pzp:

1. art. 214 ust. 1 pkt 1 lit. a i b oraz art. 388 pkt 1 Pzp przez wszczęcie postępowania w trybie z wolnej ręki mimo braku spełnienia przesłanek, o których mowa w ww. przepisie,
2. art. 16 pkt 1 i 3 Pzp przez przygotowanie i prowadzenie postępowania w sposób niezapewniający zachowania uczciwej konkurencji oraz równego traktowania wykonawców oraz nieproporcjonalny.

Odwołujący wniósł o uwzględnienie odwołania i nakazanie Zamawiającemu unieważnienia postępowania.

W uzasadnieniu odwołania Odwołujący wskazał m.in.:

W uzasadnieniu zamówienia w trybie z wolnej ręki Zamawiający powołał się na przesłanki udzielenia zamówienia określone w art. 214 ust. 1 pkt 1 lit. a i b Pzp. W ocenie Odwołującego uzasadnienie było bardzo ogólne i lakoniczne oraz pomijało szereg istotnych okoliczności.

Zgodnie z OPZ: „Wynikiem realizacji przedmiotu Zamówienia będzie Zmodernizowany System DYSTER” (str. 3); „Wynikiem realizacji przedmiotu Zamówienia będzie też płynne przejęcie obsługi procesów i zadań realizowanych obecnie przez System DYSTER zainstalowany w Krajowej Dyspozycji Mocy oraz pięciu Obszarowych Dyspozycjach Mocy przez Zmodernizowany System DYSTER zlokalizowany w siedzibach Zamawiającego w Konstancinie-Jeziornej oraz w Warszawie, ul. Mysia 2” (str. 4); „Wymaga się, aby w Zmodernizowanym Systemie DYSTER w poszczególnych Lokalizacjach Systemu zostały zaprojektowane, zaktualizowane i wdrożone następujące typy Środowisk [...]” (pkt 5.2, str. 16).

Zdaniem Odwołującego przedmiotem postępowania było zaprojektowanie i wdrożenie nowego systemu DYSTER zwanego przez Zamawiającego „Zmodernizowanym Systemem DYSTER”. Oczywistym rozwiązaniem alternatywnym/zastępczym w stosunku do zakupu nowego systemu w postaci zmodernizowanego systemu DYSTER (w trybie z wolnej ręki od dotychczasowego wykonawcy - Siemens) byłby zakup w trybie konkurencyjnym nowego systemu, spełniającego wymagania Zamawiającego określone w opisie przedmiotu zamówienia.

Zdaniem Odwołującego system posiadany przez Zamawiającego jest przestarzały i nie odpowiada aktualnym standardom, stąd potrzeba jego zastąpienia innym systemem: „Z uwagi na naturalny postęp technik informatycznych, procedur cyberbezpieczeństwa oraz starzenie się infrastruktury sprzętowo-systemowej, istnieje potrzeba modernizacji Systemu DYSTER (.)” (pkt 5 protokołu Postępowania). Aktualny system Odwołującego i zapewne także innych wykonawców niewątpliwie mogą spełnić oczekiwania Zamawiającego.

Zamawiający uzasadnienie wyboru trybu w kontekście istnienia rozsądnego rozwiązania alternatywnego lub zastępczego ograniczył wyłącznie do możliwości wykonania modernizacji obecnie posiadanego oprogramowania przez innych wykonawców, niż dostawca tego

systemu: „Dla osiągnięcia powyższych celów modernizacji Systemu DYSTER, nie istnieje rozsądne rozwiązanie alternatywne lub zastępcze w stosunku do aktualizacji oprogramowania Spectrum” (pkt 5 protokołu postępowania). Jednak celem samym w sobie nie była modernizacja posiadanego systemu DYSTER, lecz nabycie systemu spełniającego obiektywnie uzasadnione wymagania Zamawiającego. Taki cel był możliwy do osiągnięcia nie tylko przez zakup Zmodernizowanego Systemu DYSTER, ale zakup i wdrożenie także innych systemów, innych wykonawców. Modernizacja tego systemu objęta postępowaniem, to dostosowanie posiadanego przez SIEMENS rozwiązania do potrzeb Zamawiającego.

Analogicznie inni wykonawcy mogliby dostosować swoje systemy do tych potrzeb.

Zamawiający wskazał, że zamówienie mogło być świadczone tylko przez jednego wykonawcę z przyczyn związanych z ochroną praw wyłącznych wynikających z odrębnych przepisów: „Oprogramowanie Systemu DYSTER zostało dostarczone i wdrożone u Zamawiającego na podstawie umów zawartych z podmiotami koncernu Siemens, z których ostatnia to umowa nr PSE/DO/O-UO/353/2006 z 10 maja 2006 r. zawarta z polskim oddziałem koncernu, firmą Siemens Sp. z o.o. Postanowienia ww. umowy zawierają klauzule wyłączności praw na dostarczone oprogramowanie Spectrum, wyłączające udostępnianie oprogramowania i jego dokumentacji technicznej osobom trzecim (§ 15, § 21, Załącznik nr 26). Prawa wyłączne (autorskie prawa majątkowe) do oprogramowania Spectrum należą zatem do koncernu Siemens (Siemens AG, następca prawny Siemens Power Transmission and Distribution, Inc.). Koncern Siemens, w tym spółka Siemens AG, nie wyraża zgody na udostępnienie kodów źródłowych oprogramowania Spectrum. Koncern Siemens nie posiada w Polsce autoryzowanych partnerów rozwijających lub obsługujących to rozwiązanie jedynym podmiotem świadczącym takie usługi jest polski oddział koncernu - Siemens Sp. z o.o.”. Jednakże wskazana przesłanka ma charakter pozorny, ponieważ Zamawiający bezpodstawnie ograniczył przedmiot zamówienia wyłącznie do modernizacji systemu DYSTER. Z oczywistych względów inni wykonawcy, niż Siemens, w przypadku, gdyby Zamawiający zastosował rozwiązanie na które wskazał Odwołujący i wszczął postępowanie, którego przedmiotem byłby zakup systemu spełniającego jego wymagania, a nie modernizacja konkretnego systemu - DYSTER, nie potrzebowaliby żadnych kodów źródłowych do oprogramowań składających się na system DYSTER, ponieważ bazowaliby na własnych rozwiązaniach.

Zamawiający prawidłowo zidentyfikował to rozsądne rozwiązanie alternatywne/zastępcze w postaci dostawy i wdrożenia Nowego Systemu SCADA/EMS, zamiast modernizacji posiadanego systemu. Zamawiający poczynił nawet szeroko zakrojone działania w celu zrealizowania tego rozwiązania - Zamawiający przed wszczęciem postępowania przeprowadził dialog techniczny w oparciu o Pzp z 2004 r. (dalej: Dialog Techniczny).

Ogłoszenie o Dialogu Technicznym ukazało się 3 marca 2018 r., zaś zostało zakończone protokołem końcowym z 24 sierpnia 2021 r. Zgodnie z treścią pkt 2 ogłoszenia o Dialogu Technicznym - „Określenie celu i przedmiotu Dialogu”, Zamawiający wskazał:

„Polskie Sieci Elektroenergetyczne S.A. na podstawie art. 31a-31c ustawy z 29 stycznia 2004 r. Prawo zamówień publicznych (Dz.U. z 2017 r., poz. 1579, z późn. zm.) ogłaszają Dialog techniczny (zwany dalej „Dialogiem”), poprzedzający postępowanie o udzielenie zamówienia publicznego na „Dostawę i wdrożenie Nowego Systemu SCADA/EMS w PSE S.A.”. Dialog Techniczny trwał ponad 3 lata, a w tym czasie dochodziło do kilkukrotnych interakcji z wykonawcami, którzy uczestniczyli w Dialogu Technicznym. Wraz z zaproszeniem do udziału w Dialogu Technicznym Zamawiający przekazał wykonawcom dokumenty opisujące jego wymagania względem Nowego Systemu SCADA/EMS, tj. Wstępną Specyfikację Wymagań, na którą składały się: - Wymagania dla Architektury systemu SCADA/EMS, - Wymagania dla Graficznego Interfejsu Użytkownika, - Wymagania dla Modułu Danych Historycznych, - Wymagania dla Multisite, - Wymagania dla Operacji Sterowniczych i Nadzorczych, - Wymagania dla Przetwarzania Alarmowania, - Wymagania dla Przetwarzania Danych, - Wymagania dla Symulatora,

• Wymagania dla Wymiany Danych ICCP, - Wymagania dla Modułu Zarządzania Modelem, - Wymagania dla Telemechaniki, - Wymagania dla EMS, - Wymagania dla IT, - Załącznik 1 - flagi i znaczniki, - Załącznik 2 - listy alarmowe i zdarzeń, - Załącznik 3 - okno operacyjne, - Załącznik 4 - karta przełączeń, - Załącznik 5 - wzory szablonów ekranów raportowych, - Załącznik 6 - Automatyki ARNE/ARST na stacjach elektroenergetycznych, - Załącznik 7 - Tablica Synoptyczna, - Słownik pojęć.

Jak opisał Zamawiający podczas Dialogu Technicznego: „Celem przekazania Wstępnej Specyfikacji Wymagań jest pozyskanie Państwa stanowiska i opinii dotyczących wstępnego opisu przedmiotu zamówienia. W tym celu prosimy o odniesienie się do wszystkich wymagań zawartych we Wstępnej Specyfikacji, w szczególności przez przypisanie ich do następujących kategorii: a) Wymaganie zrozumiałe, aktualne rozwiązanie Uczestnika Dialogu spełnia wymaganie, b) Wymaganie zrozumiałe, aktualne rozwiązanie Uczestnika Dialogu nie spełnia wymagania, c) Wymaganie niezrozumiałe: i. niejasne, niezrozumiale napisane, ii. zbyt ogólnikowe, wymagające doprecyzowania np. w kontekście innych wymagań (wskazać jakich), iii. sprzeczne z innymi wymaganiami (wskazać jakie)”.

Dlatego Zamawiający posiadał już przygotowaną dokumentację, aby wszcząć postępowanie w trybie konkurencyjnym na zakup systemu. Informacje przekazywane przez uczestników Dialogu Technicznego pochodziły sprzed kilku lat (pierwsze informacje były przekazywane w połowie 2018 r., natomiast ostatnie na początku 2020 r.), więc aktualnie systemy tych wykonawców spełniałyby wymagania Zamawiającego w jeszcze większym zakresie.

Zamawiający w uzasadnieniu wyboru trybu postępowania wskazał także: „Z uwagi na naturalny postęp technik informatycznych, procedur cyberbezpieczeństwa oraz starzenie się infrastruktury sprzętowo-systemowej, istnieje potrzeba modernizacji Systemu DYSTER, przy jednoczesnym utrzymaniu dotychczasowych procedur działania tego systemu oraz kompetencji i doświadczenia personelu Zamawiającego, przez dokonanie aktualizacji jego oprogramowania. Dla zapewnienia bezpieczeństwa i ciągłości pracy KSE niezbędne jest zachowanie dotychczasowych funkcjonalności Systemu DYSTER opartych na architekturze systemu, koncepcji jej budowy, istniejących już dedykowanych rozszerzeniach oprogramowania Spectrum uwzględniających specyfikę pracy KSE, które stanowią efekt doświadczeń zgromadzonych przez lata pracy służb dyspozytorskich prowadzących ruch sieciowy, identyfikujących zagrożenia pracy sieci, eliminujących je oraz podejmujących środki zaradcze na przyszłość. Modernizacja Systemu DYSTER musi być powiązana z zachowaniem doświadczeń i kompetencji służb dyspozytorskich w wykorzystaniu jego funkcji oraz administratorów w samodzielnej obsłudze systemu. Konieczne jest również utrzymanie powiązań z innymi systemami Zamawiającego”.

W odniesieniu do powyższego Odwołujący wskazał:

1. W cytowanym fragmencie Zamawiający nie wymienił okoliczności przemawiających za wyborem trybu zamówienia z wolnej ręki, lecz na własne potrzeby. Był to de facto element OPZ, który nie korelował z uzasadnieniem konieczności udzielenia zamówienia konkretnemu wykonawcy z przyczyn związanych z ochroną praw wyłącznych, czy z przyczyn technicznych o obiektywnym charakterze. Zamawiający

nie twierdził i nie próbował wykazać, że tylko modernizacja systemu DYSTER pozwoliłaby osiągnąć te cele. To cele zostały postawione przed modernizacją. Takie same cele należałoby postawić przez zakupem nowego systemu.

1. Nie było podstaw do uznania, że inni wykonawcy nie dostarczyliby wymaganych przez Zamawiającego funkcjonalności w ramach swoich systemów.
2. Inni wykonawcy, a w każdym razie Odwołujący, mogliby również dostarczyć i te funkcjonalności, które realizowane są przez dedykowane rozszerzenia oprogramowania Spectrum.
3. Specyfika pracy KSE mogłaby być zaimplementowana w rozwiązaniach innych wykonawców, niż Siemens, jeśli tylko Zamawiający postawiłby odpowiednie wymagania w OPZ. Zamawiający jako gospodarz postępowania identyfikował swoje potrzeby, zaś rolą wykonawców było dostarczenie takiego rozwiązania.
4. Dostarczenie systemu innego wykonawcy, zamiast modernizacji Systemu DYSTER, nie wykluczałoby zachowania doświadczeń i kompetencji służb dyspozytorskich w wykorzystaniu jego funkcji oraz administratorów w samodzielnej obsłudze systemu.
5. Oczywistym byłoby także utrzymanie powiązań z innymi systemami Zamawiającego, ponieważ takie powiązania występują u wszystkich użytkowników tego typu systemów.

Rozwiązanie alternatywne/zastępcze w postaci zakupu nowego systemu w trybie konkurencyjnym byłoby ze wszech miar rozsądne:

1. Zamawiający mógłby wymagać, aby system realizował potrzebne Zamawiającemu funkcjonalności oraz postawić wymagania w celu zapewnienia bezpieczeństwa i ciągłości pracy KSE.
2. Zamawiający posiadał gotowy (lub bardzo zaawansowany) opis przedmiotu zamówienia na potrzeby alternatywnego/zastępczego rozwiązania, tj. zakupu nowego systemu SCADA/EMS w ramach np. przetargu nieograniczonego.
3. Nowy system mógłby być dostarczony w takim samym czasie, co modernizacja systemu DYSTER. Zgodnie opisem przedmiotu zamówienia czas na dostarczenie zmodernizowanego systemu DYSTER to 24 miesiące, a w takim samym czasie możliwe byłoby dostarczenie innego systemu przez innego wykonawcę, w tym przez Odwołującego.
4. Zakup systemu w procedurze konkurencyjnej to możliwość pozyskania znacznie korzystniejszych ofert.
5. Zamawiający nie byłby uzależniony od jednego wykonawcy.
6. Zamawiający mógłby od razu zakupić w ramach postępowania infrastrukturę sprzętowo-programową dla systemu. Było to o tyle istotne, że w tym postępowaniu będzie ona zakupywana oddzielnie przez Zamawiającego na podstawie ustaleń z Siemens (pkt 5.4). Takie rozwiązanie powoduje, że Zamawiający nie wie jaka ona konkretne będzie. Ta infrastruktura będzie wynikać z architektury zmodernizowanego systemu DYSTER, która może być różnie określona w tym zakresie, w jakim Zamawiający nie określił jej w OPZ. Mogłoby się zatem okazać, że inne systemy, przy spełnieniu wymagań Zamawiającego co do architektury (pkt 4 i 5 OPZ) byłyby zdecydowanie bardziej zoptymalizowane w tym zakresie, a Zamawiający poniósłby mniejsze wydatki.

Modernizacja systemu DYSTER będzie wymagała głębokich zmian w stosunku do posiadanego obecnie przez Zamawiającego systemu. Będzie to system zbudowany na nowo. Tak samo system dostarczony przez innego wykonawcę byłby systemem zbudowanym w oparciu o posiadane przez tych wykonawców systemy. Każdy z dostarczonych systemów byłby nowym systemem - każdy z tych systemów musiałby uwzględniać specyficzne wymagania Zamawiającego, co Zamawiający silnie zaakcentował w uzasadnieniu wyboru trybu postępowania. Dlatego też wykonawca Siemens nie posiadał gotowych rozwiązań funkcjonujących u innych jego klientów, których mógłby użyć bez konieczności ich przeprojektowania u Zamawiającego. Ponadto Siemens musiałby przeprojektować/przebudować i na nowo wdrożyć system DYSTER, co wynika z konieczności jego dostosowania do rozwoju informatycznego i wymagań cyberbezpieczeństwa.

W pkt 2.1, 2.2 i 3 OPZ wskazane zostało jak wiele modułów podlega zmianom. Zamawiający postawił wymóg (pkt 5.2 OPZ), by w zmodernizowanym systemie DYSTER w

poszczególnych lokalizacjach zostały zaprojektowane, zaktualizowane i wdrożone następujące typy Środowisk: a) Środowisko Produkcyjne, b) Środowisko Pre-produkcyjne, c) Środowisko Rozwojowe, d) Środowisko Administracyjne, e) Środowisko Zarządzania Instalacją, Konfiguracją i Zmianą, f) Środowisko Użytkowników Biuro, g) Środowisko Szkoleniowe.

Planowana zmiana dotyczyć będzie zatem wszystkich środowisk (całego istniejącego systemu) i zaprojektowania ich na nowo, a nie np. dołożenia dodatkowych modułów, oprócz już istniejących, nie objętych zmianami. W związku z koniecznością zaprojektowania tego systemu, oprócz wskazanego pkt 5.2 OPZ stanowiącego wprost o projektowaniu i wdrażaniu środowisk, OPZ zawierał także inne postanowienia, typowe dla wdrażania nowych systemów, m.in.:

1. migracja danych z obecnego systemu DYSTER do zmodernizowanego systemu na potrzeby testów FAT, SAT oraz na potrzeby uruchomienia produkcyjnego - str. 3,
2. opracowanie dokumentacji testowej oraz wykonanie testów PRE-FAT oraz testów FAT - str. 3,
3. przeprowadzenie testów SAT sprawdzających poprawność działania zmodernizowanego systemu - str. 3,
4. uruchomienie produkcyjne zmodernizowanego systemu DYSTER - str. 3, Wynikiem realizacji przedmiotu zamówienia będzie też płynne przejęcie obsługi procesów i zadań realizowanych obecnie przez system DYSTER zainstalowany w Krajowej Dyspozycji Mocy oraz pięciu Obszarowych Dyspozycjach Mocy przez zmodernizowany system zlokalizowany w siedzibach Zamawiającego - str. 4, Fakt, że Zamawiający wymagał w ciągu 24 miesięcy zaprojektowania, zaktualizowania i wdrożenia, wyraźnie wskazywał na to, że przedmiotem zamówienia nie była wyłącznie aktualizacja - upgrade (tj. podniesienie systemu z niższej wersji oprogramowania do wersji wyższej), która jest zwykle zautomatyzowana i nie wymaga aż 24 m-cy. Tyle czasu potrzebne jest dla przedsięwzięcia wdrożeniowego, zakrojonego na szeroką skalę zupełnie nowego systemu SCADA/EMS.

Specyfika wdrożeń systemów klasy SCADA/EMS wiąże się z koniecznością zachowania ciągłości nadzoru i sterowania infrastrukturą sieci elektroenergetycznej. W każdym przypadku proces wdrożenia systemu (nowego dostawcy czy dotychczasowego dostawcy) odbywa się równolegle w stosunku do istniejącej wersji systemu i nie polega na nadpisaniu starej wersji systemu nową, tak jak ma to powszechnie miejsce w przypadku typowej aktualizacji (upgrade'u) systemu informatycznego. W przypadku systemów SCADA/EMS stara wersja systemu będzie przez Zamawiającego eksploatowana równolegle (przez co najmniej 24 mce tj. tyle ile przewiduje harmonogram wykonania przedmiotu zamówienia) tj. do czasu uruchomienia produkcyjnego zmodernizowanego lub nowego systemu. Jest zatem bez znaczenia czy równolegle wdrażany nowy system SCADA/EMS będzie systemem dotychczasowego czy nowego dostawcy.

Brak przyczyn technicznych o obiektywnym charakterze Zamawiający w uzasadnieniu wyboru trybu wskazał także (pkt 5 protokołu postępowania):

„Niezależnie od powyższych okoliczności zamówienie może zostać wykonane wyłącznie przez dostawcę Systemu DYSTER z przyczyn technicznych o obiektywnym charakterze z tego względu, że jako jedyny: (1) dysponuje niezbędnym know-how dla wykonania aktualizacji oprogramowania Spectrum, (2) dysponuje personelem posiadającym niezbędną i unikatową wiedzę o systemie oraz KSE, (3) posiada referencyjny model odniesienia dla Systemu DYSTER, wykorzystywany przy rozwiązywaniu problemów technicznych, i wyłącznie w przypadku aktualizacji Systemu DYSTER możliwe jest utrzymanie tego

rozwiązania, co jest kluczowe dla zapewnienia niezawodności systemu służącego zarządzaniu KSE”.

Owe „przyczyny techniczne” miały jednak wtórne znaczenie i były irrelewantne dla przedmiotu zamówienia skoro możliwe do zastosowania byłoby rozsądne rozwiązanie alternatywne/ zastępcze, w postaci dostarczenia systemu przez innego wykonawcę.

Zamawiający nie przedstawił żadnej argumentacji w tym względzie w stosunku do rozwiązania alternatywnego.

Zamawiający poprzestał jedynie na twierdzeniach i nie przedstawił jakiejkolwiek argumentacji i uzasadnienia dla swoich tez.

Ponadto żadna ze wskazanych okoliczności nie stanowiła przyczyny technicznej w rozumieniu art. 214 ust. 1 pkt 1 lit. a Pzp, lecz odwoływała się do wiedzy i posiadanego doświadczenia. Wskazane argumenty sprowadzały się do uznania, że Siemens, w przekonaniu Zamawiającego, jest najlepszym wykonawcą.

Wygoda korzystania ze znanego sprzętu, systemu, technologii przez zamawiającego również nie jest uznawana za wystarczającą przesłankę rezygnacji z dopuszczenia rozwiązań alternatywnych lub zastępczych, które istnieją na rynku.

Względy techniczne uzasadniające udzielenie zamówienia bez przeprowadzenia procedury konkurencyjnej konkretnemu wykonawcy muszą mieć zasadniczy charakter, tak by można było wykazać, że wykonanie zamówienia przez innego wykonawcę jest ze względów technicznych rzeczywiście niemożliwe, a nie tylko utrudnione, i że ta niemożliwość ma charakter nieprzezwyciężalny. Okoliczności takie w ocenie Odwołującego nie wystąpiły w postępowaniu.

Zaniechanie przeniesienia praw autorskich niezbędnych do zachowania możliwości konkurencyjnego udzielania dalszych powiązanych z nim zamówień.

Niezapewnienie przez Zamawiającego kodów źródłowych do oprogramowania wchodzącego w skład systemu DYSTER nie może być w żadnym wypadku uzasadnieniem dla zastosowania trybu z wolnej ręki. Zamawiający nie zawarł żadnego uzasadnienia dla zaniechania nabycia majątkowych praw autorskich i kodów źródłowych przy okazji nabywania systemu DYSTER.

Skorzystanie z trybu zamówienia z wolnej ręki możliwe jest tylko w sytuacjach szczególnych, a szczególny charakter tych sytuacji zależny jest od czynników zewnętrznych - niezależnych od zamawiającego. Mimo że ani ustawa, ani dyrektywa, wymieniając przyczyny techniczne bądź też związane z prawami wyłącznymi, nie sformułowały wprost warunku, zgodnie z którym przyczyny te nie mogą t wynikać z działania zamawiającego, to tego rodzaju warunek wynika z zasad traktatowych. Natomiast z dotychczasowej praktyki UZP wynikało, że wskazywanie przez zamawiających na konieczność udzielania zamówień publicznych w trybie z wolnej ręki konkretnemu wykonawcy w obszarze zamówień informatycznych w znacznej ich części jest wynikiem braku dochowania przez zamawiającego należytej staranności w zakresie opisu przedmiotu zamówienia, czy też przy sporządzaniu projektu umowy o zamówienie publiczne.

Wykazanie przez Zamawiającego, że zamierzał nabyć usługę objętą ochroną wynikającą z praw wyłącznych, nie było wystarczające - konieczne było wykazanie, że na rynku nie ma dostępnego ekwiwalentu (substytutu) takiej usługi. Jeżeli taki substytut danej usługi lub produktu istnieje, to Zamawiający nie mógł preferować danej usługi lub produktów objętych ochroną wynikającą z praw wyłącznych.

Odwołujący w toku posiedzenia niejawnego z udziałem stron 25 października 2021 r. wniósł o przeprowadzenie dowodów z następujących dokumentów:

1. Tabelaryczne przedstawienie przebiegu dialogu technicznego na linii Odwołujący Zamawiający (dowód nr 1).
2. Korespondencja e-mailowa Zamawiającego z Odwołującym dotycząca przedmiotu zamówienia w postępowaniu (dowód nr 2).
3. Opinia Izby Rzeczoznawców Polskiego Towarzystwa Informatycznego prezentująca różnice pomiędzy aktualizacją istniejącego dotychczas oprogramowania, a wdrożeniem nowego systemu DYSTER na okoliczność wykazania, że Zamawiający zamawia nowy przedmiot zamówienia (dowód nr 3).
4. Zaproszenie Odwołującego do udziału w Dialogu Technicznym z 11 kwietnia 2018 r. (dowód nr 4).
5. Zawiadomienie z 30 marca 2015 r. o unieważnieniu postępowania w trybie z wolnej ręki, tj. postępowania o udzielenie zamówienia publicznego, sektorowego realizowanego zgodnie z ustawą Prawo zamówień publicznych w trybie negocjacji z ogłoszeniem na: "Wdrożenie aplikacji sieciowych Energy Management Systems (EMS) w Obszarowych Dyspozycjach Mocy" (dowód nr 5).
6. Opracowanie pt. „Rozwój systemów czasu rzeczywistego dla celów sterowania dyspozytorskiego w KDM" (J. S. , Stowarzyszenie Elektryków Polskich) na okoliczność wykazania, że Zamawiający zamówił system od innego podmiotu, niż Siemens (dowód nr 6).
7. Wydruk Informacji z 1 maja 2018 r. o wyborze przez Sabah Electricity Sdn. Bhd. (malezyjski odpowiednik Zamawiającego) zintegrowanego rozwiązania produkcji OSI, na okoliczność wykazania, że udzielając zamówienia na analogiczny przedmiot zamówienia, ww. podmiot zdecydował się na postępowanie konkurencyjne (dowód nr 7).
8. Informacja o postępowaniu konkurencyjnych na modernizację systemu SCADA w Bośni i Hercegowinie (dowód nr 8).
9. Ogłoszenie o udzieleniu 7 czerwca 2006 r. wykonawcy Siemens zamówienia sektorowego przez Zamawiającego na rozbudowę (upgrade) systemu sterowania dyspozytorskiego DYSTER w KDM i ODM o funkcjonalności Multisite (dowód nr 9).
10. Zapytanie ofertowe z 16 maja 2013 r. skierowane przez Zamawiającego do KPMG Advisory Sp. z o.o. z siedzibą w Warszawie - zaproszenie do złożenia oferty na „Opracowanie długofalowej strategii rozwoju i utrzymania systemów informatycznych wsparcia służb dyspozytorskich oraz nadzoru eksploatacji w PSE S.A." (dowód nr 10).
11. Dowód objęty tajemnicą przedsiębiorstwa - informacja nt. wyceny i harmonogramu przekazane przez Odwołującego Zamawiającemu w ramach Dialogu Technicznego z 2018 r. (dowód nr 11).
12. Porównanie pierwotnie udostępnionej wersji OPZ (zamieszczonego przez Zamawiającego na platformie zakupowej 29 września 2021 r. wraz z opublikowanym ogłoszeniem o dobrowolnej przejrzystości ex ante 2021/S 189-492963) z wersją OPZ ją zmieniającą (zamieszczoną na platformie zakupowej 30 września 2021 r.) w postępowaniu (dowód nr 12).
13. Dowód objęty tajemnicą przedsiębiorstwa - zestawienie referencji Odwołującego potwierdzających należytą realizację wdrożeń systemu SCADA przez Odwołującego (dowód nr 13).

Odwołujący wniósł ponadto o włączenie w poczet materiału dowodowego dokumentacji z Dialogu Technicznego z 2018 r., który poprzedzał postępowanie (dokumentów pochodzących od Zamawiającego i Odwołującego w ramach prowadzonej korespondencji), w tym: - zaproszenia z załącznikami, - dokumentów złożonych w odpowiedzi na zaproszenie przez Odwołującego, - zaktualizowanych wymagań Zamawiającego.

25 października 2021 r. pismo procesowe złożył wykonawca Emerson Process Management Sp. z o.o. z siedzibą w Warszawie (dalej: Przystępujący Emerson lub Emerson).

Przystępujący poparł stanowisko Odwołującego wskazując ponadto:

Art. 214 ust. 1 pkt 1 lit. a Pzp dotyczy sytuacji, gdy na rynku dotyczącym danej dostawy, usługi lub roboty budowlanej występuje monopol naturalny czy też swego rodzaju monopol techniczny (technologiczny). Sytuacja taka mogłaby wystąpić np., gdy dany wykonawca posiadał monopol na wykonywanie danego typu usług, co związane było przykładowo z pozostającą w jego dyspozycji infrastrukturą lub specyficzną technologią wykonania określonych dostaw czy usług.

Jakkolwiek charakter usługi będącej przedmiotem zamówienia można było określić jako skomplikowany, tak z całą pewnością na rynku informatycznym działa co najmniej kilka podmiotów posiadających doświadczenie w tworzeniu i aktualizacji tego typu systemów.

Zamawiający miał tego świadomość, skoro przeprowadził Dialog techniczny z udziałem kilku (dalej: OSI), który to podmiot jest obecnie częścią grupy kapitałowej, do której należy Przystępujący. W protokole końcowym z Dialogu z 24 sierpnia 2021 r. Zamawiający sam podkreślił, że celem Dialogu było „pozyskanie wiedzy o dostępnych na rynku systemach klasy SCADA/EMS” (pkt 6 Protokołu). Uczestnikami Dialogu były podmioty oferujące tego typu systemy, mogące dostarczyć Zamawiającemu nowy system SCADA/EMS spełniający wszystkie wymagania techniczne, funkcjonalne i niefunkcjonalne określone przez PSE.

W Protokole Zamawiający wskazał m.in.:

1. wymagania, które zmodyfikował w opracowanej specyfikacji w oparciu o przebieg Dialogu (pkt 6 Protokołu, s. 2-3), polegające chociażby na ich doprecyzowaniu, ale jednocześnie na odstąpieniu od szczegółowego określenia części wymagań, poprzestając na określeniu wymaganej przez PSE funkcjonalności;
2. zagadnienia, które w jego ocenie wymagałyby modyfikacji systemów oferowanych przez innych niż Siemens uczestników Dialogu przez implementację tzw. rozszerzeń przez dostawcę nowego systemu SCADA/EMS (pkt 6 Protokołu, s. 3 oraz pkt 7 Protokołu, s. 4);
3. okoliczności, które jego zdaniem świadczyły o tym, że rynek zaawansowanych rozwiązań teleinformatycznych dla podmiotów zarządzających w czasie rzeczywistym pracą rozległych systemów elektroenergetycznych nie oferuje w chwili obecnej systemu klasy SCADA/EMS zdolnego do obsługi obecnych procesów biznesowych PSE S.A. bez konieczności wykonania fundamentalnych zmian w oprogramowaniu tego systemu, jego architekturze, logice działania (pkt 7 Protokołu, s. 4).

We wnioskach z Dialogu Zamawiający podkreślił, że nawet gdyby wymagane zmiany w systemach oferowanych przez innych niż Siemens uczestników dialogu mogłyby zostać wprowadzone - co jego zdaniem nie zostało udowodnione - to „nie są możliwe do implementacji w ramach wymaganego harmonogramu projektu realizowanego w wyniku otwartego postepowania. Ich zakres, złożoność oraz stopień ingerencji w dotychczasowe rozwiązanie uczestnika dialogu wyklucza z przyczyn czysto technicznych możliwość poprawnego wdrożenia wszystkich wymaganych modyfikacji w celu spełnienia wymagań PSE SA., bez zapewnienia odpowiednio długiego czasu na projektowanie rozwiązania i jego weryfikację w ramach uruchomienia testowego”.

Przystępujący Emerson wskazał, że abstrahując od braku wiarygodnych podstaw do stwierdzenia przez Zamawiającego, że nie byłoby możliwe wprowadzenie przez innych niż Siemens uczestników dialogu odpowiednich zmian w oferowanych przez nich systemach SCADA/EMS w założonym przez Zamawiającego harmonogramie realizacji projektu, nie sposób wyinterpretować z przebiegu Dialogu, że „nie zostało jednoznacznie potwierdzone” (jak wskazał w Protokole sam Zamawiający), że wprowadzenie takich zmian jest w ogóle możliwe.

Po zakończeniu Dialogu i w odpowiedzi na twierdzenia Zamawiającego uwzględnione w Protokole, jeden z uczestników dialogu - OSI wystosowała do Zamawiającego pismo, w którym podtrzymała stanowisko przekazane w toku Dialogu. W piśmie podkreślono m.in. że OSI byłoby w stanie spełnić wszystkie wymagania krytyczne dotyczące systemu SCADA/EMS w zakładanym harmonogramie realizacji projektu, bez konieczności ingerencji w jądro oferowanego przez OSI systemu SCADA/EMS, a ponadto wyszczególniono te obszary/zagadnienia, w odniesieniu do których w ogóle konieczne byłoby wprowadzenie jakichkolwiek zmian w oferowanym przez OSI systemie w celu spełnienia wymagań Zamawiającego. Jednocześnie, OSI wskazał, że posiadał szerokie kompetencje i doświadczenie w wymianie/migracji systemów Siemens na system oferowany przez OSI, czego najlepszym dowodem jest skala realizowanych w tym zakresie projektów: migracja 32 systemów Siemens na przestrzeni ostatnich 8 lat, w tym 7 w Europie (m.in. w Hiszpanii i Słowacji).

Pomijając fakt, że wiedzę dotyczącą funkcjonowania oprogramowania Spectrum mogły posiadać osoby, które nie współpracują obecnie z wykonawcą Siemens (a z którymi współpracę mógłby podjąć Odwołujący lub Przystępujący), wskazanie tej okoliczności jako technicznej przyczyny o obiektywnym charakterze, uzasadniającej udzielenie zamówienia temu wykonawcy w drodze bezprzetargowej było o tyle niezasadne, że mogła ona świadczyć jedynie o przewadze konkurencyjnej Siemens wobec innych potencjalnych oferentów, która nie powinna jednak uzasadniać całkowitego wyłączenia konkurencji przez Zamawiającego.

Uznanie, że znajomość konkretnego oprogramowania i konkretnego systemu

elektroenergetycznego, do zarządzania którym dane oprogramowanie było wykorzystywane stanowiło przyczynę techniczną o obiektywnym charakterze powodowałoby, że każdy zamawiający mógłby ograniczać, a w praktyce wyłączać konkurencję, w prowadzonych przez siebie postępowaniach, utrzymując że tylko dotychczasowy wykonawca danej usługi czy danych dostaw może wykonać zamówienie.

Ponadto przyczynami technicznymi o obiektywnym charakterze nie są względy dotyczące terminu realizacji zamówienia. Zamawiający nie mógł więc twierdzić, że zasadnie zastosował art. 214 ust. 1 pkt 1 lit. a Pzp z uwagi na to, że jego zdaniem (czego jednak w żaden sposób nie wykazał) inni niż Siemens uczestnicy Dialogu nie byliby w stanie wdrożyć w oferowanych przez siebie systemach SCADA/EMS wymaganych przez Zamawiającego rozszerzeń w założonym harmonogramie realizacji projektu.

W art. 214 ust. 1 pkt 1 lit. b Pzp ustawodawca uregulował przesłankę tzw. monopolu prawnego, odnoszącą się do sytuacji, gdy tylko jeden wykonawca może zrealizować zamówienie z uwagi na przyczyny związane z ochroną praw wyłącznych wynikające z odrębnych przepisów. Dotyczy to w szczególności praw autorskich i praw pokrewnych chronionych przepisami ustawy z 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych (t.j. Dz.U. z 2021 r. poz. 1062) lub ochrony patentowej i ochrony innych praw wyłącznych udzielonej na podstawie przepisów ustawy z 30 czerwca 2000 r. - Prawo własności przemysłowej (t.j.

Dz.U. z 2021 r. poz. 324). W Ogłoszeniu Zamawiający wskazał, że umowa nr PSE/DO/OUO/353/2006 z 10 maja 2006 r. zawarta między Zamawiającym a wykonawcą Siemens, której przedmiotem było dostarczenie i wdrożenie oprogramowania Systemu DYSTER nie zapewniała Zamawiającemu możliwości udostępniania tego oprogramowania, w tym kodów źródłowych i jego dokumentacji technicznej osobom trzecim. Zakładając prawdziwość tego twierdzenia, należało uznać, że obecnie użytkowany przez Zamawiającego System DYSTER rzeczywiście podlegał ochronie przed ingerencją osób trzecich (w tym samego Zamawiającego), co mogłoby uniemożliwiać innym wykonawcom realizację zamówienia w założonym przez Zamawiającego kształcie. Powyższe nie świadczyło jednak o tym, że względy ochrony praw wyłącznych wynikające z odrębnych przepisów skutkowały koniecznością udzielenia zamówienia wykonawcy Siemens. Jak podkreślono w orzecznictwie Izby, ochrona praw wyłącznych nie może wynikać z wcześniej zawartych przez zamawiającego umów, które zapewniają ochronę tych praw - tak jak ma to miejsce w przypadku Zamawiającego i umowy na wdrożenie przez Siemens Systemu DYSTER. Akceptowanie takiej sytuacji powodowałoby na czas bliżej nieokreślony, wyłączanie raz już udzielonych cyklicznych zamówień na usługi. z rygorów udzielania zamówień wskazanych w Pzp. Dostawa i wdrożenie całkowicie nowego systemu SCADA/EMS stanowiło przy tym rozsądne rozwiązanie alternatywne wobec aktualizacji obecnie użytkowanego przez Zamawiającego systemu. Zakres aktualizacji, będącej przedmiotem zamówienia byłby na tyle szeroki, że Zamawiający otrzymałby i tak zupełnie nowy system, o znacznie bardziej zaawansowanych funkcjonalnościach i parametrach niż ten obecnie wykorzystywany.

Świadczyły o tym chociażby następujące okoliczności:

1. planowane fazy i etapy projektu wyszczególnione w OPZ dla postępowania są typowe dla projektów wdrożeniowych nowych systemów, czego najlepszym potwierdzeniem jest migracja danych. To dowodziło, że model danych obecnego Systemu DYSTER (wersja 3.9) różnił się diametralnie od modelu danych wymaganego dla nowego systemu (wersja 7.2);
2. między obecnie użytkowanym Systemem DYSTER, a teoretycznie zaktualizowaną wersją tego systemu występują istotne różnice technologiczne - obecna wersja oparta była o technologię IBM i system operacyjny AIX, natomiast system po aktualizacji ma być oparty o zupełnie inną technologię (DELL) i system operacyjny (Linux);
3. obecnie użytkowany System DYSTER oparty był o przestarzałą i wycofaną z rynku przez Siemensa linię produktową SNAUT@ Spectrum. Nowy system, który zostałby wdrożony przez wykonawcę Siemens w ramach realizacji Zamówienia oparty jest o

nową linię produktową Spectrum Power 7.x, która nie jest kontynuacją tej pierwszej (zmiana nazwy linii produktowej miała charakter wyłącznie handlowy i marketingowy);

1. wymagany termin realizacji Zamówienia (24 miesiące) odpowiadałby okresowi wdrożenia nowego systemu SCADA/EMS.

Taki sam efekt przy zwiększonej konkurencji, osiągnąłby Zamawiający wszczynając postępowanie o udzielenie zamówienia sektorowego na dostawę nowego oprogramowania.

Na dowód zasadności swojego stanowiska Przystępujący Emerson złożył wraz z pismem procesowym następujące dowody:

1. protokół końcowy z Dialogu Technicznego z 24 sierpnia 2021 r.,
2. informacje prasowe ze strony internetowej OSI o wybranych projektach realizowanych przez OSI wraz tłumaczeniem na język polski.

11 października 2021 r. wykonawca Mikronika Sp. z o.o. z siedzibą w Poznaniu (dalej:

Przystępujący Mikronika lub Mikronika) wraz ze zgłoszeniem przystąpienia do postępowania odwoławczego wniósł o dopuszczenie i przeprowadzenie przez Izbę dowodu z opinii biegłego z dziedziny informatyki i elektroniki ze szczególnym uwzględnieniem specjalizacji w zakresie systemów SCADA/EMS, w przedmiocie oceny czy rozwiązaniem alternatywnym/zastępczym w stosunku do aktualizacji bieżącego systemu DYSTER jest zakup nowego systemu SCADA/EMS, który będzie spełniał tożsame wymagania Zamawiającego określone w opisie przedmiotu zamówienia oraz w przedmiocie czy aktualizacja (upgrade) istniejącego oprogramowania podsystemów SCADA oraz EMS Systemu DYSTER jest de facto zaprojektowaniem i wdrożeniem nowego systemu zamiast aktualizacji.

25 października 2021 r. w toku posiedzenia niejawnego z udziałem stron Przystępujący Mikronika wniósł o przeprowadzenie dowodu z następujących dokumentów:

1. Dokumenty dotyczące wdrożenia systemu SCADA na Cyprze Północnym, w tym pismo Komisji Europejskiej z 31 lipca 2009 r. w sprawie unowocześnienia systemu zarządzania sektorem energetycznym - System SCADA, numer referencyjny: EuropeAid/124323ID/SUP/CY; dokumenty sporządzone w języku angielskim wraz z częściowym tłumaczeniem na język polski, złożone na okoliczność wykazania, że przedmiotem zamówienia w postępowaniu jest de facto zakup nowego systemu (dowód nr 18).
2. Zawiadomienie z 18 listopada 2020 r. o wyborze jako najkorzystniejszej w postępowaniu oferty złożonej przez Mikronikę (postępowanie nr P/1/0121/2018), gdzie Zamawiającym była Energa Operator S.A., a przedmiotem zamówienia „Wdrożenie centralnego systemu zarządzania ruchem sieci elektroenergetycznej SCADA" (dowód nr 19).
3. Zawiadomienie o wyborze jako najkorzystniejszej w postępowaniu oferty złożonej przez wykonawcę Badawczo-Rozwojowa Spółdzielnia Pracy Mikroprocesorowych Systemów Automatyki Mikronika z siedzibą w Poznaniu.

Postępowanie nr FZ-Z/P037/13 na „Zaprojektowanie, wdrożenie oraz utrzymanie systemu SCADA wraz z DMS dla RWE Stoen Operator Sp. z o.o.” (dowód nr 20).

1. Informacja z 5 marca 2013 r. o rozstrzygnięciu postępowania nr 32/12/LZA pn. „Zaprojektowanie, budowa, dostawa i wdrożenie centralnego systemu SCADA dla PGE Dystrybucja S.A. Oddział Warszawa" i wyborze oferty wykonawcy Badawczo-Rozwojowa Spółdzielnia Pracy Mikroprocesorowych Systemów Automatyki Mikronika z siedzibą w Poznaniu (dowód nr 21).
2. Zawiadomienie z 10 sierpnia 2011 r. o wyborze jako najkorzystniejszej w postępowaniu oferty złożonej przez wykonawcę Badawczo-Rozwojowa Spółdzielnia Pracy Mikroprocesorowych Systemów Automatyki Mikronika z siedzibą w Poznaniu.

Postępowanie nr OBB/IU/71/5/2011/U/330/I pn. „Dostawa oraz wdrożenie systemu SCADA dla sieci dystrybucyjnej wysokiego napięcia ENION S.A.” (dowód nr 22).

1. Zawiadomienie z 11 sierpnia 2011 r. o wyborze jako najkorzystniejszej w postępowaniu oferty złożonej przez wykonawcę Badawczo-Rozwojowa Spółdzielnia Pracy Mikroprocesorowych Systemów Automatyki Mikronika z siedzibą w Poznaniu.

Postępowanie nr OBB/IU/70/4/2011/U/330/I pn. „Dostawa oraz wdrożenie systemu

SCADA dla sieci dystrybucyjnej średnich i niskich napięć ENION S.A.” (dowód nr 23)

1. Umowa nr 56-00015509/2019/rok (data nieczytelna) zawarta między Przystępującym Mikronika, a PKN Orlen S.A. z siedzibą w Płocku (dowód nr 24).
2. Sporządzony w języku holenderskim dokument wraz z tłumaczeniem na język polski punktu 8.3 tego dokumentu (dowód nr 25).

24 października 2021 r. Zamawiający złożył pisemną odpowiedź na odwołanie i wniósł o jego oddalenie. Uzasadniając swoje stanowisko Zamawiający wskazał m. in.:

Specyfika systemów czasu rzeczywistego służących do monitorowania i określania stanów systemów przesyłowych elektroenergetycznych, nazywanych systemami SCADA/EMS (ang. Supervisory Control And Data Acquisition/Energy Management System), stanowiących podstawowe narzędzie wsparcia służb dyspozytorskich, wyraża się przede wszystkim w tym, że ich implementacja i wdrożenie następuje przez zapewnienie funkcjonalności wymaganych przez poszczególnych Operatorów Systemów Przesyłowych, które to funkcjonalności determinowane są specyfiką danego systemu elektroenergetycznego, w tym ograniczeniami sieci przesyłowej oraz strukturą, technologią i rozmieszczeniem źródeł wytwarzania. Konsekwencją powyższego stanu rzeczy jest to, że każde wdrożenie systemu SCADA/EMS ma indywidualny charakter.

Najpierw buduje się dedykowane funkcjonalności, a następnie rozwija się je adekwatnie do wymagań danego systemu elektroenergetycznego, w tym występujących w nim zjawisk fizycznych. Przekłada się to na fakt, że systemy te są wdrażane i parametryzowane latami w drodze ewolucyjnego rozwoju. Oznacza to, że nie ma dwóch takich samych wdrożeń systemów SCADA/EMS. Wiedza i doświadczenia zdobywane w czasie pracy z system są podstawowym elementem wpływającym na efektywność i prawidłowość wykorzystywania jego funkcji.

Powyższe zostało potwierdzone w toku przeprowadzonego dialogu technicznego. Unikatowość poszczególnych systemów i ich wdrożeń potwierdzała, że odejście od ewolucyjnego rozwoju systemu SCADA/EMS, jakim jest jego aktualizacja (upgrade), i zamiast tego podjęcie decyzji o wdrożeniu nowego rozwiązania informatycznego stanowiłoby istotną transformację kluczowego procesu związanego z zarządzaniem systemem elektroenergetycznym. Transformacja ta wiązałaby się powstaniem ryzyk, nie istniejących w przypadku ewolucyjnego rozwoju systemu, w tym ryzkiem braku prawidłowej implementacji w nowym systemie wymaganych przez Zamawiającego funkcjonalności. Skala tego ryzyka i skutki jego zmaterializowania powodowały, że ewentualna decyzja o takiej transformacji musiałaby opierać się na ewidentnych i kategorycznych przesłankach.

Przesłanki określenia przedmiotu zamówienia jako aktualizacji systemu DYSTER System DYSTER był przedmiotem dostaw i wdrożeń począwszy od roku 1990, a jego ostatnia modernizacja (aktualizacja) miała miejsce w latach 2006 - 2009 na postawie umowy zawartej Siemens Sp. z o.o., jako udzielenie zamówienia publicznego w trybie zamówienia z wolnej ręki na podstawie zgody Prezesa Urzędu Zamówień Publicznych (decyzja z 28 września 2005 r. znak: ZT/4074/05 - załącznik nr 1 do odpowiedzi na odwołanie). System działał w oparciu o oprogramowanie Spectrum, do którego prawa wyłączne przysługiwały wykonawcy Siemens.

System DYSTER jest podstawowym systemem informatycznym wykorzystywanym do wykonywania zadań Operatora Systemu Przesyłowego w zakresie zarządzania pracą Krajowego Systemu Elektroenergetycznego. Stanowił on system wspierający pracę służb dyspozytorskich Zamawiającego, niezbędny do prowadzenia ruchu sieciowego i zapewniania przesyłania energii elektrycznej. Z tego względu system DYSTER to kluczowy i krytyczny system informatyczny Zamawiającego.

Potrzeba modernizacji systemu DYSTER wyniknęła z konieczności wyposażenia służb dyspozytorskich w sprawdzony i niezawodny system informatyczny klasy SCADA/EMS, wspierający zarządzanie polską siecią elektroenergetyczną, który zapewniłby wymaganą funkcjonalność i poziom niezawodności, przy jednoczesnej możliwości wykorzystywania rozwijanych przez wiele lat kompetencji kluczowego personelu Zamawiającego. Potrzeba ta została wymuszona naturalnym postępem technik informatycznych, procedur cyberbezpieczeństwa oraz starzeniem się infrastruktury sprzętowo-systemowej.

Zamawiający przeprowadził w okresie 2018-2021 publiczny dialog techniczny w sprawie przygotowania postępowania o udzielenie zamówienia publicznego na dostawę i wdrożenie Nowego Systemu SCADA/EMS, w którym mógł wziąć udział każdy zainteresowany wykonawca.

Dialog techniczny miał na celu rozpoznanie rynku i zbadanie możliwości opracowania takiego opisu przedmiotu przyszłego zamówienia, który z jednej strony objąłby wszystkie wymagania Zamawiającego, przy zachowaniu płynności obsługi procesów biznesowych i kompatybilności z siecią pozostałych jego systemów, a z drugiej strony zapewniłby zachowanie konkurencji co do możliwości ubiegania się o takie zamówienie przez różnych dostawców.

Na podstawie informacji pozyskanych od uczestników dialogu technicznego, w którym wzięło udział pięciu wykonawców, ustalono, że pomiędzy systemami klasy SCADA/EMS różnych dostawców występują istotne różnice co do zakresu i sposobu spełnienia wymagań Zamawiającego. Stwierdzono przy tym, że rynek nie oferuje systemu zdolnego do pełnej obsługi aktualnych procesów biznesowych w zakresie funkcjonalności o krytycznym lub bardzo ważnym znaczeniu dla Zamawiającego, bez konieczności wykonania fundamentalnych zmian w oprogramowaniu aplikacyjnym oferowanych systemów, ich architekturze, logice działania lub modelu danych. Przy czym - co istotne - żaden z dostawców tych systemów nie był w stanie zagwarantować Zamawiającemu, że wdrożenie nowego systemu nie spowoduje przerwania płynności i zapewni pełną kompatybilność z obecnie użytkowanymi przez Zamawiającego innymi systemami. Powyższe wynikało z faktu, że wdrożenie nowego, tak złożonego systemu informatycznego byłoby obarczone immanentnym i trudno zarządzalnym ryzykiem. Ustalenie to nie odnosiło się do aktualizacji (upgrade'u) obecnie wykorzystywanego systemu DYSTER, działającego na bazie oprogramowania Spectrum.

W wyniku przeprowadzonego dialogu technicznego ustalono w szczególności, że systemy oferowane przez poszczególnych dostawców, mają własną, indywidualną (autorską) architekturę, zakres i sposób realizacji szczegółowych funkcjonalności, strukturę baz danych, a także sposób prezentacji obiektów i zdarzeń systemu elektroenergetycznego. Tym samym nie stanowiłyby produktów zamiennych w znaczeniu pełnej zastępowalności obsługi procesów biznesowych realizowanych lub wspieranych za ich pomocą. Każdy system realizuje je na własny sposób, i co do zasady nie byłoby możliwości ich zamiany bez istotnych zmian dostosowawczych w samym systemie, jak i jego otoczeniu informatycznym, tj. w systemach współpracujących.

Ustalenia dokonane w toku dialogu technicznego stanowiły dla Zamawiającego uzasadnioną podstawę do stwierdzenia, że nie istniało rozsądne rozwiązanie alternatywne lub zastępcze dla dokonania modernizacji systemu DYSTER przez wykonanie aktualizacji (upgrade) oprogramowania wykorzystywanego obecnie systemu.

Ustalenia przeprowadzonego dialogu technicznego stanowiły podstawę merytoryczną dla podjęcia przez Zamawiającego decyzji o aktualizacji (upgrade) oprogramowania wykorzystywanego obecnie systemu DYSTER. Jednocześnie stanowiły one podstawę do stwierdzenia, że brak było jakiegokolwiek uzasadnienia merytorycznego i biznesowego do podjęcia decyzji o zmianie istniejącego systemu DYSTER na inne rozwiązanie informatyczne pochodzące od nowego dostawcy.

Istota zarzutu Odwołującego sprowadzała się do oceny istnienia lub nieistnienia w realiach sprawy rozsądnego rozwiązania alternatywnego lub zastępczego w stosunku do aktualizacji oprogramowania systemu DYSTER. Odwołujący nie kwestionował zatem spełnienia przesłanki ochrony praw wyłącznych w stosunku do przedmiotu niniejszego zamówienia - ta okoliczność wobec jasnego brzmienia art. 1 ust. 2 pkt 1 Prawa autorskiego była bezsprzeczna ale kwestionował przedmiot zamówienia określony przez Zamawiającego - twierdził, że Zamawiający zamiast modernizacji systemu DYSTER powinien dokonać zakupu nowego systemu.

Pzp nie określiło szczegółowych kryteriów, według których należy dokonywać oceny istnienia rozwiązań alternatywnych lub zastępczych. Tym samym istnieje otwarty katalog przypadków, których ocena i kwalifikacja mogła być dokonywana indywidualnie z uwzględnieniem wszystkich istotnych okoliczności odnoszących się do stanu faktycznego danego zamówienia. Posłużenie się przez ustawodawcę kryterium „rozsądnego” rozwiązania alternatywnego lub zastępczego oznacza, że dokonywana w tym zakresie ocena powinna odnosić się do stwierdzenia czy według racjonalnych i merytorycznych przesłanek można uznać, że istnieje równoważna możliwość zrealizowania tej samej potrzeby zamawiającego przy zastosowaniu innych rozwiązań, aniżeli oferowanych przez wykonawcę wyłącznego. Przy czym zasadniczym punktem odniesienia dla powyższej oceny była potrzeba zamawiającego rozumiana jako konkretna potrzeba biznesowa związana z działalnością danego zamawiającego lub wypełnianymi przez niego zadaniami.

Funkcjonalności określone przez Zamawiającego, które musi posiadać zamawiany system, stanowiły zbiór będący efektem doświadczeń zgromadzonych przez lata pracy służb dyspozytorskich, prowadzących ruch sieciowy, identyfikujących i eliminujących zagrożenia pracy sieci oraz podejmujących środki zaradcze na przyszłość. Nie były to zatem wymagania będące wyrazem subiektywnych oczekiwań Zamawiającego, ale obiektywnych potrzeb związanych z zarządzaniem pracą Krajowego Systemu Elektroenergetycznego. Tym samym całkowicie uzasadnionym było wymaganie, aby funkcjonalności istniejące już w systemie DYSTER i rozwijane w ciągu całego okresu użytkowania tego systemu, były utrzymane w ramach modernizacji tego systemu. Wobec powyższego określenie tych wymagań nie mogło być w żadnym razie oceniane jako zawężenie parametrów zamówienia w rozumieniu art. 214 ust. 1 pkt 1 Pzp.

Ewolucyjne podejście do zakresu i warunków modernizacji systemu DYSTER było uzasadnione krytycznym znaczeniem i charakterem tego systemu dla zarządzania pracą KSE w czasie rzeczywistym. Tym samym kluczowym wymaganiem niezbędnym dla zapewnienia niezakłóconej pracy modernizowanego systemu oraz niezakłóconego funkcjonowania obsługiwanych przez niego procesów było zachowanie dotychczasowej architektury systemu i leżącej u jej podstaw

koncepcji (filozofii) jej budowy. Zmiana architektury systemu stworzyłaby bowiem po stronie Zamawiającego istotne ryzyko zakłóceń działania nowego systemu.

Najważniejszymi elementami architektonicznymi systemu, których zachowanie było wymagane dla zapewnienia niezakłóconej obsługi procesów były:

1. koncepcja alokacji bloków funkcjonalnych na serwery fizyczne, której znajomość pozwalałaby Zamawiającemu czynnie partycypować w optymalnym doborze architektury sprzętowej,
2. koncepcja redundancji systemu umożliwiająca elastyczne przełączanie bloków funkcjonalnych; operacje takie były kilkukrotnie już wykonywane przez Zamawiającego, zatem nie determinując z góry ostatecznie przyjętych sposobów włączenia nowego systemu do eksploatacji, znajomość koncepcji i podstawowych technik pozwala mu kontrolować kluczowe procesy przełączania,
3. mechanizmy dystrybucji danych między procesami w systemie (wewnętrzna szyna transmisji danych softbus) oraz zasady komunikacji międzyprocesowej, której znajomość miała kluczowe znaczenie w diagnostyce systemu oraz dawała maksymalną elastyczność, możliwość szybkiej i automatycznej reakcji na awarie,
4. koncepcja modeli informatycznych systemu elektroenergetycznego dla poszczególnych bloków funkcjonalnych (model łącznikowo-szynowy SCADA, model gałęziowo-węzłowy aplikacji sieciowych EMS, model danych źródłowych, model danych historycznych), ich koordynacja i metody utrzymywania spójności i ciągłości w czasie,
5. koncepcja i hierarchia identyfikacji obiektów w modelu informatycznym sieci elektroenergetycznej.

Zmiana tej koncepcji skutkowałaby koniecznością zmiany procedur działania oraz nawyków użytkowników (w szczególności dyspozytorów) oraz mapowania/konwersji obiektów we wszystkich interfejsach używających aktualnej konwencji nazw.

Podstawowym warunkiem prawidłowego i efektywnego wykorzystania systemu SCADA/EMS, a zarazem wykonywania zadań, do których jest on przeznaczony są unikatowe kwalifikacje kluczowego personelu operatora, który musi mieć umiejętności i doświadczenie w zakresie wykorzystywania funkcji systemu, utrzymania systemu oraz rozwoju systemu.

W wyniku przeprowadzonego dialogu technicznego Zamawiający ustalił w szczególności, że:

1. na rynku istnieją różne systemy klasy SCADA/EMS, oferowane przez różnych wykonawców, a tym samym istnieją rozwiązania informatyczne dające potencjalną możliwość wymiany danego systemu tej klasy i zastąpienia go całkowicie nowym, innym systemem klasy SCADA/EMS;
2. każdy system klasy SCADA/EMS jest inny pod względem przyjętych rozwiązań w zakresie architektury systemu, szczegółowych funkcji, sposobu ich realizacji, układu baz danych, sposobu prezentacji obiektów i zdarzeń systemu, co decyduje o niepowtarzalności i unikatowości każdego z systemów klasy SCADA/EMS;
3. każdy system klasy SCADA/EMS posiada własną koncepcję modeli danych, ich hierarchię oraz stosowane nazewnictwo, a przez to do migracji danych z systemu innego wykonawcy muszą być tworzone, jednorazowo i specyficznie dla danego rozwiązania, dedykowane procedury migracji danych, przy czym nie jest możliwe zagwarantowanie pełnego zautomatyzowania migracji;
4. rozwój tak złożonych systemów czasu rzeczywistego, jak systemy klasy SCADA/EMS ma charakter ewolucyjny, prowadzony jest przez cały szereg prac rozwojowych, polegających na szczegółowej identyfikacji wymaganej funkcjonalności, implementacji rozwiązania oraz testów w środowiskach deweloperskich, w ramach których poszukuje, bada się i wdraża takie rozwiązania, które dają pewność działania i wyników;
5. rozwój tych systemów jest dokonywany w związku z potrzebami klientów użytkujących te systemy, tym samym ich rozwój jest podporządkowany potrzebom korzystających z nich operatorów oraz specyfice funkcjonowania danego systemu elektroenergetycznego;
6. pomiędzy systemami klasy SCADA/EMS występują istotne różnice co do zakresu spełnienia wymagań Zamawiającego, przy czym w chwili obecnej rynek nie oferuje systemu klasy SCADA/EMS zdolnego do pełnej obsługi obecnych procesów biznesowych Zamawiającego, w tym w zakresie tych funkcjonalności, mających priorytet krytyczny lub bardzo ważny, które są dostępne w ramach dedykowanych rozszerzeń aktualnie wykorzystywanego systemu DYSTER;
7. spełnienie wymaganych funkcjonalności nie mogłoby nastąpić bez wykonania, w różnym zakresie w odniesieniu do poszczególnych dostawców, modyfikacji oferowanych systemów;
8. ewentualnie możliwe do wykonania modyfikacje, polegające na dostosowaniu dostępnych na rynku systemów klasy SCADA/EMS do ww. wymagań PSE (o priorytecie krytycznym lub bardzo ważnym), wymagałyby dokonania istotnych zmian w architekturze i logice tych systemów oraz modelu danych, które w zależności od wybranego rozwiązania, obejmowałyby w szczególności w zakresie funkcjonalności wymagających zmian w architekturze lub logice systemów; 9.

dokonanie koniecznych modyfikacji - z uwagi na ich złożoność oraz stopień i zakres

ingerencji w istniejące rozwiązanie informatyczne - nie gwarantowałoby uzyskania pozytywnego rezultatu, tj. że nowy system będzie w stanie efektywnie zastąpić istniejący system DYSTER we wszystkich aspektach jego kluczowych, bezwzględnie wymaganych, funkcjonalności.

Stwierdzony w toku dialogu technicznego brak posiadania przez nowe rozwiązania informatyczne klasy SCADA/EMS pełnych wymaganych funkcjonalności w porównaniu do wykorzystywanego obecnie systemu DYSTER, oznaczał, że implementacja szczegółowych wymagań określonych przez Zamawiającego wiązałaby się z koniecznością dokonania w nowych systemach tzw. rozszerzeń, co wymagałoby w przypadku poszczególnych dostawców nowych rozwiązań informatycznych, odpowiednio:

1. zmiany architektury oraz filozofii systemu pozwalającej na jednoczesne operatywne zarządzanie systemem (wraz ze zdalnym sterowaniem) z obu niezależnie działających oraz w pełni funkcjonalnych instalacji systemu SCADA/EMS, tzw. funkcjonalności Multisite w trybie Active-Active,
2. zmiany architektury systemu pozwalającej na bezprzerwowe wprowadzanie zmian w modelu elektroenergetycznym oraz interfejsie użytkownika bez konieczności restartu komponentów systemu,
3. odpowiedniej implementacji algorytmu wyznaczenia funkcji obciążalności linii elektroenergetycznych zależnej od temperatury oraz wykorzystanie tych charakterystyk do wyznaczania chwilowej obciążalności linii,
4. dostosowania/rozszerzenia/przebudowy szczegółowych funkcjonalności systemu, w tym modelowanie transformatorów ze złożoną regulacją przekładni, pozwalających na jednoczesną zmianę modułu i kąta przekładni pod obciążeniem, modelowanie zmostkowanych zaczepów transformatora, 5.

dostosowania/rozbudowy interfejsu użytkownika (GUI),

1. dostosowania/konfiguracji systemu do funkcjonalności wymaganych przez Zamawiającego,
2. dostosowania hierarchii elementów (obiektów) systemu elektroenergetycznego oraz związanego z tym nowego sposobu ich kodowania,
3. dostosowania/rozbudowy/rozszerzenia modelu sieci elektroenergetycznej, algorytmów obliczeniowych oraz funkcjonalności systemu,
4. implementacji dedykowanych rozszerzeń wynikających ze specyfiki polskiego modelu sieci elektroenergetycznej (m.in.: obsługa wymiany danych planistycznych w zakresie m.in. rejestru wyłączeń, planu wymiany międzysystemowej, generacji jednostek wytwórczych i odbiorów, generacji farm wiatrowych, generacji fotowoltaiki i jednostek szczytowo-pompowych, zasilanie aplikacji zewnętrznych wynikami Estymatora Stanu oraz Rozpływu Mocy w formacie EPC, (podział jednostek wytwórczych na grupy zgodnie z kwalifikacją wynikającą z rozporządzenia Komisji (UE) 2016/631 z 14 kwietnia 2016 r. ustanawiającego kodeks sieci dotyczący wymogów w zakresie przyłączenia jednostek wytwórczych do sieci i oraz ze względu na technologię wytwarzania energii elektrycznej (cieplne, wodne, fotowoltaika, wiatrowe)), 10.

zaimplementowania polskiej normy dotyczącej obliczeń zwarciowych PN-EN 60909,

1. wdrożenia pełnej obsługi redundantnych źródeł danych pozwalającej na pozyskiwanie i przetwarzanie w czasie rzeczywistym informacji o stanie systemu elektroenergetycznego z czterech różnych źródeł (np. telemechaniki stacyjnej, systemów SCADA/EMS innych operatorów systemów przesyłowych oraz operatorów systemów dystrybucyjnych), przebudowy systemu w zakresie jednego, wspólnego modelu systemu na potrzeby całego systemu SCADA/EMS.

Ustalenia dokonane w toku dialogu technicznego wykazały, że jakkolwiek istnieją na rynku inne rozwiązania informatyczne klasy SCADA/EMS, to jednak nie stwarzają one możliwości ewolucyjnego rozwoju funkcjonalności dotychczas wykorzystywanego systemu, dając wyłącznie możliwość zastąpienia obecnego systemu całkowicie nowym rozwiązaniem informatycznym.

Kluczowym wymaganiem niezbędnym dla zapewnienia niezakłóconej pracy modernizowanego systemu oraz niezakłóconego funkcjonowania obsługiwanych przez niego procesów jest zachowanie dotychczasowej architektury systemu i leżącej u jej podstaw koncepcji (filozofii) jej budowy. Zmiana architektury systemu stworzy bowiem po stronie OSP istotne ryzyko zakłóceń działania nowego systemu w powiązaniu z realizowanymi procesami biznesowymi oraz otoczeniem informatycznym.

Poza koniecznością dokonania istotnych modyfikacji w przypadku implementacji wymaganych funkcjonalności do nowego rozwiązania informatycznego, zastąpienie istniejącego systemu DYSTER zupełnie nowym, innym systemem, oznaczałoby ponowne wykonanie funkcjonalności i rozszerzeń istniejących już - w dostosowanym do potrzeb Zamawiającego - systemie DYSTER.

Tym samym konieczne byłoby stworzenie tych funkcjonalności na nowo, bez możliwości wykorzystania istniejących już rozwiązań i zaimplementowanych w systemie DYSTER. Powyższe nie dotyczy wyboru modernizacji systemu w formie aktualizacji oprogramowania systemu DYSTER.

W przypadku wdrożenia nowego systemu klasy SCADA/EMS konieczne będzie również przeprowadzenie ponownych prac dostosowawczych w innych systemach informatycznych wykorzystywanych przez Zamawiającego, współpracujących obecnie z systemem DYSTER.

Wskazane powyżej okoliczności nie zaistnieją w przypadku aktualizacji oprogramowania obecnie wykorzystywanego systemu DYSTER.

Poza kwestią zachowania koncepcji (filozofii) i architektury systemu, kluczowe znaczenie dla dokonania aktualizacji obecnie wykorzystywanego systemu DYSTER, w stosunku do wdrażania całkowicie nowego systemu, będą miały następujące uwarunkowania:

1. Zachowanie spójności i ciągłości konfiguracji systemu, przez wymóg migracji danych. Tylko aktualizacja obecnego systemu da możliwość wykorzystania automatycznych procedur migracyjnych, wykorzystywanych rutynowo przez dostawcę rozwiązania. W przypadku zmiany dostawcy procedury te musiałyby być tworzone jednorazowo i specyficznie dla obecnego rozwiązania, a ich pełna automatyzacja byłaby niemożliwa z uwagi na brak knowhow dostawcy nowego rozwiązania o rozwiązaniu innego (aktualnego) producenta, a także z powodu różnic architektury i struktur baz danych różnych rozwiązań. Powyższe wiązałoby się z ryzykiem błędów migracji oraz negatywnych ich skutków.
2. Zapewnienie poprawności oraz kompletności pozyskiwanych danych czasu rzeczywistego w związku z koniecznością ich migracji. Tylko aktualizacja obecnego systemu pozwoli na zachowanie pełnej zgodności zaimplementowanych protokołów komunikacyjnych stosowanych przy wymianie danych czasu rzeczywistego, co pozwoli na sprawne przełączenie urządzeń stacyjnych oraz innych systemów SCADA/EMS operatorów europejskich TSO oraz krajowych OSD. W przypadku wdrożenia rozwiązania innego dostawcy konieczne byłoby przeprowadzenie testów zdalnego sterowania każdego obiektu (tzw. testy punkt-punkt), które to z uwagi na ograniczone możliwości wyłączeń stacyjnych musiałyby zostać przeprowadzone z wykorzystaniem dedykowanego oprogramowania porównującego składnię protokołów. Z uwagi na szeroki zakres testów oraz możliwe różnice implementacyjne w wykorzystywanych protokołach komunikacyjnych istniałoby ryzyko opóźnień w projekcie, konieczność bardzo dużego zaangażowanie zasobów po stronie Zamawiającego, a w przypadku konieczności rekonfiguracji urządzeń stacyjnych dodatkowych nakładów finansowych.
3. Zachowanie istniejącej funkcjonalności oraz interfejsu użytkownika. Każdy system SCADA/EMS jest unikatowy, a jego funkcje o tej samej nazwie pochodzące od różnych dostawców są nieporównywalne bez przeprowadzenia ich szczegółowej analizy technicznej. Tylko aktualizacja obecnego systemu DYSTER zapewnia jego ewolucyjny rozwój bez utraty już istniejących funkcjonalności sprawdzonych w toku dotychczasowej eksploatacji systemu przez różnych użytkowników.
4. Uniknięcie konieczności ponownego strojenia modelu matematycznego. Procedura strojenia Estymatora Stanu systemu jest wymagana do zapewnienia powtarzalnego uzyskiwania przez estymator poprawnego merytorycznie i wiarygodnego (tj. maksymalnie bliskiego stanowi rzeczywistemu) modelu pracy systemu elektroenergetycznego na potrzeby analiz bezpieczeństwa pracy. Tylko aktualizacja obecnego systemu DYSTER pozwoli na uniknięcie konieczności ponownego strojenia Estymatora Stanu krajowej sieci elektroenergetycznej oraz ponownego dostosowywania systemu klasy SCADA/EMS do parametrów KSE.
5. Ponowna implementacja rozwiązań specyficznych dla Zamawiającego. Tylko w przypadku wykonania aktualizacji obecnego systemu DYSTER nie będzie konieczności ponownej

identyfikacji i definiowania rozwiązań systemu stworzonych już na potrzeby Zamawiającego (tzw. rozszerzeń). Najważniejsze z nich to: obsługa wymiany danych planistycznych, zasilanie aplikacji zewnętrznych wynikami Estymatora Stanu oraz Rozpływu Mocy w formacie EPC, obliczenia zwarciowe zgodnie z polską normą, obsługa temperaturowych charakterystyk linii, grupowanie jednostek wytwórczych, obsługa wizualizacji i sterowania automatyki ARNE i ARST.

Poza aspektem zaangażowania personelu Zamawiającego we wdrożenie nowego systemu na etapie projektowania rozwiązania, jaki i jego testowania, istotna będzie również kwestia zachowania doświadczeń służb dyspozytorskich w korzystaniu z obecnego systemu DYSTER oraz zagrożeń wynikających w tym zakresie ze zmiany systemu wsparcia dyspozytorskiego, jak również kwestia możliwości wykorzystania doświadczenia personelu Zamawiającego w samodzielnej obsłudze tego systemu. W tym zakresie podstawowe znaczenie będzie miało doświadczenie służb dyspozytorskich w korzystaniu z dotychczasowych funkcji systemu DYSTER, procedur i sposobów ich realizacji oraz graficznych interfejsów użytkownika (GUI).

Przełoży się to bowiem w sposób bezpośredni na jakość i prawidłowość decyzji operatorskich podejmowanych przy wykorzystaniu systemu, jak i na bazie generowanych przez niego raportów.

Tylko pełne rozumienie funkcji tego systemu i wzajemnych zależności pomiędzy nimi pozwoli przewidzieć konsekwencje podejmowanych decyzji ludzkich. Tylko rozumiejąc skutki podejmowanych decyzji dla prowadzenia ruchu KSE dyspozytor może podejmować prawidłowe decyzje. Należy bowiem mieć na uwadze to, że zobrazowanie stanu systemu przy pomocy grafiki i danych liczbowych wyświetlanych na stanowiskach roboczych dyspozytorów stanowi tylko model stanu rzeczywistego systemu elektroenergetycznego, a zatem jedynie jego przybliżenie. Żeby rozumieć konsekwencje decyzji, trzeba wiedzieć, jak ten model powstał. W konsekwencji wdrożenie nowego systemu będzie oznaczało, że przez długi czas od wdrożenia nowego rozwiązania, decyzje dyspozytorów mogą być obciążone błędami wynikającymi z działania w oparciu o stare przyzwyczajenia. Stanowiłoby to istotne ryzyko popełnienia błędu ludzkiego, prowadzącego do zakłóceń działania systemu elektroenergetycznego.

Zastąpienie istniejącego systemu DYSTER zupełnie nowym, innym systemem i związane z tym prace dostosowawcze w innych systemach Zamawiającego, ponowne wykonanie rozszerzeń oraz zaangażowanie personelu Zamawiającego, wiązałoby się - poza samym dodatkowym istotnym nakładem pracy personelu - również z dodatkowym nakładem znaczących środków finansowych po stronie Zamawiającego (rząd wielkości ok. 10 mln zł).

W przypadku wymiany istniejącego systemu DYSTER na zupełnie nowy system klasy SCADA/EMS, opisane powyżej doświadczenia oraz kompetencje personelu Zamawiającego zostałyby utracone, albowiem nie miałyby przełożenia na nowe rozwiązanie informatyczne.

Powyższe nie może zostać uznane za korzystne rozwiązanie dla Zamawiającego.

O ile zmiany w systemach uczestników dialogu jak podniósł Odwołujący w odwołaniu byłyby możliwe, a co nie zostało jednoznacznie potwierdzone w toku dialogu, nie byłyby możliwe do implementacji w ramach typowego projektu wdrożeniowego. Ich zakres, złożoność oraz stopień ingerencji w bazowe rozwiązanie uczestnika dialogu, wykluczał z przyczyn czysto technicznych możliwość poprawnego wdrożenia wszystkich wymaganych modyfikacji w celu spełnienia wymagań Zamawiającego, bez zapewnienia odpowiednio długiego czasu na projektowanie rozwiązania i jego weryfikację w ramach uruchomienia testowego.

25 października 2021 r. w toku posiedzenia niejawnego z udziałem stron Zamawiający wniósł o przeprowadzenie dowodów z następujących dokumentów:

1. Dokument dotyczący praw autorskich do oprogramowania Spectrum - Oświadczenie właściciela praw autorskich do Oprogramowania Spectrum PL (dowód nr 14).

2.

Oświadczenie integratora oprogramowania (dowód nr 15).

1. Załącznik 26 do Umowy na rozbudowę (upgrade) sytemu sterowania dyspozytorskiego DYSTER w KDM i ODM o funkcjonalność Multisite - wzór umowy licencyjnej na oprogramowanie Siemens (dowód nr 16).
2. Wniosek z 22 sierpnia 2005 r. skierowany do Prezesa UZP do wyrażenie zgody na udzielenie zamówienia w trybie z wolnej ręki przy udzieleniu zamówienia na rozbudowę (upgrade) systemu sterowania dyspozytorskiego DYSTER w KDM i ODM o funkcjonalność Multisite (dowód nr 17).

25 października 2021 r. wykonawca Siemens Sp. z o.o. z siedzibą w Warszawie (dalej:

Przystępujący Siemens lub Siemens) złożył pismo procesowe, w którym ustosunkował się do zarzutów odwołania. Przystępujący poparł stanowisko Zamawiającego i wniósł o oddalenie odwołania. W uzasadnieniu swojego stanowiska Przystępujący Siemens wskazał:

Argumentacja odwołania w dużej (zasadniczej) mierze skupiała się na rzekomo wadliwie, zdefiniowanym przez Zamawiającego przedmiocie zamówienia. Koronnym argumentem mającym przemawiać za jego zasadnością było, zdaniem Odwołującego to, że przedmiot postępowania stanowić miał w istocie zakup nowego systemu (a nie jego aktualizację).

Przystępujący Siemens podkreślił różnicę pomiędzy nowym, a unowocześnionym systemem.

W przypadku nowego systemu trzeba zaprojektować od nowa sposób implementacji istniejących funkcji użytkowo-biznesowych. Do takiej sytuacji nie dojdzie w przypadku aktualizacji/modernizacji istniejącego systemu - polegać to bowiem będzie na powtórzeniu (więc nie zaprojektowaniu w celu ich implementacji) funkcji użytkowo-biznesowych.

Aktualizacja/modernizacja/dostosowanie polegać więc będzie na zastosowaniu starych technologii informatycznych nowymi. W przypadku systemu DYSTER, który został wdrożony przez Siemens, sposób implementacji został zaprojektowany w ramach projektu pierwszego wdrożenia oraz kolejnych rozszerzeń funkcjonalności na przestrzeni okresu użytkowania obecnego systemu. Komponenty są w procesie rozwoju oprogramowania z czasem unowocześniane, tj. stosuje się nowsze technologie informatyczne, ale nie zmienia się ich funkcji użytkowo-biznesowych, koncepcji architektonicznej i sposobów powiązań z innymi komponentami (te procesy mają miejsce jedynie w przypadku implementacji nowego systemu).

Ponadto aktualizacja opisana przez Zamawiającego w postępowaniu nie oznaczała dostosowania rozwiązania do nowych potrzeb, ale realizację niezmienionych potrzeb Zamawiającego w oparciu o nowe technologie informatyczne zastosowane, co do zasady, na podstawie tych samych komponentów.

Twierdzenie, że zmodernizowany system systemem zbudowanym na nowo było bezpodstawne.

Każdy moduł (komponent) oprogramowania zainstalowanego u Zamawiającego będzie dostępny w zmodernizowanej wersji (Spectrum 7) uwzględniającej najnowsze technologie i wymagania bezpieczeństwa. Rozszerzenia funkcjonalne specyficzne dla Zamawiającego są zewidencjonowane i dostępne w systemach zarządzania kodem źródłowym dostawcy, ich aktualizacja nie wymagać będzie prac projektowych, a jedynie ponownej kompilacji i ewentualnej adaptacji.

Zgodnie z koncepcją środowisk przedstawioną przez Zamawiającego, instalowane w nich systemy powinny być swoimi funkcjonalnymi i technicznymi kopiami utrzymywanymi ze względu na bezpieczeństwo eksploatacji systemu (np. możliwości testów po zmianach bazy lub oprogramowania w trakcie normalnej eksploatacji). Niezbędny zakres prac projektowych ograniczy się więc do konfiguracji modułów w celu zapewnienia wymiany danych między środowiskami i uwzględnienia niektórych różnic między nimi wynikających z zadań środowiska.

Odwołanie zbudowane zostało na błędnej i, nieuzasadnionej w świetle okoliczności mających miejsce w postępowaniu, tezie, zgodnie z którą przedmiotem postępowania było zaprojektowanie i wdrożenie nowego systemu DYSTER. Konsekwencją przyjęcia takiego założenia było poszukiwanie przez Odwołującego w treści odwołania odpowiedzi na pytanie o rozwiązania alternatywne względem przedmiotu zamówienia (nowy system), którego Zamawiający nie zlecił.

Już z tego powodu odwołanie powinno zostać oddalone.

Zamawiający podjął kroki niezbędne do zweryfikowania, czy decyzja o aktualizacji (zamiast zakupu nowego systemu) była decyzją słuszną. Przywołanie argumentów odnoszących się do dialogu technicznego było istotne tym bardziej, że płynęły z niego wnioski mające znaczenie również w kontekście oceny prawidłowości zastosowania trybu z wolnej ręki w odniesieniu do aktualizacji systemu DYSTER.

Nie sposób zgodzić się, że w oparciu o informacje dotyczące dialogu technicznego uznać można było, że „Zamawiający posiada już przygotowaną dokumentację, aby wszcząć postępowanie w trybie konkurencyjnym na zakup systemu” (pkt 13 odwołania). Przeczą temu informacje z protokołu, z których wynikało, że celem dialogu było pozyskanie wiedzy i informacji niezbędnych do przeprowadzenia takiego postępowania. Cel dialogu był również zgodny z art.

31a ust. 1 ustawy z 29 stycznia 2004 r. Prawo zamówień publicznych (w oparciu o którą prowadzony był dialog techniczny), który stanowił, że celem dialogu jest doradztwo lub udzielenie informacji w zakresie niezbędnym do przygotowania opisu przedmiotu zamówienia, specyfikacji istotnych warunków zamówienia lub określenia warunków umowy.

Wnioski Zamawiającego z przeprowadzonego dialogu były jednoznacznie sprzeczne ze stanowiskiem Odwołującego, co do zasadności wdrożenia nowego zamiast aktualizacji dotychczasowego systemu.

W toku postępowania, przed otwarciem rozprawy Odwołujący, Zamawiający oraz Przystępujący złożyli kolejne pisma procesowe wraz z dowodami, w których podtrzymali i rozszerzyli zaprezentowaną wyżej argumentację.

W toku posiedzenia niejawnego z udziałem stron 10 listopada 2021 r. Przystępujący Emerson wniósł o przeprowadzenie dowodu z następujących dokumentów:

1. Ogłoszenie o dobrowolnej przejrzystości ex ante 2018/S242-553651 na okoliczność wykazania, że wersja oprogramowania Spectrum 3 uprzednio nazywała się Sinaut (dowód nr 26).
2. Wydruk ze strony internetowej Siemens wraz z tłumaczeniem na okoliczność wykazania, że oprogramowanie Spectrum Power 3, 4, 5 i 7 stanowiły odrębne produkty (dowód nr 27).
3. Wydruk ze strony internetowej HydroQuebec na okoliczność wykazania stopnia, w jakim rozbudowany jest system przesyłowy w Ameryce Północnej obsługiwany przez OSI, który wchodzi w skład grupy Emerson (dowód nr 28).
4. Referencje wystawione na OSI potwierdzające, że podmiot ten realizuje zadanie analogiczne do zadania będącego przedmiotem zamówienia (dowód nr 29, objęty tajemnicą przedsiębiorstwa).

Istotny charakter dla ustalenia i oceny stanu faktycznego miały przy tym dowody złożone 9 listopada 2021 r. przez Przystępującego Siemens wraz z pismem procesowym:

1. Opinia prywatna z 9 listopada 2021 r. wykonana na zlecenie Przystępującego Siemens dotycząca charakteru przedmiotu zamówienia wraz z objętymi tajemnicą przedsiębiorstwa załącznikami:
2. Opis zmian dokonanych w poszczególnych modułach oprogramowania Spectrum między wersjami 3.9 i 7.2,
3. Porównanie plików wykonywalnych i architektury plików instalacyjnych systemów Spectrum 3 i Spectrum 7.

Po przeprowadzeniu rozprawy Izba, uwzględniając dokumentację postępowania o udzielenie zamówienia publicznego, w tym w szczególności treść opisu przedmiotu zamówienia, jak również biorąc pod uwagę oświadczenia i stanowiska stron i Przystępujących zawarte w odwołaniu, odpowiedzi na odwołanie oraz pismach procesowych a także wyrażone ustnie na rozprawie i odnotowane w protokole, ustaliła i zważyła, co następuje.

Izba stwierdziła, że nie została wypełniona żadna z przesłanek ustawowych skutkujących odrzuceniem odwołania, wynikających z art. 528 Pzp.

Przystępując do rozpoznania odwołania, Izba ustaliła wystąpienie przesłanek z art. 505 ust.

1 Pzp, tj. istnienie po stronie Odwołującego interesu w uzyskaniu zamówienia oraz możliwości poniesienia przez niego szkody w wyniku kwestionowanych czynności zamawiającego.

Izba ustaliła, że do postępowania odwoławczego skuteczne przystąpienie zgłosili:

1. Emerson Process Management Sp. z o.o. z siedzibą w Warszawie po stronie Odwołującego,
2. Mikronika Sp. z o.o. z siedzibą w Poznaniu po stronie Odwołującego,
3. Siemens Sp. z o.o. z siedzibą w Warszawie po stronie Zamawiającego.

Rozpoznając odwołanie Izba przeprowadziła postępowanie dowodowe ze wszystkich wymienionych wyżej dowodów (o numerach o 1 do 29), a także ze wszystkich niewymienionych osobno dokumentów stanowiących załączniki do pism procesowych złożonych przez strony i uczestników w toku postępowania. Ponadto Izba przeprowadziła dowód z dokumentacji postępowania oraz z dokumentacji dotyczącej dialogu technicznego

przekazanej 2 listopada 2021 r. przez Zamawiającego w zakresie zgodnym z wnioskiem Odwołującego z 25 października 2021 r.

Izba na podstawie art. 541 Pzp oddaliła wniosek o powołanie biegłego w przedmiocie oceny czy rozwiązaniem alternatywnym/zastępczym w stosunku do aktualizacji bieżącego systemu DYSTER jest zakup nowego systemu SCADA/EMS, który będzie spełniał tożsame wymagania Zamawiającego określone w opisie przedmiotu zamówienia oraz w przedmiocie czy aktualizacja (upgrade) istniejącego oprogramowania podsystemów SCADA oraz EMS Systemu DYSTER jest de facto zaprojektowaniem i wdrożeniem nowego systemu zamiast aktualizacji. W ocenie Izby zgromadzony przeprowadzenie ww. dowodu jest zbędne i prowadzi jedynie do przewlekłości postępowania odwoławczego, bowiem materiał dowodowy w pełni pozwalał na dokonanie należytej i prawidłowej oceny ww. okoliczności mającej być przedmiotem dowodu.

Mając na uwadze powyższe Izba merytorycznie rozpoznała złożone odwołanie, uznając, że nie zasługuje ono na uwzględnienie.

Izba ustaliła co następuje:

24 września 2021 r. Zamawiający skierował do Przystępującego Siemens zaproszenie do negocjacji w postępowaniu w trybie z wolnej ręki pn. „Aktualizacja (upgrade) oprogramowania podsystemów SCADA oraz EMS Systemu DYSTER”. Jako podstawę prawną przyjętego trybu zamówienia Zamawiający wskazał art. 388 pkt 1 w związku z art.

214 ust. 1 pkt 1 lit. a i b Pzp.

W treści zaproszenia Zamawiający wskazał m. in.:

„II. Przedmiotem negocjacji będą postanowienia umowy, która zostanie zawarta po przeprowadzeniu niniejszego postępowania, szczegółowy zakres i sposób realizacji przedmiotu zamówienia oraz cena.

III. Rozpoczynając proces negocjacji, zwracamy się do Państwa z prośbą o przekazanie do dnia 25.10.2021 r. na Platformie zakupowej oferty wstępnej. Wzór formularza oferty wstępnej zawarty jest w załączniku nr 6 do zaproszenia do negocjacji. Do formularza oferty wstępnej Wykonawca powinien załączyć:

1. propozycję formuły realizacyjnej przedmiotu zamówienia z podziałem na etapy i zadania, zarówno o charakterze technicznym, jak i zarządczym, wg której możliwe jest wykonanie przedmiotu zamówienia w harmonogramie wynoszącym 24 (słownie: dwadzieścia cztery) miesiące od daty zawarcia umowy;
2. uwagi do projektu umowy załączonej do zaproszenia do negocjacji, w postaci zaproponowanych przez Wykonawcę konkretnych postanowień umowy, które w ocenie Wykonawcy powinny zostać wprowadzone do treści zawieranej umowy, dla proponowanej przez Wykonawcę formuły realizacyjnej wykonania przedmiotu umowy;
3. propozycję wstępnej ceny za przedmiot zamówienia wraz ze sposobem jej wyliczenia;
4. listę modułów oprogramowania Spectrum 7.2 zastępujących moduły oprogramowania Spectrum 3.9. wraz z niezbędnym opisem identyfikującym

poszczególne moduły w postaci np. fragmentów Functional Specification w języku polskim;

1. listę rozszerzeń oprogramowania Spectrum 7.2 niezbędnych do pełnego i poprawnego wykonania przedmiotu zamówienia”.

Załącznikiem nr 1 do zaproszenia był OPZ, w którym Zamawiający wskazał:

„Na przedmiot Zamówienia składają się następujące obowiązki Wykonawcy:

• określenie wymagań i przygotowanie specyfikacji dla platformy sprzętowo-

programowej oraz sieci teleinformatycznej przeznaczonej dla niezawodnego i prawidłowego działania Oprogramowania Spectrum 7.2. z uwzględnieniem wymagań bezpieczeństwa obowiązujących u Zamawiającego, - aktualizacja oraz konfiguracja Zmodernizowanego Systemu DYSTER opartego

na Oprogramowaniu Spectrum 7.2 w środowisku informatycznym Wykonawcy, w tym aktualizacja oprogramowania, które nie stanowiło rozwiązania podstawowego, a które zostało wdrożone w Systemie DYSTER w ramach tzw. rozszerzeń Oprogramowania w wersji 3.9, wynikających ze specyficznych wymagań funkcjonalnych Zamawiającego, - migracja danych z obecnie eksploatowanego Systemu DYSTER

do Zmodernizowanego Systemu DYSTER na potrzeby Testów FAT, SAT oraz na potrzeby uruchomienia produkcyjnego, - opracowanie dokumentacji testowej oraz wykonanie Testów PRE-FAT oraz Testów

FAT, - przeniesienie odpowiednich praw własności intelektualnej, - uruchomienie skonfigurowanego Oprogramowania Spectrum 7.2 na wymaganych

przez Zamawiającego Środowiskach Zmodernizowanego Systemu DYSTER w infrastrukturze Zamawiającego oraz uruchomienie interfejsów z innymi Systemami Zamawiającego, w tym aktualizacja oprogramowania, które nie stanowiło rozwiązania podstawowego, a które zostało wdrożone w Systemie DYSTER w ramach tzw. rozszerzeń Oprogramowania w wersji 3.9, wynikających ze specyficznych wymagań funkcjonalnych Zamawiającego, - przeprowadzenie Testów SAT sprawdzających poprawność działania

Zmodernizowanego Systemu DYSTER, - uruchomienie produkcyjne Zmodernizowanego Systemu DYSTER, - świadczenie usług serwisu pogwarancyjnego po upływie rękojmi i gwarancji.

Wykonawca jest zobowiązany do wykonania przedmiotu Zamówienia wraz z integracją

z systemem NMMS (Network Model Management System) posiadanym przez Zamawiającego, który będzie stanowił wspólne źródło danych (ang. master data) dla modeli statycznych sieci dla Zmodernizowanego Systemu DYSTER”.

Zgodnie z punktem 3 OPZ „W ramach wykonania aktualizacji oprogramowania do wersji Spectrum 7.2, Wykonawca wykona aktualizację oprogramowania, które nie stanowiło rozwiązania podstawowego Spectrum 3.9, a które zostało wdrożone w ramach tzw. rozszerzeń Oprogramowania w wersji Spectrum 3.9 wynikających ze specyficznych wymagań funkcjonalnych Zamawiającego”.

Po przeprowadzeniu dowodu z przekazanej przez Zamawiającego dokumentacji dialogu technicznego Izba uznała, że wynik dialogu opisany w protokole jest w pełni zgodny z wyrażonym w odpowiedzi na odwołanie stanowisku Zamawiającego, który wskazał, że:

„Zamawiający w odniesieniu do oferowanych systemów klasy SCADA/EMS ustalił w szczególności, że:

1. na rynku istnieją różne systemy klasy SCADA/EMS, oferowane przez różnych wykonawców, a tym samym istnieją rozwiązania informatyczne dające potencjalną możliwość wymiany danego systemu tej klasy i zastąpienia go całkowicie nowym, innym systemem klasy SCADA/EMS;
2. każdy system klasy SCADA/EMS jest inny pod względem przyjętych rozwiązań w zakresie architektury systemu, szczegółowych funkcji, sposobu ich realizacji, układu baz danych, sposobu prezentacji obiektów i zdarzeń systemu, co decyduje o niepowtarzalności i unikatowości każdego z systemów klasy SCADA/EMS;
3. każdy system klasy SCADA/EMS posiada własną koncepcję modeli danych, ich hierarchię oraz stosowane nazewnictwo, a przez to do migracji danych z systemu innego wykonawcy muszą być tworzone, jednorazowo i specyficznie dla danego rozwiązania, dedykowane procedury migracji danych, przy czym nie jest możliwe zagwarantowanie pełnego zautomatyzowania migracji;
4. rozwój tak złożonych systemów czasu rzeczywistego, jak systemy klasy SCADA/EMS ma charakter ewolucyjny, prowadzony jest poprzez cały szereg prac rozwojowych, polegających na szczegółowej identyfikacji wymaganej funkcjonalności, implementacji rozwiązania oraz testów w środowiskach deweloperskich, w ramach których poszukuje, bada się i wdraża takie rozwiązania, które dają pewność działania i wyników;
5. rozwój tych systemów jest dokonywany w związku z potrzebami klientów użytkujących te systemy, tym samym ich rozwój jest podporządkowany potrzebom korzystających z nich operatorów oraz specyfice funkcjonowania danego systemu elektroenergetycznego;
6. pomiędzy systemami klasy SCADA/EMS występują istotne różnice co do zakresu spełnienia wymagań OSP, przy czym w chwili obecnej rynek nie oferuje systemu klasy SCADA/EMS zdolnego do pełnej obsługi obecnych procesów biznesowych OSP, w tym w zakresie tych funkcjonalności, mających priorytet krytyczny lub bardzo ważny, które są dostępne w ramach dedykowanych rozszerzeń aktualnie wykorzystywanego systemu DYSTER;
7. spełnienie funkcjonalności wymaganych przez OSP nie mogłoby nastąpić bez wykonania, w różnym zakresie w odniesieniu do poszczególnych dostawców, modyfikacji oferowanych systemów;
8. ewentualnie możliwe do wykonania modyfikacje, polegające na dostosowaniu dostępnych na rynku systemów klasy SCADA/EMS do ww. wymagań PSE (o priorytecie krytycznym lub bardzo ważnym), wymagałyby dokonania istotnych zmian w architekturze i logice tych systemów oraz modelu danych, które w zależności od wybranego rozwiązania, obejmowałyby w szczególności: a) w zakresie funkcjonalności wymagających zmian w architekturze lub logice systemów: (i) jednoczesnego operatywnego zarządzania KSE (wraz ze zdalnym sterowaniem) z obu niezależnie działających oraz w pełni funkcjonalnych instalacji systemu SCADA/EMS tzw. funkcjonalności Multisite w trybie ActiveActive, (ii) bezprzerwowego wprowadzania zmian w modelu systemu elektroenergetycznego oraz interfejsie użytkownika bez konieczności restartu komponentów systemu, (iii) implementacji algorytmu wyznaczenia funkcji obciążalności linii elektroenergetycznych zależnej od temperatury oraz wykorzystanie tych charakterystyk do wyznaczania chwilowej obciążalności linii, (iv) pełnej obsługi redundantnych źródeł danych pozwalającą na pozyskiwanie i przetwarzanie w czasie rzeczywistym informacji o stanie systemu elektroenergetycznego z czterech różnych źródeł, wraz z wymaganymi mechanizmami zarządzania i walidacji; b) w zakresie funkcjonalności wymagających zmian w modelu danych: (i) wspólnego modelu systemu elektroenergetycznego na potrzeby całego systemu SCADA/EMS, (ii) hierarchii elementów (obiektów) systemu elektroenergetycznego oraz związanego z tym nowego sposobu ich kodowania, (iii) pełnej obsługi danych planistycznych z zewnętrznych źródeł, w tym przetwarzania tych danych w podsystemie SCADA (np. obliczenia z wykorzystaniem danych czasu rzeczywistego) oraz podsystemie EMS (np. wykorzystanie w estymatorze stanu, aplikacjach rozpływowych oraz analizach bezpieczeństwa);
9. dokonanie powyższych modyfikacji - z uwagi na ich złożoność oraz stopień i zakres ingerencji w istniejące rozwiązanie informatyczne - nie gwarantuje uzyskania pozytywnego rezultatu, tj. nie gwarantuje, że nowy system klasy SCADA/EMS będzie

w stanie efektywnie zastąpić istniejący system DYSTER we wszystkich aspektach jego kluczowych, bezwzględnie wymaganych, funkcjonalności”.

Pozostałe informacje i wnioski Zamawiającego z przeprowadzonego dialogu technicznego zawarte w odpowiedzi na odwołanie są zgodne z treścią zbadanej przez Izbę dokumentacji dialogu technicznego oraz protokołu z dialogu technicznego.

Biorąc pod uwagę powyższe w ocenie Izby nie budzi wątpliwości, że przedmiotem zamówienia jest aktualizacja dotychczasowego systemu SCADA/EMS, a nie jak twierdzili Odwołujący oraz Przystępujący po jego stronie - de facto zamówienie nowego systemu. Izba doszła do takiego przekonania w szczególności w oparciu o dowody o charakterze technicznym złożone przez Przystępującego Siemens, w tym objęte tajemnicą przedsiębiorstwa załączniki do opinii prywatnej z 9 listopada 2021 r. prezentujące ewolucję systemu Spectrum od wersji 3.9 do 7.2 a także przeczące twierdzeniom Odwołującego, że wersja 3.9 i 7.2 to dwa, zupełnie odrębne systemy. Izba zauważyła również modyfikację stanowiska Odwołującego, który w odwołaniu traktował przedmiot zamówienia co do zasady jako aktualizację systemu, a na etapie dalszych pism procesowych oraz podczas rozprawy wskazywał, że przedmiotem zamówienia jest instalacja nowego systemu.

Zgodnie z art. 214 ust. 1 pkt 1 Pzp zamawiający może udzielić zamówienia z wolnej ręki, jeżeli zachodzi co najmniej jedna z następujących okoliczności: