Treści
© 2026 Fryderyk Pryjma. Wszelkie prawa zastrzeżone.
Polityka prywatnościPoznaj najczęstsze problemy w procesach przetargowych, RFI i RFP, i dowiedz się, jak moim zdaniem można je naprawić. Zbiór przemyśleń na ten temat.
Wracam po letniej przerwie i jestem gotowy na nowe wpisy. Sporo myślałem o kierunku, w jakim chcę poprowadzić tego bloga, skupiając się na tym, co mnie napędza i czego brakuje w krajobrazie treści. Choć poruszałem popularne tematy, takie jak przegląd narzędzi do osobistej strony i dlaczego Research Ops jest częścią Design Ops!, teraz chcę zagłębić się w bardziej wartościowe treści, dające unikalne, przetestowane w praktyce wartości, podobnie jak mój wpis o narzędziach, na których polegamy codziennie w Design-Ops.
Obecnie moja praca koncentruje się na dwóch głównych celach: zwiększeniu efektywności naszych procesów projektowych i napędzaniu sprzedaży dla naszej grupy. Znaczna część tego procesu sprzedażowego dotyczy świata przetargów, RFI (Request for Information) i RFP (Request for Proposal). Im więcej pracuję w tej przestrzeni, tym wyraźniej widzę krytyczną potrzebę poprawy. Byłem odpowiedzialny za przygotowanie wielu ofert i prowadzenie analiz biznesowych, i szczerze mówiąc, często jestem zaskoczony, jak słabo te kluczowe dokumenty są przygotowywane.
To nie jest tylko narzekanie; to diagnoza. Sposób, w jaki prosimy o pracę, bezpośrednio wpływa na jakość pracy, którą otrzymujemy. Przeanalizujmy problem i zbadajmy bardziej efektywne, design-driven rozwiązanie.
Zanim przejdziemy do analizy problemów, uporządkujmy terminologię. Te akronimy są często używane zamiennie, ale reprezentują odrębne etapy w cyklu życia zamówień i rozwoju produktu. Ich zrozumienie to pierwszy krok do efektywnego wykorzystania.
RFI (Request for Information): To faza eksploracyjna. Firma używa RFI do zebrania ogólnych informacji od różnych dostawców o ich możliwościach. To jak oglądanie wystaw – nie jesteś jeszcze gotowy do zakupu, ale chcesz zobaczyć, co jest na rynku i kto jest kluczowym graczem.
RFP (Request for Proposal): To formalne zaproszenie do złożenia oferty. RFP dostarcza szczegółowych informacji o konkretnym projekcie lub potrzebie i prosi dostawców o przedstawienie propozycji rozwiązania, harmonogramu i oczywiście kosztów.
Przetarg: Często używany zamiennie z RFP, przetarg to bardziej formalny, ustrukturyzowany i często publiczny proces zamawiania towarów lub usług. Jest powszechny w projektach rządowych i dużych korporacyjnych.
PRD (Product Requirements Document): To dokument wewnętrzny, ale jest sekretnym składnikiem dobrego RFP. PRD jasno artykułuje cel produktu, funkcje, funkcjonalność i zachowanie. To plan. Bez solidnego PRD, RFP to tylko lista życzeń zbudowana na chwiejnych fundamentach.
Celem każdego przetargu lub RFP jest znalezienie najlepszego partnera do dostarczenia najlepszego rozwiązania za uczciwą cenę. Jednak proces jest często tak skonstruowany, że osiąga odwrotny efekt. Oto najczęstsze pułapki, z jakimi się spotkałem, szczególnie na polskim rynku.
W Polsce istnieje silna tendencja do tworzenia przetargów ocenianych niemal wyłącznie na podstawie jednego kryterium: ceny. Choć budżet jest niewątpliwie ważny, ocena oparta wyłącznie na cenie tworzy wyścig do dna. Zachęca agencje do cięcia kosztów, niedostatecznego obsadzania projektów i pomijania kluczowych faz odkrywania i badań, aby złożyć najniższą ofertę.
Stale widzę RFP, które wpadają w jedną z dwóch niepomocnych kategorii:
Czarna skrzynka: Dokument jest tak niejasny i słabo zdefiniowany, że niemożliwe jest stworzenie dokładnego szacunku lub zaproponowanie sensownego rozwiązania.
Zamknięta skrzynka: Dokument jest tak hiper-szczegółowy, że wydaje się napisany pod konkretnego dostawcę. Niedawno analizowałem przetarg dla miasta Tarnów, gdzie opis modelu 3D był tak szczegółowy – aż do specyfikacji technicznych nieadekwatnych do wymagań wydajnościowych – że silnie sugerował, iż istniejący zasób był już przeznaczony na to zlecenie.
Umowy o poufności to standardowa część biznesu, ale mogą być nadużywane w procesie RFP. Niedawno złożyłem ofertę i wygrałem projekt, w którym zakres prac omówiony po podpisaniu NDA był zasadniczo inny od tego opisanego w dokumentach przetargowych.
Choć rozumiem potrzebę poufności, ta podmiana marnuje ogromną ilość czasu i zasobów wszystkich firm składających oferty. Prosta klauzula stwierdzająca, że „dalsze kluczowe szczegóły zostaną ujawnione w ramach NDA" byłaby bardziej przejrzystym podejściem.
To klasyczny scenariusz w świecie agencyjnym. Potencjalny klient przychodzi do nas z prośbą o konkretne oprogramowanie. Inwestujemy czas w wycenę i przygotowanie oferty. A potem, gdy zaczynamy z nimi rozmawiać, okazuje się, że to, o co proszą, jest zupełnie inne od tego, czego naprawdę potrzebują.
To naturalna część procesu sprzedaży i odkrywania, ale wskazuje na głębszy problem. Ile firm przechodzi przez pełny proces przetargowy, podpisuje umowę i rozpoczyna projekt na warunkach, których żadna ze stron w pełni nie rozumie?
Nie jest jednak tak źle. Niedawno miałem okazję przeanalizować przetarg dla miasta Olsztyn i to był powiew świeżego powietrza. Choć nie idealny, był fantastycznym przykładem tego, co należy robić dobrze. Wymagania były jasno określone, dając nam solidną podstawę do wyceny. Zawierał nawet diagramy pomagające wizualizować złożone części systemu.
„komunikacja jest najważniejszym czynnikiem sukcesu w projektach IT"
Wszystko sprowadza się do fundamentalnej prawdy naszej branży. Jak zauważono w badaniu z 2017 roku, „komunikacja jest najważniejszym czynnikiem sukcesu w projektach IT" (Stevenson & Starkweather, 2017), więc powinna być dostosowana do swojego odbiorcy. Przetarg to pierwsza i prawdopodobnie najważniejsza komunikacja w projekcie.
Jak to naprawić? Odpowiedź leży w zastosowaniu tych samych zasad, których używamy do budowania świetnych produktów: praktyk discovery i user experience (UX). Musimy traktować sam proces zamówień jako problem projektowy.
Źródłem większości złych RFP jest brak wewnętrznej jasności. Zanim zaczniesz pisać RFP, Twój zespół musi stworzyć solidny PRD. To obejmuje:
Pomyśl o dostawcach czytających Twoje RFP jak o użytkownikach. Twoim celem jest pomóc im szybko i jasno zrozumieć Twoje potrzeby.
Stosując te zasady, przekształcasz swoje RFP z mylącego zestawu żądań w jasny, przekonujący brief projektowy, który przyciąga właściwych partnerów.
Świetnie jest wrócić na właściwe tory i dzielić się z Wami tymi przemyśleniami. Mój focus przesuwa się w stronę tych bardziej systemowych, operacyjnych wyzwań, bo tam wierzę, że możemy mieć największy wpływ. Lepsze przetargi, RFI i RFP prowadzą do lepszych współprac, lepszych produktów i mniej zmarnowanego czasu i pieniędzy dla wszystkich. A gdy mówimy o przetargach publicznych – to ciężko zarobione pieniądze.
Będę dążył do cotygodniowych wpisów i jestem też podekscytowany rozpoczęciem małej serii na YouTube. Mam nadzieję, że Wam się spodoba.
Bądźmy efektywni!
Deborah Stevenson & Jo Ann Starkweather, 2017.
IT Project Success: The Evaluation of 142 Success Factors by IT PM Professionals,
International Journal of Information Technology Project Management (IJITPM), IGI Global Scientific Publishing, vol. 8(3), pages 1-21, July.