Poradnik dla zamawiających i działów zakupów

Jak przygotować OPZ na symulator VR — praktyczny przewodnik i gotowy wzór

Dobrze napisany Opis Przedmiotu Zamówienia decyduje o powodzeniu całego przetargu na aplikację czy symulator VR. Zbyt ogólny OPZ ściąga oferty nieporównywalne jakościowo; zbyt „skrojony pod jednego dostawcę” naraża na zarzut ograniczania konkurencji. Poniżej pokazujemy, jak opisać przedmiot krok po kroku, jak sformułować klauzulę równoważności i kryteria oceny — a gotowy, edytowalny wzór OPZ wyślemy Ci na życzenie (wystarczy krótki mail).

1. Czym jest OPZ i dlaczego decyduje o sukcesie przetargu VR

Opis Przedmiotu Zamówienia (OPZ) to serce dokumentacji: precyzyjnie mówi, co ma dostarczyć wykonawca. W zamówieniach na VR jest trudniejszy niż w typowych dostawach, bo przedmiot jest jednocześnie oprogramowaniem (aplikacja, scenariusze), sprzętem (gogle, akcesoria) i usługą (wdrożenie, szkolenie, wsparcie). Jeśli którakolwiek z tych warstw jest opisana ogólnikowo, oferty stają się nieporównywalne, a Ty ryzykujesz, że wygra najtańsze, ale bezużyteczne rozwiązanie.

Dobry OPZ na VR robi trzy rzeczy naraz: opisuje efekt (czego uczniowie/pracownicy mają się nauczyć), ustala mierzalne wymagania techniczne (platforma, wydajność, ergonomia) oraz zabezpiecza eksploatację (licencja, aktualizacje, wsparcie, prawa autorskie).

2. Próg 130 000 zł — PZP czy postępowanie poza ustawą

Od wartości zamówienia zależy tryb:

• Poniżej 130 000 zł netto — zamówienie zwykle nie podlega ustawie PZP. Stosuje się wewnętrzny regulamin/zasadę konkurencyjności: zapytanie ofertowe, krótsze terminy, oświadczenie o braku powiązań, bez wadium i JEDZ. OPZ nadal warto napisać starannie — to on porządkuje porównanie ofert.
• Powyżej 130 000 zł netto — pełna procedura PZP (najczęściej tryb podstawowy). Dochodzą sformalizowane terminy, warunki udziału, kryteria oceny, ewentualnie wadium; powyżej progów unijnych także JEDZ.

Niezależnie od trybu, zasady opisu przedmiotu (jednoznaczność, wyczerpujący opis, zakaz nieuzasadnionego ograniczania konkurencji) są tą samą dobrą praktyką — poniżej pokazujemy je na przykładzie procedury PZP.

3. Struktura OPZ na symulator VR — sekcja po sekcji

Sprawdzona kolejność, która porządkuje myślenie zamawiającego i ułatwia wykonawcom rzetelną wycenę:

3.1. Przedmiot i cel zamówienia

Zacznij od efektu, nie od technologii. Napisz, kto i czego ma się nauczyć oraz jaki problem rozwiązujesz (np. skrócenie onboardingu, bezpieczne ćwiczenie procedur, przygotowanie do egzaminu). Dopiero potem doprecyzuj, że narzędziem jest aplikacja/symulator VR.

3.2. Wymagania funkcjonalne (moduły i scenariusze)

Wymień moduły i scenariusze, których oczekujesz — np. dla logistyki: odbiór i rozładunek towarów, kompletacja zamówień, inspekcja naczepy, zasady bezpieczeństwa ruchu. Dla każdego opisz, co użytkownik wykonuje i jak system ocenia poprawność. Zaznacz, czy wymagana jest możliwość odwzorowania realnego układu (np. Twojego magazynu).

3.3. Wymagania techniczne

Opisz parametrami, nie marką (patrz sekcja o równoważności): platforma docelowa (standalone / PCVR), płynność działania, komfort użytkowania (minimalizacja tzw. cybersickness), obsługa (kontrolery i/lub śledzenie dłoni), język (polski lektor i interfejs), tryb wielostanowiskowy, jeśli potrzebny.

3.4. Dostawa sprzętu

Jeśli zamawiasz też sprzęt: liczba gogli, wymagane parametry (opisane funkcjonalnie), akcesoria (walizka/stacja ładowania), stan dostawy („skonfigurowane, gotowe do użycia”). Rozważ, czy sprzęt i licencje mają być na jednej fakturze — ułatwia to rozliczenie dotacji.

3.5. Licencja i prawa autorskie

To pozycja, którą wykonawcy najczęściej różnie interpretują. Rozstrzygnij wprost: licencja dożywotnia czy czasowa/subskrypcyjna, liczba stanowisk, zakres pól eksploatacji, czy wymagasz kodu źródłowego (to istotnie podnosi cenę i ogranicza wykonawcy reużycie komponentów — żądaj go tylko, gdy naprawdę potrzebujesz).

3.6. Wdrożenie, szkolenie i dokumentacja

Określ zakres wdrożenia (instalacja, konfiguracja, testy odbiorowe), szkolenie kadry (liczba osób, forma, miejsce) oraz dokumentację (instrukcja użytkownika, materiały metodyczne, jeśli dotyczy edukacji).

3.7. Gwarancja, wsparcie i aktualizacje

Podaj okres gwarancji (typowo 12–36 miesięcy), czas reakcji wsparcia, język i godziny. W VR ważny jest zapis o aktualizacjach zapewniających działanie aplikacji na bieżącej wersji systemu gogli w okresie gwarancji (o pułapce „5 lat pełnej kompatybilności” — w sekcji o umowie).

3.8. Dane osobowe i bezpieczeństwo

Jeśli aplikacja zbiera dane o użytkownikach (wyniki, postępy), dodaj wymagania RODO: zakres danych, sposób przetwarzania, powierzenie przetwarzania, lokalizacja przechowywania.

4. Klauzula równoważności — opisuj parametry, nie markę

To najczęstsze pole do odwołań. Zasada z PZP: przedmiotu nie wolno opisywać przez wskazanie znaku towarowego, patentu lub pochodzenia, jeśli mogłoby to uprzywilejować lub wyeliminować niektórych wykonawców. Jeśli jest to uzasadnione specyfiką i nie da się opisać inaczej — wskazanie jest dopuszczalne, ale musi towarzyszyć mu zwrot „lub równoważny” oraz opis kryteriów równoważności.

Ta sama zasada dotyczy silnika, bibliotek i systemów — opisuj wymaganym efektem i parametrami, nie nazwą konkretnego produktu.

5. Kryteria oceny ofert — nie tylko cena

Dla VR ocena wyłącznie po cenie to prosta droga do słabego wdrożenia. Ustaw kryteria jakościowe, które realnie różnicują wykonawców. Przykładowa struktura:

Wagi dobierz do wartości i ryzyka zamówienia; opisz precyzyjnie sposób punktowania każdego kryterium pozacenowego, żeby ocena była obiektywna i odporna na odwołania. Rozważ wymóg prezentacji działającego demo — to najskuteczniejszy filtr odsiewający pośredników od realnych producentów.

6. Warunki udziału i referencje — nie za wąsko, nie za szeroko

Warunki mają potwierdzać zdolność wykonawcy, a nie zawężać rynek do jednej firmy. Dla VR sensowne jest wymaganie kilku zrealizowanych, odebranych wdrożeń aplikacji/symulatorów VR w ostatnich 3 latach, o wartości i charakterze zbliżonym do przedmiotu. Unikaj warunków „szytych na miarę” (np. bardzo wąska, nietypowa kombinacja platformy i branży), bo to klasyczna podstawa odwołania do KIO.

7. Siedem najczęstszych błędów w OPZ na VR

1. Opis przez markę bez „lub równoważny”. Najczęstsza podstawa odwołań.
2. Brak rozstrzygnięcia licencji. „Dostawa aplikacji VR” — a to dożywotnia czy roczna? Ile stanowisk? Wykonawcy wyceniają różne rzeczy.
3. Milczenie o kodzie źródłowym. Albo go potrzebujesz i to zapisz, albo nie żądaj — niejasność zawyża oferty.
4. Cena jako jedyne kryterium. Wygrywa najtańsze demo bez wsparcia.
5. Nierealny wymóg kompatybilności. „Pełna zgodność ze wszystkimi przyszłymi wersjami systemu przez 5 lat” — niewykonalne i drogie.
6. Brak wymogu demo/prezentacji. Nie da się odróżnić realnego produktu od folderu reklamowego.
7. Warunki udziału zbyt wąskie. Ograniczają konkurencję i grożą unieważnieniem.

8. Klauzule w projekcie umowy, których warto unikać

OPZ współgra z wzorem umowy. Zapisy nadmiernie ryzykowne dla wykonawców podnoszą ceny albo zniechęcają najlepszych — a bywają też abuzywne:

• Kary umowne bez limitu — dobrze widziany jest górny limit (np. określony % wartości umowy).
• Jednostronne odstąpienie bez przyczyny — powinno być ograniczone do wskazanych sytuacji.
• Brak klauzuli waloryzacyjnej przy umowach dłuższych niż 6 miesięcy — dla dłuższych umów jest wymagana.
• Nieograniczona zmiana zakresu bez zmiany wynagrodzenia — każda dodatkowa scena/moduł to realny koszt.
• Wymóg wieloletniej pełnej kompatybilności z aktualizacjami gogli — ogranicz do rozsądnych poprawek w okresie gwarancji.

9. Checklista OPZ przed publikacją

Uwaga dla redakcji strony: przycisk otwiera e-mail do office@epicvr.pl z gotowym tematem i treścią. Wzór wysyłacie ręcznie w odpowiedzi — plik nie jest publicznie do pobrania.

FAQ — najczęstsze pytania

Powiązane artykuły