Jak przygotować RFI/RFP, żeby dostać porównywalne oferty od dostawców ICT?

Jak uniknąć nieporównywalnych ofert

Przygotowanie RFI i RFP, które prowadzą do porównywalnych, a więc naprawdę decyzyjnych ofert, wymaga znacznie więcej niż zgrabnego opisu celu projektu. Jeśli dokument zostawia pola do interpretacji, dostawcy wypełnią je po swojemu: jedni dorzucą funkcje w cenie, inni wytną koszty ukryte poza zakresem, jeszcze inni zmienią metrykę licencjonowania tak, by wstępna cena wyglądała atrakcyjnie. Różnice nie wynikają wtedy z jakości rozwiązań, tylko z innego rozumienia wymagań. Dlatego RFI i RFP powinny przede wszystkim redukować niejednoznaczność, standaryzować sposób odpowiedzi i narzucać wspólny mianownik dla wymiarów technicznych, kosztowych i prawnych. Dobrze przygotowany proces zaczyna się od krótkiego RFI, które kalibruje język i możliwości rynku, a kończy na RFP z jednoznacznymi tabelami, definicjami i kryteriami oceny, dzięki którym porównujemy oferty „jabłko do jabłka”.

RFI – kalibracja rynku i języka

RFI pełni dwie kluczowe funkcje: pozwala potwierdzić, jak rynek rozumie problem, oraz pomaga zbudować wspólny słownik pojęć, zanim przejdziemy do wycen. W tym etapie nie chodzi o negocjowanie stawek, lecz o rozpoznanie architektury referencyjnej, typowych podejść licencyjnych, ograniczeń integracyjnych i dostępnych modeli serwisowych. Warto poprosić dostawców o krótkie opisy przypadków użycia, listę najczęstszych ryzyk wdrożeniowych oraz wstępną mapę kompetencji, unikając jednocześnie proszenia o gotowe kosztorysy, bo te i tak będą niewiarygodne bez twardych założeń wolumenowych. Wynik RFI powinien przełożyć się na ujednolicony słownik i strukturę odpowiedzi, które staną się załącznikami do RFP. To właśnie na tym etapie warto ustalić, czy rynek licencjonuje rozwiązanie per użytkownik, urząd, rdzeń CPU, wolumen transakcji, gigabajt danych czy przepustowość, bo późnej zamiana metryki po stronie oferenta jest jednym z głównych źródeł nieporównywalności.

RFP – struktura, która wymusza precyzję

RFP z kolei musi być dokumentem operacyjnym: nie esejem o strategii, tylko „instrukcją wypełnienia” z rygorystyczną strukturą. Najwięcej porządku wprowadza zestaw trzech załączników. Pierwszy to założenia referencyjne i dane wejściowe, czyli twarde, liczbowe parametry środowiska: liczba aktywnych użytkowników i ich typy, profile ruchu dobowego i sezonowego, wolumeny przechowywanych danych oraz przyrosty, liczba lokalizacji, okna serwisowe, języki wsparcia, wymagane poziomy dostępności, założona stopa wzrostu i plan rozwoju funkcjonalności w horyzoncie trzech lat. Drugi to macierz wymagań funkcjonalnych i niefunkcjonalnych z oznaczeniem priorytetu (must, should, could) oraz prośbą o jasną deklarację spełnienia wraz ze wskazaniem, czy dana funkcja jest dostępna natywnie, wymaga konfiguracji, czy też wymaga rozwoju. Trzeci to wzór arkusza kosztowego i kontraktowego, który narzuca jednolite pozycje TCO: licencje podstawowe i dodatkowe, koszty infrastruktury chmurowej lub on premise, profesjonalne usługi wdrożeniowe z rozbiciem na etapy, wsparcie L2/L3, utrzymanie, szkolenia, migrację danych, testy wydajności i bezpieczeństwa, a także elementy często pomijane jak koszty transmisji danych w chmurze, narzędzia do monitoringu i logowania, backup i retencja, testy odtworzeniowe czy rezerwy na refaktoryzację integracji.

Słownik pojęć i wymogi zgodności

Kluczowym mechanizmem zapewniającym porównywalność jest słownik pojęć i definicji. Pojęcia takie jak użytkownik, incydent, dostępność, okno serwisowe, czas reakcji, czas przywrócenia, błąd krytyczny, wersja minor i major, a nawet pojęcie wdrożenia produkcyjnego wymagają precyzyjnego zdefiniowania, bo różne firmy rozumieją je inaczej. Warto z góry opisać sposób pomiaru i dowodzenia wskaźników, na przykład czy dostępność liczona jest w skali miesiąca kalendarzowego z wyłączeniem okien serwisowych, czy też w skali roku, oraz jaki jest sposób raportowania zdarzeń i wyznaczania granicy odpowiedzialności w modelu wspólnej odpowiedzialności. RFP powinno jasno oddzielać wymogi zgodności regulacyjnej i bezpieczeństwa – od RODO i umowy powierzenia przetwarzania, przez wymagania wynikające z NIS2 czy DORA, po oczekiwane certyfikaty typu ISO 27001 i NIS 2 – a także określać minimalne wymagania dotyczące logów, retencji, testów penetracyjnych, reakcji na incydenty i planów ciągłości działania.

Integracja i odpowiedzialność

W sferze integracji konieczny jest opis granic odpowiedzialności i środowisk. Zamawiający powinien wskazać systemy źródłowe i docelowe, protokoły i standardy integracji, wzorce API oraz oczekiwaną architekturę wymiany danych, jednocześnie precyzując, kto odpowiada za dostarczenie środowisk testowych, danych syntetycznych i narzędzi do testów. Dobrym zwyczajem jest dołączenie schematu RACI dla kluczowych aktywności: migracji danych, integracji, testów, szkolenia użytkowników, zarządzania zmianą i go live. W ten sposób oferty będą uwzględniały ten sam zakres pracy, a nie różniły się ukrytym przerzucaniem obowiązków na stronę klienta. Podobną funkcję pełni opis planu zarządzania zmianą: częstotliwości wydań, okien wdrożeniowych, procesu CAB (ang. Change Advisory Board), zasad wprowadzania poprawek krytycznych i harmonogramu publikacji roadmapy.

SLA, testy i monitorowanie

RFP powinno precyzować wymagania dotyczące poziomów usług i konsekwencji ich niespełnienia, ale również mechanikę naliczania kredytów serwisowych i ich kapitalizacji. Sama deklaracja dostępności nic nie znaczy, jeśli nie wiemy, w jakim reżimie i na jakich danych będzie liczona oraz czy kredyty są odliczane od faktury bieżącej, czy odkładane jako „punkty” uznaniowe. Podobnie ważna jest weryfikowalna metodologia monitorowania usług, najlepiej z dostępem klienta do panelu z metrykami. Jeśli projekt przewiduje Disaster Recovery, RFP powinno wymagać nie tylko RTO i RPO, ale również cyklu testów odtworzeniowych oraz raportów z ich wyników, bo bez testów parametry pozostają deklaracją marketingową.

Spójność cen i okresów obowiązywania

Dużym źródłem nieporównywalności są odmienne metryki cenowe i okresy obowiązywania stawek. RFP musi narzucić walutę wyceny, zasady indeksacji i maksymalne limity podwyżek, określić długość gwarancji cenowej oraz wymagane progi rabatowe przy zobowiązaniach wolumenowych. Jednocześnie konieczne jest wymuszenie scenariuszy cenowych: baza na trzydzieści sześć miesięcy i wariant pięcioletni, a także trzy scenariusze wolumenowe – ostrożny, bazowy i ambitny – które pozwolą policzyć wrażliwość TCO na zmianę skali. Dostawca powinien wprost zdeklarować koszty wyjścia: eksport danych, deinstalację usług, wsparcie migracji do innego rozwiązania i pomoc w transferze wiedzy. Bez tej pozycji ryzyko lock in materializuje się dopiero na końcu cyklu życia, kiedy pole manewru jest najwęższe.

Format odpowiedzi

Często niedocenianym elementem jest wymuszenie formatu odpowiedzi, który minimalizuje kreatywność tam, gdzie nie jest ona pożądana. Najlepiej sprawdzają się arkusze z polami wyboru i ograniczoną liczbą dozwolonych wartości oraz komentarzami tylko w wyznaczonych sekcjach. Rzetelny proces dopuszcza różnice – na przykład alternatywne architektury – ale wymaga, by każda różnica była jasno oznaczona jako odstępstwo wraz z uzasadnieniem, wpływem na koszty i ryzykiem. Dostawcy powinni też potwierdzić, że zapoznali się z wszystkimi odpowiedziami w trybie Q&A i uwzględnili je w ofercie, a Zamawiający musi zagwarantować, że odpowiedzi na pytania będą publikowane anonimowo, w tym samym czasie dla wszystkich i jako część kontraktowa RFP. Równie ważna jest dyscyplina wersjonowania dokumentów: zmiany w treści RFP po publikacji należy oznaczać jako „uzupełnienie” z wyraźnym opisem zakresu i wpływu na terminy.

Normalizacja i ocena ofert

Aby porównanie ofert nie sprowadzało się do wrażenia estetycznego, proces oceny powinien mieć dwie bramki: zgodność minimalna i ocena punktowa. Najpierw odrzucamy oferty niespełniające krytycznych wymagań lub odmawiające kluczowych zapisów prawnych, dopiero później porównujemy pozostałe na bazie macierzy wag i kryteriów. Kryteria powinny obejmować nie tylko cenę bazową, ale także TCO z kosztami wdrożenia i utrzymania, jakość spełnienia wymagań funkcjonalnych i niefunkcjonalnych, ryzyko projektu mierzone liczbą i powagą odstępstw, dojrzałość zespołu i referencje oraz ocenę warunków kontraktowych. Równolegle warto przewidzieć krótki dowód koncepcji z jasno zdefiniowanym scenariuszem, danymi testowymi i kryteriami sukcesu, bo PoC urealnia deklaracje i pokazuje, jak wygląda współpraca operacyjna.

Kalendarz i komunikacja

Równie istotny jest kalendarz i dyscyplina komunikacji. Ogłoszenie RFP powinno zawierać datę zamknięcia Q&A, termin publikacji odpowiedzi oraz warunki ewentualnej konferencji dla oferentów. Na pytania należy odpowiadać cyklicznie, a nie na bieżąco, aby wszyscy mieli ten sam dostęp do wiedzy. Zmiany w RFP po publikacji odpowiedzi muszą być ograniczone i ściśle wersjonowane, ponieważ każda modyfikacja wpływa na porównywalność. Wreszcie, aby uniknąć nieporozumień przy interpretacji, warto wskazać osobę odpowiedzialną za spójność wymagań i wyraźnie zabronić kontaktów poza oficjalnym kanałem, bo nieformalny lobbing dostarcza przewagi informacyjnej nielicznym i psuje jakość procesu.

Normalizacja i analiza wyników

Po zebraniu ofert następuje etap normalizacji kosztów, bez którego tabela porównawcza łatwo staje się zbiorem nieprzystających kolumn. Normalizacja polega na przeliczeniu wszystkich pozycji do z góry zdefiniowanych metryk, horyzontów i scenariuszy. Jeśli jeden dostawca wycenił licencję per użytkownik, a drugi per jednoczesna sesja, trzeba zastosować współczynniki wynikające z danych referencyjnych i potwierdzonych w RFI. Jeśli jeden ujął koszty migracji danych, a drugi nie, należy je doszacować według jednolitych stawek lub poprosić o uzupełnienie. Jeśli ktoś oparł indeksację na CPI USA, a drugi na HICP UE, trzeba przeliczyć wpływ na pięcioletni TCO według wspólnych założeń. Wynik normalizacji przedstawiamy w postaci kilku wykresów wodospadowych: od ceny katalogowej przez rabaty, koszty wdrożenia, utrzymanie i opcjonalne moduły po koszt wyjścia. Takie ujęcie ujawnia, gdzie dokładnie kryją się różnice i jakie są ich konsekwencje w czasie.

Dobre praktyki i rola PMO

Na koniec warto pamiętać, że RFI/RFP nie są celem samym w sobie, tylko narzędziem do zawarcia dobrej umowy i zbudowania działającego rozwiązania. Dokumenty, które wymuszają precyzję, przyspieszają później wdrożenie, bo eliminują spory definicyjne i ograniczają liczbę zmian zakresu. Im więcej jednoznaczności i wspólnych definicji włożymy do zapytania, tym mniej „pomysłowości” zobaczymy w ofertach tam, gdzie nie jest ona pożądana, a tym więcej różnic jakościowych i merytorycznych tam, gdzie powinna decydować o wyborze dostawcy. Jeśli proces ma być powtarzalny i obronny, dobrze jest pracować na ustandaryzowanych szablonach, które obejmują słownik pojęć, macierz wymagań, arkusz TCO, wzory SLA i KPI, minimalne wymagania bezpieczeństwa oraz matrycę odpowiedzialności; to właśnie one tworzą wspólny mianownik „porównywalnej oferty”. W organizacjach, które prowadzą kilka równoległych postępowań, dojrzałe biuro PMO lub zewnętrzny partner pełniący rolę Design Authority pomaga utrzymać spójność wymagań, terminów i kryteriów, dzięki czemu ryzyko rozjechania się założeń między projektami jest mniejsze. Dobrze przygotowane RFI i RFP to inwestycja w jakość decyzji, a nie koszt administracyjny: zwracają się nie tylko w postaci niższych cen i lepszych warunków, ale przede wszystkim w mniejszej liczbie niespodzianek po podpisaniu umowy, kiedy każda zmiana kosztuje najwięcej.

Pamiętaj