|
8 czerwca 2022 | Ostatnio zmodyfikowano 18 grudnia, 2023 o 12:27 | Czas na przeczytanie: 16 minut
Pozostałe Artykuły
Szczególne cechy zamówienia publicznego na system informatyczny
Co sprawia, że wybór dostawcy systemu informatycznego nastręcza podmiotom takich trudności? Przede wszystkim mnogość aspektów, które należy wziąć pod uwagę oraz skomplikowanie na poziomie zagadnień technologicznych. Do tego dochodzi także ustawodawstwo, w oparciu o które nierzadko trudno jest dokonać odpowiedniej kwalifikacji prawnej usługi.
Przede wszystkim należy podkreślić, iż jak każde zamówienie w reżimie zamówień publicznych, także zamówienie na system informatyczny, powinno czynić zadość wymaganiom ogólnym ustanowionym przez Ustawę z dnia z dnia 11 września 2019 r. Prawo zamówień publicznych (Dz. U. z 2021 r., poz. 1129). Podmiot winien zatem m.in. oszacować wartość zamówienia, opisać jego przedmiot, przygotować niezbędną dokumentację, a także przeanalizować swoje potrzeby. To co wyróżnia postępowanie na usługi z branży IT, to konieczność po stronie zamawiającego zaznajomienia się z dostępnymi rozwiązaniami w zakresie nowych technologii.
Zamawiający musi wiedzieć jakich rozwiązań potrzebuje, jakimi warunkami organizacyjnymi dysponuje, a także czy przepisy prawa przewidują w jego przypadku możliwość wykorzystania danej formy rozwiązania technologicznego. Zamawiający może w zakresie zamówienia potrzebować tylko oprogramowania lub sprzętu i oprogramowania. Może także być niezbędne pozyskanie wsparcia w zakresie ich wdrożenia, a może okazać się, że zamawiający potrzebuje nie tylko wdrożenia, ale także przygotowania wyspecjalizowanego oprogramowania na swoje skonkretyzowane potrzeby. Stąd też, jeśli chodzi o postępowanie w sprawie zamówienia publicznego na system informatyczny, będzie się ono charakteryzowało koniecznością podjęcia szeregu czynności jeszcze przed jego oficjalnym podjęciem.
Czynności przygotowawcze
Z punktu widzenia wyboru dostawcy systemu w reżimie zamówień publicznych jest to krok kluczowy. Prawidłowe przygotowanie się do postępowania gwarantuje, że w odpowiedzi na zapotrzebowanie, do zamawiającego napłyną oferty, które będą korelować z jego rzeczywistymi potrzebami i oczekiwaniami. Poprzez prawidłowe przeprowadzenie czynności przygotowawczych zamawiający będzie w stanie prawidłowo wypełnić wszystkie wymagania, jakie stawia na nim ustawodawca w reżimie zamówień publicznych: będzie mógł prawidłowo oszacować wartość zamówienia, przygotować warunki udziału, opis przedmiotu zamówienia, a w efekcie będzie w stanie sprawnie przeprowadzić całość postępowania.
Sprawdzenie własnych potrzeb i zasobów
W pierwszej kolejności zamawiający winien zastanowić się, czy dysponuje odpowiednio wykwalifikowanym personelem – z jednej strony takimi osobami, które są w stanie zidentyfikować potrzeby, których dotyczyć będzie postępowanie, z drugiej strony także takimi pracownikami, którzy będą w stanie czuwać nad realizacją projektu. Powinien zbadać, w jakim zakresie wykazują się wiedzą, czy odpowiada ona zapotrzebowaniu przedsięwzięcia oraz, czy są w stanie koordynować wdrażanie systemu już po zakończeniu postępowania. Jeżeli podmiot na tym etapie dojdzie do wniosku, że nie posiada w swoich szeregach osób, które byłyby w stanie przygotować odpowiednią specyfikację potrzeb, lub też “zaopiekować” się projektem od strony technicznej, powinien rozważyć uzyskanie profesjonalnego wsparcia.
Ponadto, zamawiający przed wszczęciem postępowania musi zweryfikować, czy posiada odpowiednie zasoby techniczne oraz infrastrukturę na potrzeby wdrożenia systemu. Na tym etapie powinien rozważyć ewentualną rozbudowę czy modyfikację posiadanych rozwiązań, jeżeli nie spełniają one warunków dla integracji z nabywanym systemem. Ważnym elementem jest także zbadanie uprawnień i praw autorskich do rozwiązań technologicznych posiadanych już przez zamawiającego – nierzadko firmy z branży IT odmawiają pracy na “nie swoim” systemie, którego budowy nie znają, lub wręcz jest to niemożliwe w przypadku gdy zamawiający nie posiada odpowiednich dostępów lub kodów źródłowych, albo pierwotny wykonawca zastrzegł, że prac na danym rozwiązaniu może podjąć się tylko on, co wynika z licencji lub praw autorskich. Odpowiednie zbadanie zasobów pozwoli zamawiającemu uchronić się przed niemożliwością dokonania integracji zamówionego systemu z rozwiązaniem, które już posiada i tym samym przed nadmiernym wydatkowaniem środków publicznych.
Warto by zamawiający zorientował się także, czy w związku z planowanym postępowaniem nie jest możliwe pozyskanie dodatkowych środków np. w ramach dofinansowań z programów unijnych.
Research rynku
Odpowiednie zbadanie rynku – zwłaszcza w sektorze IT – jest niezbędnym elementem dla prawidłowego oszacowania wartości zamówienia. Oszacowanie wartości zamówienia jest z kolei bardzo ważne, bo od wartości zależy czy ogłoszenie o wszczęciu postępowania będzie publikowane w Dzienniku Urzędowym Unii Europejskiej (zamawiający będzie stosował przepisy właściwe dla postępowań o wartości równej lub przekraczającej progi unijne), czy wystarczy opublikowanie ogłoszenia o zamówieniu w Biuletynie Zamówień Publicznych (właściwe będzie stosowanie przepisów dla zamówień o wartości mniejszej niż progi unijne). Poniżej przypomnienie progów unijnych dla dostaw i usług w 2022 roku:
-
Sektor finansów publicznych (rządowy) – 140.000 EUR (623.504 PLN),
-
Zamawiający samorządowi – 215.000 EUR (957.524 PLN),
-
Zamawiający sektorowi i zamówienia w dziedzinach obronności i bezpieczeństwa – 431.000 EUR (1.919.502 PLN).
Nadto, o czym zostało już wspomniane wcześniej, badanie rynku pozwoli zamawiającemu ustalić, jakie są powszechnie stosowane rozwiązania i które z nich będą odpowiedzią na potrzeby zamawiającego. W zakresie systemów informatycznych co do zasady zamawiający będzie musiał podjąć decyzje między systemem SaaS (software as a service), polegającym na przechowywaniu danych w chmurze obliczeniowej, a systemem on premises, który jest instalowany bezpośrednio w ramach infrastruktury zamawiającego.
Jeżeli w przypadku zamawiającego korzystne i możliwe okaże się zamówienie systemu w modelu on premises, system w zdecydowanej większości tworzony będzie zgodnie z indywidualnymi wytycznymi zamawiającego. Umowa zatem będzie obejmowała także przekazanie prawa autorskich po zakończeniu wdrożenia u zamawiającego. Czym różni się od chmury obliczeniowej? Rozwiązanie w przypadku chmury będzie zainstalowane w ramach infrastruktury wykonawcy, a zamawiający będzie tylko czerpał z gotowego rozwiązania udostępnianego zamawiającemu najczęściej online.
Nie jest to więc usługa, która będzie pasowała każdemu zamawiającemu i w każdym przypadku. Takie rozwiązanie będzie różniło się także formą płatności – o ile umowy na system w modelu on premises zakładają płatność jednorazową, lub rozłożoną na kilka etapów, o tyle korzystanie z rozwiązania w modelu SaaS może polegać na rozliczaniu miesięcznej subskrypcji. Koszty uzależnione będą od mocy obliczeniowej wykorzystywanej w ramach danej chmury, czy zajmowanej przestrzeni dyskowej.
Wybór trybu zamówienia
Zgodnie z przywołaną wcześniej ustawą Prawo zamówień publicznych, zamawiający może przeprowadzić postępowanie w następujących trybach:
-
jeżeli wartość przedmiotu zamówienia jest równa lub przekracza progi unijne: przetarg ograniczony, przetarg nieograniczony, negocjacje z ogłoszeniem lub dialog konkurencyjny;
-
jeżeli wartość przedmiotu zamówienia jest mniejsza niż progi unijne: podstawowy, partnerstwo innowacyjne, negocjacje bez ogłoszenia, zamówienie z wolnej ręki.
Wybór odpowiedniego trybu może być kluczowym dla sprawnego i skutecznego przeprowadzenia postępowania, przy czym trudno jest wskazać, który z trybów będzie tym najwłaściwszym. Można pokusić się o stwierdzenie, że jeżeli zamawiający nie ma kompleksowo sprecyzowanych parametrów zamówienia, odpowiednie będą negocjacje ogłoszeniem lub dialog konkurencyjny, które dają możliwość wymiany informacji z wykonawcą. Należy jednak zaznaczyć, iż aby prowadzić postępowanie w trybie bezprzetargowym, zamawiający musi spełnić przesłanki wynikające z ustawy:
-
w przypadku negocjacji z ogłoszeniem z art. 153 PZP pkt 1) – rozwiązania dostępne na rynku nie mogą zaspokoić, bez ich dostosowania, potrzeb zamawiającego;
-
w przypadku dialogu konkurencyjnego z art. 170 PZP – zamawiający może udzielić zamówienia w trybie dialogu konkurencyjnego, jeżeli zachodzi co najmniej jedna z okoliczności, o których mowa w art. 153 PZP.
Podział zamówienia na części
W pewnych przypadkach zasadnym może być także podział zamówienia na części. Zgodnie z art. 91 PZP zamawiający może udzielić zamówienia w częściach, z których każda stanowi przedmiot odrębnego postępowania o udzielenie zamówienia, lub dopuścić możliwość składania ofert częściowych w ramach jednego postępowania o udzielenie zamówienia, określając zakres i przedmiot części oraz wskazując, czy ofertę można składać w odniesieniu do jednej, kilku lub wszystkich części zamówienia. Czasem bowiem łatwiej będzie zamawiającemu zrealizować całość projektu, jeżeli jego poszczególne części zleci pojedynczym wykonawcom.
W przypadku zamówień publicznych w zakresie systemów informatycznych zamawiający powinien przeanalizować, czy przedmiot zamówienia może ulec podziałowi i spełnia przesłanki z ustawy dla przeprowadzenia podziału. Zakup oprogramowania standardowego wraz ze wsparciem producenta czy dostawa oprogramowania dedykowanego wraz z jego wdrożeniem i utrzymaniem, nie spełni takich przesłanek gdyż ich charakterystyka wskazuje na konieczność spełnienia całości usług przez jeden podmiot – ten który jest producentem/wytwórcą. Czasami podział lub jego brak będzie miał wpływ na koszt postępowania, jego czasochłonność czy sposób realizacji. Każdy przypadek będzie jednak wymagał odrębnej analizy zamawiającego, o której mowa w art. 83 PZP.
Określenie przedmiotu zamówienia
Na podstawie art. 99 ust. 1 PZP, zadaniem zamawiającego jest opis przedmiotu postępowania w sposób jednoznaczny i wyczerpujący, za pomocą dostatecznie dokładnych i zrozumiałych określeń, uwzględniając wymagania i okoliczności mogące mieć wpływ na sporządzenie oferty. W przypadku zapotrzebowania na system informatyczny ta część wydaje się nastręczać wyjątkowych trudności. O ile osoba działająca w imieniu zamawiającego nie posiada szczegółowej wiedzy z zakresu IT, trudno będzie spełnić warunek wyczerpującego opisu, w którym mowa w art. 99 PZP.
Zamawiający powinien przyłożyć przede wszystkim szczególną uwagę do stworzenia katalogu definicji. Pozwoli to na jednoznaczność w zakresie ustalenia co zamawiający w rzeczywistości pragnie otrzymać w drodze postępowania. Do tego wszystkiego dochodzi także konieczność ustalenia parametrów gwarancyjnych na potrzeby dokumentu zwanego SLA (service level agreement) – umowy o gwarantowanym poziomie świadczenia usług. Zamawiający na potrzeby sporządzenia SLA powinien wskazać nie tylko wysokość parametrów, ale także sposób ich obliczania.
Badanie ofert
Na tym etapie celem zamawiającego jest z jednej strony wybór najkorzystniejszej pod wieloma aspektami oferty, ale także odpowiednie zabezpieczenie swoich interesów na przyszłość. Zamawiający musi mieć świadomość, że to jaki system wybierze i jakie zasady pracy na systemie wypracuje z wykonawcą, będzie rzutowało na jego późniejszą pracę i ewentualne możliwości rozbudowy systemu.
Zasada konkurencyjności i równego traktowania wykonawców
Zasada konkurencyjności i równego traktowania wykonawców ujęta została w art. 99 ust.4 PZP. Ustęp ten stanowi, że przedmiotu zamówienia nie można opisywać w sposób, który mógłby utrudniać uczciwą konkurencję, w szczególności przez wskazanie znaków towarowych, patentów lub pochodzenia, źródła lub szczególnego procesu, który charakteryzuje produkty lub usługi dostarczane przez konkretnego wykonawcę, jeżeli mogłoby to doprowadzić do uprzywilejowania lub wyeliminowania niektórych wykonawców lub produktów. Zasada ta sprowadza się do uznania, że zamawiający ma obowiązek w taki sposób sporządzić specyfikację warunków zamówienia, aby tworzyła ona przejrzyste i jasne reguły gry dla wszystkich graczy – wykonawców.
Zamawiający powinien opisywać przedmiot zamówienia w oparciu o rzetelnie ustalone i uzasadnione potrzeby, a także zweryfikować, czy wybór konkretnego typu systemu informatycznego, w tym w szczególności “gotowego” produktu, nie sprawia, że znacznie ograniczona zostaje konkurencyjność. Z tego też względu, zamawiający powinien zweryfikować także dostępne na rynku modele dystrybucyjne i licencyjne producentów systemów.
Ocena równoważności
Od zasad przewidzianych powyżej Ustawa przewiduje jeden wyjątek – art. 99 ust. 5 PZP, który stanowi że przedmiot zamówienia można opisać przez wskazanie znaków towarowych, patentów lub pochodzenia, źródła lub szczególnego procesu, który charakteryzuje produkty lub usługi dostarczane przez konkretnego wykonawcę, jeżeli zamawiający nie może opisać przedmiotu zamówienia w wystarczająco precyzyjny i zrozumiały sposób, a wskazaniu takiemu towarzyszą wyrazy „lub równoważny”. Co to oznacza? Zgodnie z definicją ze Słownika Języka Polskiego – gdyż takowa nie istnieje w Ustawie – równoważny oznacza: mający równą wartość, równe znaczenie z czymś.
Ustawa dopuszcza zatem możliwość powołania się przez zamawiającego w dokumencie SWZ na konkretne rozwiązania technologiczne, jeżeli zaznaczy, że do postępowania przystąpić mogą także wykonawcy proponujący rozwiązania o tożsamym sposobie działania czy rezultacie jak opisany. W zakresie postępowań dotyczących branży IT problem oceny równoważności jest niezwykle aktualny. Jest to jedna z najprężniej rozwijających się branży, a każdy kolejny dzień przynosi nowe rozwiązania. Z tego powodu ważnym jest, aby umożliwić przystąpienie do postępowania także wykonawcom stosującym własne rozwiązania, które jednak będą kompatybilne z technologiami stosowanymi już u zamawiającego.
Wymagane uprawnienia do korzystania z systemów informatycznych
Zamawiający powinien szczegółowo opisać w SWZ wymagane i oczekiwane przez niego uprawnienia do korzystania z zamawianego systemu informatycznego oraz elementów składających się na wdrożenie. Wiąże się to z faktem, iż często ani sam podmiot zamawiający, ani osoby, które następnie ten system udoskonalają, nie mają wiedzy na temat jego funkcjonowania. Wiąże się to oczywiście z przeniesieniem praw autorskich do systemu. Obowiązkiem zamawiającego jest precyzyjne określenie, jakie prawa autorskie i do jakiego zakresu systemu mają zostać na niego przeniesione. Przede wszystkim winien zwrócić uwagę na przeniesienie praw do korzystania z systemu, które także obejmie modyfikacje programu oraz do zezwalania na wykonywanie praw zależnych i korzystania ze zmian w programie. W tym zakresie należy odwołać się do przepisów Ustawy Prawo autorskie.
Obecnie niezwykle istotne jest także przekazanie kodów źródłowych. Są to pierwotne “instrukcje” pozwalające na dokonywanie gruntownych zmian w systemie, rozpracowanie jego funkcjonowania i wprowadzanie zmian. Można pokusić się o stwierdzenie, że kod źródłowy jest sercem każdego systemu. Dlatego często w umowach ramowych pojawia się zapis, w którym strony zobowiązują się zdeponować kody źródłowe np. u notariusza. Taki zabieg chroni kody przed nieuprawnionym dostępem do nich lub zaginięciem.
Vendor in-lock
Sformułowanie vendor-in-lock oznacza uzależnienie od dostawcy, co w rzeczywistości przekłada się na sytuację, w której zamawiający jest potencjalnie zakładnikiem jednego ze swoich wykonawców, a jego ewentualna zmiana wiąże się dla zamawiającego z wysokimi kosztami i nakładami pracy. Z tego też powodu zamawiający, zwłaszcza prowadzący postępowanie w zakresie IT, powinni wystrzegać się przywiązywania do jednego, pierwotnego wykonawcy. Rolą zamawiającego jest wybór takiej oferty – szczególnie jeśli chodzi o system informatyczny – aby kolejne postępowania w przedmiocie jakichkolwiek prac związanych z tym systemem nie powodowały konieczności korzystania z usług raz zatrudnionego już wykonawcy. Aby maksymalnie ograniczyć przywiązanie, należy stosować się do zasad wskazanych już powyżej: prowadzić postępowanie zgodnie z zasadą konkurencyjności oraz zadbać o przekazanie kodów źródłowych, uprawnień i praw autorskich.
Wnioski
Prowadzenie postępowań z zakresu zamówień publicznych dotyczących systemów informatycznych wymaga kompleksowego przygotowania na etapie czynności związanych z tworzeniem dokumenty specyfikacyjnego. Przeprowadzenie szerokiej analizy wraz z przeglądem własnych zasobów i możliwości rynkowych, pozwoli uniknąć zamawiającemu sytuacji, w której gotowy produkt nie będzie zharmonizowany z technologiami już stosowanymi u zamawiającego. Minimalizacja ryzyka na tym etapie, a także przemyślany wybór końcowej oferty pozwoli zamawiającemu na zapewnienie cyberbezpieczeństwa systemów, co będzie miało pozytywny wpływ na świadczone przez niego usługi.
Pytania
Umowa powinna czynić zadość wymaganiom formalnym, które są uzależnione od jej formy i zakresu usług. Natomiast z punktu widzenia merytorycznego, zamawiający powinien zawrzeć zapisy, które pozwolą mu maksymalnie zminimalizować ryzyka nieprawidłowej realizacji projektu. Z wielkim pietyzmem należy podejść do kwestii przekazania praw autorskich lub licencji. Determinantą dla tego co konkretnie będzie zawierała umowa, będzie jednak de facto przedmiot zamówienia. Możemy sobie z łatwością wyobrazić, że umowa będzie wyglądała inaczej, gdy zamawiający opowie się za rozwiązaniem polegającym na realizacji przedmiotu zamówienia przy zastosowaniu metody kaskadowej (waterfall model), który polega na wykonywaniu czynności związanych z projektem kaskadowo, krok za krokiem, a inaczej przy zastosowaniu metody (agile software development), w którym proces realizacji zamówienia ewoluuje w ramach tworzenia. Inaczej w takim przypadku będzie wyglądał opis przedmiotu zamówienia, inaczej będą kształtowały się prawa i obowiązki stron, inaczej będzie następowała płatność za usługi.
Tak. Zgodnie z art. 38 Ustawy PZP, jeżeli kilku zamawiających ma wspólne potrzeby w zakresie zapotrzebowania na system informatyczny, a przy tym takie same zasoby technologiczne i zbieżne oczekiwania co do rezultatu, nie ma przeszkód aby połączyli siły w ramach jednego postępowania.
Tak. Model Time&Material oznacza sposób rozliczenia się z wykonawcą, w którym uiszcza się opłatę za faktycznie wykonaną pracę (dosłownie za czas i materiały). Zamawiający może postąpić w ten sposób w szczególności jeśli na etapie tworzenia dokumentu SWZ nie jest w stanie określić w sposób precyzyjny zakresu prac. Czasami dzieje się tak, że w toku wykonywania projektu jego zakres się poszerza, lub zawęża lub też zastana przez wykonawcę infrastruktura wymaga przebudowy. Wówczas także wartość zamówienia będzie ulegała zmianom, proporcjonalnie do zakresu zleconych zadań.
Zaufali nam:
