Jak przygotować OPZ na symulator VR (wzór). Gotowy wzór specyfikacji dla zamówień publicznych

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 p