RFI, RFP czy RFQ: jak wybrać wykonawcę sklepu internetowego

RFI, RFP czy RFQ należy wybierać nie według wielkości budżetu, lecz na podstawie tego, czego jeszcze nie wiecie o przyszłym sklepie internetowym. Jeśli możliwości rynku nie są jasne — potrzebne są informacje. Jeśli rezultat jest określony, ale sposób jego osiągnięcia pozostaje otwarty — potrzebne są propozycje rozwiązania. Jeśli zakres i warunki zostały już uzgodnione — można poprosić o porównywalne wyceny.

Błąd pojawia się wtedy, gdy firma wysyła do kilku zespołów prośbę o „wycenę sklepu z integracją z ERP” i porównuje końcowe kwoty. Jeden zespół uwzględnia tylko przekazywanie zamówień, drugi — także stany magazynowe, zwroty i przywracanie działania po awariach. Różnica w cenie pokazuje wtedy różny zakres założeń, a nie różną efektywność programistów. Właściwe zapytanie powinno ujawnić te założenia przed zawarciem umowy.

1. Zacznijcie od niewiadomych, a nie od nazwy dokumentu

Wspólnie z osobami kierującymi sprzedażą i marketingiem oraz osobą odpowiedzialną za system ewidencyjny zapiszcie, co sklep powinien zmienić: udostępnić dealerom indywidualne ceny, wyeliminować ręczne przenoszenie zamówień czy obsługiwać kilka magazynów. Oddzielcie znane fakty, oczekiwania i pytania bez odpowiedzi.

Na przykład, aby wyświetlać stan magazynowy, trzeba ustalić, który system zarządza rezerwacjami, jak aktualne powinny być dane i co widzi kupujący podczas awarii. Dopóki tego nie wiadomo, stały kosztorys stwarza pozory precyzji. Najpierw potrzebna jest analiza.

2. Czym różnią się RFI, RFP i RFQ

RFI oznacza Request for Information — zapytanie o informacje; RFP, Request for Proposal — zapytanie o propozycje; RFQ, Request for Quotation — zapytanie o wycenę. W wytycznych New Zealand Government Procurement rozróżnienie to wiąże się z celem zakupu: zbadaniem rynku, uzyskaniem sposobu osiągnięcia rezultatu lub wyceną już określonego przedmiotu zamówienia. Poniżej przedstawiono praktyczną adaptację dla ukraińskich firm prywatnych, a nie obowiązkową procedurę zagraniczną.

Nie jest to obowiązkowy ciąg trzech postępowań. Jeśli rynek i zadanie są zrozumiałe, przejdźcie od razu do RFP. Jeśli wszystkie istotne warunki zostały już określone — do RFQ. Nawet duży budżet nie sprawia automatycznie, że zapytanie o propozycje jest potrzebne, a mały nie usuwa niewiadomych technicznych.

3. RFI: zdobądźcie wiedzę, której brakuje zamawiającemu

Krótkie RFI jest odpowiednie, gdy nie wiecie, czy wystarczy gotowe rozwiązanie, czy potrzebne jest oprogramowanie tworzone na zamówienie. Opiszcie model sprzedaży, role kupujących, obecne systemy, stan katalogu i ograniczenia związane z uruchomieniem. Poproście o wyjaśnienie możliwych podejść, związanych z nimi kompromisów, potrzebnych dostępów oraz tego, czego nie da się wycenić bez analizy. Można omówić orientacyjny budżet, ale nie zastępuje on przyszłego kosztorysu.

Pytajcie o granice, a nie o liczbę funkcji

Zamiast „czy integrujecie z ERP?” zapytajcie: „Jakie dane i dokumentacja są potrzebne, aby wycenić wymianę cen, stanów magazynowych i zamówień?”. Zamiast „czy system jest skalowalny?” — „Jakie parametry obciążenia trzeba zmierzyć przed wyborem architektury?”. Przydatna odpowiedź wskazuje warunki i niewiadome, a nie jedynie potwierdza wszystkie oczekiwania.

Wynikiem RFI są doprecyzowany brief, alternatywy i lista rzeczy do sprawdzenia. Poinformujcie, że jest to badanie rynku, a nie wybór zwycięzcy. Szczegółowe projektowanie lub prototyp wymagają osobno uzgodnionego zakresu, a nie bezpłatnego wykonania w ramach odpowiedzi.

4. RFP: zadbajcie o porównywalność różnych rozwiązań

W RFP określcie wspólny kontekst, ale pozostawcie miejsce na uzasadnione alternatywy. Potrzebne są cele, granice zakresu pierwszego uruchomienia, główne scenariusze, lista systemów, wymagania dotyczące przenoszenia danych i kryteria odbioru. Oddzielcie elementy obowiązkowe od pożądanych. Jeśli technologia nie została wybrana, poproście o wyjaśnienie wyboru; jeśli została wybrana, wskażcie rzeczywiste ograniczenie, a nie tylko nazwę platformy.

Jeden formularz odpowiedzi dla wszystkich zespołów

Przygotujcie macierz: identyfikator wymagania, sposób realizacji, co obejmuje cena, zależność od zamawiającego, wyłączenie i dowód spełnienia wymagania. W przypadku funkcji odpowiedź powinna rozróżniać gotową możliwość, konfigurację, oprogramowanie tworzone na zamówienie i usługę zewnętrzną. Sformułowanie „obsługiwane” bez tych doprecyzowań ukrywa przyszłe koszty.

Poproście o rozbicie ceny na analizę, projekt graficzny, prace programistyczne, integracje, migrację, testowanie, uruchomienie i wsparcie. Oddzielcie zakres podstawowy od opcji. Dla kosztów cyklicznych uzgodnijcie wspólny okres porównania, walutę, podatki i zakres korzystania z usług.

Przed otrzymaniem odpowiedzi określcie kryteria oceny: pokrycie krytycznych scenariuszy, jakość dowodów, możliwość zarządzania integracjami, zespół, wsparcie i całkowity koszt. Wagi dobierzcie do własnych ryzyk, a nie według uniwersalnej formuły. Pytania uczestników i ogólne wyjaśnienia wymagań przekazujcie wszystkim w jednakowym brzmieniu, nie ujawniając cudzych danych handlowych.

Osobno sprawdzajcie, kto konkretnie będzie wykonywał prace, jak uzgadniane są zmiany i kto odpowiada za podwykonawców. Informacje o firmie GL.ua (Глянець), podobnie jak strona firmowa innego kandydata, dostarczają kontekstu, ale nie zastępują weryfikacji konkretnego zespołu i jego propozycji.

5. RFQ: pytajcie o cenę tylko przy określonych granicach zakresu

Do RFQ potrzebne są jednakowo określony rezultat, specyfikacja, dane testowe i zasady odbioru. Jeśli każdy zespół sam określa logikę rabatów lub zakres migracji, ceny nie będą porównywalne.

Wskażcie wersję specyfikacji. Poproście o podanie terminu ważności ceny, wyłączeń, warunków płatności, zależności od dostępów oraz procedury zmiany zakresu. Wyjaśnijcie, czy cena obejmuje usuwanie defektów, wdrożenie, dokumentację i przekazanie rezultatów prac.

Jeśli uczestnicy odsyłają pytania zamiast ceny, doprecyzujcie zakres lub wydzielcie nierozpoznany komponent do osobnej analizy. RFQ może dotyczyć określonej części prac, a nie całego sklepu.

6. Zweryfikujcie ryzykowną integrację przed zawarciem głównej umowy

Prezentacja gotowego sklepu pokazuje interfejs, ale nie dowodzi niezawodności wymiany danych z waszym systemem ewidencyjnym. Dla najbardziej ryzykownego scenariusza uzgodnijcie ograniczoną weryfikację techniczną: prototyp, test wymiany danych lub analizę rzeczywistej dokumentacji. To osobna praca z określonym rezultatem, dostępami i kryteriami zakończenia, a nie żądanie bezpłatnego stworzenia części produktu.

1. Wybierzcie krytyczny przepływ: produkt i cena z systemu ewidencyjnego, zamówienie ze sklepu, potwierdzenie płatności i zmiana statusu. Wskażcie właściciela każdego typu danych.
2. Udostępnijcie środowisko testowe, dokumentację API — interfejsu wymiany danych między systemami — i zanonimizowane przykłady. Sprawdźcie uprawnienia i limity częstotliwości zapytań.
3. Zapiszcie oczekiwany rezultat dla prawidłowego przebiegu, awarii, opóźnienia i ponownego komunikatu. Ustalcie, jak porównać zapisy po obu stronach.
4. Odtwórzcie awarię połączenia i ponowną wysyłkę. Sprawdźcie, czy nie powstały duplikaty zamówienia lub rezerwacji oraz jak operator dowiedział się o błędzie.
5. Uzyskajcie dziennik weryfikacji, listę ograniczeń i wniosek: potwierdzono, potrzebna jest zmiana podejścia albo danych jest za mało. Zaktualizujcie wycenę i kryteria odbioru.

Ochronę przed ponownym wykonaniem operacji nazywa się idempotencją. Na przykład dokumentacja Stripe dotycząca ponawiania zapytań API opisuje zastosowanie klucza do bezpiecznego powtórzenia operacji. To przykład mechanizmu, a nie dowód, że wasz ERP ma taką samą ochronę: zachowanie konkretnej integracji trzeba sprawdzić osobno.

Bezpieczeństwo również wymaga dowodów

Software Acquisition Guide opracowany przez CISA omawia ocenę praktyk dostawcy w całym cyklu życia oprogramowania. W przypadku sklepu praktyczne pytania dotyczą dostępów, zależności, aktualizacji i reagowania na podatności. To przydatne ramy rozmowy, a nie wymóg stosowania amerykańskich procedur państwowych.

Zamiast „strona musi być bezpieczna” uzgodnijcie, kto weryfikuje uprawnienia ról, zabezpieczenie dostępu administracyjnego i przywracanie kopii zapasowej. OWASP ASVS można wykorzystać jako podstawę konkretnych wymagań weryfikacyjnych. Wskażcie wersję, mające zastosowanie wymagania i dowody; samo odwołanie do standardu nie potwierdza jeszcze zgodności.

7. Oszacujcie terminy, koszty i cenę niewiadomych

Harmonogram zależy nie tylko od programistów. Wpływają na niego gotowość katalogu, zatwierdzenie projektu graficznego, dostęp do ERP, udział dostawcy płatności, oczyszczenie danych i dostępność osób po stronie zamawiającego. Wymagajcie planu z zależnościami i osobami odpowiedzialnymi: co można robić równolegle, co blokuje następny etap i kiedy ponownie weryfikowana jest wycena. Ogólna data bez tych warunków niewiele pomaga w zarządzaniu uruchomieniem.

Porównujcie nie tylko koszty stworzenia, lecz także posiadania sklepu. W kalkulacji pokażcie osobno analizę biznesową, projektowanie, projekt graficzny, prace programistyczne, wymianę danych, migrację, weryfikację i szkolenia. Do kosztów cyklicznych należą infrastruktura, płatne usługi, monitoring, aktualizacje i wsparcie. Ustalcie, które opłaty zależą od zamówień, użytkowników lub ilości danych oraz kto zawiera umowy z dostawcami tych usług.

W przypadku nierozpoznanych prac poproście nie o ukryty narzut, lecz o wyjaśnienie: co konkretnie jest niewiadomą, jak to ustalić i kiedy zmieni się wycena. Stała cena nie usuwa niejasnych wymagań, a rozliczenie godzinowe nie znosi kontroli budżetu. Oba modele wymagają granic zakresu, raportowania i procedury uzgadniania zmian. Warunki handlowe i prawne sprawdzajcie z odpowiedzialnymi za nie specjalistami; ten artykuł nie stanowi porady prawnej.

8. Wybierajcie na podstawie zweryfikowanego rezultatu, a nie obietnicy

Przed ostateczną decyzją wróćcie do macierzy wymagań. Nie warto rekompensować niedopuszczalnego ryzyka w krytycznej integracji atrakcyjniejszym projektem graficznym lub niższą kwotą. Jednocześnie prototyp nie dowodzi gotowości całego sklepu na szczytowe obciążenie: wyjaśnia tylko określoną niewiadomą. Pozostałe scenariusze będą wymagały własnych testów podczas prac programistycznych i uruchomienia.

Zapiszcie uzgodnione doprecyzowania w zakresie prac, zamiast pozostawiać je w korespondencji. Określcie kryteria odbioru, osoby odpowiedzialne za dane i dostępy, zasady wsparcia oraz przekazania kodu, dokumentacji i konfiguracji. Nie przekazujcie uczestnikom haseł do środowiska produkcyjnego ani pełnych baz klientów na potrzeby wyceny. Do wstępnej weryfikacji wykorzystujcie ograniczone dostępy i zanonimizowane dane.

Dobrym wynikiem wyboru nie jest najdłuższe RFP, lecz propozycja, w której widać wykonalny zakres, potwierdzone możliwości i pozostałe ryzyka. Jeśli przygotowujecie nowy sklep lub migrację, porozmawiajcie z GL.ua o stworzeniu sklepu internetowego: przekażcie scenariusze biznesowe, listę systemów i otwarte pytania, aby zacząć rozmowę od rzeczywistego zadania, a nie od nieporównywalnych cen.