Artykuł nr 4

Błędy w SWZ i OPZ – które problemy najczęściej ujawniają się dopiero po ogłoszeniu postępowania?

Adam Gierasimczuk | Expert Design
Aktualizacja: 19 września 2026 r.

SWZ i OPZ mogą wyglądać na gotowe.

Dokumenty przeszły kilka rund poprawek. Prawnik przeczytał projekt umowy. Zespół techniczny zaakceptował wymagania. Formularze zostały dołączone. Terminy sprawdzone. Postępowanie zostaje opublikowane.

I dopiero wtedy wykonawca zadaje pytanie:

„Czy wymagany termin wynosi 90 czy 120 dni?”

Albo:

„W jaki sposób mamy wycenić element, którego nie ma w formularzu cenowym?”

Albo:

„Która wersja wymagania jest obowiązująca – ta z OPZ czy z projektu umowy?”

To właśnie moment, w którym ujawnia się szczególna cecha błędów w dokumentacji przetargowej:

wiele problemów nie wygląda jak błąd, dopóki ktoś z zewnątrz nie spróbuje zastosować dokumentacji w praktyce.

Dlatego kontrola SWZ i OPZ przed publikacją powinna obejmować nie tylko poprawność poszczególnych zapisów.

Powinna próbować przewidzieć:

Jakie pytania, sprzeczności i problemy mogą ujawnić się dopiero po ogłoszeniu postępowania?

---

Dokumentacja przed publikacją i po publikacji to dwa różne światy

Przed publikacją zespół zna kontekst.

Wie:

• dlaczego zmieniono wymaganie;
• która tabela jest najnowsza;
• co autor miał na myśli;
• z czego wynika termin;
• który załącznik zastąpił poprzedni.

Po publikacji wykonawca ma tylko dokumenty.

Nie zna historii pracy nad nimi.

Nie wie, że:

„to jest oczywiste, bo omawialiśmy to na spotkaniu”.

Dla niego obowiązuje wyłącznie to, co można odczytać z opublikowanego pakietu.

Dlatego jednym z najlepszych testów jakości dokumentacji jest:

Czy osoba, która nie uczestniczyła w jej tworzeniu, odczyta ją tak samo jak zespół zamawiającego?

---

Radar po publikacji – gdzie najczęściej ujawniają się problemy?

Można potraktować końcową kontrolę jak Radar po publikacji.

Zamiast pytać:

„Czy dokument wygląda dobrze?”

pytamy:

„Co prawdopodobnie zakwestionuje albo będzie musiał doprecyzować wykonawca?”

Radar obejmuje między innymi:

Obszar	Pytanie kontrolne
Zakres	Czy wszystkie dokumenty opisują to samo zamówienie?
Terminy	Czy wszędzie obowiązują te same daty i okresy?
Cena	Czy wykonawca może prawidłowo wycenić wszystkie obowiązki?
Kryteria	Czy formularze pozwalają podać informacje wymagane do oceny?
Umowa	Czy obowiązki umowne odpowiadają OPZ?
Załączniki	Czy wszystkie wersje są aktualne?
Odbiory	Czy można jednoznacznie potwierdzić wykonanie wymagania?
Zmiany	Czy ostatnia poprawka została przeniesiona do całego pakietu?

---

Problem nr 1. SWZ i OPZ opisują podobne, ale nie identyczne zamówienie

To jeden z najpoważniejszych problemów.

SWZ może opisywać przedmiot zamówienia ogólnie.

OPZ – szczegółowo.

Projekt umowy – przez obowiązki wykonawcy.

Formularz cenowy – przez pozycje podlegające wycenie.

Jeżeli zakres został zmieniony tylko w jednym miejscu, każdy dokument może pozostać logiczny osobno, a mimo to cały pakiet będzie niespójny.

Przykład modelowy

SWZ:

dostawa 120 urządzeń.

OPZ:

opis parametrów dla 100 urządzeń.

Formularz:

120 pozycji.

Projekt umowy:

odwołanie do OPZ.

Która wartość obowiązuje?

Tego problemu nie rozwiązuje korekta językowa.

Potrzebna jest kontrola przekrojowa.

---

Problem nr 2. Terminy nie są takie same w całym pakiecie

Terminy są szczególnie podatne na rozjazdy.

Mogą występować w:

• SWZ;
• OPZ;
• projekcie umowy;
• harmonogramie;
• formularzu;
• SLA;
• tabeli etapów.

Przykład:

Zdarzenie	SWZ	OPZ	Umowa	Wynik
realizacja całości	120 dni	120 dni	120 dni	zgodne
szkolenie	7 dni	7 dni	brak	do sprawdzenia
odbiór	10 dni	14 dni	14 dni	niespójność
usunięcie wad	5 dni	—	5 dni	zgodne

Największe ryzyko powstaje wtedy, gdy różnice są niewielkie.

90 i 120 dni łatwo zauważyć.

10 i 14 dni znacznie łatwiej przeoczyć.

---

Problem nr 3. OPZ wymaga czegoś, czego formularz nie pozwala zaoferować

To klasyczna luka pomiędzy wymaganiem a mechanizmem składania oferty.

OPZ może wymagać:

• dodatkowego modułu;
• usługi serwisowej;
• kilku wariantów;
• szkolenia;
• określonego okresu wsparcia.

Ale formularz cenowy nie zawiera pozycji, w której można to wycenić.

Powstaje pytanie:

Czy koszt powinien zostać wliczony gdzie indziej?

Jeżeli dokumentacja tego nie wyjaśnia, wykonawcy mogą przyjąć różne założenia.

A wtedy oferty mogą przestać być łatwo porównywalne.

---

Problem nr 4. Projekt umowy zawiera inny obowiązek niż OPZ

OPZ i projekt umowy często powstają w różnych zespołach.

To naturalne.

Problem pojawia się wtedy, gdy oba dokumenty rozwijają się niezależnie.

Przykład:

OPZ:

czas reakcji serwisu – 4 godziny.

Umowa:

6 godzin.

Albo:

OPZ:

szkolenie 3 grup użytkowników.

Umowa:

szkolenie użytkowników – bez określenia liczby grup.

Takie różnice mogą mieć bezpośredni wpływ na:

• cenę;
• harmonogram;
• ryzyko wykonawcy;
• późniejszy odbiór.

---

Problem nr 5. W dokumentacji pozostaje odwołanie do starego załącznika

Dokumentacja jest aktualizowana.

Załącznik nr 4 zostaje zastąpiony nowym.

Ale w SWZ nadal występuje:

„zgodnie z tabelą 7 załącznika nr 4”.

Po zmianie struktury tabela 7 może już nie istnieć.

To częsty rodzaj błędu wersyjnego.

Nie wygląda poważnie podczas czytania dokumentu głównego.

Problem ujawnia się dopiero wtedy, gdy ktoś próbuje wykonać instrukcję.

---

Problem nr 6. Kryterium oceny nie odpowiada formularzowi

Jeżeli SWZ przyznaje punkty za określony parametr, wykonawca musi mieć możliwość jednoznacznego zadeklarowania tej wartości.

Przykład:

SWZ:

dodatkowe punkty za wydłużony okres gwarancji.

Formularz:

brak pola dotyczącego gwarancji.

Wtedy pojawia się pytanie:

W jaki sposób wykonawca ma złożyć informację podlegającą punktacji?

Problem może dotyczyć również:

• doświadczenia;
• parametrów technicznych;
• terminu;
• jakości;
• dodatkowych funkcjonalności.

---

Problem nr 7. Jednostki są spójne językowo, ale nie znaczeniowo

Przykłady:

• miesięcy zamiast dni;
• netto zamiast brutto;
• kW zamiast MW;
• MB zamiast GB;
• liczby stanowisk zamiast liczby użytkowników.

To szczególnie niebezpieczne w tabelach.

Liczba może wyglądać prawidłowo.

Problemem jest jednostka.

Dlatego każdą ważną wartość warto sprawdzać jako parę:

wartość + jednostka

a nie samą liczbę.

---

Problem nr 8. Wymaganie jest formalnie zapisane, ale nie da się go obiektywnie odebrać

Przykład:

„System powinien działać szybko.”

Albo:

„Interfejs powinien być intuicyjny.”

Albo:

„Raport ma być wysokiej jakości.”

Jak stwierdzić spełnienie?

Jeżeli wymaganie wpływa na odbiór, powinno być możliwe wskazanie:

jakiego dowodu oczekujemy.

W przeciwnym razie konflikt może pojawić się dopiero po wykonaniu zamówienia.

---

Problem nr 9. Równoważność jest deklarowana, ale warunki jej oceny są niejasne

Jeżeli dokumentacja dopuszcza rozwiązania równoważne, trzeba ustalić:

• jakie parametry są istotne;
• w jaki sposób wykonawca ma wykazać równoważność;
• jakie dokumenty powinien przedstawić;
• według jakiego kryterium zostanie oceniona.

Samo użycie słowa:

„lub równoważny”

nie zawsze rozwiązuje problem praktyczny.

Jeżeli warunki oceny są niejasne, pytania pojawią się dopiero po publikacji.

---

Problem nr 10. Jedna poprawka tworzy nową niespójność

To szczególnie częste tuż przed publikacją.

Zespół zauważa:

termin jest zbyt krótki.

Zmienia:

90 → 120 dni.

Poprawia SWZ.

Nie poprawia:

• umowy;
• harmonogramu;
• formularza;
• załącznika.

Zmiana była prawidłowa.

Ale dokumentacja po zmianie stała się niespójna.

Dlatego każda ważna poprawka powinna uruchamiać pytanie:

Gdzie jeszcze ta informacja występuje?

---

Pre-mortem dokumentacji – wyobraź sobie, że postępowanie już opublikowano

To jeden z najbardziej praktycznych testów.

Przed publikacją przyjmujemy hipotetycznie:

postępowanie zostało już ogłoszone i pojawiły się pytania wykonawców.

Następnie próbujemy przewidzieć:

1. o jakie terminy mogą zapytać;
2. które wymagania można rozumieć na dwa sposoby;
3. czego nie da się wycenić;
4. które obowiązki nie mają odpowiednika w formularzu;
5. gdzie załącznik może zawierać starą wersję;
6. które kryterium trudno będzie ocenić;
7. które wymaganie trudno będzie odebrać;
8. gdzie zmiany wprowadzono tylko częściowo.

To właśnie pre-mortem dokumentacji.

Nie czekamy, aż wykonawca znajdzie problem.

Próbujemy znaleźć go wcześniej z jego perspektywy.

---

Pytania wykonawców są często informacją o jakości dokumentacji

Samo pojawienie się pytań nie oznacza automatycznie, że dokumentacja jest błędna.

W złożonych postępowaniach pytania są naturalne.

Warto jednak obserwować ich strukturę.

Jeżeli wielu wykonawców pyta o:

• ten sam termin;
• tę samą definicję;
• sposób wyceny;
• jeden załącznik;

może to oznaczać, że zapis nie jest wystarczająco jednoznaczny.

Takie pytania mogą później służyć jako materiał do poprawy przyszłych postępowań.

---

Jak odróżnić różnicę od rzeczywistej sprzeczności?

Nie każda różna wartość oznacza błąd.

Przykład:

SWZ:

120 dni na realizację całego zamówienia.

OPZ:

90 dni na wdrożenie systemu.

Obie wartości mogą być poprawne.

Dlatego audyt powinien zawsze sprawdzić:

czy porównywane informacje dotyczą dokładnie tego samego zdarzenia.

Dopiero wtedy różnicę można klasyfikować jako niespójność.

---

Rejestr faktów krytycznych

Przy większej dokumentacji dobrze jest utworzyć listę informacji, które muszą być zgodne w całym pakiecie.

Fakt krytyczny	Gdzie występuje?
termin realizacji	SWZ, umowa, harmonogram
gwarancja	OPZ, SWZ, umowa
liczba urządzeń	OPZ, formularz cenowy
czas reakcji	OPZ, SLA, umowa
liczba szkoleń	OPZ, umowa, cena
termin odbioru	umowa, harmonogram

Taki rejestr pozwala kontrolować dokumentację nie:

plik po pliku,

ale:

fakt po fakcie.

---

Co sprawdzić po każdej zmianie dokumentacji?

Jeżeli po kontroli albo konsultacjach zmieniono ważny zapis, warto przejść przez prostą sekwencję:

zmiana → wyszukanie wszystkich zależnych miejsc → aktualizacja → ponowna kontrola

Przykład:

Zmiana:

okres gwarancji 24 → 36 miesięcy.

Do sprawdzenia:

• SWZ;
• OPZ;
• umowa;
• formularz;
• kryteria oceny;
• SLA;
• ewentualne tabele.

Sama poprawka jednego zdania nie wystarcza.

---

Dlaczego zwykła korekta językowa tego nie wykryje?

Bo oba zdania mogą być językowo idealne:

„Termin realizacji wynosi 90 dni.”

„Termin realizacji wynosi 120 dni.”

Nie ma w nich błędu językowego.

Problem istnieje dopiero na poziomie relacji pomiędzy dokumentami.

To właśnie różnica pomiędzy:

korektą

a

audytem spójności.

---

Radar po publikacji – końcowa checklista

Przed ogłoszeniem postępowania warto jeszcze raz sprawdzić:

Pytanie	TAK / NIE
Czy SWZ i OPZ opisują ten sam zakres?
Czy terminy są zgodne?
Czy formularz pozwala wycenić wszystkie obowiązki?
Czy projekt umowy odpowiada OPZ?
Czy kryteria mają właściwe pola w formularzach?
Czy wszystkie odwołania prowadzą do aktualnych załączników?
Czy jednostki są konsekwentne?
Czy wymagania dają się obiektywnie odebrać?
Czy sposób wykazania równoważności jest jasny?
Czy ostatnie zmiany zostały przeniesione do wszystkich zależnych miejsc?

Jeżeli kilka odpowiedzi brzmi:

„nie wiem”

to właśnie tam warto rozpocząć końcową kontrolę.

---

Czy po publikacji jest już za późno?

Nie.

Po ogłoszeniu również można analizować dokumentację.

Taki audyt może pomóc:

• ustalić źródło problemu;
• przeanalizować pytania wykonawców;
• sprawdzić wpływ planowanej zmiany;
• przygotować kolejne postępowanie lepiej.

Jednak przed publikacją możliwości są zwykle znacznie większe.

Można poprawić dokument bez konieczności zarządzania skutkami problemu, który jest już widoczny dla rynku.

---

Audyt nie zastępuje analizy prawnej

Audyt spójności, danych, terminów i zależności pomiędzy dokumentami nie powinien być przedstawiany jako zamiennik profesjonalnej opinii prawnej tam, gdzie taka opinia jest potrzebna.

Może natomiast wskazać:

• sprzeczności;
• luki;
• nieaktualne elementy;
• miejsca wymagające decyzji;
• problemy, które warto skierować do specjalisty.

To inny rodzaj kontroli.

---

Dokumentacja przetargowa powinna mówić jednym głosem

Największym problemem może nie być wadliwe zdanie.

Może nim być sytuacja, w której:

SWZ mówi jedno,

OPZ drugie,

umowa trzecie,

a formularz nadal zawiera czwartą wersję.

Dlatego końcowa kontrola przed publikacją powinna patrzeć nie tylko:

w dół każdego dokumentu,

ale przede wszystkim:

w poprzek całego pakietu.

Jeżeli przygotowujesz SWZ, OPZ, projekt umowy i załączniki, nie zawsze trzeba rozpoczynać od audytu wszystkiego.

Można najpierw skontrolować najbardziej ryzykowne obszary:

• terminy;
• zakres;
• formularze;
• cenę;
• kryteria;
• obowiązki;
• ostatnie zmiany.

A następnie zdecydować, czy potrzebna jest szersza kontrola.

Więcej o sprawdzaniu całego pakietu znajdziesz również w artykule Audyt dokumentacji przetargowej – jak sprawdzić SWZ, OPZ, umowę i załączniki?.

Opisz dokumentację przed publikacją

---

Dane SEO

1. Meta title: Błędy w SWZ i OPZ – co sprawdzić przed publikacją?

2. Meta opis: Jakie problemy w SWZ i OPZ ujawniają się dopiero po publikacji? Sprawdź Radar po publikacji, pre-mortem i 10 obszarów ryzyka.

3. Tagi: błędy w SWZ, błędy w OPZ, SWZ, OPZ, dokumentacja przetargowa, audyt dokumentacji przetargowej, zamówienia publiczne, kontrola SWZ, kontrola OPZ

4. Fraza kluczowa: błędy w SWZ i OPZ

5. Uproszczona nazwa: bledy-w-swz-i-opz