Zapytanie ofertowe (RFP) na oprogramowanie dedykowane: struktura, kryteria oceny ofert i błędy, które podnoszą cenę

Dyrektor zakupów w średniej firmie dystrybucyjnej otwiera trzy oferty na nowy portal dla partnerów handlowych. Pierwsza opiewa na 380 tysięcy złotych, druga na 720 tysięcy, trzecia na 1,4 miliona. Wszystkie trzy odpowiadają na ten sam, dwunastostronicowy dokument. Zarząd pyta, skąd prawie czterokrotna różnica i który dostawca próbuje go oszukać.

Odpowiedź jest mniej sensacyjna, niż chciałby zarząd. Najprawdopodobniej nikt nikogo nie oszukuje. Pierwszy dostawca wycenił portal z logowaniem, katalogiem i formularzem zamówienia. Drugi dodał integrację z ERP, bo w dokumencie było zdanie „system powinien współpracować z naszymi systemami”. Trzeci założył dwustronną synchronizację w czasie rzeczywistym, osobną aplikację mobilną i wysoką dostępność, bo tak zrozumiał słowo „nowoczesny”. Każdy wycenił inny projekt, ponieważ zapytanie ofertowe pozwoliło każdemu wymyślić własny.

Ten artykuł jest dla osoby, która ma napisać zapytanie ofertowe (RFP, request for proposal) na oprogramowanie dedykowane albo ocenić odpowiedzi, które już przyszły. Pokazujemy, co musi być w dokumencie, jak opisać zakres, żeby dostawcy wyceniali to samo, jak zbudować kryteria oceny ofert i ich wagi, które błędy po stronie zamawiającego podnoszą cenę i jak rozpoznać ofertę, która jest tania tylko do dnia podpisania umowy. Teza jest prosta: jakość ofert, które dostajesz, jest odbiciem jakości zapytania, które wysłałeś.

Dlaczego zapytanie ofertowe decyduje o cenie, zanim dostawca ją policzy?

Bo wycena oprogramowania to w dużej części wycena niepewności. Dostawca, który czyta zapytanie, robi dwie rzeczy: szacuje pracę, którą rozumie, i dolicza rezerwę na to, czego nie rozumie. Im więcej w dokumencie luk, tym większa druga część. Niejasne zdanie w RFP nie jest neutralne. Kosztuje.

Skala tej niepewności w projektach IT jest dobrze opisana. Badanie McKinsey i Uniwersytetu Oksfordzkiego z 2012 roku, obejmujące ponad 5400 projektów IT, wykazało, że duże projekty (z budżetem początkowym powyżej 15 milionów dolarów) przekraczały budżet średnio o 45%, a dostarczały o 56% mniej wartości, niż zakładano (McKinsey, 2012). Dostawcy znają takie liczby z własnej praktyki. Dlatego doświadczony zespół ofertowy, widząc mglisty zakres, nie zgaduje optymistycznie, tylko zabezpiecza się wyższą ceną albo długą listą wykluczeń.

Dostawca ma do wyboru trzy reakcje na lukę w zapytaniu i każda jest dla Ciebie kosztowna. Może doliczyć rezerwę, wtedy płacisz za ryzyko, które być może się nie zmaterializuje. Może przyjąć najtańszą interpretację i dopisać wykluczenie, wtedy oferta wygląda atrakcyjnie, a różnica wraca w zleceniach zmian. Może też wycenić najszerszą interpretację, żeby nikt mu potem nie zarzucił, że czegoś nie przewidział, wtedy przepłacasz za zakres, którego nie potrzebujesz. Trzy oferty z otwierającego przykładu to dokładnie te trzy reakcje.

Dobre zapytanie ofertowe nie usuwa niepewności, bo w oprogramowaniu dedykowanym jej się nie da usunąć przed rozpoczęciem pracy. Ale zmienia ją z ukrytej w jawną. Zamiast „system powinien współpracować z naszymi systemami” piszesz „integracja z ERP przez istniejące REST API: odczyt stanów magazynowych co 15 minut, zapis zamówień w czasie rzeczywistym, około 2000 zamówień dziennie”. Dostawca nadal może się pomylić w szacunku, ale wszyscy trzej mylą się w sprawie tego samego zadania.

Jest też efekt drugiego rzędu. Dokument, który pokazuje, że zamawiający rozumie swój problem, przyciąga lepszych dostawców. Firmy z dobrym portfelem zleceń wybierają, na które zapytania odpowiadają, i chętniej poświęcają czas architekta na dokument, z którego widać, że projekt ma właściciela, budżet i decyzję. Mglisty RFP rozesłany do dziesięciu firm często przyciąga odpowiedzi od tych, które odpowiadają na wszystko.

Kiedy potrzebujesz pełnego RFP, a kiedy wystarczy RFI albo rozmowa z trzema firmami?

Pełne zapytanie ofertowe to inwestycja: kilka tygodni pracy po Twojej stronie i po stronie dostawców. Nie zawsze się zwraca. Warto rozróżnić trzy narzędzia.

RFI (request for information) to zapytanie o informacje. Pytasz rynek, kto robi podobne rzeczy, jak by do tego podszedł i w jakim przedziale kosztów się to zwykle mieści. RFI nie kończy się wyborem, tylko krótką listą i lepszym zrozumieniem, co w ogóle kupujesz. Ma sens, gdy nie wiesz jeszcze, czy potrzebujesz systemu dedykowanego, czy wystarczy gotowy produkt z konfiguracją, albo gdy nie masz punktu odniesienia dla budżetu.

RFP (request for proposal) to właściwe zapytanie ofertowe. Opisujesz problem i zakres, oczekujesz propozycji rozwiązania, zespołu, harmonogramu i ceny, oceniasz według ogłoszonych kryteriów. Ma sens, gdy projekt jest na tyle duży, że różnica między dostawcami przekłada się na setki tysięcy złotych, gdy w firmie obowiązuje procedura zakupowa wymagająca udokumentowanego wyboru albo gdy kilka działów musi uzgodnić, czego właściwie chcą.

Rozmowy z trzema firmami bez formalnego dokumentu sprawdzają się przy mniejszych zleceniach, przy rozszerzeniu zespołu o kilku specjalistów albo wtedy, gdy kluczowe jest dopasowanie ludzi, a nie porównanie koncepcji. Jeśli potrzebujesz dwóch programistów do istniejącego zespołu, RFP na dwudziestu stronach jest przerostem formy. Wystarczy profil kompetencji, stawka i rozmowy techniczne.

Jest też wariant pośredni, który w projektach o dużej niepewności działa lepiej niż cokolwiek innego: RFP na fazę discovery. Zamiast prosić o wycenę całego systemu, której nikt rzetelnie nie poda, prosisz o wycenę kilkutygodniowej analizy przedwdrożeniowej, której wynikiem jest zakres, architektura i szacunek reszty. Wybierasz dostawcę na discovery, a decyzję o całości podejmujesz, mając w ręku dokumenty, za które zapłaciłeś i które należą do Ciebie. Szerzej o tym, jak wygląda cały proces od discovery do utrzymania, piszemy w przewodniku po oprogramowaniu dedykowanym.

Prosty test: jeśli nie potrafisz w jednym akapicie opisać, co system ma robić i dla kogo, nie jesteś gotowy na RFP na całość. Zacznij od RFI albo od zapytania na discovery.

Co musi zawierać zapytanie ofertowe na oprogramowanie dedykowane?

Dobre RFP ma stałą strukturę. Kolejność sekcji nie jest święta, ale brak którejkolwiek z nich prawie zawsze odbija się w ofertach.

1. Kontekst i cel biznesowy. Kim jesteście, jaki problem rozwiązuje system i jak poznacie, że się udało. Mierniki sukcesu, nawet przybliżone: skrócenie czasu obsługi zamówienia, odciążenie działu obsługi klienta, wejście na nowy rynek. Dostawca, który zna cel, potrafi zaproponować tańszą drogę do niego.
2. Użytkownicy i procesy. Kto będzie korzystał z systemu, ilu ich jest, jakie są główne scenariusze. Krótki opis procesu „dziś” i „po wdrożeniu” jest wart więcej niż lista funkcji.
3. Zakres funkcjonalny z priorytetami. Lista funkcji pogrupowana według ważności (o metodzie za chwilę), z wyraźnym zaznaczeniem, co jest poza zakresem.
4. Wymagania niefunkcjonalne. Wydajność, dostępność, bezpieczeństwo, dostępność cyfrowa, wymagania prawne. Z liczbami, nie przymiotnikami. Więcej o tym, jak je zapisać, w haśle wymagania niefunkcjonalne.
5. Otoczenie techniczne. Systemy do integracji, ich interfejsy i właściciele, preferowany hosting, standardy technologiczne firmy, dane do migracji.
6. Ograniczenia. Termin i to, co od niego zależy, budżet lub jego przedział, regulacje branżowe, wymagania działu bezpieczeństwa.
7. Oczekiwany model współpracy. Fixed price, time & materials, abonament zespołu albo otwartość na propozycję dostawcy.
8. Warunki umowne nienegocjowalne. Przeniesienie autorskich praw majątkowych, dostęp do repozytorium od pierwszego dnia, poufność, wymagania co do podwykonawców. Lepiej, żeby dostawca wiedział o nich przed wyceną niż po wyborze.
9. Formularz odpowiedzi. Jednolity format: tabela wyceny, opis zespołu, harmonogram, założenia i wykluczenia, odpowiedzi na pytania.
10. Kryteria oceny i ich wagi oraz harmonogram procesu. Termin pytań, termin odpowiedzi, prezentacje, data decyzji.

Najczęściej pomijane są punkty 1, 8 i 9. Bez celu biznesowego dostawcy wyceniają literalnie listę funkcji. Bez warunków nienegocjowalnych wybierasz ofertę, która potem okazuje się droższa, bo dostawca dolicza przeniesienie praw albo nie godzi się na dostęp do repozytorium. Bez formularza odpowiedzi dostajesz trzy dokumenty o różnych strukturach, z których jeden podaje cenę za całość, drugi stawki i szacunek godzin, a trzeci cenę za pierwszy etap. Porównanie ich zajmuje więcej czasu niż napisanie RFP.

Dokument nie musi być długi. Kilkanaście stron dobrze ustrukturyzowanego tekstu i załącznik z listą funkcji zwykle wystarczą. Długość nie jest miarą jakości; liczba otwartych pytań, które dostawca musi rozstrzygnąć sam, już tak.

Jak opisać zakres, żeby dostawcy wyceniali to samo?

Zakres to sekcja, która najbardziej wpływa na rozrzut cen. Trzy techniki znacząco go zmniejszają.

Pierwsza: priorytety MoSCoW. Każda funkcja dostaje kategorię: musi być (must have), powinna być (should have), może być (could have), nie w tym etapie (won’t have). Prosisz o wycenę osobno dla kategorii „musi” i „powinna”. Dzięki temu widzisz nie tylko cenę całości, ale też cenę minimalnej wersji, którą da się wdrożyć, i możesz zdecydować, czy funkcje z drugiej grupy są warte swojej ceny. Dostawca, który wycenia wszystko jednym blokiem, odbiera Ci tę decyzję.

Druga: scenariusze zamiast przymiotników. „Intuicyjny panel administracyjny” nie daje się wycenić. „Administrator dodaje partnera, przypisuje mu cennik z jednej z pięciu grup rabatowych i nadaje dostęp do wybranych kategorii produktów; operacja zajmuje mniej niż dwie minuty” daje się wycenić i da się sprawdzić przy odbiorze. Taki opis jest jednocześnie zalążkiem kryteriów akceptacji, które potem trafią do umowy.

Trzecia: liczby wszędzie, gdzie skala zmienia architekturę. Liczba użytkowników jednocześnie, liczba transakcji dziennie, wolumen danych do migracji, liczba języków, liczba ról z różnymi uprawnieniami, wymagana dostępność. System dla 50 użytkowników wewnętrznych i system dla 50 tysięcy klientów końcowych to dwa różne projekty, nawet jeśli lista ekranów jest identyczna. Jeśli nie znasz dokładnej liczby, podaj przedział i horyzont: „dziś 300 partnerów, za trzy lata do 1500”.

Równie ważne jest to, czego w zakresie nie ma. Wyraźna lista „poza zakresem” (na przykład aplikacja mobilna, moduł płatności, migracja danych sprzed 2020 roku) zapobiega temu, że jeden dostawca ją wyceni, a drugi nie. Jeśli jakaś funkcja jest niepewna, nazwij ją wprost i poproś o osobną pozycję w wycenie. Opcja wyceniona osobno nie zaburza porównania; opcja wliczona po cichu przez jednego oferenta tak.

Na koniec rzecz, której zamawiający często się wstydzą: przyznaj, czego nie wiesz. Zdanie „nie mamy jeszcze decyzji, czy portal będzie obsługiwał zamówienia z odroczonym terminem płatności; prosimy o wycenę wariantu z tą funkcją i bez niej” jest dla dostawcy cenniejsze niż udawana pewność. Udawana pewność kończy się zleceniem zmiany w trzecim miesiącu projektu.

Jakie informacje o ograniczeniach i otoczeniu najczęściej pomija zamawiający?

Ta część RFP rzadko jest ciekawa dla autora, a bardzo często decyduje o koszcie. Pięć braków powtarza się najczęściej.

Integracje opisane jednym zdaniem. Integracja jest w projektach dedykowanych jednym z najczęstszych źródeł przekroczeń, bo jej koszt zależy od rzeczy, których dostawca nie widzi: czy system docelowy ma udokumentowane API, czy ktoś po stronie klienta je zna, czy istnieje środowisko testowe, czy dostawca systemu docelowego musi coś zmienić i ile to potrwa. Dla każdej integracji podaj: system i jego wersję, sposób komunikacji, kierunek i częstotliwość wymiany danych, wolumen, dostępność środowiska testowego i osobę kontaktową.

Dane do migracji. Skąd pochodzą, ile ich jest, w jakim są stanie. Migracja danych, o której dostawca dowiaduje się po podpisaniu umowy, to klasyczne zlecenie zmiany.

Ograniczenia technologiczne i hostingowe. Jeśli dział IT wymaga określonej chmury, określonego języka albo zgodności z wewnętrznymi standardami bezpieczeństwa, napisz to. Dostawca, który zaproponuje inną technologię, i tak będzie musiał ją zmienić, ale już po wyborze i za dopłatą.

Wymagania regulacyjne. Dane osobowe i RODO, wymagania sektorowe w finansach czy ochronie zdrowia, dostępność cyfrowa, wymagania dotyczące bezpieczeństwa produktów z elementami cyfrowymi. Każde z nich przekłada się na pracę: testy bezpieczeństwa, dokumentację, rejestry, przeglądy. Lepiej, żeby była w ofercie.

Zaangażowanie po Twojej stronie. Kto będzie właścicielem produktu, ile ma na to czasu, jak szybko będziecie odpowiadać na pytania i akceptować etapy. Dostawca, który wie, że po stronie klienta jest dostępny właściciel produktu na pół etatu, wyceni inaczej niż ten, który zakłada, że na każdą decyzję będzie czekał tydzień. Czas oczekiwania na decyzje klienta to w modelu fixed price ryzyko, które ktoś musi wycenić.

Budżet zasługuje na osobne zdanie. W zamówieniach prywatnych warto go podać, przynajmniej jako przedział. Obawa, że dostawcy „dopasują się do budżetu”, jest zrozumiała, ale w praktyce działa to odwrotnie: budżet mówi dostawcom, jaki projekt mają zaprojektować. Przy 300 tysiącach złotych zaproponują inną architekturę i inny zakres pierwszego etapu niż przy półtora miliona. Bez tej informacji każdy zgaduje, a rozrzut ofert odzwierciedla zgadywanie.

O co pytać dostawców, żeby odpowiedzi dało się porównać?

Formularz odpowiedzi to najtańsza inwestycja w całym procesie. Zamiast prosić o „ofertę”, prosisz o wypełnienie konkretnych pól. Proponujemy pięć bloków.

Blok 1: rozumienie problemu. Jedna strona, na której dostawca własnymi słowami opisuje, co zrozumiał, jakie widzi ryzyka i czego mu brakuje do pewniejszej wyceny. Ta strona mówi więcej o dostawcy niż cała sekcja „o nas”. Jeśli dostawca nie widzi żadnych ryzyk w projekcie, który Ty uważasz za trudny, albo nie przeczytał dokumentu, albo nie chce Cię martwić przed podpisaniem.

Blok 2: wycena w jednolitej strukturze. Tabela z podziałem na etapy lub moduły, osobno kategorie „musi” i „powinna”, osobno opcje. Dla każdej pozycji: liczba osobodni według ról i stawka. Do tego jawna rezerwa na ryzyko, jeśli dostawca ją stosuje. O tym, jak czytać taką wycenę i co w niej sprawdzić, piszemy szczegółowo w artykule o tym, jak software house wycenia projekt.

Blok 3: założenia i wykluczenia. Lista wszystkiego, co dostawca przyjął, a czego nie było w zapytaniu, oraz wszystkiego, czego nie wycenił. To najważniejsza część oferty i najczęściej pomijana przy ocenie. Dwie oferty z tą samą ceną i różnymi wykluczeniami to dwie różne ceny.

Blok 4: zespół. Kto konkretnie będzie pracował, w jakich rolach, z jakim doświadczeniem i w jakim wymiarze czasu. Czy osoby z oferty to te same, które zobaczysz w projekcie, i co się stanie, jeśli któraś odejdzie. Pytanie o warunki zastępstwa jest tu ważniejsze niż życiorysy.

Blok 5: sposób pracy. Długość iteracji, częstotliwość pokazów działającego oprogramowania, sposób raportowania, zarządzanie zmianą, praktyki inżynierskie (testy automatyczne, code review, CI/CD), dostęp klienta do repozytorium i narzędzi.

Do tego kilka pytań zamkniętych, na które oczekujesz odpowiedzi „tak” albo „nie” z komentarzem: czy akceptujecie przeniesienie autorskich praw majątkowych do kodu z chwilą zapłaty za etap, czy repozytorium będzie w naszej organizacji od pierwszego dnia, czy korzystacie z podwykonawców, czy akceptujecie wzór umowy z załącznika. Takie pytania wyłapują niezgodności, zanim zainwestujesz w ocenę.

Pytania, których nie warto zadawać: „opiszcie swoją metodykę” (każdy opisze Agile), „podajcie listę klientów” bez prośby o rozmowę referencyjną przy podobnym projekcie, „zalety waszej firmy”. Odpowiedzi na nie są marketingiem i nie różnicują ofert.

Jak zbudować kryteria oceny ofert i ich wagi?

Kryteria muszą być ogłoszone w zapytaniu, zanim przyjdą oferty. Ustalanie ich po otwarciu kopert zawsze kończy się dopasowaniem kryteriów do faworyta, nawet jeśli nikt tego nie planował.

Najważniejsza decyzja dotyczy wagi ceny. W oprogramowaniu dedykowanym cena oferty jest słabym predyktorem kosztu projektu, bo koszt końcowy zależy od tego, jak dostawca radzi sobie ze zmianą, jakością i ryzykiem. Ustawodawca doszedł do podobnego wniosku dla sektora publicznego: art. 246 Prawa zamówień publicznych co do zasady nie pozwala zamawiającym z administracji publicznej stosować ceny jako jedynego kryterium albo kryterium o wadze przekraczającej 60%, chyba że określą wymagania jakościowe dla głównych elementów zamówienia (Pzp, art. 246). Firma prywatna nie podlega temu przepisowi, ale jego logika dobrze przenosi się na zakup oprogramowania. W projektach o niepewnym zakresie rozsądny przedział wagi ceny to 30–40%.

Pozostałe kryteria warto podzielić na cztery grupy:

• Jakość rozwiązania i zrozumienie problemu. Czy propozycja odpowiada na cel biznesowy, czy dostawca zidentyfikował ryzyka, czy architektura jest adekwatna do skali (nie za skromna, nie przesadzona).
• Zespół i jego stabilność. Doświadczenie osób nazwanych w ofercie, warunki zastępstwa, proporcje seniorów do juniorów.
• Sposób pracy i przejrzystość. Pokazy działającego oprogramowania, dostęp do repozytorium, raportowanie, zarządzanie zmianą, praktyki jakości.
• Warunki umowne i ryzyko. Akceptacja kluczowych zapisów, model rozliczeń, okres gwarancji, łatwość wyjścia.

Każde kryterium potrzebuje skali punktowej z opisem, co znaczy 1, 3 i 5. „Zespół: 5 punktów, gdy wszystkie kluczowe role mają nazwane osoby z doświadczeniem w podobnym projekcie i dostawca gwarantuje ich udział; 3 punkty, gdy kluczowe role są nazwane, ale bez gwarancji; 1 punkt, gdy zespół opisano tylko rolami”. Bez takich opisów punktacja zależy od nastroju oceniającego.

Ocenę powinny przeprowadzić co najmniej trzy osoby: ktoś od biznesu, ktoś technicznie kompetentny i ktoś od zakupów lub finansów. Każda ocenia osobno, potem porównujecie wyniki i omawiacie największe rozbieżności. Rozbieżności są cenne: zwykle pokazują, że oferta mówi coś niejednoznacznie i trzeba dopytać dostawcę.

Cenę warto punktować nie liniowo względem najtańszej oferty, tylko względem budżetu albo mediany. Formuła „najniższa cena dostaje 100% punktów, pozostałe proporcjonalnie” premiuje skrajnie tanią ofertę i karze rzetelne. Jeśli jedna z ofert jest wyraźnie zaniżona, ustawia skalę dla wszystkich.

Jak wygląda przykładowa macierz oceny ofert?

Poniższa macierz to punkt wyjścia, który dostosujesz do swojego projektu. Wagi są naszą rekomendacją dla projektu dedykowanego o średniej niepewności zakresu, nie normą rynkową. Kolumna „sygnał ostrzegawczy” pomaga oceniającym, którzy nie są technikami.

Kryterium	Waga	Co oceniasz (5 pkt)	Sygnał ostrzegawczy (1 pkt)
Cena całkowita etapu „musi”	30%	Mieści się w budżecie, rozbita na role i osobodni, z jawną rezerwą	Jedna kwota bez rozbicia albo cena o 30% i więcej poniżej mediany bez wyjaśnienia
Zrozumienie problemu i ryzyk	15%	Dostawca nazwał ryzyka, zadał pytania, zaproponował uproszczenia	Brak ryzyk, powtórzenie treści RFP, „zrobimy wszystko”
Założenia i wykluczenia	10%	Pełna lista, zgodna z RFP, bez wykluczeń kluczowych elementów	Brak listy albo wykluczone integracje, testy, wdrożenie
Zespół	15%	Nazwane osoby w kluczowych rolach, warunki zastępstwa na piśmie	Zespół opisany tylko rolami, przewaga juniorów
Sposób pracy i jakość	10%	Pokazy co 2 tygodnie, testy automatyczne, code review, CI/CD, repozytorium u klienta	Pierwsze demo po kilku miesiącach, brak dostępu do kodu
Warunki umowne	10%	Akceptacja przeniesienia praw, odbioru, gwarancji i wyjścia	Licencja zamiast przeniesienia praw, brak planu przekazania
Referencje przy podobnym projekcie	5%	Rozmowa z klientem o podobnej skali i integracjach	Same logotypy, brak zgody na kontakt
Wynik pilotażu lub warsztatu	5%	Działający fragment lub rzetelne wyniki warsztatu	Brak udziału albo prezentacja handlowa zamiast pracy

Dwie uwagi praktyczne. Po pierwsze, jeśli dwie oferty różnią się w punktacji o kilka punktów procentowych, traktuj to jako remis i rozstrzygaj pilotażem albo dodatkową rundą pytań, a nie arytmetyką. Macierz porządkuje dyskusję, nie zastępuje osądu. Po drugie, zapisz uzasadnienie każdej oceny. Za pół roku, gdy projekt będzie w połowie, chcesz wiedzieć, dlaczego wybraliście tego dostawcę, a zarząd będzie chciał to wiedzieć jeszcze bardziej.

Jakie błędy w zapytaniu podnoszą cenę ofert?

Część kosztu projektu powstaje w dokumencie, zanim dostawca zobaczy go pierwszy raz. Siedem błędów powtarza się najczęściej.

1. Fixed price przy niejasnym zakresie. Prośba o stałą cenę za system opisany na kilku stronach to prośba o wycenę ryzyka. Dostawca, który przyjmuje na siebie ryzyko zakresu, dolicza do ceny premię za to ryzyko, i jest to racjonalne. Jeśli zakres jest niepewny, poproś o fixed price na discovery albo pierwszy etap, a resztę w modelu z jawną stawką. Szczegółowe porównanie, kto w którym modelu płaci za niepewność, znajdziesz w artykule abonament zespołu, time & materials czy fixed price.

2. Przymiotniki zamiast liczb. „Skalowalny”, „bezpieczny”, „wydajny”, „nowoczesny”. Każde z tych słów dostawca musi przełożyć na liczbę i każdy przełoży na inną. Ostrożny dostawca przyjmie wysoką liczbę i wyceni drogą architekturę.

3. Za krótki termin na odpowiedź. Tydzień na odpowiedź na RFP dużego systemu oznacza, że dostawcy nie zdążą zadać pytań, więc doliczą rezerwę na wszystko, czego nie rozumieją. Dla projektu średniej wielkości realne minimum to dwa do trzech tygodni, w tym tydzień na pytania.

4. Brak sesji pytań i odpowiedzi. Pytania zadane przez jednego dostawcę i odpowiedzi rozesłane wszystkim to najtańszy sposób na zmniejszenie rozrzutu cen. Bez tego każdy interpretuje dokument sam.

5. Ukryte warunki umowne. Jeśli wzór umowy z karami umownymi, nieograniczoną odpowiedzialnością albo długą gwarancją pojawia się dopiero po wyborze, dostawca albo podniesie cenę w negocjacjach, albo wycofa się. W obu przypadkach tracisz czas. Pokaż kluczowe warunki w RFP. Co powinno się w nich znaleźć, opisujemy w artykule o klauzulach umowy z software house’em, które chronią zamawiającego.

6. Nieproporcjonalne wymagania formalne. Gwarancje bankowe, wysokie ubezpieczenia OC, certyfikaty, których projekt nie potrzebuje, obszerne oświadczenia. Każde z nich ma koszt, który trafi do ceny, i każde zmniejsza liczbę firm, które odpowiedzą. Wymagaj tego, co chroni projekt, nie tego, co było we wzorze z innego przetargu.

7. Rozesłanie zapytania do zbyt wielu firm. Dziesięciu oferentów oznacza, że każdy ma około 10% szans. Dostawcy wiedzą o tym i inwestują w ofertę proporcjonalnie mniej: zamiast architekta odpowiada handlowiec z szablonem. Trzech do pięciu starannie wybranych dostawców daje lepsze oferty i mniej pracy przy ocenie.

Wszystkie te błędy mają wspólny mianownik: przerzucają na dostawcę pracę albo ryzyko, które zamawiający mógłby wziąć na siebie taniej. Dostawca nie odmówi, tylko wystawi za to rachunek.

Jak rozpoznać ofertę zaniżoną, która podrożeje po podpisaniu?

Najtańsza oferta nie zawsze jest pułapką. Czasem dostawca ma gotowy komponent, który skraca pracę, czasem lepiej zrozumiał, czego nie trzeba budować. Ale są sygnały, które warto sprawdzić, zanim uznasz niską cenę za okazję.

Cena wyraźnie poniżej pozostałych bez wyjaśnienia. W polskich zamówieniach publicznych cena niższa o co najmniej 30% od średniej arytmetycznej cen złożonych ofert albo od wartości zamówienia powiększonej o VAT co do zasady obliguje zamawiającego do wezwania wykonawcy do wyjaśnień (art. 224 ust. 2 Pzp). Ten próg to dobra reguła także w zakupach prywatnych: oferta tańsza o jedną trzecią od mediany wymaga rozmowy, nie gratulacji.

Brak założeń i wykluczeń albo bardzo długa lista wykluczeń. Pierwsze oznacza, że dostawca nie przemyślał projektu, drugie, że przemyślał go bardzo dokładnie i wyciął wszystko, co kosztowne. Szukaj szczególnie wykluczonych integracji, migracji danych, testów, wdrożenia na produkcję i dokumentacji.

Mało godzin na pracę „wokół kodu”. Testy, zarządzanie projektem, analiza, wdrożenie, poprawki po testach akceptacyjnych. Jeśli w ofercie programowanie stanowi prawie całość, a reszta to symboliczne pozycje, ta praca i tak zostanie wykonana, tylko w ramach zleceń zmian albo kosztem jakości.

Zespół zdominowany przez juniorów albo nienazwany. Niska stawka średnia może oznaczać mniej doświadczony zespół. To nie musi być złe, ale wtedy cena za funkcję wcale nie jest niższa, bo junior potrzebuje więcej czasu i więcej poprawek.

Agresywny harmonogram. Termin krótszy niż u pozostałych o połowę przy podobnym zespole oznacza, że ktoś się pomylił. Zapytaj, skąd różnica.

Rygorystyczna procedura zmian. Jeśli oferta jest tania, a definicja zmiany szeroka i każda wymaga osobnej wyceny, model biznesowy dostawcy może opierać się na zleceniach zmian. Poproś o przykładową wycenę typowej zmiany i o stawki, które będą do niej stosowane.

Kiedy widzisz te sygnały, nie odrzucaj oferty automatycznie. Wezwij dostawcę do wyjaśnień: poproś o rozbicie wyceny, założenia i porównanie z Twoim rozumieniem zakresu. Rzetelny dostawca z niską ceną umie ją obronić. Dostawca, który na pytanie „dlaczego tak tanio?” odpowiada „bo jesteśmy efektywni”, zwykle odzyska różnicę później.

Jak przeprowadzić proces: terminy, pytania, prezentacje i płatny pilotaż?

Proces jest równie ważny jak dokument. Typowy przebieg dla projektu średniej wielkości wygląda tak.

Tydzień 0: krótka lista. Wybierz trzech do pięciu dostawców na podstawie RFI, rekomendacji, publicznych referencji albo rozmów wstępnych. Podpisz NDA, zanim wyślesz szczegóły.

Tydzień 1: wysłanie RFP i pytania. Dostawcy mają tydzień na pytania pisemne. Odpowiedzi publikujesz wszystkim jednocześnie, bez wskazywania, kto pytał. Jeśli pytania pokazują, że coś w dokumencie jest niejasne, popraw dokument i roześlij nową wersję.

Tygodnie 2–3: przygotowanie ofert. Opcjonalnie jedno spotkanie z każdym dostawcą, na którym jego architekt może dopytać o szczegóły techniczne. To dobra inwestycja: rozmowa zastępuje kilkanaście założeń.

Tydzień 4: ocena pisemna. Każdy członek komisji ocenia osobno według macierzy. Potem wspólne spotkanie i lista pytań uzupełniających do każdego dostawcy.

Tydzień 5: prezentacje. Najlepiej z udziałem osób, które faktycznie będą pracować w projekcie, nie tylko zespołu sprzedaży. Poproś, żeby zamiast prezentacji firmy omówili trzy największe ryzyka Twojego projektu i jak by nimi zarządzali. Zadaj pytanie, na które nie ma dobrej odpowiedzi w RFP, i zobacz, jak zespół rozumuje.

Opcjonalnie tygodnie 6–9: płatny pilotaż. Gdy dwóch dostawców wypada podobnie, najpewniejszym rozstrzygnięciem jest płatna, krótka praca: discovery, prototyp kluczowego scenariusza albo mały, zamknięty fragment systemu. Kosztuje ułamek projektu i pokazuje to, czego nie pokaże żadna oferta: jak zespół zadaje pytania, jak szybko pojawia się działające oprogramowanie i jak reaguje, gdy zmienisz zdanie. Ustal z góry, że wynik pilotażu należy do Ciebie niezależnie od tego, kto wygra.

Ten harmonogram wydaje się długi, ale porównaj go z kosztem złego wyboru. Zmiana dostawcy w trakcie projektu oznacza przekazanie kodu, odtwarzanie wiedzy i zwykle kilka miesięcy opóźnienia. Pięć tygodni starannego wyboru to tania polisa.

Jedna uwaga dla firm, które podlegają Prawu zamówień publicznych: opisany proces dotyczy zamówień prywatnych. Zamówienia publiczne mają własne, sformalizowane tryby, terminy i zasady komunikacji z wykonawcami, i to one mają pierwszeństwo.

Co zrobić z wynikiem, żeby przejść od oceny do umowy?

Wybór dostawcy to nie koniec pracy zakupowej, tylko przejście do jej najważniejszej części. Trzy kroki chronią wartość, którą zbudowało RFP.

Wpisz ofertę do umowy. Założenia, wykluczenia, skład zespołu i harmonogram z oferty powinny stać się załącznikami do umowy. Jeśli dostawca w ofercie obiecał nazwanych architektów, a umowa mówi tylko o „odpowiednio wykwalifikowanym personelu”, obietnica nie ma mocy. To samo dotyczy rezerwy na ryzyko i stawek dla zleceń zmian.

Zamień zakres na plan pierwszego etapu. Niezależnie od modelu rozliczeń pierwszy etap powinien zakończyć się działającym, odebranym fragmentem systemu w ciągu kilku tygodni, a nie kilku miesięcy. Pierwszy odbiór to moment, w którym widzisz, czy założenia z oferty się sprawdzają, i najtańszy moment na korektę.

Poinformuj przegranych i poproś ich o zgodę na kontakt w przyszłości. Rzetelni dostawcy, którzy przegrali, są najlepszym planem awaryjnym na wypadek, gdyby wybrany partner nie dowiózł. Krótka informacja zwrotna, dlaczego przegrali, buduje relację i sprawia, że następnym razem odpowiedzą chętniej.

Warto też policzyć całkowity koszt wyboru, a nie tylko cenę oferty: koszt utrzymania po wdrożeniu, licencji, infrastruktury, Twojego zespołu po stronie klienta. Wyższa cena wytworzenia przy niższym koszcie utrzymania często wygrywa w horyzoncie pięciu lat. Jak to policzyć, opisujemy w artykule o całkowitym koszcie posiadania oprogramowania.

Jakie są kluczowe wnioski?

Zapytanie ofertowe na oprogramowanie dedykowane jest pierwszym dokumentem projektu, nie formalnością zakupową. To w nim powstaje większość rozrzutu cen, który potem przypisujemy dostawcom.

Zapamiętaj sześć rzeczy. Po pierwsze, każda luka w dokumencie kosztuje, bo dostawca albo dolicza rezerwę, albo przyjmuje najtańszą interpretację i odzyskuje różnicę w zleceniach zmian. Po drugie, zakres opisuj priorytetami, scenariuszami i liczbami, a nie przymiotnikami, i wyraźnie zaznacz, co jest poza zakresem. Po trzecie, podaj budżet lub jego przedział oraz warunki umowne, które są nienegocjowalne. Po czwarte, wymuś jednolity formularz odpowiedzi z rozbiciem wyceny, założeniami, wykluczeniami i nazwanym zespołem. Po piąte, ogłoś kryteria i wagi przed otwarciem ofert, trzymaj wagę ceny w okolicach jednej trzeciej i punktuj ją względem budżetu lub mediany, a nie najtańszej oferty. Po szóste, ofertę tańszą o jedną trzecią od pozostałych traktuj jako powód do pytań, a remis rozstrzygaj płatnym pilotażem.

Dobre RFP nie gwarantuje udanego projektu, ale sprawia, że porównujesz oferty na ten sam projekt. A to jedyny warunek, przy którym wybór dostawcy w ogóle jest wyborem.

Na koniec kilka słów o tym, jak wygląda to z naszej strony. W tworzeniu oprogramowania na zamówienie zaczynamy od fazy discovery, która trwa zwykle od tygodnia do dwóch i służy zdefiniowaniu zakresu oraz architektury. Pracujemy w dwutygodniowych sprintach, z działającymi przyrostami od początku, i wyceniamy w modelu fixed price albo time & materials, zależnie od tego, jak dobrze zdefiniowany jest zakres. Przy projektach o stałej cenie pracujemy na kamieniach milowych.

Gdy zakres jest niepewny, rekomendujemy rozpoczęcie od krótkiego pilotażu zamiast wyceny całości na podstawie kilku stron opisu. Nasze orientacyjne stawki według ról i seniority są opublikowane, więc możesz porównać je z ofertami przed rozmową, a przy MVP wstępne widełki da Ci kalkulator kosztów MVP.

Jeśli przygotowujesz zapytanie ofertowe i chcesz sprawdzić, czy dokument jest gotowy do wysłania, albo masz już oferty i nie wiesz, skąd biorą się różnice, umów rozmowę. Powiemy wprost, czego w zapytaniu brakuje, i czy w Twojej sytuacji lepsze będzie pełne RFP, zapytanie na discovery czy po prostu rozmowa z kilkoma firmami.