Jaki model cyfryzacji administracji jest optymalny dla Polski?

Cyfryzacja administracji publicznej w Polsce balansuje między samodzielnym wytwarzaniem systemów a zlecaniem ich rozwoju rynkowi. Mamy zarówno przykłady dojrzałych modeli współpracy, jak i centralnie tworzone rozwiązania dla samorządów, które budzą obawy dostawców komercyjnych. Jak znaleźć tzw. „złoty środek” i czy w ogóle jest potrzebny? O tym dyskutowaliśmy z przedstawicielami Asseco Poland, Centralnego Ośrodka Informatyki NASK PIB oraz Zakładu Ubezpieczeń Społecznych.

Tematem naszej debaty jest model cyfryzacji administracji publicznej w Polsce, a konkretnie to, jak wyważyć rolę administracji państwowej i rynku w budowie kluczowych systemów IT. Jak to wygląda w Zakładzie Ubezpieczeń Społecznych? Państwa instytucja ma chyba najbardziej dojrzały i przemyślany model współpracy z firmami komercyjnymi.

Sławomir Wasielewski, członek zarządu ZUS (S.W.): Wypracowaliśmy model, który nazywam „hybrydą złotego środka” i on się sprawdza. Choć jesteśmy ogromną instytucją, zatrudniającą ok. 43 tys. pracowników, to – przy tempie zmian legislacyjnych, którego oczekuje strona rządowa – nie bylibyśmy w stanie samodzielnie nadążyć za rozwojem systemów IT bez wsparcia podmiotów komercyjnych.

Dlatego od lat współpracujemy z dwoma dużymi wykonawcami Kompleksowego Systemu Informatycznego ZUS (KSI ZUS), wyłonionymi w ramach konkurencyjnych postępowań przetargowych, których efektem jest podpisanie umowy ramowej. Są to Asseco Poland i CGI (d. Comarch – przyp. red.).

Kluczowe jest dla nas to, że – korzystając z zewnętrznych wykonawców – nie oddaliśmy im kontroli nad naszymi systemami. ZUS jest właścicielem kodów źródłowych. Ma pełne prawa do systemu, kompletną dokumentację i zespoły na pierwszej, drugiej, a w niektórych obszarach również trzeciej linii wsparcia. Dzięki temu możemy na bieżąco reagować na zmiany legislacyjne, a jednocześnie świadomie definiować wymagania wobec dostawców, standardy architektoniczne i cały cykl wytwórczy.

Równolegle rozwijamy też własny dział programistyczny. Nie zastąpi on w 100% wykonawców zewnętrznych, ale – w określonych sytuacjach – jest niezastąpiony. Stało się tak przykładowo, gdy – po powodzi w 2024 r. – trzeba było w ciągu kilku tygodni przygotować nowy system wspierający pracowników ZUS w obsłudze spraw wypłat.

W takich warunkach klasyczna procedura zamówienia publicznego nie miałaby szans zadziałać z uwagi na zbyt krótki czas potrzebny na przygotowanie wymagań, przeprowadzenia zakupu i samego wdrożenia. Podobnie bywa przy postępowaniach, w których nie otrzymujemy żadnej oferty. Wtedy również sięgamy po wytwórstwo wewnętrzne. Wewnętrzny zespół deweloperów dzięki swej elastyczności i znajomości zagadnień biznesowych świetnie adresuje także inne bieżące potrzeby komórek bizne-sowych ZUS.

Jak to wygląda w NASK – Państwowy Instytut Badawczy? Od 2025 roku wdrażany jest w administracji samorządowej stworzony przez Państwa system EZD RP. Z drugiej strony mamy jednak ok. 20 dostawców tego typu rozwiązań, którzy protestują, że nie wybrano ich rozwiązań.

dr inż. Radosław Nielek, dyrektor NASK PIB (R.N.): EZD RP to jeden z najbardziej zaawansowanych systemów obiegu dokumentów w administracji, opracowany przez samą administrację publiczną. Ale to też tylko jedna z wielu rzeczy, którymi zajmuje się NASK PIB. Równolegle prowadzimy liczne projekty, w których kupujemy usługi.

Dlaczego zdecydowaliśmy się stworzyć i udostępnić system EZD RP? Jeśli spojrzymy na sam problem obiegu dokumentów w administracji – od dużych miast, jak Warszawa czy Kraków, po małe gminy – to widać kilka powtarzających się wyzwań.

Po pierwsze – koszty. Państwo chciałoby, aby wszystkie jednostki przeszły na cyfrowy obieg dokumentów. Ale wielu wójtów mówi wprost, że wolą wydać te pieniądze na nowy chodnik. Jednocześnie – nie dźwigną później utrzymania tego rozwiązania.

Obowiązki ustawowe są więc podobne, ale możliwości finansowe gmin radykalnie się różnią. Narzucenie wymogu cyfrowego obiegu dokumentów bez zapewnienia docelowego rozwiązania byłoby po prostu niesprawiedliwe. Uważamy, że skoro państwo nakłada obowiązek, musi zapewnić przynajmniej jedno, dostępne centralnie rozwiązanie, zwłaszcza dla samorządów.

Liczy się też jakość, stabilność i bezpieczeństwo. Usługi w najmniejszej gminie muszą być równie bezpieczne, jak w dużym mieście czy ministerstwie, utrzymywane i administrowane według tego samego standardu. Tymczasem w wielu małych urzędach jest co najwyżej pół etatu na informatyka.

Kolejnym wyzwaniem jest rosnąca liczba usług centralnych – takich jak Centralny Rejestr Umów, który ma sprawić, że wszystkie umowy jednostek publicznych będą dostępne w jednym miejscu. To oznacza, że lokalne systemy obiegu dokumentów muszą się z tymi rozwiązaniami integrować. Bez tego gmina nie jest w stanie spełnić ustawowego obowiązku.

Czym różni się system centralny, udostępniany przez Państwo od tego komercyjnego?

R.N.: Centralny system, taki jak EZD RP, zapewnia zgodność z rozwiązaniami centralnymi i minimalny zestaw funkcji, który pozwala gminom wypełnić obowiązki ustawowe. Jednocześnie sam system pozostaje opcją. Każda jednostka może wybrać inne rozwiązanie, jeśli uzna je za lepsze. Oczywiście pod warunkiem, że zapewni wymaganą integrację.

Bardzo ważne jest przy tym to, że EZD RP zapewnia otwarte API. Budujemy ten system jak platformę, z publicznie dostępnym interfejsem, piaskownicą do testów, a w przyszłości również sklepem z „dodatkami” do EZD RP.

Dzięki temu każda firma, również start-up, będzie mogła napisać usługę integrującą EZD RP z innymi systemami, która wygeneruje pisma czy zautomatyzuje pracę urzędników. W ten sposób, wdrażając jeden system w kilkuset czy kilku tysiącach instytucji, tworzymy duży, jednolity rynek, na którym opłaca się budować specjalistyczne rozwiązania.

Tymczasem to nie jest standard w przypadku komercyjnych systemów. Nawet jeśli udostępniają API, to rynek jest mocno pofragmentowany i często po prostu nie opłaca się tworzyć integracji dla rzeszy małych rozwiązań.

Rozumiem wysokie koszty, zwłaszcza w małych samorządach. Z drugiej strony część wymogów, jak otwarte API czy zgodność ze standardami, można przecież wpisać w specyfikację zamówienia? ZUS, zamawiając system, stawia przecież wykonawcom określone wymagania prawne i techniczne.

S.W.: ZUS ma o tyle uprzywilejowaną pozycję, że jeśli zamawiamy nowe oprogramowanie, to zwykle są to duże projekty i duże budżety. W takich warunkach naturalnie negocjujemy pełne prawa do kodu, dokumentację, otwarte API. Możemy też oczekiwać integracji z innymi systemami. Zdarza się też, że prosimy producentów stan-dardowych rozwiązań o otwarte API. W naszym przypadku najczęściej spotykamy się z zrozumieniem.

Natomiast w małej gminie skala jest zupełnie inna. Tam nie ma dużych budżetów ani siły negocjacyjnej, a często i kompetencji po stronie zamawiającego. Kompetencji do stworzenia wymagań technicznych. W praktyce gmina akceptuje więc warunki, jakie stawia dostawca.

Radosław Maćkiewicz, dyrektor generalny Centralnego Ośrodka Informatyki (R.M.): Zgadzam się, że państwo musi wziąć odpowiedzialność za to, aby cyfryzacja realnie posuwała się naprzód, a nie pozostawała tylko zbiorem deklaracji. Stąd decyzje o kontynuacji takich projektów jak EZD RP i przekonanie, że jeśli gminy czy inne jednostki nie chcą albo nie mogą korzystać z rozwiązań komercyjnych, powinny mieć możliwość nieodpłatnego korzystania z systemów państwowych.

Są obszary, w których państwo – kierując się interesem obywatela, bezpieczeństwem danych czy ciągłością działania – po prostu musi przejąć odpowiedzialność za systemy. Oznacza to m.in. budowę cyfrowych fundamentów, wokół których rynek może rozwijać własne usługi. Takimi fundamentami są obieg dokumentów, centralne rejestry, a w przyszłości też nowa Platforma e-Usług, która ma zastąpić ePUAP.

W ramach EZD RP czy e-Usług chcemy stworzyć marketplace, gdzie początkowo udostępniane gminom będą nasze formularze. Docelowo będzie to przestrzeń otwarta również dla firm komercyjnych, które będą mogły dostarczać własne wnioski, integracje i usługi elektroniczne.

Państwo zapewnia więc minimum funkcjonalne, standardy i bezpieczeństwo, ale nie zamyka przestrzeni dla rynku. Przeciwnie, buduje stabilne fundamenty, na których firmy mogą tworzyć własne, wyspecjalizowane rozwiązania.

Czy taki model już się gdzieś sprawdził?

S.W.: Z naszych doświadczeń wynika, że model „państwo + rynek” naprawdę działa. Dobrym przykładem są elektroniczne zwolnienia lekarskie e ZLA. Udostępniliśmy lekarzom możliwość wystawiania zwolnień w portalu eZUS i w bezpłatnej aplikacji mobilnej mZUS dla Lekarza.

Mimo to aż 70% zwolnień jest wystawianych z poziomu komercyjnych aplikacji gabinetowych, które obsługują też inne procesy w placówkach medycznych. Od początku zakładaliśmy taki model, więc włożyliśmy bardzo dużo pracy, aby odpowiednie funkcje powstały w tych aplikacjach. Współpracowaliśmy z ich producentami, udostępniliśmy im środowisko testowe.

Podobnie było z programem Płatnik. Początkowo zakładano, że wszystkie dokumenty będą przygotowywane właśnie w tym programie i przesyłane do ZUS. Stało się inaczej. Dziś większość systemów kadrowo płacowych zostało zintegrowanych z programem Płatnik. Dokumenty są przygotowywane w systemach kadrowych, a program Płatnik służy głównie do ich walidacji i synchronizacji danych z informacjami w ZUS i wysyłki.

Dodatkowo – na podstawie dokumentacji udostępnionej przez ZUS – powstają komercyjne oprogramowania interfejsowe, które służą do przekazywania drogą elek-troniczną dokumentów ubezpieczeniowych do ZUS.

Przykłady e ZLA i Płatnia pokazują, że jeśli państwo postawi jasne wymagania i udostępni otwarty format, rynek sam zbuduje narzędzia, które lepiej odpowiadają potrzebom użytkowników.

R.N.: Jeśli państwo ma oczekiwania wobec gmin, przedsiębiorców czy obywateli, musi dostarczyć komplet „puzzli”, które umożliwiają realizację tych obowiązków. Jednocześnie te „puzzle” nie mogą być systemami zamkniętymi. Muszą dawać możliwość wymiany elementów i integracji z innymi rozwiązaniami.

Im więcej dostępnych jest e-usług bez konieczności kupowania drogich rozwiązań, tym większa jest przestrzeń dla firm IT do budowania własnych, innowacyjnych produktów. Rynek i tak znajdzie swoje miejsce, jeśli fundamenty będą dobrze zaprojektowane.

R.M.: Podobny wzorzec widać wokół Krajowego Systemu e Faktur. Integracja z KSeF to nie tylko kwestia nakładek na systemy finansowo księgowe. Powstaje cały ekosystem narzędzi automatyzujących przepływ danych, również po stronie administracji. Sami korzystamy z dodatkowego pluginu do naszego systemu, który usprawnia obieg faktur i integrację z KSeF.

To dobry przykład, jak państwo buduje fundament – centralny rejestr i standard wymiany danych – a rynek dostarcza rozwiązania wokół niego, wypełniając luki i dodając specjalistyczne funkcje. Korzystają na tym nie tylko obywatele, jak i firmy.

Wrócę jednak do pierwotnego pytania, ale na innym przykładzie. Jakie cele stoją za stworzeniem Dziennika Elektronicznego przez Państwo, skoro takie rozwiązania już funkcjonują i wydaje się, że są powszechne?

R.M.: Po pierwsze, jeszcze nie wszystkie szkoły korzystają dziś z dzienników elektronicznych, mimo że rozwiązań rynkowych faktycznie nie brakuje. Po drugie, uważam, że jest to obszar, w którym państwo powinno przejąć odpowiedzialność i zapewnić wszystkim szkołom i rodzicom bezpłatny, bezpieczny i powszechnie dostępny system.

Pilotaż eDziennika ruszy już na początku nowego roku szkolnego w kilkudziesięciu szkołach – a udział w nim będzie dobrowolny. Finalny kształt systemu zostanie wypracowany na podstawie wniosków z konsultacji oraz doświadczeń zdobytych podczas pilotażu. Widzimy ten projekt również jako element edukacji cyfrowej dzieci i młodzieży. Chcemy pokazać, że smartfon to nie tylko rozrywka czy komunikator, ale także narzędzie do potwierdzania tożsamości i korzystania z usług publicznych.

Czy można sobie wyobrazić model, w którym duża instytucja zamawia system na rynku, a następnie udostępnia go innym podmiotom administracji, np. gminom, których nie stać na własne wdrożenia? Przecież tak robimy z komputerami w szkołach.

R.N.: Warto też zachować proporcje w dyskusji o „informatyce państwowej”. W Polsce przytłaczająca większość rynku IT to sektor prywatny, a zespoły programistyczne w administracji są relatywnie niewielkie względem skali potrzeb.
Z naszych szacunków wynika, że ok. 6000 osób zajmuje się rozwojem i utrzymaniem aplikacji krytycznych dla państwa. W tej grupie duża część to zespoły utrzymaniowe, testerzy i analitycy, których i tak byśmy potrzebowali, nawet gdyby wytwarzanie zostało zlecone.

Jeśli państwo chce sensownie zamawiać oprogramowanie na rynku, musi mieć wewnętrzne kompetencje do opisania wymagań, oceny architektury i odbioru prac. To oznacza, że nawet przy pełnym „otwarciu się na rynek” rdzeń kompetencji IT w administracji będzie konieczny.

Rzeczywistość jest daleka od wizji, w której państwo „wszystko pisze samo”. Raczej jest tak, że mamy kilka wąskich wysp wytwarzania wewnętrznego i ogromny obszar kontraktowany.

Sławomir Szmytkowski, wiceprezes zarządu Asseco Poland (S.Sz.): Zamiast przeciwstawiać sobie „informatykę państwową” i „informatykę rynkową”, warto szukać modeli, które łączą mocne strony obu podejść. Dobrym przykładem jest współpraca Asseco z NASK przy realizacji usług cyberbezpieczeństwa dla ZUS. Tworzone przez nas konsorcjum łączy kompetencje i państwowy mandat instytutu badawczego z doświadczeniem komercyjnego integratora technologicznego. Z perspektywy klienta taki model jest bardziej efektywny i racjonalny niż samodzielne budowanie wszystkich kompetencji od podstaw.

Jak rynek patrzy na swoją rolę w budowie rozwiązań dla administracji?

S.Sz.: Z perspektywy rynku model realizowany m.in. w ramach projektu EZD RP należy do najlepszych rozwiązań dla powszechnych usług publicznych. Państwo nie powinno uchylać się od odpowiedzialności za zapewnienie standardów, które samo wyznacza. Jego rolą jest stworzenie wspólnego fundamentu – minimalnego, ale solidnego poziomu usług dostępnych w jednolitym standardzie.

Ważne, aby takie rozwiązania były udostępniane również w modelu otwartym, który pozwala budować wokół nich ekosystem firm rozwijających dodatkowe funkcjonalności i usługi. W ten sposób państwo realizuje swoje zobowiązania wobec obywateli, szkół czy jednostek samorządu terytorialnego, a jednocześnie wspiera rozwój rynku.

W obecnych realiach warto także rozważyć stworzenie państwowego pakietu biurowego opartego na rozwiązaniach open source, dostosowanego do potrzeb administracji i udostępnianego zwłaszcza samorządom o ograniczonych możliwościach finansowych. Takie podejście pozwoliłoby zbudować krajowy standard, zwiększyć niezależność technologiczną oraz racjonalizować wydatki publiczne.

A jaki mógłby być model docelowy?

S.Sz.: Kiedy zastanawiam się nad modelem docelowym, zawsze sprawdzam, czy podobne rozwiązania zostały już skutecznie wdrożone w innych krajach. Warto przyglądać się nie tylko Stanom Zjednoczonym czy Izraelowi, które pokazują, że nawet w warunkach podwyższonych zagrożeń państwo nie musi samodzielnie realizować wszystkich zadań technologicznych. Cennych inspiracji dostarczają również kraje skandynawskie.

W tym modelu państwo odpowiada za wyznaczanie kierunków rozwoju, zarządzanie architekturą korporacyjną, definiowanie priorytetów strategicznych – m.in. w obszarach obronności, nauki czy infrastruktury krytycznej – oraz pełni rolę kluczowego inwestora. Jednocześnie pozostawia rynkowi tworzenie i rozwój wielu gotowych produktów oraz usług.

W Polsce istotnym czynnikiem wpływającym na relacje między administracją a sektorem technologicznym pozostaje jednak Prawo Zamówień Publicznych. W dużej mierze opiera się ono na logice projektów infrastrukturalnych i modelu Fixed Price, co nie zawsze odpowiada specyfice przedsięwzięć informatycznych. Niejednokrotnie skłania to instytucje publiczne do budowania własnych struktur IT, ponieważ postrzegają je jako sposób na ograniczenie obciążeń formalnych związanych z procesami zakupowymi.

Z jednej strony konieczna jest skuteczna kontrola wydatkowania środków publicznych. Z drugiej jednak nadmierny ciężar procedur może ograniczać efektywność działania. Warto zauważyć, że te same regulacje unijne obowiązują również w krajach skandynawskich, gdzie sposób ich implementacji i praktyka stosowania są znacznie bardziej elastyczne i mniej obciążające dla realizowanych projektów.

O niedoskonałościach zamówień publicznych pisze się od lat i zawsze jest z nimi problem.

S.Sz.: Warto rozdzielić dwie kwestie. Pierwsza to ograniczenia systemowe. Prawo zamówień publicznych zostało w dużej mierze zbudowane wokół modelu Fixed Price, który dobrze sprawdza się w projektach infrastrukturalnych, ale znacznie gorzej odpowiada specyfice przedsięwzięć IT, gdzie wymagania ewoluują wraz ze zmianami legislacyjnymi, technologicznymi czy organizacyjnymi.

Druga kwestia dotyczy praktyki stosowania przepisów. Często sami komplikujemy procesy bardziej, niż wynikałoby to z prawa. Przykładem jest nadużywanie instytucji tajemnicy przedsiębiorstwa, nierzadko wykorzystywanej do ukrywania słabości ofert zamiast ochrony rzeczywiście wrażliwych informacji. W efekcie postępowania znacząco się wydłużają, rośnie liczba sporów i odwołań, a koszty ponoszone przez zamawiających i wykonawców idą w dziesiątki milionów złotych. Samo to zjawisko może wydłużać wiele postępowań o 30-40%.

Czy model ZUS – oparty na punktach funkcyjnych i umowach ramowych – pozwala realnie ominąć część problemów z PZP przy szybkich zmianach legislacyjnych?

S.W.: W znacznym stopniu tak. Co kilka lat ogłaszamy otwarty przetarg na umowę ramową na rozwój KSI ZUS, do którego mogą przystąpić dowolni wykonawcy. Tak się ułożył rynek, że zwykle jest to stały zestaw wykonawców. Gdy pojawia się zmiana legislacyjna, nie uruchamiamy nowego „pełnego”, przetargu, tylko organizujemy „mi-ni konkurs” w ramach już zawartej umowy ramowej. Wykonawcy konkurują ceną za tzw. punkt funkcyjny.

Proces jednak wciąż jest wymagający. Po stronie ZUS trzeba umieć przełożyć ustawę na wymagania funkcjonalne, zwymiarować pracochłonność metodą punktów funkcyjnych i przygotować postępowanie przetargowe w ramach umowy ramowej. To zajmuje minimum 1,5-2 miesiące; oczywiście w zależności od skali planowanych zmian w naszych systemach IT. Ale to i tak dramatycznie krócej niż pełne postępowanie PZP trwające nawet 9 miesięcy.

W sytuacjach ekstremalnych, gdy ustawodawcy bardzo zależy na szybkim wdrożeniu zmian, możemy zostać zwolnieni ze stosowania PZP dla konkretnego aktu prawnego. Pozwala to jeszcze bardziej przyspieszyć prace i od razu przystąpić do wspólnego projektowania i realizacji z jednym z wykonawców, przy zachowaniu zdrowej konkurencji na poziomie cen punktów funkcyjnych. Nawet ustawowe zwolnienie ze stosowania PZP nie zwalnia ZUS-u z przeprowadzenia swoistej procedury zakupowej do której zwykle zapraszamy wykonawców umów ramowych.

S.Sz.: Kluczową rolę odgrywa model umowy ramowej, ale równie istotna jest odpowiednia metodyka szacowania prac programistycznych. W ZUS, podobnie jak w Agencji Restrukturyzacji i Modernizacji Rolnictwa, wykorzystujemy metodę punktów funkcyjnych. Pozwala ona odejść od dyskusji sprowadzającej się do liczby godzin i stawek, przenosząc ocenę zakresu prac na bardziej obiektywny i mierzalny poziom.

Dzięki wieloletnim doświadczeniom oraz rozbudowanej bazie danych projektów rozliczanych w tej metodyce ZUS może dziś sprawnie oceniać realność wycen, a w sytuacji pojawienia się nowych potrzeb szybko i elastycznie dostosowywać zakres prac. W połączeniu z umową ramową zapewnia to wysoki poziom elastyczności przy zacho-waniu transparentności procesu oraz kontroli kosztów.

Nie jest to jednak model, który można łatwo przenieść do każdej organizacji. Jego skuteczność opiera się na odpowiedniej skali działania, dojrzałości organizacyjnej i doświadczeniu zarówno po stronie zamawiającego, jak i wykonawcy. W przypadku mniejszych postępowań stworzenie podobnego mechanizmu byłoby znacznie trudniejsze.

R.N.: Metodyki punktów funkcyjnych nigdy nie są idealnie precyzyjne. Jest tak np. przy zaawansowanych interfejsach czy rozwiązaniach AI. Natomiast one umożliwiają uczciwe rozliczanie pracy. Przy tak dużej skali, jak w ZUS, błędy „w górę” i „w dół” zazwyczaj się bilansują. To model realistyczny dla największego zamawiającego w kraju i kilku, największych firm IT. Natomiast trudno oczekiwać jego masowego zastosowania w małych jednostkach samorządowych.

Są inne, łatwiejsze metody?

R.M.: Innym sposobem na pogodzenie elastyczności z wymogami ustawy PZP są umowy typu body leasing czy team leasing. Zamawiający, który wie, że będzie miał określone potrzeby, ale nie zna jeszcze dokładnego produktu końcowego, może zakontraktować specjalistów na ustalonych stawkach, a potem budować zespoły projektowe pracujące w modelu zwinnych sprintów. Taka forma daje dużo swobody w korygowaniu zakresu i priorytetów w trakcie trwania projektu.

W COI dwa lata temu świadomie ograniczyliśmy ten model tam, gdzie nasze procesy są silnie determinowane przez zmiany legislacyjne. Potrzebowaliśmy stabilnych, własnych zespołów, opartych na umowach o pracę.

Do body leasingu wróciliśmy jednak niedawno w formule umowy ramowej, ale z inną logiką. Traktujemy go jako bufor dla szybkich, krótkotrwałych projektów, których nie da się obsłużyć istniejącymi zasobami. Kluczowe systemy nadal wolimy rozwijać własnymi siłami.

Skoro mowa o PZP, co z masowymi protestami i odwołaniami? Jak wspominał przed debatą Sławomir Szmytkowski, często wycofywanymi tuż przed terminem ich rozpatrzenia. Może rozwiązaniem byłoby wprowadzenie np. 1% wadium od wartości zamówienia za złożenie odwołania, przepadającego przy wycofaniu skargi?

R.N.: Taki pomysł natychmiast spotkałby się z oporem rynku. W dużych postępowaniach mówimy o wadium liczonym nawet w milionach złotych. To realnie ograniczyłoby możliwość korzystania z ochrony prawnej mniejszym wykonawcom. Dziś jednak opłata za wniesienie odwołania jest stała i relatywnie niewielka względem wartości dużych kontraktów. Nie powstrzymuje więc od składania nawet słabych merytorycznie środków ochrony.

S.Sz.: Sama idea powiązania wysokości opłaty z wartością zamówienia jest racjonalna, ale wymaga odpowiedniego wyważenia. Krajowa Izba Odwoławcza jest dziś znacząco obciążona, a jedną z przyczyn jest fakt, że odwołania coraz częściej pełnią nie tylko funkcję ochrony interesów wykonawców, lecz także stają się narzędziem zarządzania ryzykiem biznesowym czy elementem strategii negocjacyjnej.

Warto rozróżnić sytuacje, w których odwołanie prowadzi do merytorycznej dyskusji między stronami i kończy się wypracowaniem rozwiązania, od przypadków, gdy zostaje ono złożone, a następnie wycofane bez jakiejkolwiek reakcji zamawiającego. Takie sytuacje mogą świadczyć o tym, że koszt wniesienia odwołania jest niewspółmiernie niski względem korzyści wynikających choćby z samego opóźnienia postępowania.

Dlatego system powinien z jednej strony gwarantować realną możliwość dochodzenia praw, a z drugiej ograniczać zachowania, które nie służą merytorycznemu rozstrzyganiu sporów.

S.W.: Z naszej perspektywy KIO stała się standardowym etapem postępowania. Szacuję, że co najmniej 3/4 większych przetargów w ZUS kończy się odwołaniem. Często na kilku etapach.

Jak można by podsumować naszą dyskusję?

R.N.: Musimy zrozumieć, że to nie jest gra o sumie zerowej. Rozwijając EZD RP czy inne systemy centralne, nie „zabieramy rynku”, tylko tworzymy fundament pod nowe segmenty rynku – choć po drodze niektóre modele biznesowe rzeczywiście tracą rację bytu. Polska administracja ma do pokonania ogromny dystans w cyfryzacji, więc przestrzeni na rozwiązania publiczne i komercyjne jest więcej niż wystarczająco.

NASK działa jak normalny podmiot rynkowy. Utrzymujemy się samodzielnie, sprzedając np. rozwiązania komercyjne, takie jak systemy antyfraudowe czy anty DDoS chroniące np. mObywatela. Konsorcja z firmami takimi jak Asseco pozwalają nam łączyć nasze technologie z ich skalą operacyjną. Przekłada się to na wyższy poziom bezpieczeństwa kluczowych systemów państwa.

To przykład, że sektor publiczny i prywatny mogą wspólnie tworzyć rozwiązania o znaczeniu strategicznym, zamiast rywalizować o każdy kawałek rynku.

S.Sz.: W pełni się z tym zgadzam. Historie wielu globalnych marek technologicznych pokazują, że ich rozwój nie byłby możliwy bez udziału państwa – jako inwestora, klienta referencyjnego albo regulatora tworzącego sprzyjające warunki.

Państwo musi angażować się w rozwój systemów IT, bo w wielu obszarach jest to konieczne. Kluczowe jest to, w jaki sposób powinno to robić, aby nie ograniczać rozwoju rynku, lecz wzmacniać jego potencjał, innowacyjność i zdolność do tworzenia konkurencyjnych rozwiązań.