Jak napisać RFP na TMS: nasze doświadczenia [+ 5 bezpłatnych szablonów]

Co tydzień odpowiadamy na RFP dotyczące oprogramowania do zarządzania transportem. Niektóre to czysta przyjemność. Inne są lekcją poglądową z kategorii „jak tego nie robić".

Ten artykuł to dokładnie to, co sam bym zbudował, gdybym dziś od zera prowadził proces wyboru TMS. Opiera się na RFP, na które odpowiadaliśmy, na wzorcach powtarzających się w różnych firmach i branżach, na tym, co większość z nich zawiera — i na błędach, które widzimy najczęściej.

Jeśli jesteś specjalistą ds. zakupów, większość z tego będzie Ci znana. Mam nadzieję, że przynajmniej część pozwoli Ci zaoszczędzić jedną zbędną rundę wyjaśnień.

Czym jest RFP na TMS?

RFP na TMS (Request for Proposal) to ustrukturyzowany dokument, który wysyłasz do dostawców oprogramowania do zarządzania transportem. Opisuje Twoją operację logistyczną i prosi każdego z nich o zaproponowanie, w jaki sposób ich system by ją obsłużył — na podstawie tego samego zestawu wymagań. Cały sens tkwi w porównywalności. Te same pytania, ten sam format, ten sam kontekst — żeby to, co wraca, można było zestawić obok siebie, zamiast czytać pięć oddzielnych prezentacji sprzedażowych.

Nie zawsze jest to konieczne. RFP ma sens wtedy, gdy decyzja jest skomplikowana albo gdy będziesz musiał ją uzasadnić innym osobom wewnątrz organizacji. Jeśli Twoja logistyka jest prosta, wystarczą demo produktu i rozmowa z kilkoma dostawcami.

Czy naprawdę potrzebujesz przeprowadzać przetarg na TMS?

Pomyłka w tej kwestii to najkosztowniejszy błąd w całym procesie wyboru TMS. Rozstrzygnij to zanim zrobisz cokolwiek innego.

Wszystko sprowadza się do złożoności Twojej logistyki — nie do wielkości firmy.

Przeprowadź ustrukturyzowany przetarg na TMS, jeśli wysyłasz towary z kilku lokalizacji, korzystasz z wielu gałęzi transportu i potrzebujesz integracji systemu z ERP. Właśnie wtedy musisz mieć wszystkich dostawców ustawionych obok siebie, żeby nic ważnego nie umknęło. Przewoźnicy są podłączani przez różnych dostawców w zupełnie różny sposób. Jeden nazywa to „natywnym", drugi po cichu kieruje wszystko przez kogoś innego. W luźnym procesie nie wychwycisz tego, dopóki nie podpiszesz umowy. A wtedy jest już za późno.

Pomiń formalne RFP, jeśli prowadzisz jedną lokalizację z garstką przewoźników i wiesz już, czego potrzebujesz. Dlaczego? Bo w chwili, gdy uruchamiasz RFP, automatycznie trafiasz do przedziału cenowego dla klientów enterprise. 2–3 dobre dema z konkretnymi pytaniami często dają lepszy system, taniej i szybciej. Powiedz tym 2–3 dostawcom, co wysyłasz i jaki problem chcesz rozwiązać, a następnie poproś, żeby pokazali Ci to w swoim działającym systemie. W ciągu godziny będziesz wiedział. A jeśli wysyłasz głównie paczki, a nie palety czy fracht, możliwe, że w ogóle nie potrzebujesz pełnego TMS — oprogramowanie do wysyłek wieloprzewoźnikowych to odrębna, lżejsza kategoria stworzona właśnie do tego.

Bądź więc ze sobą szczery w tej kwestii, zanim zaczniesz. Przeprowadzenie RFP, którego nie potrzebowałeś, to najwolniejszy i najdroższy sposób na zakup TMS.

Przeprowadzenie RFP, którego nie potrzebowałeś, to najwolniejszy i najdroższy sposób na zakup TMS.

Jeszcze jedno ostrzeżenie, jeśli decydujesz się na pełne RFP. Proces przeładowany językiem governance, ramami metodologicznymi i żądaniami stałej ceny zajmuje tygodnie, żeby na niego odpowiedzieć — a dostawcy, którzy mogą sobie pozwolić na taki nakład pracy, to zazwyczaj duże, ugruntowane firmy. Jeśli więc bardziej nowoczesna platforma faktycznie lepiej by Ci służyła, nadmiernie zbiurokratyzowany proces może po cichu ją wyeliminować, zanim w ogóle zobaczysz demo.

Celem jest znalezienie właściwego rozwiązania dla Ciebie. Zaprojektuj proces wokół tego celu — nie wokół zarządzania samym procesem.

Proces RFP na TMS w 9 krokach

Wybór TMS nie musi być skomplikowany. Wymaga jednak jasnej sekwencji. Pomiń kroki, a zapłacisz za to później — zazwyczaj podczas wdrożenia, gdy założenia, które powinny być wyjaśnione na początku, stają się kosztownymi niespodziankami.

Dobrze przeprowadzony proces zajmuje 8–12 tygodni. Mniej przy prostym zakresie, a rzadko kiedy potrzeba więcej.

Oto sekwencja, która działa:

1. Analiza rynku. Zanim napiszesz pierwsze wymaganie, poświęć czas na zrozumienie tego, co jest dostępne. Rynek TMS bardzo się zmienił w ciągu ostatnich pięciu lat: są dobre platformy enterprise, dobre platformy dla średniego rynku i naprawdę sprawne nowoczesne rozwiązania SaaS, które pięć lat temu jeszcze nie istniały. Zbuduj długą listę 5–8 dostawców TMS wartych rozważenia.
2. NDA. Wyślij je wcześnie. Będziesz udostępniać dane operacyjne — wolumeny, nazwy przewoźników, szczegóły wewnętrznych systemów — a podpisane NDA przed wysłaniem RFP to standardowa praktyka chroniąca obie strony.
3. RFI (opcjonalnie). Krótkie Request for Information ma sens, jeśli Twoja długa lista jest szeroka i chcesz ją zawęzić przed inwestowaniem w pełny proces RFP. Ogranicz je do jednej strony: tło firmy, kluczowe możliwości, orientacyjny przedział cenowy. Wystarczy, żeby skrócić listę bez zmuszania dostawców do pisania elaboratów.
4. RFP. Główny dokument. Daje każdemu dostawcy to, czego potrzebuje, żeby złożyć dokładną ofertę. Więcej na ten temat w następnym rozdziale.
5. Okno Q&A. Zawsze je uwzględniaj. Dostawcy będą mieli pytania, a odpowiedzi często poprawiają każdą otrzymaną ofertę. Prowadź je pisemnie i udostępniaj wszystkie pytania i odpowiedzi wszystkim dostawcom jednocześnie. To utrzymuje proces w porządku i zapewnia porównywalność.
6. Krótka lista i prezentacje. Oceń pisemne oferty, a następnie zaproś 2–3 dostawców do prezentacji. Prezentacja powinna obejmować demonstrację systemu na żywo opartą na Twoich rzeczywistych przypadkach użycia — nie ogólne demo. Jeśli dostawca nie potrafi pokazać Ci Twojego scenariusza w swoim systemie, to też jest cenna informacja.
7. Druga runda (jeśli potrzebna). W przypadku złożonej decyzji warto poświęcić czas na głębszą sesję skupioną na konkretnych lukach — bezpieczeństwie, integracji, warunkach handlowych. Nie planuj jej, jeśli nie masz już realnych pytań.
8. Decyzja i umowa. Uzgodnij stanowisko wewnętrznie, zanim zaczniesz negocjować. Znaj swoje wymagania bezwzględne, akceptowalne kompromisy i granice, których nie przekroczysz.
9. Wdrożenie. Proces nie kończy się na podpisaniu umowy. Najlepsze wyniki RFP mają plan wdrożenia uzgodniony przed podpisaniem kontraktu.

Harmonogram RFP na TMS, który możesz skopiować

Orientacyjny czas trwania według zakresu:

• Jedna prosta lokalizacja: 6–8 tygodni (pełne RFP może nie być potrzebne).
• Wiele lokalizacji + integracja z ERP: 8–12 tygodni.
• Wdrożenie globalne, wielopodmiotowe, z rozbudowaną integracją: 12–20 tygodni, zazwyczaj z dwiema rundami prezentacji.

Pobierz szablon harmonogramu RFP (.docx)

Co powinno zawierać RFP na TMS

Dokument RFP to Twoje najważniejsze narzędzie w całym procesie. Dobre RFP wykonuje za Ciebie większość pracy oceniającej — dlatego trzymaj je w ryzach. Zwięzłe RFP na 10 stronach bije 30-stronicowe, które próbuje objąć wszystko.

1. List przewodni i cel

Jedna strona. Kim jesteś, czego szukasz, dlaczego teraz. Trzymaj się faktów. Dostawcy nie potrzebują deklaracji wizji — potrzebują zrozumieć Twój problem operacyjny.

2. Harmonogram

Jasny harmonogram z konkretnymi datami: wysłanie RFP, termin Q&A, termin składania ofert, okno prezentacji, decyzja. Dostawcy planują swój wysiłek odpowiedzi na tej podstawie. Niejasne harmonogramy skutkują niejasymi ofertami.

3. Tło firmy i opis operacji

Tu większość RFP zawodzi — a to właśnie ta różnica decyduje o tym, czy oferty będą porównywalne, czy skończy się rundą wyjaśnień. Nie opisuj tylko swojej firmy — opisz swoją operację logistyczną. Ile lokalizacji. Ile podmiotów prawnych. Jakie gałęzie transportu (paczki, LTL, FTL, lotniczy, morski, kolejowy). Jakie regiony. Przybliżone wolumeny. Obecne systemy. To, co oznacza „dobre rozwiązanie", różni się też w zależności od branży — wymagania producentów elektroniki, maszyn, chemikaliów czy poligrafii i opakowań nie są takie same. To jest kontekst, którego dostawcy potrzebują, żeby dokładnie wycenić swoją ofertę. Jeśli nie podasz tu wystarczających szczegółów, spędzisz dwa tygodnie odpowiadając na pytania wyjaśniające, których można było całkowicie uniknąć. Ten temat ma swój własny rozdział poniżej.

4. Wymagania funkcjonalne

Tabela tego, co system musi robić, uszeregowana według ważności: wymaganie bezwzględne / powinno być / mile widziane (Excel w zupełności wystarczy). Poproś dostawców, żeby do każdego wymagania podali poziom pokrycia: a) natywne, b) zewnętrzne (third-party), c) przez customizację lub d) nieobsługiwane. To właśnie sprawia, że oferty są porównywalne. Więcej o tym, jak zbudować tę listę, znajdziesz niżej.

5. Kryteria oceny

Powiedz dostawcom, jak podejmiesz decyzję: funkcjonalność, cena, podejście do wdrożenia, referencje, bezpieczeństwo, zespół. Jeśli jesteś gotowy, podaj wagi poszczególnych kryteriów. Im bardziej jesteś transparentny, tym lepsze oferty otrzymasz.

6. Model cenowy

Poproś o pełne zestawienie: subskrypcja, wdrożenie, opłaty transakcyjne, wsparcie i wszystko inne. Jeśli to możliwe, poproś o przykładową fakturę. Struktury cenowe bardzo się różnią między dostawcami, a ukryte koszty mają zwyczaj pojawiać się późno. Staraj się je wykryć wcześnie.

7. Format odpowiedzi

Powiedz dostawcom dokładnie, jak ma być zbudowana oferta, a jeśli udostępniasz szablony — wymagaj ich użycia. Porównywalne oferty oszczędzają Ci dni podczas oceny, a format jest całkowicie w Twoich rękach.

Pobierz szablon dokumentu RFP, żeby zacząć od pełnej struktury opisanej powyżej:

Pobierz szablon dokumentu RFP (.docx)

Informacje operacyjne, których brakuje w większości RFP na TMS — i dlaczego są najważniejsze

To rozdział, który chciałbym, żeby każdy autor RFP na TMS przeczytał jako pierwszy.

Odpowiadamy na wiele przetargów na TMS. Niemal każda oferta, którą piszemy, wymaga rundy wyjaśnień — i rzadko kiedy wynika to z niejasnych wymagań. Powodem jest brak kontekstu operacyjnego: wolumenów, struktury lokalizacji, sieci przewoźników, obecnych systemów.

RFP wymagające pełnej rundy wyjaśnień mają niemal zawsze jedną wspólną cechę:

Widzieliśmy firmy, które spędzały tygodnie na opracowywaniu kryteriów oceny i list wymagań, a potem wysyłały RFP, w którym nie było ani słowa o tym, ile przesyłek przetwarzają miesięcznie.

Bez tej informacji dostawcy zgadują. A gdy zgadują, oferty wracają ogólnikowe, wyceny nie są ostateczne i nie ma niczego konkretnego do porównania.

Na przykład globalny producent z 10 magazynami i systemem SAP potrzebuje zupełnie innej oferty niż dystrybutor z jedną lokalizacją prowadzący logistykę na arkuszach kalkulacyjnych. Jeśli dostawca nie może stwierdzić, którym z nich jesteś, zabezpiecza się — i dostajesz oferty, które do niczego się nie zobowiązują.

Rozwiązanie tego problemu zajmuje jedno popołudnie. Odpowiedz na te dziesięć pytań w RFP, zanim je wyślesz.

1. Organizacja i zakres. Ile podmiotów prawnych i lokalizacji jest objętych zakresem? Czy wdrożenie jest równoległe, czy etapowe? Jak samodzielnie działają poszczególne lokalizacje — osobne umowy z przewoźnikami, osobne zespoły?
2. Wolumeny przesyłek. Miesięczna i dzienna liczba przesyłek na lokalizację, średnia i szczytowa. Sezonowość. Podział na przesyłki przychodzące i wychodzące.
3. Podział według gałęzi transportu. Jaki udział stanowią paczki, LTL, FTL, transport lotniczy, morski? Które gałęzie rosną? Które są najbardziej krytyczne operacyjnie?
4. Sieć przewoźników. Ilu przewoźników na lokalizację i na gałąź transportu? Wspólni dla wszystkich lokalizacji czy zarządzani lokalnie? Czy są strategiczni przewoźnicy, którym trzeba nadać priorytet, albo przewoźnicy wskazani przez klientów, których nie możesz zmienić?
5. Geografia i trasy handlowe. Jakie regiony są objęte zakresem? Które trasy są najważniejsze: krajowe, transgraniczne, międzykontynentalne? Kluczowe porty lub węzły logistyczne?
6. Stan obecny. Jak dziś planowane, zlecane i śledzone są przesyłki? W ERP, arkuszach kalkulacyjnych, portalach przewoźników, przez e-mail? Jakie są główne bolączki obecnego procesu?
7. Struktura finansowa. Kto płaci za transport — jeden podmiot czy kilka? Czy są numery kont stron trzecich lub klientów? Jak dziś rejestrowane i weryfikowane są koszty frachtu?
8. Model biznesowy. B2B, B2C? Jeśli mieszany — jaki jest podział. Wymagania operacyjne i systemowe różnią się dość znacząco.
9. Krajobraz integracji. Jakie systemy muszą się połączyć z TMS: ERP, WMS, CRM? Czy są istniejące integracje z przewoźnikami do utrzymania? Jak wysoki poziom automatyzacji jest potrzebny od pierwszego dnia?
10. Harmonogram i ograniczenia. Czy jest docelowa data uruchomienia? Czy są wewnętrzne kamienie milowe — koniec roku finansowego, szczyt sezonu, migracje systemów — które wpływają na harmonogram?

Żadna z tych rzeczy nie jest trudna do zapisania. Ale zmienia wszystko w tym, co wraca.

Pobierz listę kontrolną informacji operacyjnych, która zamienia te dziesięć pytań w tabelę do wypełnienia, gotową do wklejenia do RFP:

Pobierz listę kontrolną informacji operacyjnych (.docx)

Jak pisać wymagania funkcjonalne dla TMS

Wymagania funkcjonalne to serce RFP. Napisz je dobrze, a uzyskasz klarowny, porównywalny obraz tego, co każdy dostawca potrafi, a czego nie. Napisz je źle, a możesz spędzić tygodnie na dekodowaniu odpowiedzi, które wszystkie brzmią „tak".

Celem nie jest najdłuższa lista. Lecz najbardziej uczciwa.

Priorytetyzuj bezlitośnie: wymaganie bezwzględne, powinno być, mile widziane

Nie wszystko, czego chcesz, jest równie ważne. Używaj trzech kategorii i trzymaj się ich:

1. Wymaganie bezwzględne (M): niepodlegające negocjacji. Dostawca, który go nie spełnia, odpada — niezależnie od wszystkiego innego.
2. Powinno być (S): ważne, ale możesz żyć z obejściem lub obietnicą w bliskiej perspektywie roadmapy.
3. Mile widziane (N): dobrze wiedzieć, ale stoi za wszystkim powyżej.

Większość list ma zdecydowanie za dużo wymagań bezwzględnych. Jeśli wszystko jest krytyczne, nic nie jest. Bądź szczery wobec siebie w kwestii tego, co naprawdę uniemożliwiłoby działanie systemu — i tylko to oznaczaj jako wymaganie bezwzględne.

Poproś dostawców o klasyfikację pokrycia funkcjonalności: natywne / zewnętrzne / przez customizację

Dla każdego wymagania niech odpowiedzą jedną z tych opcji:

Ta kolumna decyduje o tym, czy oferta zyskuje, czy traci Twoje zaufanie. Dostawca, który odpowiada uczciwie i wpisuje nieobsługiwane tam, gdzie to prawda, pokazuje Ci, jak będzie się zachowywał jako partner. Dostawca, który na wszystko odpowiada natywne, też Ci coś mówi — i to ważnego.

Formułuj pytania konkretnie

„Czy system obsługuje wyceny przewoźników?" da Ci bezużyteczne „tak". „Czy system potrafi wyliczyć cenę frachtu dla każdego przewoźnika — w tym tych bez API cenowego — i pokazać je obok siebie dla każdej przesyłki?" daje Ci coś, co możesz realnie ocenić.

Gdzie kończy się ERP, a zaczyna TMS?

Jednym z najczęstszych źródeł nieporozumień przy wyborze oprogramowania do zarządzania transportem jest kwestia tego, gdzie kończy się TMS, a zaczyna ERP.

Procesy finansowe, takie jak kodowanie GL, landed cost czy audyt frachtu, są często obsługiwane po stronie ERP, a TMS dostarcza do niego dane. To normalne i często właściwe rozwiązanie. Ale musi być jasno określone. Gdy dostawca odpowiada „obsługiwane przez integrację z ERP" na jedno z Twoich wymagań bezwzględnych, dopytaj dokładnie, co to oznacza dla Twojego wdrożenia — i kto to buduje.

Opisuj cel, nie rozwiązanie techniczne

Opisuj to, co chcesz osiągnąć, a nie to, jak system ma to technicznie zrealizować. Nadmiernie szczegółowe wymagania techniczne eliminują dobre rozwiązania z błahych powodów. Zostaw dostawcom przestrzeń, żeby pokazali Ci lepszy sposób niż ten, który miałeś na myśli — bo czasem go mają.

Lista 30 rzetelnych, priorytetyzowanych wymagań powie Ci więcej niż arkusz z 150 pozycjami, gdzie wszystko jest krytyczne i każdy dostawca zaznaczył każde pole.

Startowy zestaw wymagań TMS do adaptacji

Większość kupujących po raz pierwszy chce mieć punkt wyjścia do listy wymagań — oto przykładowy zestaw z naszego doświadczenia, już skategoryzowany, który możesz dostosować do swojej operacji. Pełna lista jest do pobrania w arkuszu oceny poniżej; poniżej tyle, żeby zobaczyć jej kształt.

Pobierz arkusz oceny wymagań funkcjonalnych — już zbudowany z priorytetami i kolumną pokrycia dla każdego dostawcy:

Pobierz arkusz oceny wymagań funkcjonalnych (.docx)

Jak porównywać koszty TMS i zbudować model na trzy lata

„Ile kosztuje TMS?" to pytanie, na które kupujący najbardziej chcą odpowiedzi, a dostawcy najchętniej jej unikają. Tyle że opłata subskrypcyjna rzadko kiedy jest Twoim ostatecznym kosztem. W przypadku średniej wielkości załadowcy z wieloma lokalizacjami wdrożenie i integracja mogą nawet bardziej wpłynąć na łączny koszt trzyletni niż miesięczna opłata — i właśnie ta pozycja jest przez dostawców najbardziej rozmyta. Dlatego kluczem jest takie sformułowanie pytania, żeby odpowiedzi były porównywalne, a rzeczywisty koszt był widoczny.

Orientacyjnie: chmurowe TMS dla średniego rynku kosztuje zazwyczaj od kilkuset do kilku tysięcy euro miesięcznie, podczas gdy tradycyjne systemy enterprise — od dziesiątek tysięcy do ponad miliona rocznie, z wdrożeniem sięgającym sześciu lub siedmiu cyfr. To szeroki przedział — i właśnie dlatego model porównujący te same składniki jest ważniejszy niż jakakolwiek pojedyncza liczba. Żeby zorientować się, ile naprawdę pobierają dostawcy TMS, zajrzyj do naszego przeglądu czołowych dostawców TMS.

Składniki cenowe TMS

Niemal każda wycena TMS to jakiś miks poniższych elementów:

Zbuduj model kosztów na trzy lata, zanim zaczniesz porównywać

Dostawca TMS, który wygląda tanio na subskrypcji, może okazać się najdroższy, gdy doliczy się wdrożenie, opłaty za transakcje i onboarding przewoźników. Przepuść każdego dostawcę przez ten sam model:

Koszt 3-letni = wdrożenie + (roczna subskrypcja × 3) + (opłata za przesyłkę × roczny wolumen × 3) + wsparcie + przewidywane dodatki za integracje z przewoźnikami.

Używaj swoich rzeczywistych wolumenów, nie schludnych przykładów dostawcy. Ta jedna tabela potrafi przetasować krótką listę.

Zwracaj uwagę na różne składniki cenowe, nie tylko na opłatę podstawową

Niektórzy dostawcy oferują niską subskrypcję i odrabiają to na opłatach transakcyjnych lub za poszczególnych przewoźników. To niekoniecznie zły model, ale zmienia to, kto jest najtańszy w miarę Twojego wzrostu. Jeśli Twój wolumen rośnie, model per przesyłka może szybko wyprzedzić stawkę ryczałtową. Poproś o przykładową fakturę i warunki subskrypcji, żeby porównywać to, co naprawdę zapłacisz — nie cenę nagłówkową.

Jedno pytanie warte zadania każdemu dostawcy: czy nowe integracje z przewoźnikami są wliczone w cenę, czy rozliczane osobno? Niektóre platformy TMS pobierają 5 000–10 000 € za nową integrację z przewoźnikiem i realizują ją przez miesiące, inne budują nowe integracje bez dodatkowych kosztów. Dla średniej wielkości załadowcy dodającego przewoźników przez lata ta jedna odpowiedź może zmienić łączny koszt trzyletni bardziej niż cała linia subskrypcji.

Jak oceniać oferty na TMS — nie tylko przez pryzmat ceny

Oferty są już w Twoich rękach. Wszystkie wyglądają rozsądnie, większość mówi „tak" na Twoje wymagania, a ceny są w podobnym przedziale. Co teraz?

W tym momencie zespoły po cichu wracają do ceny, bo wszystko inne wydaje się trudniejsze do porównania. Nie rób tego. Oto co naprawdę je różnicuje.

1. Łączność z przewoźnikami.

W TMS łączność z przewoźnikami to fundament. Jak dostawca faktycznie łączy się z przewoźnikami — przez bezpośrednie integracje API/EDI, agregatory zewnętrzne, czy w ogóle nie (zlecenia e-mailem i PDF niezależnie od możliwości IT przewoźnika)? Co się dzieje, gdy potrzebujesz przewoźnika, którego jeszcze nie obsługują — jak długo to trwa i ile kosztuje?

Dostawca z głębokimi, bezpośrednimi integracjami z przewoźnikami to zupełnie inna kategoria niż ten, który kieruje wszystko przez warstwę pośrednią. Różnicę czuć w niezawodności zleceń, jakości śledzenia i w tym, czy możesz dodać przewoźnika bez każdorazowego otwierania nowych negocjacji handlowych.

2. Harmonizacja poziomu usług przewoźników — to ma większe znaczenie, niż większość ludzi zdaje sobie sprawę.

Przewoźnicy bardzo różnią się pod względem możliwości cyfrowych. Jedni mają zaawansowane API obejmujące wyceny w czasie rzeczywistym, przewidywanie ETA, walidację adresów, generowanie etykiet i szczegółowe zdarzenia śledzenia. Inni wysyłają potwierdzenie zlecenia e-mailem i na tym koniec. W większości sieci przewoźników oba typy współistnieją jednocześnie.

To staje się Twoim problemem w chwili, gdy podłączasz ERP lub WMS do TMS. Jeśli Twoja integracja oczekuje pełnego zestawu danych od każdego przewoźnika — potwierdzenia zlecenia, linku do śledzenia, etykiety, szacunku kosztów — a część przewoźników nie jest w stanie ich dostarczyć, pojawiają się wyjątki, ręczne obejścia i luki w danych. Jeden słaby przewoźnik psuje spójność całego przepływu pracy.

Różni dostawcy oprogramowania do zarządzania transportem radzą sobie z tym na dwa sposoby — warto zdecydować, który wolisz, zanim przeczytasz choćby jedną ofertę:

• Cieńszy TMS przekazuje to, co każdy przewoźnik dostarcza — a luki w ERP lub w pracy ręcznej będą Twoim problemem. Prostsza integracja, więcej wyjątków do obsługi po Twojej stronie.
• TMS, który normalizuje dane i sam wypełnia luki: oblicza koszt frachtu z przesłanego przez Ciebie cennika, gdy nie ma API cenowego; szacuje czas dostawy, gdy przewoźnik nie podaje ETA; generuje etykiety, gdy przewoźnik nie potrafi ich wyprodukować; gdy nie ma śledzenia, pozwala przewoźnikom ręcznie wprowadzać statusy przesyłki — i wiele więcej. Oprogramowanie wypełnia luki w możliwościach technicznych Twoich przewoźników, a Twój ERP widzi jedną spójną strukturę.

Oceniając oferty, zapytaj dostawców wprost: jak radzą sobie z przewoźnikami o ograniczonych możliwościach cyfrowych? Odpowiedź wiele mówi o tym, jak dojrzała jest ich platforma.

3. Uczciwość w kwestii integracji.

Zwróć szczególną uwagę na to, jak dostawcy opisują zakres integracji (kto co robi). Oferta, która wprost mówi „prace po stronie ERP leżą po Twojej stronie, oto co my dostarczamy i jak Cię wspieramy", jest bardziej wiarygodna niż ta, która sugeruje „bezproblemową integrację" bez wyjaśnienia, która strona odpowiada za którą część. Niespodzianki integracyjne to jeden z najczęstszych powodów, dla których projekty TMS przekraczają czas i budżet.

4. Podejście do wdrożenia.

Podejście etapowe — najpierw ręczna walidacja operacyjna, potem automatyzacja — jest zazwyczaj mniej ryzykowne niż uruchomienie wszystkiego naraz. Masz szansę potwierdzić, że system działa dla Twoich rzeczywistych przepływów pracy, zanim oprze się na nim cała operacja. Z naszego doświadczenia: dostawcy, którzy proponują to podejście bez pytania, zazwyczaj mieli już za sobą trudne uruchomienie. Ci, którzy od razu sprzedają pełną automatyzację od pierwszego dnia, często nie.

5. Referencje

Proś o referencje od firm o podobnym profilu operacyjnym — nie tylko o podobnej wielkości czy liczbie pracowników. Referencja od dystrybutora z jedną lokalizacją nie jest szczególnie przydatna, jeśli prowadzisz wielolokalizacyjną operację produkcyjną z integracją SAP. I zadawaj konkretne pytania: „Jak przebiegał onboarding przewoźników?" „Jak wyglądał proces integracji?" „Co się stało, gdy coś nie zadziałało zgodnie z oczekiwaniami?"

6. Sama oferta.

To, jak dostawca TMS odpowiada na Twoje RFP, jest zapowiedzią tego, jak będzie się zachowywał jako Twój partner. Czy odpowiedział na Twoje pytania wprost, czy owinął wszystko w bawełnę? Czy uczciwie wskazał luki, czy twierdził, że w pełni pokrywa każde wymaganie? Czy pokazał, że rozumie Twoją operację, czy przysłał lekko zmodyfikowaną wersję swojej standardowej prezentacji?

Oferta, która w dwóch miejscach przyznaje nieobsługiwane i wyjaśnia dlaczego, jest warta więcej niż ta, która mówi „tak" na wszystko. Prawdę i tak poznasz — lepiej podczas oceny niż przy uruchomieniu.

Pobierz macierz oceny dostawców do punktowania według ważonych kryteriów:

Pobierz macierz oceny dostawców (.docx)

Runda prezentacji dostawców TMS

Pisemne oferty mówią Ci, co dostawca twierdzi. Prezentacje pokazują, czy potrafi to udowodnić.

Na tym etapie powinieneś mieć krótką listę 2–3 dostawców. Celem rundy prezentacji jest poddanie oferty realnej próbie i sprawdzenie, czy system działa w Twoich rzeczywistych scenariuszach.

Proś o demonstrację na żywo, nie o demo

Demo to wyreżyserowana sekwencja pokazująca system od najlepszej strony. Demonstracja na żywo to sytuacja, gdy mówisz: „Pokaż mi, jak obsłużyłbyś tę przesyłkę — z naszego magazynu w Holandii, z naszym przewoźnikiem, po naszej uzgodnionej stawce" — i obserwujesz, co naprawdę się dzieje.

Przed spotkaniem przygotuj 2–3 rzeczywiste scenariusze ze swojej operacji: standardowe zlecenie wychodzące, przesyłkę wymagającą wyceny spot i coś trudniejszego — jak opóźniona przesyłka albo przewoźnik, który nie zapewnia śledzenia. Gdy dostawca ciągle wraca do dopracowanego demo zamiast realizować Twój scenariusz — masz już odpowiedź.

Kwestionuj luki

Każda oferta na TMS je ma. Idź prosto w miejsca, gdzie dostawca odpowiedział częściowo lub gdzie masz wątpliwości — i zostań przy nich. Nie pozwól mu wrócić do czegoś, co działa pięknie. Jak dokładnie to działa? Kto co robi? Co się dzieje, gdy coś nie zadziała zgodnie z oczekiwaniami?

Zaproś właściwe osoby

Po stronie dostawcy TMS prezentować powinni ci, którzy faktycznie będą pracować przy Twoim wdrożeniu — nie tylko zespół sprzedaży. Poproś o to wprost. Po Twojej stronie zaproś kogoś z IT (jeśli integracja jest w zakresie) oraz przynajmniej jedną osobę, która będzie korzystać z systemu na co dzień. Ona zadaje inne pytania niż dział zakupów — i chcesz, żeby padły oba zestawy pytań.

Druga runda — tylko jeśli naprawdę potrzebna

W przypadku złożonej decyzji dodatkowa sesja skupiona na konkretnych tematach jest warta czasu. Przykładowe tematy do omówienia:

• Bezpieczeństwo i ochrona danych — poproś o raport z testów penetracyjnych lub dokumentację bezpieczeństwa, jeśli wymaga tego Twój dział IT lub bezpieczeństwa informacji
• Architektura integracji — sesja techniczna między Twoim zespołem IT a zespołem dostawcy
• Warunki handlowe — przejdź przez kontrakt, SOW i założenia punkt po punkcie, zanim wejdziesz w formalne negocjacje

Nie planuj jej tylko po to, żeby powtórzyć pierwsze spotkanie z większą liczbą osób w sali. Albo rozwiązuje konkretne otwarte pytania, albo nie powinna się odbyć.

Potwierdzaj zobowiązania na piśmie

Wszystko, do czego dostawca zobowiązuje się podczas spotkania, a czego nie ma w pisemnej ofercie, musi zostać potwierdzone na piśmie przed przejściem dalej. Ustne zobowiązania nie przeżywają negocjacji kontraktowych. Jeśli dostawca TMS mówi „tak, możemy to zrobić" w ważnej kwestii, wyślij e-mail tego samego dnia i poproś o potwierdzenie.

Kontrakt i SOW (Statement of Work) dla TMS: co sprawdzić przed podpisaniem

Wybrałeś dostawcę. Większość zespołów w tym momencie odetchnie z ulgą. Odradzam — bo właśnie tutaj szczegóły, które wszyscy przemilczeli podczas oceny, po cichu stają się Twoim problemem.

Uzgodnij stanowisko wewnętrznie, zanim zaczniesz negocjować

Zanim rozmowa się zacznie, znaj swoje wymagania bezwzględne, akceptowalne kompromisy i granice, których nie przekroczysz. Zmiana wymagań w trakcie negocjacji kosztuje czas, niszczy zaufanie i czasem sprawia, że tracisz dostawcę TMS, którego naprawdę chciałeś. Najpierw ustal to wewnętrznie, a dopiero potem negocjuj.

Rozumiej, co kupujesz: SaaS, nie licencję

Nowoczesne platformy TMS to subskrypcje SaaS, a nie licencje na oprogramowanie. Subskrybujesz usługę, którą dostawca hostuje, utrzymuje i aktualizuje — nie kupujesz systemu na własność. To zmienia to, co musi obejmować kontrakt: warunki subskrypcji, rozwiązanie umowy, własność danych i prawa do ich eksportu, zobowiązania dotyczące dostępności, czasy reakcji wsparcia. Standardowe szablony zakupowe nie były pisane z myślą o tym modelu — upewnij się, że Twój nadąża za rzeczywistością.

SOW jest tak samo ważny jak kontrakt

Statement of Work określa, co zostanie dostarczone, przez kogo i kiedy: konfiguracja konta, onboarding przewoźników, wsparcie integracji, szkolenia i kryteria akceptacji potwierdzające, że wdrożenie jest faktycznie zakończone. Jeśli czegoś nie ma w SOW, nie jest wliczone w cenę — niezależnie od tego, co padło na spotkaniu lub w e-mailu. Czytaj sekcję założeń ze szczególną uwagą. Tam zakres jest warunkowo zdefiniowany. Jeśli Twoja lista przewoźników okaże się dłuższa niż podana, albo Twój ERP wymaga niestandardowego formatu integracji, to właśnie sekcja założeń decyduje, czy to szybka rozmowa, czy wycenione zlecenie zmiany.

Jasno określ, co jest poza zakresem

Niestandardowe prace deweloperskie, szkolenia na miejscu, migracja danych, prace integracyjne po Twojej stronie, zmiany po stronie przewoźników — to zazwyczaj osobno wyceniane pozycje. Zapisanie tego na papierze przed podpisaniem eliminuje najczęstsze i najbardziej unikalne źródło tarć przy wdrożeniu: dwie strony, które każda inaczej rozumiały, co jest wliczone.

Uzgodnij plan wdrożenia przed podpisaniem

Nie po. Priorytety przewoźników, harmonogram konfiguracji, kamienie milowe integracji, kryteria uruchomienia — ustal to wszystko, gdy masz jeszcze siłę negocjacyjną. Dostawca, który nie potrafi przedstawić Ci jasnego planu wdrożenia na etapie kontraktu, mówi Ci coś, co warto wiedzieć przed podjęciem zobowiązania.

Po podpisaniu: wdrożenie i onboarding TMS

Większość realnego ryzyka pojawia się po podpisaniu umowy. Trzy rzeczy decydują o tym, jak to pójdzie.

1. Migracja danych

Umowy z przewoźnikami, cenniki, książki adresowe, historia przesyłek. Zdecyduj wcześnie, co musisz przenieść, co najpierw wymaga oczyszczenia i kto odpowiada za tę pracę. Brudne dane źródłowe to najczęstszy powód, dla którego data uruchomienia przesuwa się coraz dalej. Oczyść je przed migracją — nie w jej trakcie.

2. Kolejność onboardingu przewoźników

Nie podłączasz wszystkich przewoźników pierwszego dnia. Priorytetyzuj według wolumenu i krytyczności — uruchom i zwaliduj kilku najważniejszych, a potem rozszerzaj. To dokładnie ten moment, w którym etapowe podejście, o które pytałeś podczas oceny, przynosi efekty.

3. Adopcja przez użytkowników

Osoby zlecające przesyłki każdego dnia muszą chcieć korzystać z nowego systemu. Włącz przynajmniej jedną z nich w proces od etapu RFP, przeszkol ją porządnie podczas hypercare (onboardingu) i upewnij się, że codzienny przepływ pracy jest naprawdę szybszy niż to, co robili wcześniej. Technicznie bezbłędne wdrożenie, z którego zespół po prostu nie korzysta, to nadal nieudane wdrożenie.

10 najczęstszych błędów w RFP na TMS

Wzorce, które widzimy najczęściej — wszystkie w jednym miejscu:

• Brak kontekstu operacyjnego. Największy błąd. Dostawcy nie otrzymują informacji o wolumenach, strukturze lokalizacji ani sieci przewoźników. Runda wyjaśnień i ogólnikowe wyceny są wtedy gwarantowane.
• Wszystko jest wymaganiem bezwzględnym. Gdy każde wymaganie jest krytyczne, kolumna priorytetów jest bezużyteczna i nie możesz odróżnić blokerów od rzeczy miłych do posiadania.
• Niejasny harmonogram. Brak dat oznacza, że dostawcy nie mogą oszacować swojego nakładu pracy — i oferty wracają równie niejasne.
• Nadmierne specyfikowanie rozwiązania technicznego. Opisywanie implementacji technicznej zamiast wyniku operacyjnego eliminuje dobre rozwiązania z błahych powodów.
• Ignorowanie granicy ERP/TMS. Zakładanie, że TMS obsługuje procesy finansowe, które faktycznie należą do ERP — i odkrycie tego w połowie wdrożenia.
• Decyzja wyłącznie na podstawie ceny. Wybór na podstawie nagłówkowej stawki subskrypcji bez modelu trzyletnego i bez uwzględnienia łączności z przewoźnikami oraz uczciwości integracyjnej.
• Demo zamiast demonstracji na żywo. Oglądanie dopracowanej sekwencji dostawcy zamiast zmuszenia systemu do przetestowania Twoich rzeczywistych scenariuszy.
• Referencje niedopasowane do Twojej operacji. Patrzenie na imponujące logo firm, których logistyka może wyglądać zupełnie inaczej niż Twoja. Proś o referencje podobne do Ciebie, a potem pytaj, jak naprawdę przebiegły onboarding i integracja.
• Odkładanie wdrożenia na po podpisaniu. Plan, który negocjujesz z siłą przetargową, bije ten, który negocjujesz bez niej.
• Proces zbyt ciężki dla właściwego dostawcy. Biurokratyczny nakład, który może wyeliminować nowoczesne platformy, które najlepiej by Ci służyły.

Bezpłatne szablony RFP na TMS

Zbudowaliśmy pięć szablonów na podstawie RFP, na które odpowiadamy — żebyś nie musiał zaczynać od pustej strony:

1. Szablon dokumentu RFP. Pełna struktura z tego przewodnika.
2. Arkusz oceny wymagań funkcjonalnych. Z priorytetami i kolumną pokrycia dla każdego dostawcy.
3. Lista kontrolna informacji operacyjnych. Dziesięć pytań w formie tabeli do wypełnienia.
4. Macierz oceny dostawców. Ważone punktowanie dla wielu dostawców.
5. Szablon harmonogramu RFP. Działania, daty, właściciele.

Pobierz cały pakiet — wszystkie pięć, bezpłatnie, bez podawania adresu e-mail. Weź to, co przydatne, resztę zignoruj:

Pobierz pełny pakiet szablonów RFP na TMS (.zip)

Cargoson to oprogramowanie do zarządzania transportem używane przez średniej wielkości producentów i dystrybutorów w Europie i Ameryce Północnej. Odpowiadamy na RFP takie jak to, które zaraz napiszesz — więc jeśli wolisz najpierw omówić swoje wymagania, zanim zaczniesz pisać, chętnie pomożemy Ci to przemyśleć, bez żadnych zobowiązań.

Umów bezpłatną 30-minutową konsultację

Przeprowadź ten proces dobrze, a każda poświęcona godzina się opłaci.