Zakupy technologii: dlaczego RFP często premiuje złego dostawcę

RFP porządkuje zakupy technologii, ale jego największa zaleta jest zarazem największą słabością: wymusza porównywalność tam, gdzie część najważniejszych różnic między dostawcami ujawnia się dopiero po wdrożeniu.

W klasycznym procesie wszystko wygląda racjonalnie. Firma opisuje wymagania, ustala kryteria, zbiera oferty i przelicza je na punkty. Cena jest liczbą. Liczba funkcji również. Doświadczenie można wyrazić liczbą wdrożeń, a certyfikaty zaznaczyć w tabeli.

Znacznie trudniej w ten sposób zmierzyć jakość architektury, elastyczność rozwiązania, koszt przyszłych zmian, kompetencje konkretnego zespołu wdrożeniowego czy łatwość odejścia od dostawcy. Właśnie tutaj formalnie poprawne RFP może zacząć zniekształcać decyzję.

Nie oznacza to, iż RFP statystycznie „wybiera złych dostawców”. Na taką tezę nie ma dziś dobrych danych. Badania pokazują jednak mechanizmy, które sprawiają, iż przy złożonych zakupach technologicznych wynik postępowania może nie odzwierciedlać pełnego ryzyka biznesowego.

Im bardziej szczegółowe RFP, tym niekoniecznie więcej wiedzy

Badanie 250 amerykańskich RFP dotyczących oprogramowania, opublikowane w „International Journal of Procurement Management”, pokazuje skalę formalizacji takich procesów. Próba obejmowała publicznych zamawiających w USA i systemy m.in. ERP, finansowe oraz asset management, więc nie można przenosić jej wyników bezpośrednio na cały rynek przedsiębiorstw.

Dane są jednak wymowne. Zaledwie 2 proc. analizowanych RFP ujawniało budżet projektu, a tylko 30 proc. podawało oczekiwany harmonogram wdrożenia. Autorzy stwierdzili również, iż większość dokumentów zawierała ograniczone informacje o przebiegu procesu oceny i harmonogramie zakupu.

Podobny obraz daje znacznie nowsze badanie National Academies z 2025 r. Obejmowało ono 75 postępowań na zaawansowane technologie w amerykańskim sektorze transportowym. Przeciętne RFP zawierało 60 szczegółowych wymagań, ale rozpiętość wynosiła od pięciu do 400. Budżet ujawniono tylko w siedmiu przypadkach, a oczekiwany harmonogram implementacji w 14. Szczegółowy opis istniejącego środowiska technologicznego znalazł się w 24 z 75 dokumentów.

To istotna asymetria. Dostawca może odpowiadać na dziesiątki lub setki pytań o funkcjonalność, nie znając jednocześnie wszystkich warunków, które zdecydują o rzeczywistym koszcie integracji i wdrożenia.

To, co łatwo zmierzyć, zaczyna dominować

Problem nie ogranicza się do samego RFP. Badanie Davida Fitoussiego i Vijaya Gurbaxaniego dotyczące rzeczywistych kontraktów outsourcingowych IT pokazuje szerszą trudność z mierzeniem złożonych usług technologicznych.

Autorzy analizowali kontrakty, w których dostawcy realizowali jednocześnie cele łatwe i trudne do zmierzenia. Stwierdzili, iż im więcej stosowano wskaźników wydajności, tym niższy był poziom satysfakcjonujących wyników kontraktu. Nie oznacza to, iż KPI powodują porażkę. Pokazuje natomiast, iż większa liczba miar nie musi poprawiać kontroli nad usługą, jeżeli jej wartość zależy od wielu wzajemnie powiązanych elementów.

Podobne napięcie opisuje badanie trzech rzeczywistych zakupów systemów informatycznych w Norwegii. Organizacje musiały z jednej strony dokładnie zdefiniować wymagania przed zakupem, a z drugiej potrzebowały dialogu z dostawcami, aby w ogóle dobrze zrozumieć dostępne rozwiązania. Im bardziej złożony system, tym trudniejsze staje się założenie, iż zamawiający potrafi z góry opisać wszystkie istotne wymagania.

To właśnie tutaj RFP może premiować nie tyle najlepszą technologię, ile ofertę najlepiej dopasowaną do konstrukcji dokumentu.

Cena zakupu nie pokazuje ceny decyzji

Drugi problem pojawia się kilka lat później.

OECD, analizując zamówienia ICT na Słowacji, wskazało vendor lock-in jako najważniejszy problem zgłaszany podczas rozmów z uczestnikami rynku. W latach 2016–2019 na jeden zakończony przetarg dotyczący usług IT przypadało tam przeciętnie tylko 1,9 oferty. OECD wiązało niską konkurencję m.in. z uzależnieniem od istniejących systemów oraz kosztami kompatybilności i migracji. Są to dane dotyczące konkretnego rynku zamówień publicznych, nie uniwersalna miara europejskiego procurementu, ale sam mechanizm jest dobrze rozpoznany.

Podobny problem widać dziś w chmurze. W badaniu przygotowanym dla brytyjskiego Competition and Markets Authority przeprowadzono 60 pogłębionych rozmów z przedstawicielami 50 firm korzystających z usług AWS, Microsoftu, Google, IBM i Oracle. Badanie było jakościowe, a więc nie reprezentuje statystycznie całego rynku, ale pokazuje realne decyzje dużych klientów.

Koszt zmiany dostawcy stał się zresztą problemem regulacyjnym. Unijny Data Act przewiduje, iż od 12 stycznia 2027 r. dostawcy usług przetwarzania danych nie będą mogli pobierać od klientów opłat za sam proces zmiany dostawcy.

RFP nie jest modelem przyszłości

RFP pozostaje użytecznym narzędziem, szczególnie gdy kupujący dokładnie wie, czego potrzebuje, a rozwiązania rzeczywiście można porównać według wspólnych parametrów.

Znacznie gorzej działa założenie, iż arkusz punktowy może sprowadzić złożoną decyzję technologiczną do jednej liczby. Przy systemach, które będą działać przez pięć czy dziesięć lat, znaczenie mają również elementy słabo widoczne w dniu składania ofert: migracja, integracje, możliwość zmiany architektury, dostęp do danych, zależność od kompetencji dostawcy i koszt wyjścia.

RFP mierzy bardzo dokładnie zgodność z wymaganiami zapisanymi w RFP. To wcale nie musi być to samo, co wartość technologii dla firmy.