Jak napsat RFP pro TMS: naše zkušenosti [+ 5 šablon zdarma]

Na RFP (Request for Proposal) pro software pro správu přepravy odpovídáme každý týden. Některá jsou radost zpracovat. Jiná jsou spíše lekcí v tom, jak to nedělat.

Tento článek je tím, co bych sestavil, kdybych dnes od nuly řídil výběr TMS. Vychází z RFP, na která jsme odpovídali, ze vzorců, které se opakují napříč firmami a odvětvími, z toho, co většina z nich obsahuje, a z chyb, které v nich pravidelně vídáme.

Pokud jste specialista na nákup, většina z toho vám bude povědomá. Snad vám to ušetří alespoň jedno zbytečné kolo upřesňujících dotazů.

Co je RFP pro TMS?

RFP pro TMS (Request for Proposal) je strukturovaný dokument, který zasíláte dodavatelům softwaru pro správu přepravy. Popisuje vaši logistickou operaci a každého dodavatele žádá, aby navrhl, jak by jejich systém danou situaci řešil – a to na základě stejné sady požadavků. Celý smysl spočívá ve srovnatelnosti. Stejné otázky, stejný formát, stejný kontext – aby to, co se vrátí, šlo postavit vedle sebe, místo abyste četli pět samostatných obchodních prezentací.

Ne vždy ho potřebujete. RFP se vyplatí tehdy, když je rozhodnutí složité nebo když ho budete muset interně obhájit. Pokud jsou vaše logistické operace jednoduché, postačí ukázka produktu a hovor s několika dodavateli.

Potřebujete skutečně vypsat přepravní výběrové řízení formou RFP?

Chybné rozhodnutí v tomto bodě je nejdražší chybou celého výběru TMS. Vyřešte to dřív, než cokoliv jiného.

Záleží na tom, jak složitá je vaše logistika – ne na tom, jak velká je vaše firma.

Strukturované výběrové řízení formou RFP spusťte tehdy, když expedujete z více poboček, využíváte více přepravních módů a potřebujete systém propojit s ERP. V takovém případě potřebujete mít všechny dodavatele seřazeny vedle sebe, aby vám nic důležitého neuniklo. Dodavatelé se připojují k dopravcům velmi různými způsoby. Jeden to označí jako „nativní", druhý to potichu přesměruje přes někoho dalšího. V neformálním procesu to nezjistíte, dokud nepodepíšete smlouvu. A to je pozdě.

Formální RFP vynechte tehdy, když provozujete jednu pobočku s hrstkou dopravců a víte, co potřebujete. Proč? Protože jakmile spustíte RFP, automaticky se zařadíte do cenové kategorie pro velké podniky. 2–3 dobré demoverzí s cílenými otázkami vám často přinesou lepší systém, levněji a rychleji. Řekněte těm 2–3 dodavatelům, co přepravujete a co chcete vyřešit, a požádejte je, ať vám to ukážou v živém systému. Do hodiny budete vědět. A pokud přepravujete převážně zásilky spíše než palety nebo nákladní zásilky, možná nepotřebujete plnohodnotný TMS vůbec – software pro přepravu více dopravci je jiná, odlehčená kategorie přímo pro tento účel.

Buďte tedy k sobě upřímní a rozhodněte se dřív, než začnete. Spustit RFP, které jste nepotřebovali, je nejpomalejší a nejdražší způsob, jak TMS pořídit.

Spustit RFP, které jste nepotřebovali, je nejpomalejší a nejdražší způsob, jak TMS pořídit.

Ještě jedno varování, pokud se pro plné RFP rozhodnete. Proces přeplněný řídicí terminologií, metodickými rámci a požadavky na pevnou cenu zabere dodavatelům týdny zpracování – a ti, kdo si takovou administrativní zátěž mohou dovolit, bývají velcí, zavedení hráči. Pokud by vám ve skutečnosti lépe posloužila štíhlejší a modernější platforma, příliš byrokratický proces ji může tiše vyřadit ještě předtím, než ji vůbec uvidíte v akci.

Cílem je najít správné řešení pro vás. Navrhněte proces tak, aby tomuto cíli sloužil – ne aby sloužil sám sobě.

Výběrové řízení na TMS v 9 krocích

Výběr TMS nemusí být složitý. Potřebuje ale jasnou posloupnost. Přeskočte kroky a zaplatíte za to později – zpravidla při implementaci, kdy předpoklady, které měly být vyjasněny včas, přerostou v nákladná překvapení.

Při dobré organizaci celý proces trvá 8 až 12 týdnů. U jednoduchého rozsahu méně, a zřídkakdy je třeba více.

Tato posloupnost funguje:

1. Průzkum trhu. Než napíšete jediný požadavek, věnujte čas tomu, abyste pochopili, co je k dispozici. Trh TMS se za posledních pět let výrazně posunul: existují dobré podnikové platformy, dobré platformy pro střední trh a skutečně schopná moderní SaaS řešení pro správu přepravy, která před pěti lety neexistovala. Sestavte dlouhý seznam 5–8 dodavatelů TMS, které stojí za oslovení.
2. NDA. Pošlete ji brzy. Budete sdílet provozní data – objemy, názvy dopravců, interní systémy – a podepsaná NDA před odesláním RFP je standardní praxe, která chrání obě strany.
3. RFI (volitelné). Krátký Request for Information má smysl tehdy, když je váš dlouhý seznam rozsáhlý a chcete ho zúžit ještě před investicí do plného RFP procesu. Omezte ho na jednu stránku: představení firmy, klíčové schopnosti, přibližný cenový rozsah. Dost na to, abyste sestavili užší seznam, aniž byste žádali dodavatele o rozsáhlé eseje.
4. RFP. Hlavní dokument. Dává každému dodavateli vše, co potřebuje k přesnému zpracování nabídky. Více o tom v následující kapitole.
5. Okno pro dotazy (Q&A). Vždy ho zařaďte. Dodavatelé budou mít otázky a odpovědi na ně často zlepší každou nabídku, kterou obdržíte. Veďte ho písemně a všechny otázky i odpovědi sdílejte se všemi dodavateli současně. Proces tak zůstane čistý a srovnatelný.
6. Užší výběr a prezentace. Ohodnoťte písemné nabídky a poté pozvěte 2–3 dodavatele k prezentaci. Prezentace by měla zahrnovat živou ukázku systému na základě vašich skutečných případů užití – ne generické demo. Pokud dodavatel nedokáže ukázat váš scénář ve svém systému, je to samo o sobě užitečná informace.
7. Druhé kolo (pokud je třeba). U složitého rozhodnutí stojí za to věnovat čas hlubšímu sezení zaměřenému na konkrétní otevřené body – bezpečnost, integraci, obchodní podmínky. Neplánujte ho, pokud nemáte skutečné zbývající otázky.
8. Rozhodnutí a smlouva. Slaďte se interně ještě před zahájením vyjednávání. Znáte svá nepřekročitelná kritéria, přijatelné kompromisy i hranice, za které nepůjdete.
9. Onboarding. Proces nekončí podpisem smlouvy. Nejlepší výsledky RFP mají plán onboardingu dohodnutý ještě před podpisem smlouvy.

Harmonogram výběrového řízení na TMS, který si můžete zkopírovat

Přibližná délka podle rozsahu:

• Jedna jednoduchá pobočka: 6 až 8 týdnů (plné RFP nemusí být nutné).
• Více poboček + integrace s ERP: 8 až 12 týdnů.
• Globální nasazení s více právními subjekty a složitou integrací: 12 až 20 týdnů, pravděpodobně se dvěma koly prezentací.

Stáhnout šablonu harmonogramu RFP (.docx)

Co zahrnout do dokumentu RFP pro TMS

Dokument RFP je vaším nejdůležitějším nástrojem v celém procesu. Dobré RFP odvede většinu hodnotící práce za vás – proto ho udržte soustředěný. Stručné RFP na 10 stranách předčí třicetistránkový dokument, který se snaží pokrýt vše.

1. Průvodní dopis a cíl

Jedna stránka. Kdo jste, co hledáte, proč právě teď. Držte se faktů. Dodavatelé nepotřebují vizi – potřebují pochopit váš provozní problém.

2. Harmonogram

Jasný plán s konkrétními daty: vydání RFP, uzávěrka dotazů, termín odevzdání nabídek, okno pro prezentace, datum rozhodnutí. Dodavatelé podle toho plánují svůj čas na zpracování. Vágní harmonogram přinese vágní nabídky.

3. Informace o firmě a provozu

Zde většina RFP selhává – a právě to rozhoduje mezi srovnatelnými nabídkami a kolem upřesňujících dotazů. Nepopisujte jen svou firmu, ale svou logistickou operaci. Kolik máte poboček. Kolik právních subjektů. Jaké přepravní módy (zásilky, LTL, FTL, letecky, námořně, železnicí). Které regiony. Přibližné objemy. Stávající systémy. To, co znamená „dobré řešení", se také liší podle odvětví – požadavky výrobců elektroniky, strojírenství, chemie nebo tiskáren a obalového průmyslu nejsou totožné. To je kontext, který dodavatelé potřebují, aby mohli nabídku přesně zpracovat. Pokud zde neposkytnete dostatek informací, strávíte dva týdny odpovídáním na upřesňující dotazy, kterým jste se mohli zcela vyhnout. Tato část má vlastní kapitolu níže.

4. Funkční požadavky

Tabulka toho, co systém musí umět, seřazená podle důležitosti: musí mít / měl by mít / bylo by hezké mít (Excel postačí). Požádejte dodavatele, aby ke každému požadavku uvedli míru pokrytí: a) nativní, b) třetí strana, c) customizace, nebo d) nepodporováno. Díky tomu jsou nabídky srovnatelné. Jak tento seznam sestavit, popisujeme níže.

5. Hodnotící kritéria

Sdělte dodavatelům, jak budete rozhodovat: funkčnost, cena, přístup k implementaci, reference, bezpečnost, tým. Pokud jste ochotni, sdílejte i váhy jednotlivých kritérií. Čím transparentnější budete, tím lepší nabídky dostanete.

6. Cenový model

Požádejte o úplný rozpis: předplatné, implementace, transakční poplatky, podpora a vše ostatní. Pokud je to možné, požádejte o vzorovou fakturu. Cenové struktury se mezi dodavateli výrazně liší a skryté náklady mají ve zvyku vynořit se pozdě. Zjistěte je co nejdříve.

7. Formát odpovědi

Přesně sdělte dodavatelům, jak má být nabídka strukturována, a pokud jim poskytnete šablony, vyžadujte jejich použití. Srovnatelné nabídky vám ušetří dny při hodnocení – a formát máte zcela ve svých rukou.

Stáhněte šablonu dokumentu RFP a začněte s hotovou strukturou popsanou výše:

Stáhnout šablonu dokumentu RFP (.docx)

Provozní informace, které většina RFP pro TMS vynechává – a proč jsou nejdůležitější

Tuto kapitolu bych si přál, aby přečetl každý, kdo píše RFP pro TMS, a to jako první.

Odpovídáme na mnoho přepravních výběrových řízení. Téměř každá nabídka, kterou zpracujeme, si vyžádá kolo upřesňujících dotazů – a zřídkakdy proto, že by požadavky byly nejasné. Důvodem je chybějící provozní kontext: objemy, struktura poboček, síť dopravců, stávající systémy.

RFP, která si vyžádala plné kolo upřesňujících dotazů, mají téměř vždy jedno společné:

Viděli jsme firmy, které strávily týdny sestavováním hodnotících kritérií a seznamů požadavků, a pak odeslaly RFP, v němž nebylo zmíněno, kolik zásilek měsíčně zpracovávají.

Bez toho dodavatelé hádají. A když hádají, nabídky se vrátí obecné, ceny nejsou konečné a není co porovnávat.

Například globální výrobce s 10 sklady a systémem SAP potřebuje zcela jiný návrh než jednopobočkový distributor, který řídí logistiku v tabulkách. Pokud dodavatel nedokáže rozlišit, o který případ jde, zajistí si zadní vrátka – a vy dostanete nabídky, které se k ničemu nezavazují.

Náprava zabere odpoledne. Před odesláním RFP odpovězte na těchto deset otázek.

1. Organizace a rozsah. Kolik právních subjektů a poboček je zahrnuto? Probíhá nasazení paralelně nebo postupně? Jak samostatně pobočky fungují – mají vlastní smlouvy s dopravci, vlastní týmy?
2. Objemy zásilek. Měsíční a denní počty zásilek na pobočku, průměr a špičky. Případná sezónnost. Poměr příchozích a odchozích zásilek.
3. Přepravní módy. Jaký podíl tvoří zásilky, LTL, FTL, letecká a námořní přeprava? Které módy rostou? Které jsou provozně nejkritičtější?
4. Síť dopravců. Kolik dopravců na pobočku a na mód? Jsou sdíleni napříč pobočkami, nebo spravováni lokálně? Existují strategičtí dopravci, kteří musí mít přednost, nebo dopravci určení zákazníkem, které nelze změnit?
5. Geografie a přepravní trasy. Které regiony jsou zahrnuty? Které trasy jsou nejdůležitější: tuzemské, přeshraniční, mezikontinentální? Klíčové přístavy nebo logistická centra?
6. Současný stav. Jak jsou zásilky dnes plánovány, objednávány a sledovány? V ERP, tabulkách, portálech dopravců, e-mailem? Jaké jsou hlavní bolestivé body stávajícího procesu?
7. Finanční nastavení. Kdo platí za přepravu – jeden subjekt, nebo více? Existují čísla účtů třetích stran nebo zákazníků? Jak jsou dnes zachycovány a ověřovány přepravní náklady?
8. Obchodní model. B2B, B2C? Pokud obojí, v jakém poměru. Provozní i systémové požadavky se poměrně výrazně liší.
9. Integrační prostředí. Které systémy se musí připojit k TMS: ERP, WMS, CRM? Existují stávající integrace dopravců, které je třeba zachovat? Jak vysoká míra automatizace je potřeba od prvního dne?
10. Harmonogram a omezení. Existuje cílové datum spuštění? Jsou tu interní milníky – konec fiskálního roku, sezónní špička, migrace systémů – které ovlivňují plán?

Nic z toho není těžké sepsat. Ale změní vše, co se vrátí.

Stáhněte si kontrolní seznam provozních informací a proměňte těchto deset otázek ve vyplňovací tabulku, kterou přímo vložíte do svého RFP:

Stáhnout kontrolní seznam provozních informací (.docx)

Jak formulovat funkční požadavky na TMS

Funkční požadavky jsou srdcem RFP. Zpracujete-li je správně, získáte jasný a srovnatelný přehled o tom, co každý dodavatel umí a neumí. Uděláte-li to špatně, můžete strávit týdny luštěním odpovědí, které všechny říkají „ano".

Cílem není nejdelší seznam. Ale ten nejupřímnější.

Prioritizujte důsledně: musí mít, měl by mít, bylo by hezké mít

Ne vše, co chcete, je stejně důležité. Používejte tři kategorie a držte se jich:

1. Musí mít (M): nepřekročitelné. Dodavatel, který tento požadavek nesplní, vypadává – bez ohledu na vše ostatní.
2. Měl by mít (S): důležité, ale lze přijmout náhradní řešení nebo příslib v blízkém horizontu.
3. Bylo by hezké mít (N): dobré vědět, ale stojí za vším výše uvedeným.

Většina seznamů má příliš mnoho položek „musí mít". Pokud je vše kritické, nic kritické není. Buďte upřímní v tom, co by skutečně znemožnilo systém používat, a označte jako „musí mít" pouze to.

Požádejte dodavatele o klasifikaci pokrytí: nativní / třetí strana / customizace

Ke každému požadavku musí odpovědět jednou z těchto možností:

Právě v tomto sloupci nabídky získávají nebo ztrácejí vaši důvěru. Dodavatel, který odpovídá upřímně a napíše nepodporováno tam, kde to odpovídá skutečnosti, vám ukazuje, jak se bude chovat jako partner. Dodavatel, který u všeho odpovídá nativní, vám také něco sděluje – a to je rovněž důležitá informace.

Formulujte otázky konkrétně

„Podporuje systém cenotvorbu dopravců?" vám přinese zbytečné „ano". „Dokáže systém vypočítat přepravní cenu pro každého dopravce, včetně těch bez cenového API, a zobrazit je vedle sebe pro každou zásilku?" – to je otázka, na jejímž základě lze skutečně hodnotit.

Kde končí ERP a kde začíná TMS?

Jedním z nejčastějších zdrojů zmatku při hodnocení softwaru pro správu přepravy je otázka, kde TMS končí a kde začíná ERP.

Finanční procesy jako účtování do hlavní knihy, landed cost a audit přepravních faktur jsou často řešeny na straně ERP, přičemž TMS do něj data předává. To je normální a často správné nastavení. Musí to ale být výslovně definováno. Když dodavatel u jednoho z vašich požadavků „musí mít" odpoví „řešeno prostřednictvím integrace s ERP", zjistěte přesně, co to znamená pro vaši implementaci – a kdo to realizuje.

Specifikujte cíl, ne technické řešení

Popisujte, čeho potřebujete dosáhnout, ne jak by to systém měl technicky zajistit. Příliš předpisové požadavky vyřadí dobré systémy ze špatných důvodů. Nechte dodavatelům prostor ukázat vám lepší cestu, než jakou jste měli na mysli – někdy ji skutečně mají.

Seznam třiceti upřímných a prioritizovaných požadavků vám řekne více než stopandesátořádková tabulka, kde je vše kritické a každý dodavatel zaškrtl každé políčko.

Výchozí sada požadavků na TMS k přizpůsobení

Většina kupujících poprvé chce mít náskok při sestavování samotného seznamu – proto zde uvádíme příklad z naší praxe, již roztříděný do kategorií, který si můžete přizpůsobit svému provozu. Úplný seznam je ke stažení v hodnotící tabulce níže; tato ukázka postačí k tomu, abyste pochopili jeho strukturu.

Stáhněte si hodnotící tabulku funkčních požadavků, která je již připravena s prioritami a sloupcem pokrytí pro každého dodavatele:

Stáhnout hodnotící tabulku funkčních požadavků (.docx)

Jak porovnat náklady na TMS (a sestavit tříletý model)

„Kolik stojí TMS?" je otázka, na kterou kupující nejvíce chtějí odpověď a dodavatelé se jí nejraději vyhýbají. Jenže poplatek za předplatné je zřídkakdy vaším konečným nákladem. U středně velkého zákazníka s více pobočkami mohou implementace a integrace pohánět celkové tříleté náklady více než měsíční poplatek – a právě o tuto položku se dodavatelé vyjadřují nejmlhavěji. Klíčem je proto strukturovat otázku tak, aby se odpovědi daly porovnat a skutečné náklady byly viditelné.

Pro hrubou orientaci: cloudový TMS pro střední trh se pohybuje od několika stovek do několika tisíc eur měsíčně, zatímco tradiční podnikové systémy stojí od desítek tisíc až po více než milion eur ročně, přičemž implementace může dosáhnout šesti nebo sedmi číslic. To je velmi široké rozpětí – a právě proto je srovnatelný model důležitější než jakékoli jednotlivé číslo. Pro představu o tom, co skuteční dodavatelé TMS účtují, si přečtěte náš přehled předních dodavatelů TMS.

Složky ceny TMS

Téměř každá nabídka na TMS je nějakou kombinací těchto položek:

Sestavte tříletý model nákladů ještě před porovnáváním

Dodavatel, který vypadá levně na předplatném, může být nakonec nejdražší, jakmile přičtete implementaci, transakční poplatky a onboarding dopravců. Každého dodavatele projeďte stejným modelem:

Náklady za 3 roky = implementace + (roční předplatné × 3) + (poplatek za zásilku × roční objem × 3) + podpora + očekávané příplatky za dopravce a integrace.

Používejte skutečné objemy, ne uklizený příklad od dodavatele. Tato jedna tabulka má tendenci přeskládat pořadí v užším výběru.

Sledujte různé složky ceny, nejen základní poplatek

Někteří dodavatelé drží předplatné nízko a dohánějí to na transakčních poplatcích nebo poplatcích za dopravce. To samo o sobě není špatné, ale mění to, kdo je nejlevnější s tím, jak rostete. Pokud váš objem stoupá, model s poplatkem za zásilku může rychle předehnat paušální sazbu. Požádejte o vzorovou fakturu a podmínky předplatného, abyste porovnávali to, co skutečně zaplatíte – ne jen inzerovanou sazbu.

Jedna otázka, kterou stojí za to položit každému dodavateli: jsou integrace nových dopravců zahrnuty, nebo se účtují zvlášť? Některé platformy TMS účtují za integraci nového dopravce 5 000–10 000 EUR a trvá to měsíce, jiné integrace nových dopravců budují bez příplatku. Pro středně velkého zákazníka, který v průběhu let přidává dopravce, může tato jediná odpověď posunout tříleté celkové náklady více než celý řádek předplatného.

Jak hodnotit nabídky na TMS nad rámec ceny

Nabídky jsou na stole. Všechny vypadají rozumně, většina říká ano na vaše požadavky a ceny jsou v podobném rozsahu. Co teď?

V tuto chvíli týmy tiše sklouznou k ceně, protože vše ostatní se zdá těžší porovnat. Nedělejte to. Zde je to, co je skutečně odlišuje.

1. Propojení s dopravci.

Pro TMS je propojení s dopravci základem. Jak se dodavatel skutečně připojuje k dopravcům – přes přímé API/EDI integrace, agregátory třetích stran, nebo vůbec ne (e-mail a PDF objednávky bez ohledu na IT možnosti dopravce)? Co se stane, když potřebujete dopravce, kterého zatím nepodporují – jak dlouho to trvá a co to stojí?

Dodavatel s hlubokým, přímým propojením s dopravci je jiná kategorie než ten, kdo vše směruje přes middleware vrstvu. Rozdíl pocítíte na spolehlivosti objednávání, kvalitě sledování zásilek a na tom, zda můžete přidat dopravce, aniž byste pokaždé zahajovali nové obchodní vyjednávání.

2. Harmonizace úrovně digitálních služeb dopravců – tato věc je důležitější, než si většina lidí uvědomuje.

Dopravci nejsou z hlediska digitálních možností rovnocenní. Někteří mají sofistikovaná API pokrývající ceny v reálném čase, predikci ETA, ověřování adres, generování štítků a podrobné události sledování. Jiní vám pošlou potvrzení objednávky e-mailem – a tím komunikace končí. Většina sítí dopravců obsahuje oba typy najednou.

To se stane vaším problémem ve chvíli, kdy připojíte ERP nebo WMS k TMS. Pokud vaše integrace očekává od každého dopravce kompletní sadu dat – potvrzení objednávky, odkaz pro sledování, štítek, odhad nákladů – ale někteří dopravci to poskytnout nemohou, vznikají výjimky, ruční obcházení a mezery v datech. Jeden slabý dopravce naruší konzistenci celého pracovního postupu.

Různí dodavatelé softwaru pro správu přepravy se s tím vypořádávají dvěma způsoby – a stojí za to rozhodnout se, který chcete, ještě před přečtením jediné nabídky:

• Tenčí TMS předává vše, co každý dopravce poskytne – a mezery budete řešit vy, ve svém ERP nebo ručně. Jednodušší integrace, ale více výjimek na vaší straně.
• TMS, který data normalizuje a mezery sám doplňuje: vypočítá přepravní cenu z vaší nahrané ceníkové tabulky, když není k dispozici cenové API; odhadne dobu přepravy, když dopravce neposkytuje ETA; vygeneruje přepravní štítky, když to dopravce neumí; umožní dopravcům ručně zadávat milníky sledování, pokud sledování nemají – a mnoho dalšího. Software doplňuje mezery v technických možnostech vašich dopravců a váš ERP vidí jednu konzistentní strukturu.

Při hodnocení nabídek se dodavatelů přímo zeptejte: jak pracujete s dopravci s omezenými digitálními možnostmi? Odpověď vám hodně napoví o skutečné vyspělosti jejich platformy.

3. Upřímnost ohledně integrace.

Věnujte pozornost tomu, jak dodavatelé popisují rozsah integrace (kdo co dělá). Nabídka, která jasně říká „vývoj na straně ERP je na vás, zde je to, co poskytujeme a jak to podporujeme", je důvěryhodnější než ta, která naznačuje „bezproblémovou integraci", aniž by vysvětlila, která strana co řeší. Překvapení při integraci jsou jedním z nejčastějších důvodů, proč projekty TMS překračují čas i rozpočet.

4. Přístup k implementaci.

Postupný přístup – nejprve ruční ověření provozu, pak automatizace – je zpravidla méně rizikový než spuštění na jeden ráz. Máte tak možnost potvrdit, že systém funguje pro vaše skutečné pracovní postupy, ještě než na něm postavíte celý provoz. Z naší zkušenosti: dodavatelé, kteří tento přístup navrhují bez vyzvání, si zpravidla prošli chaotickým spuštěním. Ti, kteří od prvního dne nabízejí plnou automatizaci, často ne.

5. Reference

Žádejte reference od firem s podobným provozem, nejen s podobnou velikostí nebo počtem zaměstnanců. Reference od jednopobočkového distributora není příliš užitečná, pokud provozujete vícepobočkovou výrobní operaci s integrací SAP. A ptejte se konkrétně: „Jak probíhal onboarding dopravců?" „Jak šla integrace?" „Co se stalo, když něco nefungovalo podle očekávání?"

6. Samotná nabídka.

To, jak dodavatel TMS reaguje na vaše RFP, je předobrazem toho, jak se bude chovat jako váš partner. Odpověděl na vaše otázky přímo, nebo vše zahalil do výhrad? Přiznal mezery upřímně, nebo tvrdil plné pokrytí u každého požadavku? Ukázal, že pochopil váš provoz, nebo vám poslal mírně upravenou verzi svého standardního materiálu?

Nabídka, která na dvou místech přizná nepodporováno a vysvětlí proč, má větší hodnotu než ta, která říká ano na vše. Pravdu zjistíte tak jako tak. Lepší je zjistit ji při hodnocení než při spuštění.

Stáhněte si hodnotící matici dodavatelů pro bodové hodnocení podle vážených kritérií:

Stáhnout hodnotící matici dodavatelů (.docx)

Kolo prezentací dodavatelů TMS

Písemné nabídky vám říkají, co dodavatel tvrdí. Prezentace vám ukážou, zda to dokáže podložit.

V této fázi byste měli mít užší výběr 2–3 dodavatelů. Cílem prezentačního kola je vystavit nabídku skutečnému tlaku a zjistit, zda systém funguje na vašich konkrétních scénářích.

Žádejte živou ukázku, ne demo

Demo je nacvičená sekvence ukazující systém v nejlepším světle. Živá ukázka znamená, že řeknete: „Ukažte mi, jak byste zpracovali tuto zásilku z našeho skladu v Nizozemsku, s naším dopravcem, za naši sjednanou cenu" – a sledujete, co se skutečně stane.

Před schůzkou si připravte 2–3 skutečné scénáře z vašeho provozu: standardní odchozí objednávku, zásilku vyžadující spot nabídku a něco komplikovaného – třeba zpožděnou zásilku nebo dopravce, který neposkytuje sledování. Pokud dodavatel neustále stáčí pozornost zpět k vyleštěnému demu místo toho, aby prošel vaším scénářem, máte odpověď.

Tlačte na mezery

Každá nabídka na TMS je má. Jděte přímo na místa, kde dodavatel odpověděl jen částečně nebo kde máte pochybnosti, a zůstaňte tam. Nenechte je sklouznou zpět k tomu, co funguje bezchybně. Jak přesně to funguje? Kdo co dělá? Co se stane, když to nefunguje podle očekávání?

Zajistěte správné lidi v místnosti

Na straně dodavatele TMS by měli prezentovat ti, kdo budou skutečně pracovat na vaší implementaci – ne jen obchodní tým. Požádejte o to výslovně. Na vaší straně přiveďte někoho z IT (pokud je integrace v rozsahu) a alespoň jednoho člověka, který bude systém každý den skutečně používat. Ti kladou jiné otázky než nákupní oddělení – a chcete mít obě sady otázek položeny.

Druhé kolo jen tehdy, když je třeba

U složitého rozhodnutí stojí za to věnovat čas druhému sezení zaměřenému na konkrétní témata. Příklady témat k projednání:

• Bezpečnost a ochrana dat – požádejte o zprávu z penetračního testování nebo bezpečnostní dokumentaci, pokud to vyžaduje váš IT nebo tým informační bezpečnosti
• Architektura integrace – technické sezení mezi vaším IT týmem a týmem dodavatele
• Obchodní podmínky – projděte smlouvu, SOW a předpoklady řádek po řádku ještě před zahájením formálního vyjednávání

Neplánujte ho jen proto, abyste zopakovali první schůzku s více lidmi v místnosti. Buď řeší konkrétní otevřené otázky, nebo by se konat nemělo.

Závazky potvrďte písemně

Vše, k čemu se dodavatel zaváže na schůzce a co není v písemné nabídce, musí být před dalším postupem potvrzeno písemně. Ústní závazky nepřežijí smluvní vyjednávání. Pokud dodavatel TMS řekne „ano, to zvládneme" u něčeho důležitého, pošlete mu ještě tentýž den e-mail a požádejte ho o potvrzení.

Smlouva a SOW (Statement of Work) pro TMS: co zkontrolovat před podpisem

Vybrali jste dodavatele. Většina týmů v tuto chvíli „vydechne". Nedoporučuji to – právě zde se detaily, které byly při hodnocení přehlédnuty, tiše promění ve váš problém.

Slaďte se interně ještě před vyjednáváním

Znáte svá nepřekročitelná kritéria, přijatelné kompromisy a hranice, za které nepůjdete, ještě před zahájením rozhovoru. Měnit požadavky uprostřed vyjednávání stojí čas, narušuje důvěru a občas vám to stojí dodavatele TMS, kterého jste skutečně chtěli. Nejprve se dohodněte interně, pak teprve vyjednávejte.

Pochopte, co kupujete: SaaS, ne licenci

Moderní platformy TMS jsou SaaS předplatné, ne softwarové licence. Přihlašujete se ke službě, kterou dodavatel hostuje, spravuje a aktualizuje – nekupujete systém natrvalo. To mění, co musí smlouva pokrývat: podmínky předplatného, ukončení, vlastnictví dat a práva na export, závazky ohledně dostupnosti, doby odezvy podpory. Standardní nákupní šablony pro tento model nebyly psány – ujistěte se, že vaše jsou aktuální.

SOW je stejně důležité jako smlouva

Statement of Work přesně vymezuje, co se dodá, kým a kdy: konfigurace účtu, onboarding dopravců, podpora integrace, školení a přejímací kritéria potvrzující, že implementace je skutečně hotová. Co není v SOW, není zahrnuto – bez ohledu na to, co bylo řečeno na schůzce nebo v e-mailu. Zvláštní pozornost věnujte sekci předpokladů. Tam je rozsah podmíněně definován. Pokud se ukáže, že váš seznam dopravců je větší, než bylo uvedeno, nebo váš ERP vyžaduje nestandardní formát integrace, právě sekce předpokladů rozhodne, zda jde o rychlý rozhovor nebo o zpoplatněný požadavek na změnu.

Výslovně definujte, co je mimo rozsah

Vývoj na míru, školení na místě, migrace dat, integrační práce na vašich systémech, změny na straně dopravce. Tyto položky jsou obvykle oceňovány zvlášť. Písemné zachycení před podpisem odstraňuje nejčastější – a nejlépe předvídatelný – zdroj třenic při implementaci: dvě strany, z nichž každá předpokládala, že něco jiného je zahrnuto.

Dohodněte plán onboardingu před podpisem

Ne po něm. Prioritizace dopravců, harmonogram konfigurace, milníky integrace, kritéria spuštění – vše vyřešte, dokud máte ještě páku. Dodavatel, který vám v době podpisu smlouvy nedokáže poskytnout jasný plán onboardingu, vám říká něco, co budete chtít vědět ještě před závazkem.

Po podpisu: implementace a onboarding TMS

Většina skutečného rizika přichází po podpisu. O výsledku rozhodují tři věci.

1. Migrace dat

Smlouvy s dopravci, ceníky, adresáře, historické zásilky. Rozhodněte včas, co potřebujete přenést, co je třeba nejprve vyčistit a kdo práci zajistí. Nekvalitní zdrojová data jsou nejčastějším důvodem, proč se datum spuštění posouvá dál a dál. Vyčistěte je před migrací, ne v jejím průběhu.

2. Pořadí onboardingu dopravců

Všechny dopravce nepřipojíte první den. Prioritizujte podle objemu a kritičnosti, zprovozněte a ověřte nejdůležitější z nich, pak rozšiřujte. Právě zde se postupný přístup, na který jste se ptali při hodnocení, skutečně vyplatí.

3. Přijetí uživateli

Lidé, kteří každý den objednávají zásilky, musí nový systém chtít používat. Zapojte alespoň jednoho z nich již od fáze RFP, řádně je vyškolte během hypercare (onboardingu) a ujistěte se, že každodenní pracovní postup je skutečně rychlejší než to, co dělali dříve. Technicky bezchybné nasazení, které tým prostě nepoužívá, je stále neúspěšné nasazení.

10 nejčastějších chyb v RFP pro TMS

Vzorce, které vídáme nejčastěji – vše na jednom místě:

• Chybějící provozní kontext. Ta největší. Dodavatelům nejsou poskytnuty žádné informace o objemech, struktuře poboček ani síti dopravců. Kolo upřesňujících dotazů a obecné ceny jsou zaručeny.
• Vše je „musí mít". Když je každý požadavek kritický, sloupec priorit je k ničemu a nelze rozlišit dealbreaker od příjemného bonusu.
• Vágní harmonogram. Bez konkrétních dat dodavatelé nedokážou odhadnout svůj čas – a nabídky přijdou stejně vágní.
• Přílišná specifikace způsobu řešení. Předepisování technické implementace místo provozního výsledku vyřadí dobré systémy ze špatných důvodů.
• Přehlížení hranice ERP/TMS. Předpoklad, že TMS vlastní finanční procesy, které ve skutečnosti patří ERP – a zjištění toho uprostřed implementace.
• Rozhodování podle ceny. Výběr na základě inzerovaného předplatného bez tříletého modelu nebo bez zohlednění propojení s dopravci a upřímnosti ohledně integrace.
• Demo místo živé ukázky. Sledování vyleštěné sekvence dodavatele místo toho, aby systém prošel vaše skutečné scénáře.
• Reference, které neodpovídají vašemu provozu. Zaměření na působivá loga, ale tyto firmy mohou mít logistické operace, které se vašim vůbec nepodobají. Žádejte reference, které vypadají jako vy, a pak se ptejte, jak skutečně probíhal onboarding a integrace.
• Odkládání onboardingu na po podpisu. Plán, který vyjednáte s pákou, je lepší než ten, který vyjednáte bez ní.
• Příliš těžký proces pro správného dodavatele. Byrokratická zátěž, která může vyřadit moderní platformy, jež by vám nejlépe posloužily.

Šablony pro RFP na TMS zdarma

Sestavili jsme pět šablon z RFP, na která odpovídáme, abyste nemuseli začínat od prázdné stránky:

1. Šablona dokumentu RFP. Kompletní struktura z tohoto průvodce.
2. Hodnotící tabulka funkčních požadavků. Prioritizovaná, se sloupcem pokrytí pro každého dodavatele.
3. Kontrolní seznam provozních informací. Deset otázek ve formě vyplňovací tabulky.
4. Hodnotící matice dodavatelů. Vážené bodové hodnocení napříč dodavateli.
5. Šablona harmonogramu RFP. Aktivity, data, odpovědné osoby.

Stáhněte si celý balíček – všech pět šablon zdarma, bez zadání e-mailu. Vezměte si, co se hodí, zbytek ignorujte:

Stáhnout kompletní balíček šablon pro RFP na TMS (.zip)

Cargoson je software pro správu přepravy využívaný středně velkými výrobci a velkoobchodníky po celé Evropě i Severní Americe. Na RFP, jako je to, které se chystáte napsat, odpovídáme pravidelně – takže pokud si chcete požadavky nejprve probrat, než začnete psát, rádi vám pomůžeme to promyslet, bez závazků.

Rezervujte si bezplatnou 30minutovou konzultaci zde

Veďte proces dobře a každá hodina se vyplatí.