Dlaczego rozpoznanie potrzeb przed opisaniem zamówienia IT decyduje o całym postępowaniu

Zamawiający często zna główny cel biznesowy, jaki ma spełniać nowy system informatyczny. Trudność pojawia się jednak w momencie, gdy te ogólne założenia trzeba przełożyć na spójny opis przedmiotu zamówienia. Zamówienia w sektorze IT charakteryzują się wyjątkową złożonością technologiczną i prawną. Wymagają one precyzyjnego przetłumaczenia codziennych procesów operacyjnych na konkretne wymagania funkcjonalne oraz parametry wydajnościowe. Brak rzetelnego przygotowania na tym wczesnym etapie sprawia, że dokumentacja przetargowa staje się niejasna. Zmusza to potencjalnych wykonawców do zadawania setek pytań, co wydłuża całą procedurę i zwiększa ryzyko błędnej wyceny projektu.

Rozpoznanie potrzeb oddziela rezultat od technologii

Analiza przedmiotu zamówienia pozwala odgraniczyć oczekiwany skutek wdrożenia od narzucania z góry wybranego narzędzia informatycznego. Art. 83 ustawy Prawo zamówień publicznych nakłada na zamawiającego obowiązek dokonania weryfikacji potrzeb i wymagań przed wszczęciem postępowania. Krok ten zmusza jednostki publiczne do zbadania rynku i oceny, czy zamierzony cel da się zrealizować różnymi metodami. Dokumentacja nie powinna ograniczać się do jednej technologii czy konkretnego producenta oprogramowania. Zgodnie z art. 101 wspomnianej ustawy podmiot publiczny może opisać przedmiot zamówienia poprzez wskazanie wymagań dotyczących funkcjonalności oraz oczekiwanej wydajności. Taki mechanizm sprzyja zachowaniu uczciwej konkurencji i ułatwia wykonawcom proponowanie innowacyjnych rozwiązań.

Rekomendacje Prezesa Urzędu Zamówień Publicznych ujęte w Tomie II bezpośrednio odnoszą się do specyfiki systemów informatycznych. Ósma rekomendacja ogólna podkreśla konieczność opierania opisu zamówienia na wcześniej ustalonych, rzeczywistych potrzebach instytucji. W praktyce oznacza to szczegółowe określenie pożądanego efektu działania systemu dla końcowego odbiorcy. Dopiero w kolejnym kroku definiuje się minimalne techniczne środki prowadzące do jego osiągnięcia. Pominięcie tego podziału często kończy się przygotowaniem specyfikacji stworzonej pod gotowe oprogramowanie dostępne na rynku. Takie działanie drastycznie zawęża krąg oferentów, narusza przepisy prawa i nierzadko stanowi podstawę do wniesienia odwołania.

Zbieranie danych o procesach i szacowanie ryzyka

Przed sformułowaniem ostatecznych kryteriów funkcjonalnych niezbędne jest zmapowanie środowiska pracy przyszłego systemu. Obejmuje to zebranie dokładnych informacji o planowanej liczbie użytkowników, przypisanych im uprawnieniach oraz hierarchii ról w organizacji. Równie ważne pozostaje zdefiniowanie punktów styku. Nowe rozwiązanie musi zazwyczaj wymieniać informacje z już działającymi w instytucji bazami danych, co wymaga zaplanowania odpowiednich interfejsów programistycznych. Należy także ustalić ramy utrzymania infrastruktury po zakończeniu wdrożenia, w tym czasy reakcji na awarie oraz zasady aktualizacji.

Praktyka pokazuje, że opisy przedmiotu zamówienia często skupiają się wyłącznie na samym dostarczeniu licencji lub napisaniu głównego kodu programu. Pominięcie kwestii wdrożenia, rygorystycznych testów akceptacyjnych czy bezpiecznej migracji danych historycznych zniekształca ocenę ryzyk. Braki te dają o sobie znać już na etapie planowania budżetu przez zamawiającego. Te dodatkowe procesy bezpośrednio wpływają na zakres obowiązków wykonawcy i wymagają zabezpieczenia odpowiedniego czasu w harmonogramie prac. Błędnie zdiagnozowane uwarunkowania brzegowe zawężają pole dopuszczalnych rozwiązań informatycznych. Na etapie realizacji zawartej umowy wywołuje to spory o faktyczny zakres zamówienia lub podział odpowiedzialności między stronami. Niepełna dokumentacja analityczna utrudnia ponadto weryfikację, czy zaoferowane przez wykonawcę rozwiązanie faktycznie spełnia wymóg równoważności.

Prawidłowo przeprowadzona analiza potrzeb porządkuje całą strukturę dokumentacji przetargowej. Tworzy ona stabilną podstawę do prowadzenia procedury udzielenia zamówienia publicznego i minimalizuje ryzyko unieważnienia postępowania. Pozwala uniknąć niejasności interpretacyjnych przy ocenie funkcjonalności proponowanego oprogramowania. Działająca we Wrocławiu Tomasz Raczyński Kancelaria Adwokacka zajmuje się obsługą prawną przedsiębiorców z branży IT startujących w przetargach. Zakres świadczonych usług obejmuje analizę dokumentacji pod kątem zgodności z prawem zamówień publicznych oraz reprezentację podmiotów na etapie postępowań przed Krajową Izbą Odwoławczą. Rzetelne przygotowanie specyfikacji na wczesnym etapie stanowi fundament bezpiecznej realizacji każdego złożonego projektu informatycznego.