IT w zamówieniach publicznych – OPZ i SWZ.

IT w zamówieniach publicznych wymaga jednoznacznych zapisów w OPZ i SWZ, które definiują architekturę, integracje systemowe oraz wymagania niefunkcjonalne dla Zamawiającego.

Nasze usługi z zakresu zamówień publicznych w IT, OT, ICT

Pełna dokumentacja OPZ

Przygotowujemy kompletną dokumentację OPZ i SWZ dla projektów z zakresu IT, zgodną z przepisami Prawa Zamówień Publicznych. Projektujemy wymagania w oparciu o cele biznesowe, procesy, dane i architekturę organizacji. Dokumentacja zapewnia jednoznaczność zapisów, porządkuje integracje, role i zakresy prac, eliminuje dowolność działań i prowadzi do stabilnych wdrożeń. Obsługujemy również dokumentacje OPZ i SWZ marketing i cyber.

Audyty OPZ i SWZ

Przeprowadzamy audyt dokumentacji OPZ i SWZ na etapie przygotowania albo po zakończeniu postępowania. Analizujemy zapisy pod kątem zgodności z przepisami PZP, spójności formalnej oraz jednoznaczności wymagań technicznych i organizacyjnych. Audyt pozwala zidentyfikować ryzyka interpretacyjne, potencjalne podstawy odwołań oraz błędy mogące wpływać na przebieg lub wynik postępowania.

Wsparcie komisji

Zapewniamy merytoryczne wsparcie komisji przetargowej na etapie prowadzenia postępowania. Wspieramy prawidłową interpretację zapisów OPZ i SWZ, przygotowanie odpowiedzi na pytania wykonawców oraz weryfikację ofert pod kątem zgodności z wymaganiami dokumentacji. Działania są prowadzone z uwzględnieniem przepisów Prawa Zamówień Publicznych oraz praktyki postępowań w obszarze IT.

Najczęstsze wyzwania w projektach IT, OT, ICT

W zamówieniu publicznym IT dokumentacja sprzętowa powstaje bez analizy obciążeń, procesów operacyjnych i rzeczywistego sposobu wykorzystania infrastruktury. Specyfikacja koncentruje się na parametrach technicznych, a nie na roli sprzętu w zapewnieniu wydajności, dostępności i ciągłości działania. Zakupy są realizowane zgodnie z OPZ, lecz bez odniesienia do faktycznych potrzeb zespołów i systemów.

Efekt:
Infrastruktura IT jest formalnie zgodna z zamówieniem, ale niedopasowana do pracy organizacji. Pojawiają się wąskie gardła wydajnościowe, przeciążenia lub niewykorzystane zasoby, rosną koszty utrzymania, a konieczność doposażenia lub wymiany sprzętu pojawia się krótko po wdrożeniu.

Wymagania powstają bez analizy procesów i realnych potrzeb użytkowników. Do dokumentacji trafiają funkcjonalności projektowane „na zapas” lub takie, które są łatwe do wdrożenia, ale nie wspierają kluczowych zadań organizacji. Brakuje priorytetyzacji opartej na wpływie na procesy i efektywność pracy.

Efekt:
System jest rozbudowany, ale niepraktyczny. Użytkownicy omijają go na rzecz rozwiązań zastępczych, procesy nie przyspieszają, a organizacja ponosi koszty utrzymania elementów, które nie przynoszą realnej wartości operacyjnej.

W wielu projektach OPZ opisuje systemy i moduły bez powiązania ich z infrastrukturą, procesami operacyjnymi i realnym sposobem pracy organizacji. Brakuje opisu środowisk, zależności infrastrukturalnych, ról systemów w procesach oraz ograniczeń wynikających z architektury technicznej. Procesy są projektowane w oderwaniu od możliwości infrastruktury, a infrastruktura bez odniesienia do przebiegu pracy i odpowiedzialności użytkowników.

Efekt:
Środowisko jest niestabilne, procesy nie działają zgodnie z założeniami, a systemy nie wspierają pracy operacyjnej. Pojawiają się ręczne obejścia, przeciążenia infrastruktury, błędy w przepływie danych i opóźnienia w realizacji zadań. Organizacja ponosi koszty utrzymania rozwiązań, które nie są dopasowane do realnych procesów.

Zakres OPZ koncentruje się na klasycznych funkcjonalnościach systemu, pomijając automatyzacje procesów, integracje danych, warstwy analityczne oraz możliwości wykorzystania narzędzi AI i mechanizmów uczenia maszynowego. Dokumentacja nie definiuje punktów automatyzacji, źródeł i przepływów danych ani sposobu integracji z innymi systemami. Brakuje także wymagań dotyczących skalowalności, jakości danych i gotowości środowiska na rozwój technologiczny.

Efekt:
System nie generuje przewagi operacyjnej i szybko traci aktualność. Automatyzacje muszą być doprojektowywane po wdrożeniu, integracje są kosztowne, a potencjał danych i AI pozostaje niewykorzystany. Organizacja traci czas i środki na korekty, które powinny zostać zaprojektowane na etapie dokumentacji.

Dokumentacja nie określa struktur danych, standardów integracyjnych, protokołów komunikacji ani zasad rozwoju i migracji systemu. Wiedza o rozwiązaniu pozostaje po stronie wykonawcy, a organizacja nie dysponuje pełnym obrazem architektury ani danymi niezbędnymi do zmiany dostawcy lub dalszego rozwoju systemu w trybie konkurencyjnym.

Efekt:
Wykonawca zyskuje przewagę negocjacyjną, rosną koszty utrzymania i zmian, wydłużają się terminy realizacji, a organizacja traci elastyczność i kontrolę nad środowiskiem IT. Rozwój technologiczny i procesowy staje się zależny od jednego podmiotu.

Dokumentacja nie zawiera precyzyjnych informacji o strukturach danych, formatach, API, częstotliwościach synchronizacji ani ograniczeniach systemów źródłowych i docelowych. Integracje są oparte na założeniach, a nie na rzeczywistym obrazie środowiska technicznego i jego ograniczeń.

Efekt:
Integracje są niestabilne, dane niespójne, a procesy podatne na błędy. Wdrożenie wymaga wielu iteracji poprawek, rosną koszty i opóźnienia, a codzienna praca użytkowników zostaje zakłócona

W wielu projektach wymagania bezpieczeństwa, modele uprawnień, zasady migracji danych i struktury licencyjne są opisywane fragmentarycznie i bez powiązania z architekturą systemów, procesami operacyjnymi i logiką danych. Elementy te nie są projektowane razem z rozwiązaniem, lecz dokładane na późniejszym etapie, bez wpływu na kluczowe decyzje technologiczne.
Efekt:
Systemy stają się podatne na incydenty, błędy konfiguracyjne i przerwy w działaniu. Koszty korekt rosną, pojawiają się problemy audytowe i licencyjne, a wdrożenie może zostać opóźnione, ograniczone lub niemożliwe do odebrania bez kosztownych zmian.

Nasze podejście do zamówień publicznych w IT, OT, ICT

Przekładamy cele biznesowe na architekturę rozwiązań w dokumentacji OPZ i SWZ.

W pierwszym kroku określamy kierunki rozwoju organizacji: skalę, zakres usług, zmiany operacyjne, nowe obowiązki i oczekiwania wobec IT w perspektywie kolejnych lat. Identyfikujemy, jak organizacja chce działać w przyszłości i jakie decyzje biznesowe ma wspierać system, a nie tylko jakie problemy ma rozwiązać tu i teraz.

Na tej podstawie projektujemy architekturę wymagań, która umożliwia rozwój, skalowanie operacji i integrację kolejnych systemów. Dopiero w tym kontekście analizujemy procesy, dane i sposób pracy użytkowników, aby przełożyć cele biznesowe na spójne wymagania funkcjonalne i niefunkcjonalne. Dokumentacja opisuje rozwiązanie jako element długofalowego rozwoju organizacji, a nie jednorazowe wdrożenie.

Architektura IT w zamówieniach publicznych jako fundament stabilnego wdrożenia

Tworzymy dokumentację w logice docelowego funkcjonowania systemu, a nie jego jednorazowego wdrożenia. Opisujemy procesy, role, przepływy informacji, integracje i zależności w taki sposób, aby rozwiązanie mogło się rozwijać, skalować i adaptować do kolejnych zmian organizacyjnych oraz technologicznych.

Dokumentacja powstaje w oparciu o aktualną analizę środowiska IT oraz planowany kierunek rozwoju organizacji. Projektujemy wymagania jednoznacznie i inżyniersko, eliminując opisy ogólne i interpretacyjne, które utrudniają realizację, prowadzą do rozbieżności i ograniczają możliwość dalszego rozwoju systemu.

Eliminujemy luki poprzez precyzyjne kryteria, wymagania i mierzalność.

Projektujemy dokumentację jako element zarządzania projektem, a nie zbiór niezależnych zapisów. Identyfikujemy obszary, w których projekty IT najczęściej się rozjeżdżają: integracje, modele danych, bezpieczeństwo, licencje, migracje, harmonogramy i zakresy odpowiedzialności. Dbamy o to, aby wszystkie te elementy były opisane spójnie i w jednej logice decyzyjnej.

Precyzyjnie definiujemy obszary krytyczne oraz ich wzajemne zależności, eliminując luki i sprzeczności między wymaganiami. Dzięki temu dokumentacja łączy cele biznesowe, architekturę systemu i realizację w jeden uporządkowany proces. Projekt pozostaje przewidywalny, zarządzalny i możliwy do skutecznego wdrożenia oraz rozwoju.

Co zapewnia dobrze napisana dokumentacja przetargowa IT, OT, ICT, w definicji zamówienia publicznego

Zamówienie publiczne IT zgodne z potrzebami organizacji.

Dokumentacja powstaje na podstawie celów biznesowych, sposobu działania organizacji oraz rzeczywistych potrzeb użytkowników, a nie na bazie uniwersalnych list funkcjonalności.

OPZ porządkuje wymagania w oparciu o procesy, dane i odpowiedzialności, uwzględniając zarówno bieżące potrzeby operacyjne, jak i planowany rozwój organizacji. Dzięki temu wykonawca projektuje rozwiązanie odpowiadające faktycznemu modelowi pracy, a nie abstrakcyjnemu opisowi systemu.

Powstaje system, który wspiera kluczowe procesy organizacji i jest wykorzystywany zgodnie z potrzebami biznesowymi.

Ograniczone zostają obejścia, ręczne operacje i konieczność wprowadzania kosztownych korekt po wdrożeniu.

Dokumentacja OPZ SWZ dla architektury IT, zaprojektowana długoterminowo.

Wymagania są osadzone w architekturze uwzględniającej kierunek rozwoju organizacji, a nie wyłącznie aktualny stan środowiska.

Dokumentacja opisuje zależności między systemami, danymi i jednostkami organizacyjnymi, a także przewiduje możliwość rozbudowy i integracji w kolejnych latach. OPZ buduje spójny model rozwoju środowiska IT, a nie jednorazowe rozwiązanie.

Kolejne projekty mogą być realizowane jako rozszerzenia istniejącej architektury, a nie jej przebudowy.

Zmniejsza się ryzyko kosztownych zmian strukturalnych i destabilizacji środowiska IT.

Zamówienie publiczne przewiduje automatyzację i rozwój IT.

Dokumentacja uwzględnia skalowalność, integracje danych oraz miejsca potencjalnej automatyzacji procesów.

OPZ nie zamyka rozwiązania w obecnym sposobie pracy, lecz tworzy warunki do dalszej cyfryzacji i wykorzystania nowych technologii. Wymagania są projektowane w perspektywie kilku lat, a nie jednego wdrożenia.

System pozostaje użyteczny i możliwy do rozwoju bez konieczności jego wymiany.

Organizacja zachowuje zdolność adaptacji do zmian technologicznych i operacyjnych.

Jasne kryteria stabilnych procesów i integracji IT.

Dokumentacja precyzyjnie opisuje przepływy informacji, struktury danych oraz zależności między systemami.

Wymagania integracyjne są jednoznaczne, wykonalne i osadzone w rzeczywistych ograniczeniach środowiska. OPZ eliminuje sytuacje, w których kluczowe zależności ujawniają się dopiero na etapie wdrożenia.

Integracje są stabilne, a procesy spójne i przewidywalne.

Wdrożenie przebiega bez wielokrotnych korekt i przestojów wynikających z braków w dokumentacji.

Bezpieczeństwo i ciągłość systemu.

OPZ definiuje bezpieczeństwo, licencje, migracje i utrzymanie jako integralne elementy architektury rozwiązania.

Wymagania te są spójne z procesami, danymi i odpowiedzialnościami, a nie dopisywane fragmentarycznie. Dokumentacja jasno określa standard, który musi zostać dostarczony i odebrany.

Organizacja zachowuje kontrolę nad systemem, danymi i kosztami jego utrzymania.

Ograniczone zostają ryzyka audytowe, migracyjne i uzależnienie od jednego wykonawcy.

Zamówienie publiczne określa budżet na IT zgodnie z kryteriami.

Zakres projektu wynika z analizy procesów i priorytetów organizacji, a nie z nadmiarowych wymagań funkcjonalnych.

OPZ porządkuje zakres w sposób umożliwiający racjonalne decyzje budżetowe i eliminację elementów o niskiej wartości operacyjnej. Dokumentacja wspiera świadome inwestowanie w obszary kluczowe dla działania organizacji.

Środki finansowe są przeznaczane na rozwiązania realnie poprawiające efektywność i stabilność operacyjną.

Koszty wdrożenia i utrzymania są lepiej kontrolowane, a zwrot z inwestycji bardziej przewidywalny.

Etapy pracy nad dokumentacją przetargową IT, OT, ICT

Analiza

Etap 1 i 2

Analiza kierunku rozwoju IT.

Definiujemy, jaki efekt organizacja chce osiągnąć, zarówno operacyjnie, jak i strategicznie – dzisiaj i w przyszłości. Ustalamy, w jaki sposób system ma wspierać ludzi, procesy i dane na podstawie informacji przekazanych przez zamawiającego. To etap, w którym powstaje realna potrzeba, a nie lista funkcjonalności.

W tym kroku:
Ustalamy cel projektu i oczekiwany rezultat. Eliminujemy ryzyko tworzenia rozwiązania zgodnego z opisem, lecz niezgodnego z rzeczywistymi potrzebami biznesu.

Audyt procesów IT, systemów i zależności.

Analizujemy sposób działania organizacji na podstawie dokumentacji, przepływów informacji, jakości danych, zależności między systemami oraz ograniczeń technologicznych. Identyfikujemy punkty krytyczne i obszary, które mogą prowadzić do opóźnień i błędów podczas realizacji zamówienia.

W tym kroku:
Ujawniamy ryzyka, które mogłyby zablokować projekt już na etapie wdrożenia, takie jak brak danych wejściowych, niespójne integracje, czy problemy związane z bezpieczeństwem.

Założenia

Etap 3 i 4

Projektowanie architektury rozwiązań IT

Tworzymy spójną architekturę wymagań obejmującą procesy, dane i integracje, zgodną z kierunkiem cyfryzacji i rozwoju organizacji. Uwzględniamy przyszłe projekty, automatyzacje, integracje, skalowalność oraz miejsca krytyczne, w których systemy będą musiały współpracować.

W tym kroku:
Eliminujemy ryzyko niekompatybilności z kolejnymi systemami, dublowania prac, przebudów i kosztownych zmian.

Określenie zasad integracji, licencji i migracji.

Określamy wymagania dotyczące struktur danych, komunikacji między systemami, modeli licencyjnych, zasad rozwoju rozwiązania, standardów bezpieczeństwa oraz wymagań migracyjnych. Definiujemy przyszłe mechanizmy współpracy między systemami i zasady ich rozwijania.

W tym kroku:
Zabezpieczamy organizację przed niekontrolowanymi kosztami utrzymania, błędami integracyjnymi i ryzykami migracji.

Specyfikacja

Etap 5 i 6

Kryteria wymagań technicznych IT

Na podstawie architektury wymagań tworzymy jednoznaczne, kompletne i wykonalne wymagania funkcjonalne, niefunkcjonalne i technologiczne. Opisujemy logikę działania systemu, parametry techniczne, scenariusze użytkownika, wymagania dotyczące danych, integracji, wydajności, bezpieczeństwa oraz przyszłego rozwoju rozwiązania.

W tym kroku:
Eliminujemy interpretacje wykonawcy, blokujemy rozwiązania pozorne i unikamy budowy modułów, które nie wnoszą wartości operacyjnej.

Przygotowanie kompletnej dokumentacji.

Przygotowujemy pełny i spójny zestaw dokumentów niezbędnych do przeprowadzenia postępowania: OPZ i SWZ, załączniki techniczne, kryteria oceny ofert, wymagania formalne oraz logiczny model etapów prac i zasad odbioru. Dokumentacja jest projektowana w logice realizacyjnej, opisując elementy możliwe do wykonania, zweryfikowania i rozliczenia.

W tym kroku:
Zapewniamy spójność między ryzykami, wymaganiami, umową i zakresem prac. Eliminujemy luki, niespójności i różnice które mogą pojawić podczas tworzenia dokumentacji.

Postępowanie

Etap 7

Wsparcie zamawiającego w wyborze wykonawcy oraz w odbiorze prac.

Analizujemy oferty, porównujemy je z dokumentacją i identyfikujemy elementy mogące wpłynąć na jakość, koszt lub przebieg realizacji. Wspieramy zamawiającego w wyborze wykonawcy oraz w odbiorze prac, weryfikując zgodność z OPZ i SWZ, kompletność realizacji, jakość przygotowanych materiałów i terminowość wykonania. Zapewniamy merytoryczne wsparcie, aby projekt został zrealizowany zgodnie z ustalonym celem.

W tym kroku:
Dbamy o spójną realizację projektu, eliminujemy ryzyka zakresowe i chronimy projekt przed zmianami po stronie wykonawcy, które mogłyby obniżyć efekt działań.

Dlaczego warto z nami przeprowadzić zamówienie publiczne

Praktyka

Za przygotowanie dokumentacji odpowiada zespół, który prowadził projekty IT i Cyber w pełnym cyklu życia, od analizy procesów i projektowania architektury wymagań, przez bezpieczeństwo i integracje, aż po wsparcie odbioru prac po stronie zamawiającego. Dzięki temu dokumentacja jest realistyczna, wykonalna i zgodna z praktyką wdrożeniową, a nie tworzona na podstawie szablonu lub w oderwaniu od technologii. Każdy element wynika z doświadczenia operacyjnego i praktycznej wiedzy, a nie z założeń teoretycznych.

Przejrzystość

Projektujemy dokumentację w oparciu o zasady, stosowane przy tworzeniu architektury bezpieczeństwa. Opisujemy procesy, role, integracje, zależności technologiczne, scenariusze zagrożeń i logikę działania w taki sposób, aby odzwierciedlały realia. OPZ wynikają z analizy ryzyk i architektury, a nie z katalogów narzędzi czy interpretacji wykonawcy. Dzięki temu dokumentacja prowadzi projekt, blokuje uproszczenia, chroni zamawiającego i zapewnia że wdrożone zabezpieczenia realnie podnoszą odporność organizacji na kolejne lata.

Doświadczenie

W projekcie uczestniczą specjaliści z certyfikacjami CISSP, CISM, CISA, CRISC, CEH, ISO IEC 27001 Lead Auditor, CompTIA Security Plus, CompTIA CySA Plus, CCSP oraz z doświadczeniem w projektach SOC, SIEM, IAM, DR BCP i architekturze chmurowej. Taki poziom kompetencji sprawia, że dokumentacja od początku uwzględnia kierunek rozwoju organizacji, jej bezpieczeństwo, architekturę danych, ryzyka, integracje, migracje, licencje, utrzymanie oraz pozostałe standardy branżowe – czyli kluczowe obszary rozwoju projektów IT.

Zapraszamy do kontaktu

Najczęstsze pytania

Jaki jest zakres Waszej odpowiedzialności w projektach PZP IT?

Odpowiadamy za przygotowanie spójnej, logicznej i rozliczalnej dokumentacji IT, która prowadzi projekt od celu biznesowego do wykonalnego wdrożenia systemu. Definiujemy wymagania funkcjonalne i niefunkcjonalne, architekturę wymagań, kryteria oceny ofert oraz zasady odbioru prac. Nie realizujemy wdrożeń w projektach, w których przygotowujemy dokumentację. Naszą rolą jest zaprojektowanie projektu odpornego na błędy strukturalne, interpretacyjne i organizacyjne.

Gdzie kończy się Wasza rola, a zaczyna odpowiedzialność wykonawcy?

Nasza rola kończy się na zaprojektowaniu dokumentacji oraz wsparciu zamawiającego w wyborze wykonawcy i odbiorach. Odpowiedzialność za dobór technologii, implementację, konfigurację, integracje i utrzymanie systemu spoczywa po stronie wykonawcy. My projektujemy ramy architektury, zakres i standardy, wykonawca realizuje je w praktyce.

Czy zastępujecie firmę wdrożeniową, integratora lub dostawcę IT?

Nie. Posiadamy doświadczenie wdrożeniowe, ale nie realizujemy wdrożeń w projektach, w których przygotowujemy OPZ lub SWZ. Naszą funkcją jest zaprojektowanie dokumentacji w taki sposób, aby wybrany wykonawca dostarczył system zgodny z celem projektu, a nie jedynie formalnie zgodny z opisem.

Jak wygląda Wasza współpraca z wykonawcami wyłonionymi w przetargu?

Współpraca ma charakter merytoryczny i kontrolny. Analizujemy oferty pod kątem zgodności z dokumentacją, architekturą i założonym efektem projektu, a następnie wspieramy zamawiającego w odbiorach. Nie zarządzamy wykonawcą operacyjnie ani nie ingerujemy w jego decyzje techniczne, o ile mieszczą się one w ramach OPZ i SWZ.

Jak opisać projekt IT, aby wykonawca dobrze go zrozumiał?

Punktem wyjścia nie są technologie, lecz cel biznesowy, procesy i wymagany efekt operacyjny. Dobrze przygotowany opis definiuje rolę systemu, zakres odpowiedzialności, integracje, dane, ograniczenia oraz sposób odbioru. Klarowność na tym etapie eliminuje większość problemów na etapie wdrożenia.

Jak uniknąć sytuacji, w której system spełnia OPZ, ale nie działa w praktyce?

Najczęstszą przyczyną jest brak powiązania wymagań z realnymi procesami, danymi i użytkownikami. Gdy dokumentacja jasno określa, jaki problem system ma rozwiązać i w jakim kontekście będzie używany, rozwiązanie jest adekwatne. Skuteczność rośnie wtedy, gdy wymagania są jednoznaczne, weryfikowalne i powiązane z odbiorami.

Jak ustalić budżet projektu IT w przetargu?

Budżet powinien wynikać z zakresu procesów, liczby użytkowników, integracji, poziomu bezpieczeństwa i oczekiwanego czasu życia rozwiązania. Kluczowa jest analiza środowiska i celu projektu, a nie kopiowanie kosztów z innych postępowań. Racjonalny budżet to efekt świadomych decyzji projektowych, a nie kompromisów wymuszonych po wyborze wykonawcy.

Jak zabezpieczyć możliwość rozwoju systemu i zmiany wykonawcy?

Podstawą jest precyzyjne opisanie danych, integracji, interfejsów, licencji i zasad migracji już w OPZ. Dokumentacja musi zapewniać przejrzystość architektury i dostęp do kluczowych elementów rozwiązania. Pozwala to rozwijać system konkurencyjnie i ogranicza ryzyko vendor lock.

Czym różni się dobrze przygotowany OPZ IT od opisu technicznego lub analizy przedwdrożeniowej?

Analiza opisuje stan obecny, natomiast OPZ projektuje przyszłe wdrożenie. OPZ nie diagnozuje problemów, lecz definiuje wymagania, standardy, zakres odpowiedzialności i sposób ich weryfikacji. Dzięki temu wykonawcy pracują w tych samych ramach, a zamawiający może rzetelnie porównać oferty i odebrać efekt.

Jak zdefiniować wymagania IT, aby były mierzalne i rozliczalne?

Wymagania muszą określać nie tylko co ma powstać, ale jak system ma działać i jak zostanie sprawdzony. Kluczowe są scenariusze odbiorowe, kryteria akceptacji i jednoznaczne punkty kontroli. Dobrze zdefiniowane wymagania pozwalają rozliczyć wykonawcę z efektu, a nie z samego zakresu prac.

Jak uniknąć sytuacji, w której projekt jest formalnie zgodny z OPZ, ale nie spełnia celu biznesowego?

Przyczyną jest brak spójności między celem, wymaganiami i odbiorami. Jeśli dokumentacja nie definiuje, co oznacza sukces projektu, wykonawca optymalizuje realizację pod formalną zgodność. Ryzyko znika, gdy OPZ konsekwentnie prowadzi od celu biznesowego, przez architekturę wymagań, aż po mierzalne efekty operacyjne.