Większość firm zaczyna wybór ERP od rozmów z dostawcami i po trzech miesiącach ma na biurku kilka ofert, z których każda jest skonstruowana według innej logiki. Nie da się ich porównać, więc decyzja zapada na podstawie wrażenia z prezentacji albo ceny. RFP, czyli dobrze ułożone zapytanie ofertowe, odwraca ten porządek: najpierw spisujesz, czego potrzebujesz, a dopiero potem prosisz dostawców o odpowiedzi na te same pytania.
Ten przewodnik pokazuje, co musi zawierać RFP do systemu ERP, jak go zbudować i jak punktować odpowiedzi. To część szerszego procesu wyboru, który opisaliśmy w tekście o niezależnym doradztwie ERP, a jeśli dopiero zaczynasz, zerknij najpierw na to, czym jest ERP oraz na przewodnik wyboru ERP dla firmy produkcyjnej.
W skrócie
- RFP to ustrukturyzowane zapytanie ofertowe, dzięki któremu wszyscy dostawcy odpowiadają na te same pytania w tej samej strukturze.
- Dobry RFP powstaje po audycie procesów, a nie przed nim, bo inaczej jest listą życzeń oderwaną od realiów firmy.
- Kompletny dokument zawiera kontekst, procesy TO-BE, wymagania z priorytetami, część techniczną, scenariusze testowe i instrukcję odpowiedzi.
- Najwięcej wartości daje macierz oceny przygotowana zanim wyślesz RFP, bo to ona pozwala porównać oferty liczbowo, a nie po wrażeniu.
Czym jest RFP i czym różni się od RFI
RFP (Request for Proposal) to zapytanie ofertowe, w którym firma opisuje swoje potrzeby i prosi dostawców o wiążącą propozycję. W odróżnieniu od luźnej rozmowy handlowej RFP narzuca strukturę: każdy dostawca dostaje ten sam dokument i odpowiada w tym samym formacie. To właśnie ta dyscyplina sprawia, że oferty da się później porównać bezpośrednio.
Warto odróżnić RFP od RFI (Request for Information). RFI jest wcześniejszym, lżejszym krokiem: zbierasz ogólne informacje o dostawcach i ich możliwościach, żeby zawęzić rynek. RFP przychodzi później, gdy masz już krótką listę, i dotyczy konkretów: wymagań, scenariuszy, ceny i harmonogramu. W praktyce RFI filtruje, a RFP rozstrzyga.
| Cecha | RFI | RFP |
|---|---|---|
| Cel | zawęzić rynek dostawców | porównać i wybrać |
| Moment | wcześnie, przed shortlistą | po shortliście |
| Szczegółowość | ogólna | konkretne wymagania i scenariusze |
| Odpowiedź | informacyjna | oferta wiążąca |
Jak budujemy RFP do ERP
W procesach, które prowadzimy dla firm produkcyjnych i dystrybucyjnych, RFP nigdy nie powstaje „z głowy". Zawsze wyrasta z wcześniejszego audytu procesów AS-IS, bo dopiero wiedza o tym, jak firma działa dziś, pozwala napisać wymagania, na które dostawca może rzetelnie odpowiedzieć. Sam dokument budujemy w pięciu krokach.
- Kontekst i procesy TO-BE. Opisujemy skalę firmy, lokalizacje, branżę i docelowe procesy, które ERP ma obsłużyć. To rama, bez której wymagania wiszą w próżni.
- Wymagania z priorytetami. Spisujemy funkcje w podziale na must-have i nice-to-have. Bez priorytetów dostawca nie wie, co jest warunkiem, a co miłym dodatkiem.
- Część techniczna. Architektura, integracje, bezpieczeństwo, zgodność z KSeF, migracja danych z obecnych narzędzi. To tu kryją się największe koszty.
- Scenariusze testowe. Konkretne przypadki z procesów firmy, które dostawca musi pokazać na działającym systemie, a nie na ogólnym pokazie.
- Macierz oceny i instrukcja odpowiedzi. Wagi, skala ocen i format, w jakim dostawca ma odpowiedzieć. Bez tego oferty znowu będą nieporównywalne.
Najczęstszy błąd to napisanie RFP jako listy funkcji, których chcemy, bez scenariuszy. Wtedy dostawca pokazuje własny showcase, a nie Twój proces, i wracasz do punktu wyjścia: ofert, których nie da się porównać.
Co musi zawierać RFP
Kompletny RFP do ERP dla firmy w skali 100 do 500 osób realnie liczy 40 do 80 stron. Nie chodzi o objętość, tylko o to, żeby każde wymaganie dało się jednoznacznie ocenić w odpowiedzi. Oto sekcje, których nie powinno zabraknąć:
| Sekcja RFP | Co zawiera | Po co |
|---|---|---|
| Kontekst firmy | skala, branża, lokalizacje, obecne systemy | dostawca rozumie, do czego dopasowuje ofertę |
| Procesy TO-BE | docelowy przepływ pracy po wdrożeniu | oferta odpowiada na realny proces, nie abstrakcję |
| Wymagania funkcjonalne | lista must-have i nice-to-have | oddziela warunki od dodatków |
| Wymagania techniczne | architektura, integracje, bezpieczeństwo, KSeF | ujawnia koszty i ryzyka integracji |
| Migracja danych | zakres i źródła danych do przeniesienia | jedna z najczęściej pomijanych pozycji kosztu |
| Model licencyjny i budżet | oczekiwany model, ramy budżetu | odsiewa oferty poza zasięgiem |
| Scenariusze testowe | przypadki do pokazania w demo | weryfikuje system na Twoim procesie |
| Instrukcja odpowiedzi | format, terminy, macierz oceny | czyni oferty porównywalnymi |
Sekcja, którą najczęściej widzimy pominiętą, to migracja danych i instrukcja odpowiedzi. Pierwsza potrafi urosnąć do jednej z najdroższych pozycji wdrożenia, a druga decyduje o tym, czy w ogóle da się oferty zestawić obok siebie.
Jak punktować odpowiedzi dostawców
Macierz oceny przygotowujemy zanim wyślemy RFP, a nie po otrzymaniu ofert. Inaczej wagi nieświadomie dopasowują się do najładniejszej prezentacji. Każde wymaganie dostaje wagę, a odpowiedź dostawcy ocenę w jednej, prostej skali pokrycia:
- Pełne pokrycie standardem: funkcja działa od razu, bez dodatkowej pracy.
- Pokrycie po konfiguracji: funkcja jest, ale wymaga ustawień w ramach wdrożenia.
- Pokrycie po rozwoju: funkcja wymaga dedykowanego programowania, czyli kosztu i ryzyka.
- Brak: funkcji nie ma i nie jest planowana.
Obok pokrycia wymagań osobno oceniamy architekturę i integracje, model partnerstwa wdrożeniowego, całkowity koszt posiadania w perspektywie kilku lat oraz ryzyka. Wynik liczbowy nie podejmuje decyzji za zarząd, ale porządkuje dyskusję i sprawia, że różnice między systemami są widoczne, a nie ukryte pod marketingiem. O tym, jak liczyć sam koszt, piszemy w tekście o kosztach wdrożenia systemu.
Czego brakuje w typowym RFP
Przez lata zbiera się lista braków, które wracają niemal w każdym RFP pisanym bez doświadczenia. Zanim wyślesz dokument, sprawdź go po tej checkliście:
- Czy wymagania mają priorytety, czy to jedna płaska lista życzeń?
- Czy są scenariusze testowe, czy dostawca pokaże własny showcase?
- Czy uwzględniono integracje z obecnymi systemami i dokumentami?
- Czy jest sekcja migracji danych z dotychczasowych narzędzi?
- Czy pytasz o TCO w kilkuletnim horyzoncie, a nie tylko o cenę licencji?
- Czy jest instrukcja odpowiedzi i jednolity format, w którym dostawca ma odpowiedzieć?
- Czy ujęto zgodność z KSeF i inne wymogi regulacyjne istotne dla firmy?
Jeśli choć na jedno z tych pytań odpowiedź brzmi „nie", oferty wrócą nieporównywalne, a decyzja znowu oprze się na wrażeniu. Te same braki opisujemy przy okazji najczęstszych błędów przy wdrożeniu CRM, bo mechanizm jest identyczny.
Przykład: RFP firmy produkcyjnej
Pokażę to na ilustracyjnym profilu, żeby liczby były konkretne. Załóżmy producenta komponentów z tworzyw sztucznych, 230 osób, dwie lokalizacje, sprzedaż B2B w kilku krajach, dziś rozproszony między księgowość, arkusze magazynowe i osobny CRM. Po audycie AS-IS RFP dla takiej firmy wygląda zwykle tak:
- Objętość: około 67 stron, w tym 340 wymagań w podziale must-have i nice-to-have.
- Scenariusze testowe: przykładowo 12 przypadków, od przyjęcia materiału na magazyn, przez zlecenie produkcyjne, po wystawienie faktury i raport zarządczy.
- Integracje: e-commerce, EDI z klientami, dane z maszyn, KSeF.
- Macierz oceny: pokrycie wymagań, architektura, partner wdrożeniowy, TCO w 5 lat, ryzyka.
Tak przygotowany RFP trafia do shortlisty 3 do 4 dostawców, a każdy odpowiada w tej samej strukturze. Efekt jest taki, że na koniec zarząd porównuje cztery oferty wiersz po wierszu, a nie cztery prezentacje. To właśnie po to powstaje RFP. Liczby powyżej są poglądowe i zależą od skali oraz liczby integracji w Twojej firmie, więc policz je na własnym zakresie.
Piszesz RFP do systemu ERP?
Jeżeli przygotowujesz zapytanie ofertowe i chcesz mieć pewność, że oferty da się porównać, pomożemy ułożyć wymagania, scenariusze i macierz oceny. Pierwsza rozmowa jest bezpłatna i niezobowiązująca.
Umów rozmowę →Najczęstsze błędy
- RFP przed audytem: wymagania powstają z wyobrażeń, nie z realnych procesów.
- Brak priorytetów: dostawca nie wie, co jest warunkiem, a co dodatkiem.
- Brak scenariuszy: prezentacje zostają marketingowe i nieporównywalne.
- Pominięcie migracji i integracji: koszty wychodzą dopiero na wdrożeniu.
- Pytanie tylko o cenę licencji zamiast o całkowity koszt w kilka lat.
Jeżeli planujesz wybór systemu, zacznij od audytu i procesu opisanego w doradztwie ERP, a rankingu dostawców szukaj w zestawieniu najlepszych systemów ERP. Jeśli wolisz, żeby ktoś poprowadził to z Tobą, zobacz systemy dla firm produkcyjnych albo umów konsultację.
FAQ
Czym jest RFP do systemu ERP?
RFP (Request for Proposal) to ustrukturyzowane zapytanie ofertowe, które firma wysyła do wybranych dostawców ERP. Zawiera kontekst firmy, docelowe procesy, listę wymagań funkcjonalnych i technicznych, scenariusze testowe oraz ramy budżetowe i czasowe. Dzięki temu wszyscy dostawcy odpowiadają na te same pytania w tej samej strukturze, co pozwala porównać oferty bezpośrednio, a nie po wrażeniu z prezentacji.
Czym RFP różni się od RFI?
RFI (Request for Information) to wcześniejszy, lżejszy krok: zbieranie ogólnych informacji o dostawcach, żeby zawęzić rynek. RFP jest dokładniejsze i przychodzi później, gdy masz już shortlistę. Zawiera konkretne wymagania i scenariusze, na które dostawca odpowiada ofertą wiążącą. W praktyce RFI filtruje rynek, a RFP służy do finalnego porównania i wyboru.
Co musi zawierać RFP do ERP?
Minimalny kompletny RFP zawiera: kontekst i skalę firmy, opis docelowych procesów TO-BE, listę wymagań w podziale must-have i nice-to-have, wymagania techniczne (architektura, integracje, bezpieczeństwo, KSeF), oczekiwany model licencyjny, ramy budżetu i harmonogramu, scenariusze testowe oraz instrukcję, jak i w jakim formacie odpowiedzieć. Bez tej ostatniej części oferty będą nieporównywalne.
Jak punktować odpowiedzi dostawców na RFP?
Najlepiej przygotować macierz oceny jeszcze przed wysłaniem RFP. Każde wymaganie dostaje wagę, a odpowiedź dostawcy ocenę w jednej skali: pełne pokrycie standardem, pokrycie po konfiguracji, pokrycie po rozwoju, brak. Osobno ocenia się architekturę, integracje, model partnerstwa, TCO w 5 lat i ryzyka. Wynik liczbowy nie decyduje za zarząd, ale porządkuje dyskusję.
Ile stron powinien mieć RFP do ERP?
Dla firmy w skali 100 do 500 osób realny RFP to zwykle 40 do 80 stron, zależnie od liczby modułów i integracji. Krótszy zwykle pomija wymagania, które potem wracają jako kosztowne zmiany zakresu. Klucz to nie objętość, lecz to, czy każde wymaganie da się jednoznacznie ocenić w odpowiedzi.
Czy małej firmie też potrzebny jest RFP do ERP?
Im mniejsza firma i prostszy zakres, tym lżejszy może być RFP, ale sama dyscyplina się opłaca. Nawet w firmie kilkudziesięcioosobowej spisanie procesów, wymagań must-have i scenariuszy na kilku stronach sprawia, że dostawcy odpowiadają na realne potrzeby, a nie sprzedają standardowy pakiet.
Jakie są najczęstsze błędy w RFP do ERP?
Najczęstsze braki to: wymagania bez priorytetów, brak scenariuszy testowych, pominięcie integracji i migracji danych, brak pytania o TCO w kilkuletnim horyzoncie oraz brak instrukcji odpowiedzi. Efektem są oferty, których nie da się porównać, i decyzja podejmowana na wrażeniu zamiast na danych.
