Hogyan írjunk TMS RFP-t: tapasztalataink [+ 5 ingyenes sablon]

Hetente válaszolunk szállításkezelő rendszer RFP-kre (ajánlatkérési dokumentumokra). Vannak köztük olyanok, amelyeken öröm dolgozni. És vannak olyanok, amelyek inkább azt mutatják meg, hogyan ne csináljuk.

Ez a cikk azt mutatja be, hogyan építenék fel egy TMS-kiválasztási folyamatot ma, a nulláról. Alapja azok az RFP-k, amelyekre válaszoltunk, az iparágakon átívelő visszatérő minták, a leggyakoribb tartalmak – és a leggyakoribb hibák.

Ha te már tapasztalt beszerző vagy, a legtöbb itt leírt dolog ismerős lesz. Remélhetőleg legalább egy felesleges pontosítási kört megspórol neked.

Mi az a TMS RFP?

A TMS RFP (ajánlatkérési dokumentum) egy strukturált dokumentum, amelyet szállításkezelő rendszerek szállítóinak küldesz el. Leírja a logisztikai működésedet, és arra kéri a szállítókat, hogy ugyanazokra a követelményekre válaszolva mutassák be, hogyan kezelné a rendszerük a te helyzetedét. A lényeg az összehasonlíthatóság: azonos kérdések, azonos formátum, azonos kontextus – hogy az érkező ajánlatokat egymás mellé lehessen tenni, ne pedig öt különálló értékesítési prezentációként kelljen olvasni.

Nem mindig van rá szükség. Az RFP akkor éri meg a befektetett energiát, ha a döntés összetett, vagy ha belső szinten is indokolni kell majd. Ha a logisztikai működésed egyszerű, egy termékdemó és néhány szállítóval folytatott megbeszélés is elegendő.

Valóban szükséges TMS RFP-tendert lefolytatni?

A legdrágább hiba az egész TMS-kiválasztási folyamatban, ha ezt rosszul döntöd el. Ezt tisztázd mindenekelőtt.

A kérdés nem a cég méretétől, hanem a logisztika összetettségétől függ.

Futtass strukturált TMS RFP-tendert, ha több telephelyről szállítasz, több szállítási módot használsz, és a rendszernek az ERP-dhez kell csatlakoznia. Ilyenkor szükséges, hogy minden szállítót egymás mellé állíts, nehogy valami fontos kicsússzon a rostán. A fuvarozók csatlakoztatásának módja szállítónként nagyon eltérő lehet: az egyik „natívnak" nevezi, a másik csendben egy közvetítőn keresztül oldja meg. Egy laza folyamatban ezt csak az aláírás után veszed észre – ami már késő.

Hagyd el a formális RFP-tendert, ha egyetlen telephelyet üzemeltetsz néhány fuvarozóval, és pontosan tudod, mire van szükséged. Miért? Mert amint elindítasz egy RFP-t, automatikusan a vállalati árazási kategóriába kerülsz. 2-3 célzott kérdésekkel lefolytatott demó sokszor jobb rendszert, olcsóbban és gyorsabban eredményez. Mondd el a 2-3 kiszemelt szállítónak, mit szállítasz és milyen problémát szeretnél megoldani, majd kérd meg őket, hogy mutassák meg az élő rendszerükben. Egy órán belül képet kapsz. Ha pedig főleg csomagokat szállítasz raklapok vagy teheráruk helyett, lehet, hogy teljes TMS-re sincs szükséged – a több fuvarozós szállítási szoftver egy másik, könnyebb kategória, amelyet kifejezetten erre terveztek.

Légy tehát őszinte magaddal, melyiket preferálod, mielőtt belevágsz. Egy felesleges RFP a leglassabb és legdrágább módja egy TMS megvásárlásának.

Egy felesleges RFP a leglassabb és legdrágább módja egy TMS megvásárlásának.

Még egy figyelmeztetés, ha mégis a teljes RFP-folyamat mellett döntesz. Egy irányítási nyelvezettől, módszertani keretrendszerektől és rögzített áras követelményektől terhes folyamatra hetekig tart válaszolni, és az ilyen terhet elnyelni képes szállítók jellemzően a nagy, bevett szereplők. Ha egy karcsúbb, modernebb platform jobban kiszolgálna, egy túlzottan bürokratikus folyamat csendben kiszűrheti őket, mielőtt egyáltalán látnál tőlük egy demót.

A cél az, hogy neked megfelelő megoldást találj. A folyamatot ehhez igazítsd – ne a folyamat kezeléséhez.

A TMS RFP folyamat 9 lépése

A TMS-kiválasztásnak nem kell bonyolultnak lennie. De egyértelmű sorrendben kell haladni. Ha kihagysz lépéseket, később fizeted meg az árát – általában a bevezetés során, amikor a korán tisztázandó feltételezések drága meglepetésekké válnak.

Jól végrehajtva az egész folyamat 8–12 hétig tart. Egyszerűbb hatókörrel kevesebb, és ritkán kell ennél több.

A bevált sorrend a következő:

1. Piackutatás. Mielőtt egyetlen követelményt is leírnál, szánj időt arra, hogy megismerd a piacot. A TMS-piac az elmúlt öt évben sokat változott: vannak jó vállalati platformok, jó középpiaci platformok, és valóban képes modern SaaS-alapú szállításkezelő szoftver megoldások, amelyek öt éve még nem léteztek. Állíts össze egy 5-8 TMS-szállítóból álló hosszú listát, amelyeket érdemes megkeresni.
2. Titoktartási megállapodás (NDA). Küldd el korán. Operatív adatokat fogsz megosztani – forgalmi adatokat, fuvarozók nevét, belső rendszerek részleteit –, és az aláírt NDA az RFP kiküldése előtt bevett gyakorlat, amely mindkét felet védi.
3. RFI (opcionális). Egy rövid információkérés (Request for Information) akkor indokolt, ha a hosszú listád széles, és szűrni szeretnél, mielőtt teljes RFP-folyamatba fektetsz energiát. Tartsd egy oldalon: céges háttér, főbb képességek, hozzávetőleges árkategória. Elég ahhoz, hogy rövidlistát állíts össze anélkül, hogy esszéket kérnél a szállítóktól.
4. RFP. A folyamat alapdokumentuma. Megad minden szállítónak mindent, amire pontos ajánlathoz szükségük van. Erről bővebben a következő fejezetben.
5. Kérdés-válasz ablak. Mindig iktass be egyet. A szállítóknak lesznek kérdéseik, és a válaszok sokszor minden beérkező ajánlatot jobbá tesznek. Írásban bonyolítsd le, és az összes kérdést és választ egyszerre oszd meg minden szállítóval. Ez tisztán tartja a folyamatot és megőrzi az összehasonlíthatóságot.
6. Rövidlista és prezentációk. Értékeld a beírásos ajánlatokat, majd hívj meg 2-3 szállítót prezentációra. A prezentáció tartalmazzon élő rendszerbemutatót a te valós felhasználási eseteid alapján – ne általános demót. Ha egy szállító nem tudja megmutatni a te forgatókönyvedet a saját rendszerében, az önmagában is hasznos információ.
7. Második kör (ha szükséges). Összetett döntésnél megéri az idő egy mélyebb munkamenet, amely a konkrét nyitott kérdésekre – biztonság, integráció, kereskedelmi feltételek – fókuszál. Ne ütemezd be, ha nincs valódi nyitott kérdésed.
8. Döntés és szerződés. Belső szinten egyezz meg, mielőtt tárgyalni kezdesz. Tudd, mik a kötelező elvárásaid, miben tudsz kompromisszumot kötni, és hol van a határod.
9. Onboarding. A folyamat nem ér véget az aláírásnál. A legjobb RFP-eredményekhez az onboarding-tervet a szerződés aláírása előtt kell egyeztetni.

TMS RFP-ütemterv, amelyet lemásolhatsz

Hozzávetőleges időtartam hatókör szerint:

• Egyszerű, egytelepes eset: 6–8 hét (teljes RFP-re esetleg nincs is szükség).
• Több telephely + ERP-integráció: 8–12 hét.
• Globális, több jogalanyos, összetett integráció: 12–20 hét, valószínűleg két prezentációs körrel.

RFP-ütemterv sablon letöltése (.docx)

Mit tartalmazzon a TMS RFP-dokumentum?

Az RFP-dokumentum a folyamat legfontosabb eszköze. Egy jól megírt RFP az értékelési munka nagy részét elvégzi helyetted – ezért tartsd fókuszáltan. Egy tömör, 10 oldalas RFP felülmúl egy 30 oldalas, mindent lefedni próbáló változatot.

1. Kísérőlevél és célmeghatározás

Egy oldal. Ki vagy, mit keresel, miért most. Maradj tényszerű. A szállítóknak nem víziónyilatkozatra van szükségük, hanem arra, hogy megértsék az operatív problémádat.

2. Ütemterv

Egyértelmű menetrend valós dátumokkal: az RFP kiküldése, a kérdések határideje, a benyújtás, a prezentációs ablak, a döntés. A szállítók ez alapján tervezik a válaszadásra fordított erőforrásaikat. Homályos ütemterv homályos ajánlatokat eredményez.

3. Céges és operatív háttérinformáció

A legtöbb RFP itt hagy kívánnivalót maga után – és ez a különbség az összehasonlítható ajánlatok és egy pontosítási kör között. Ne csak a vállalkozásodat írd le, hanem a logisztikai működésedet is. Hány telephely. Hány jogi személy. Milyen szállítási módok (csomag, LTL, FTL, légi, tengeri, vasúti). Mely régiók. Hozzávetőleges forgalmi adatok. Jelenlegi rendszerek. Az is számít, hogy mi számít „jónak" az adott szektorban – az elektronikai, a gépipari, a vegyipari vagy a nyomda- és csomagolóipari gyártók követelményei nem azonosak. Ez az a kontextus, amelyre a szállítóknak szükségük van ahhoz, hogy pontosan tudják beárazni az ajánlatukat. Ha itt nem adsz elég részletet, két hetet töltesz majd olyan pontosítási kérdések megválaszolásával, amelyek teljesen elkerülhetők lettek volna. Ennek külön fejezetet szentelünk alább.

4. Funkcionális követelmények

Egy táblázat arról, mit kell tudnia a rendszernek, fontosság szerint prioritizálva: kötelező / ajánlott / hasznos lenne (Excel tökéletesen megfelel). Kérd meg a szállítókat, hogy minden követelményre jelöljék a lefedettség szintjét: a) natív, b) harmadik féltől származó, c) testreszabás, vagy d) nem támogatott. Ez teszi az ajánlatokat összehasonlíthatóvá. A lista összeállításáról bővebben alább.

5. Értékelési szempontok

Mondd el a szállítóknak, hogyan hozod meg a döntést: funkcionalitás, ár, bevezetési megközelítés, referenciák, biztonság, csapat. Ha hajlandó vagy rá, oszd meg a súlyozást is. Minél átláthatóbb vagy, annál jobb ajánlatokat kapsz.

6. Ármodell

Kérj teljes részletezést: előfizetés, bevezetés, tranzakciós díjak, támogatás és minden egyéb tétel. Ha lehetséges, kérj mintaszámlát is. Az árazási struktúrák szállítónként nagyon eltérnek, és a rejtett költségek előszeretettel bukkannak fel késői fázisban. Próbáld ezeket korán kiszűrni.

7. Válaszformátum

Mondd meg pontosan a szállítóknak, hogyan strukturálják az ajánlatukat, és ha sablonokat adsz nekik, tedd kötelezővé a használatukat. Az összehasonlítható ajánlatok napokat spórolnak meg az értékelés során, és a formátum teljes mértékben a te kezedben van.

Töltsd le az RFP-dokumentumsablont, hogy a fenti teljes struktúrából indulhass:

RFP-dokumentumsablon letöltése (.docx)

Az operatív háttérinformáció, amelyet a legtöbb TMS RFP kihagy – és miért ez a legfontosabb rész

Ezt a fejezetet szeretném, ha minden TMS RFP szerzője először olvasná el.

Sok TMS-tenderre válaszolunk. Szinte minden ajánlathoz szükség van egy pontosítási körre – és ez szinte soha nem azért van, mert a követelmények nem voltak egyértelműek. Azért van, mert az operatív kontextus hiányzott: forgalmi adatok, telephelystruktúra, fuvarozói környezet, jelenlegi rendszerek.

Az összes olyan RFP-nek, amelyhez teljes pontosítási körre volt szükség, szinte mindig van egy közös vonása:

Láttunk olyan cégeket, amelyek heteket töltöttek értékelési szempontok és követelménylisták kidolgozásával, majd olyan RFP-t küldtek ki, amelyből az sem derült ki, hány küldeményt dolgoznak fel havonta.

Enélkül a szállítók találgatnak. Ha pedig találgatnak, az ajánlatok általánosak maradnak, az árazás nem végleges, és nincs semmi szilárd alap az összehasonlításhoz.

Például egy 10 raktárral rendelkező, SAP-ot használó globális gyártónak teljesen más ajánlatra van szüksége, mint egy egytelepes forgalmazónak, aki táblázatokban kezeli a logisztikáját. Ha a szállító nem tudja megállapítani, melyik vagy te, fedezi magát – és olyan ajánlatokat kapsz, amelyek semmire sem kötelezik.

A megoldás egy délutánt vesz igénybe. Válaszolj az alábbi tíz kérdésre az RFP-ben, mielőtt kiküldöd.

1. Szervezet és hatókör. Hány jogi személy és telephely tartozik a hatókörbe? A bevezetés párhuzamos vagy fázisolt? Mennyire önállóan működnek a telephelyek – külön fuvarozói szerződések, külön csapatok?
2. Küldeményforgalom. Havi és napi küldeményszám telephelyenként, átlag és csúcs. Esetleges szezonalitás. Bejövő és kimenő forgalom aránya.
3. Szállítási módok megoszlása. Mekkora arányban van jelen a csomag, LTL, FTL, légi, tengeri szállítás? Melyik mód növekszik? Melyik a legkritikusabb operatív szempontból?
4. Fuvarozói környezet. Hány fuvarozó van telephelyenként és módozatonként? Közösen kezelik a telephelyek, vagy helyi szinten? Van-e stratégiai fuvarozó, amelyet előnyben kell részesíteni, vagy vevő által előírt fuvarozó, amelyet nem lehet megváltoztatni?
5. Földrajzi lefedettség és kereskedelmi útvonalak. Mely régiók tartoznak a hatókörbe? Melyek a legfontosabb útvonalak: belföldi, határon átnyúló, interkontinentális? Kulcskikötők vagy logisztikai csomópontok?
6. Jelenlegi állapot. Hogyan tervezik, rendelik meg és követik nyomon ma a küldeményeket? ERP-ben, táblázatokban, fuvarozói portálokon, e-mailben? Mik a jelenlegi folyamat fő fájdalompontjai?
7. Pénzügyi struktúra. Ki fizeti a szállítást – egy jogalany vagy több? Van-e harmadik feles vagy vevői számlaszám? Hogyan rögzítik és ellenőrzik ma a fuvarköltségeket?
8. Üzleti modell. B2B, B2C? Ha vegyes, az arány. Az operatív és rendszerkövetelmények meglehetősen eltérnek egymástól.
9. Integrációs környezet. Mely rendszereknek kell csatlakozniuk a TMS-hez: ERP, WMS, CRM? Van-e meglévő fuvarozói integráció, amelyet fenn kell tartani? Mennyire kell automatizáltnak lennie az első naptól fogva?
10. Ütemterv és korlátok. Van-e élesindítási célkitűzés? Vannak-e belső mérföldkövek – pénzügyi évzárás, csúcsszezon, rendszermigráció –, amelyek befolyásolják az ütemezést?

Ezeket nem nehéz leírni. De minden megváltozik attól, ami visszajön.

Töltsd le az operatív információs ellenőrzőlistát, amely ezt a tíz kérdést kitölthető táblázattá alakítja, amelyet közvetlenül az RFP-be illeszthetsz:

Operatív információs ellenőrzőlista letöltése (.docx)

Hogyan írjunk TMS funkcionális követelményeket?

A funkcionális követelmények az RFP szíve. Ha jól csinálod, világos és összehasonlítható képet kapsz arról, mit tud és mit nem tud az egyes szállítók rendszere. Ha rosszul, heteket tölthetsz olyan válaszok értelmezésével, amelyek mind azt mondják: „igen".

A cél nem a leghosszabb lista. A legőszintébb.

Prioritizálj kíméletlenül: kötelező, ajánlott, hasznos lenne

Nem minden, amit szeretnél, egyformán fontos. Használj három kategóriát, és tartsd magad hozzájuk:

1. Kötelező (K): nem alkuképes. Aki nem tudja teljesíteni, kiesik, bármit is hoz egyébként.
2. Ajánlott (A): fontos, de elfogadható egy kerülő megoldás vagy egy közeli jövőbeli fejlesztési ígéret.
3. Hasznos lenne (H): jó tudni róla, de minden fentebb említett mögé sorolódik.

A legtöbb listán jóval túl sok a „kötelező". Ha minden kritikus, semmi sem az. Légy őszinte azzal kapcsolatban, mi akadályozná valóban a rendszer működését, és csak azokat jelöld kötelezőként.

Kérd meg a szállítókat, hogy osztályozzák a lefedettséget: natív / harmadik féltől / testreszabás

Minden követelménynél az alábbiak egyikével kell válaszolniuk:

Ez az oszlop az, ahol az ajánlatok megnyerik vagy elveszítik a bizalmadat. Az a szállító, aki őszintén válaszol, és ott írja, hogy nem támogatott, ahol ez igaz, megmutatja, hogyan fog viselkedni partnerként. Az, aki mindenre natívot ír, szintén mond valamit – csak mást.

Légy konkrét a kérdésben

„Támogatja a rendszer a fuvarozói árazást?" – erre használhatatlan „igen" jön vissza. „Képes a rendszer minden fuvarozóra kiszámítani a fuvardíjat – beleértve azokat is, amelyeknek nincs árazási API-juk –, és küldeményenként egymás mellett megjeleníteni őket?" – erre már értékelhető választ kapsz.

Hol ér véget az ERP, és hol kezdődik a TMS?

A szállításkezelő rendszerek értékelésének egyik leggyakoribb félreértési forrása az, hogy hol ér véget a TMS és hol kezdődik az ERP.

A pénzügyi folyamatokat – főkönyvi kódolás, teljes bekerülési költség, fuvarszámla-ellenőrzés – sokszor az ERP kezeli, a TMS pedig adatot szolgáltat az ERP-nek. Ez normális, és sokszor a helyes felállás. De ezt pontosan le kell fektetni. Ha egy szállító az egyik kötelező követelményre azt válaszolja, hogy „ERP-integráción keresztül kezelt", derítsd ki pontosan, mit jelent ez a te bevezetésed szempontjából – és ki fejleszti.

A célt határozd meg, ne a technikai megoldást

Azt írd le, mit kell elérned, ne azt, hogyan kell a rendszernek technikailag megvalósítania. A túlzottan előíró követelmények jó megoldásokat zárnak ki rossz okokból. Hagyj teret a szállítóknak, hogy megmutassák: van jobb út, mint amit te elképzeltél – mert néha valóban van.

Egy 30 soros, őszinte, prioritizált lista többet mond el, mint egy 150 soros táblázat, ahol minden kritikus, és minden szállító minden négyzetet kipipált.

Kiindulási TMS-követelménylista, amelyet adaptálhatsz

A legtöbb első alkalommal vásárló szeretne egy előre összeállított listát, ezért itt van egy példakészlet a saját tapasztalataink alapján, már kategorizálva, amelyet a saját működésedhez igazíthatsz. A teljes lista letölthető az alábbi pontozási lapon – ez elegendő ahhoz, hogy lásd a struktúrát.

Töltsd le a funkcionális követelmények pontozási lapját, amely már tartalmazza a prioritásokat és egy lefedettségi oszlopot szállítónként:

Funkcionális követelmények pontozási lapjának letöltése (.docx)

Hogyan hasonlítsuk össze a TMS költségét (és hogyan építsünk hároméves modellt)?

„Mennyibe kerül egy TMS?" – ez az a kérdés, amelyre a vásárlók a leginkább választ szeretnének, a szállítók pedig a legszívesebben kerülik. De az előfizetési díj ritkán az egyetlen és végleges költség. Egy közepes méretű, több telephelyes vállalatnál a bevezetés és az integráció akár jobban is meghatározhatja a hároméves összköltséget, mint a havi díj – és ez az a sor, amelyről a szállítók a leghomályosabban fogalmaznak. A feladat tehát az, hogy úgy tedd fel a kérdést, hogy az összehasonlítható válaszok érkezzenek vissza, és a valós költség láthatóvá váljon.

Tájékozódási pontként: a középpiaci felhőalapú TMS általában néhány száztól néhány ezer euróig terjed havonta, míg a hagyományos vállalati rendszerek évi tízezer eurótól egymillió euró fölé is nyúlhatnak, olyan bevezetési költségekkel, amelyek hat-hét számjegyűek is lehetnek. Ez széles skála – pontosan ezért fontosabb egy összehasonlítható modell, mint bármely egyedi szám. A valós TMS-szállítói árakról lásd a vezető TMS-szállítókról szóló kutatásunkat.

A TMS árazásának összetevői

Szinte minden TMS-árajánlat az alábbiak valamilyen kombinációja:

Építs hároméves költségmodellt, mielőtt összehasonlítasz

Az a TMS-szállító, aki olcsónak tűnik az előfizetésen, a bevezetés, a tranzakciós díjak és a fuvarozói onboarding után a legdrágábbnak bizonyulhat. Futtass minden szállítót ugyanazon a modellen keresztül:

Hároméves költség = bevezetés + (éves előfizetés × 3) + (küldeményenkénti díj × éves forgalom × 3) + támogatás + várható fuvarozói és integrációs kiegészítők.

Használd a valós forgalmi adataidat, ne a szállító szép kerek példáját. Ez az egy táblázat általában átrendezi a rövidlistát.

Figyelj az összes árazási összetevőre, ne csak az alapdíjra

Egyes szállítók alacsony előfizetési díjat kínálnak, és tranzakciós díjakon vagy fuvarozónkénti tételeken hozzák be a különbséget. Ez önmagában nem feltétlenül rossz, de megváltoztatja, ki a legolcsóbb, ahogy növekszel. Ha a forgalmad emelkedik, egy küldeményenkénti modell gyorsan megelőzhet egy átalánydíjasat. Kérj mintaszámlát és az előfizetési feltételeket, hogy azt hasonlítsd össze, amit valójában fizetnél – ne egy fejlécdíjat.

Érdemes minden szállítónak feltenni a következő kérdést: az új fuvarozói integrációk benne vannak az árban, vagy minden alkalommal külön számláznak? Egyes TMS-platformok 5 000–10 000 eurót számítanak fel új fuvarozói integrációnként, és hónapokig tart, mások külön díj nélkül fejlesztenek új fuvarozói integrációkat. Egy közepes méretű vállalatnál, amely az évek során fuvarozókat ad hozzá, ez az egyetlen válasz jobban befolyásolhatja a hároméves összeget, mint az előfizetési sor valaha is.

Hogyan értékeljük a TMS-ajánlatokat az áron túl?

Az ajánlatok megérkeztek. Mind ésszerűnek tűnik, a legtöbb igennel válaszol a követelményeidre, és az árazás hasonló tartományban mozog. Mi következik?

Ilyenkor a csapatok csendben visszaesnek az ár alapján való döntésre, mert minden más nehezebben összehasonlíthatónak tűnik. Ne tedd ezt. Íme, ami valójában megkülönbözteti őket.

1. Fuvarozói kapcsolódás.

TMS esetén a fuvarozói kapcsolódás az alap. Hogyan csatlakozik valójában a szállító a fuvarozókhoz – közvetlen API/EDI-integráción, harmadik feles aggregátorokon keresztül, vagy egyáltalán nem (e-mail + PDF megrendelések, az IT-képességektől függetlenül)? Mi történik, ha olyan fuvarozóra van szükséged, amelyet még nem támogatnak – mennyi ideig tart, és mennyibe kerül?

Az a szállító, akinek mély, közvetlen fuvarozói kapcsolódása van, egészen más kategória, mint az, aki mindent egy közvetítő rétegen keresztül irányít. A különbséget a foglalás megbízhatóságában, a nyomon követés minőségében és abban érzed, hogy tudsz-e fuvarozót hozzáadni anélkül, hogy minden alkalommal új kereskedelmi tárgyalást kellene nyitnod.

2. Fuvarozói szolgáltatási szintek harmonizálása – ez fontosabb, mint a legtöbben gondolják.

A fuvarozók digitális képességei nem egyformák. Egyeseknek kifinomult API-juk van, amely lefedi a valós idejű árazást, az ETA-előrejelzést, a cím-ellenőrzést, a kaubaetikett-generálást és a részletes nyomon követési eseményeket. Mások e-mailben küldik a foglalási visszaigazolást – és ennyi. A legtöbb fuvarozói hálózatban egyszerre van jelen mindkét típus.

Ez a te problémáddá válik, amint az ERP-det vagy WMS-edet csatlakoztatod a TMS-hez. Ha az integrációd minden fuvarozótól teljes adatkészletet vár vissza – foglalási visszaigazolás, nyomon követési link, kaubaetikett, költségbecslés –, de egyes fuvarozók ezt nem tudják biztosítani, kivételek, manuális kerülő megoldások és adathézagok keletkeznek. Egyetlen gyenge fuvarozó megtöri az egész munkafolyamat konzisztenciáját.

A különböző szállításkezelő szoftverek két módon kezelik ezt – érdemes eldönteni, melyiket szeretnéd, mielőtt egyetlen ajánlatot is elolvasol:

• A vékonyabb TMS átadja, amit az egyes fuvarozók biztosítanak, és a hézagokat az ERP-dben vagy manuálisan kell kezelned. Egyszerűbb integráció, de több kivételt kell kezelned a te oldaladról.
• Az adatokat normalizáló és a hézagokat maga kitöltő TMS: kiszámítja a fuvardíjat a feltöltött fuvardíj-táblázatból, ha nincs árazási API; megbecsüli a szállítási időt, ha a fuvarozó nem ad ETA-t; kaubaetiketteket generál, ha a fuvarozó nem tudja; ha nincs nyomon követés, lehetővé teszi a fuvarozóknak, hogy manuálisan rögzítsék a nyomon követési mérföldköveket – és még sok más. A szoftver pótolja a fuvarozók technikai hiányosságait, és az ERP egységes struktúrát lát.

Az ajánlatok értékelésekor kérdezd meg közvetlenül a szállítókat: hogyan kezelik a korlátozott digitális képességekkel rendelkező fuvarozókat? A válasz sokat elárul a platform valódi érettségéről.

3. Integrációs őszinteség.

Figyelj oda arra, hogyan írják le a szállítók az integráció hatókörét (ki mit csinál). Az az ajánlat, amely egyértelműen kimondja: „az ERP-oldali fejlesztés a te feladatod, mi ezt és ezt biztosítjuk, és így támogatjuk" – megbízhatóbb, mint amelyik „zökkenőmentes integrációt" ígér anélkül, hogy elmagyarázná, melyik fél melyik részt kezeli. Az integrációs meglepetések az egyik leggyakoribb oka annak, hogy a TMS-projektek túllépik az időt és a büdzsét.

4. Bevezetési megközelítés.

A fázisolt megközelítés – először manuális operatív validálás, aztán automatizálás – általában kisebb kockázatú, mint az egyszeri nagy bevezetés. Megerősítheted, hogy a rendszer valóban működik a valós munkafolyamataidban, mielőtt az egész működésedet rá támaszkodtatod. A mi tapasztalatunk szerint azok a szállítók, akik ezt felkérés nélkül javasolják, általában már átestek egy kaotikus élesindításon. Akik az első naptól teljes automatizálást ígérnek, sokszor nem.

5. Referenciák

Kérj referenciákat hasonló működésű cégektől – nem csupán hasonló méretű vagy létszámú vállalatoktól. Egy egytelepes forgalmazó referenciája nem különösebben hasznos, ha te több telephelyes gyártóüzemet vezetsz SAP-integrációval. És tedd fel a konkrét kérdéseket: „Hogyan ment a fuvarozói onboarding?" „Hogyan zajlott az integrációs folyamat?" „Mi történt, amikor valami nem úgy működött, ahogy kellett volna?"

6. Maga az ajánlat.

Ahogyan egy TMS-szállító válaszol az RFP-dre, előrevetíti, hogyan fog viselkedni partnerként. Közvetlenül válaszoltak a kérdéseidre, vagy mindent fenntartásokba csomagoltak? Őszintén jelezték a hiányosságokat, vagy minden követelményre teljes lefedettséget állítottak? Megmutatták, hogy megértették a működésedet, vagy a standard prezentációjuk enyhén módosított változatát küldték el?

Az az ajánlat, amely két helyen nem támogatott-ot ír, és megmagyarázza, miért, többet ér, mint amelyik mindenre igent mond. Az igazságot úgyis megtudod. Jobb az értékelés során, mint az élesindításkor.

Töltsd le a szállítói értékelési mátrixot a szállítók súlyozott szempontok szerinti pontozásához:

Szállítói értékelési mátrix letöltése (.docx)

A TMS-szállítói prezentációs kör

Az írásos ajánlatok azt mondják el, mit állít egy szállító. A prezentációk megmutatják, képes-e ezt alátámasztani.

Ezen a ponton már 2-3 szállítóból álló rövidlistával kell rendelkezned. A prezentációs kör célja, hogy valódi nyomás alá helyezd az ajánlatot, és megnézd, működik-e a rendszer a te tényleges forgatókönyveidre.

Kérj élő bemutatót, ne demót

A demó egy begyakorolt sorrend, amely a rendszert a legjobb oldaláról mutatja be. A bemutató az, amikor te mondod: „Mutasd meg, hogyan kezelnéd ezt a küldeményt, a hollandiai raktárunkból, a mi fuvarozónkkal, a mi megállapodott díjunkon" – és figyeled, mi történik valójában.

Készíts elő 2-3 valós forgatókönyvet a saját működésedből a találkozó előtt: egy szokásos kimenő foglalást, egy azonnali árajánlatot igénylő küldeményt, és valami bonyolultabbat – például egy késedelmes küldeményt vagy egy fuvarozót, amely nem biztosít nyomon követést. Ha a szállító folyamatosan visszatér a csiszolt demójához ahelyett, hogy lefuttatná a te forgatókönyvedet, az önmagában is válasz.

Kérdőjelezd meg a hiányosságokat

Minden TMS-ajánlatban vannak ilyenek. Menj egyenesen azokhoz a pontokhoz, ahol a szállító részleges választ adott, vagy ahol kétségeid vannak – és maradj ott. Ne hagyd, hogy visszacsússzon valami, ami tökéletesen működik. Pontosan hogyan működik ez? Ki mit csinál? Mi történik, ha nem úgy működik, ahogy kellene?

Hozd be a megfelelő embereket

A TMS-szállító oldaláról azoknak kell prezentálniuk, akik valójában dolgozni fognak a bevezetéseden – ne csak az értékesítési csapatnak. Kérd ezt kifejezetten. A te oldaladról hozz valakit az IT-ból (ha az integráció a hatókörben van), és legalább egy olyan személyt, aki naponta fogja használni a rendszert. Ők más kérdéseket tesznek fel, mint a beszerző – és mindkét kérdéssorra szükséged van.

Második kör, csak ha szükséges

Összetett döntésnél megéri az idő egy második munkamenet, amely konkrét témákra fókuszál. Példák a lehetséges témákra:

• Biztonság és adatvédelem – kérj penetrációs tesztelési jelentést vagy biztonsági dokumentációt, ha az IT- vagy információbiztonsági csapatod megköveteli
• Integrációs architektúra – technikai munkamenet az IT-csapatod és a szállító között
• Kereskedelmi feltételek – menj végig a szerződésen, a SOW-on és a feltételezéseken soronként, mielőtt formális tárgyalásba kezdesz

Ne ütemezd be csak azért, hogy az első találkozót megismételd több emberrel a szobában. Vagy konkrét nyitott kérdéseket old meg, vagy nem érdemes megtartani.

Erősítsd meg az ígéreteket írásban

Bármit, amit a szállító a találkozón vállal, de az írásos ajánlatban nem szerepel, erősíttesd meg írásban, mielőtt továbblépnél. A szóbeli ígéretek nem élik túl a szerződéses tárgyalásokat. Ha a TMS-szállító valami fontosra azt mondja: „igen, meg tudjuk csinálni", még aznap küldj egy e-mailt, és kérd meg, hogy erősítse meg.

TMS-szerződés és SOW (munkavégzési megállapodás): mit ellenőrizz aláírás előtt?

Megvan a szállítód. A legtöbb csapat ezen a ponton „fellélegzik". Én azt javaslom, ne tedd – mert itt válnak csendesen a te problémáddá azok a részletek, amelyeket mindenki átsiklott az értékelés során.

Egyezz meg belső szinten, mielőtt tárgyalni kezdesz

Tudd, mik a kötelező elvárásaid, miben tudsz kompromisszumot kötni, és hol van a határod, mielőtt a tárgyalás elkezdődik. A követelmények megváltoztatása tárgyalás közben időt vesz el, bizalmat éget el, és néha elveszíted azt a TMS-szállítót, akit valójában akartál. Rendezd belső szinten, aztán tárgyalj.

Értsd meg, mit veszel: SaaS-t, nem licencet

A modern TMS-platformok SaaS-előfizetések, nem szoftverlicencek. Egy olyan szolgáltatásra fizetsz elő, amelyet a szállító üzemeltet, karbantart és frissít – nem vásárolsz meg egy rendszert. Ez megváltoztatja, minek kell szerepelnie a szerződésben: előfizetési feltételek, felmondás, adattulajdon és exportjogok, üzemidő-vállalások, támogatási válaszidők. A szabványos közbeszerzési sablonokat nem erre a modellre írták, ezért győződj meg arról, hogy a tiéd naprakész.

A SOW ugyanolyan fontos, mint a szerződés

A munkavégzési megállapodás pontosan meghatározza, mi kerül átadásra, ki által és mikor: fiókbeállítás, fuvarozói onboarding, integrációs támogatás, képzés és az elfogadási kritériumok, amelyek alapján a bevezetés ténylegesen befejezettnek minősül. Ha nincs benne a SOW-ban, nem tartozik bele – függetlenül attól, mi hangzott el egy találkozón vagy egy e-mailben. Különösen figyelmesen olvasd el a feltételezések részt. Ott van feltételesen meghatározva a hatókör. Ha a fuvarozói listád nagyobbnak bizonyul a megadottnál, vagy az ERP-d nem szabványos integrációs formátumot igényel, a feltételezések rész dönti el, hogy ez egy gyors egyeztetés vagy egy fizetős változtatási kérelem lesz.

Légy explicit azzal kapcsolatban, mi nem tartozik a hatókörbe

Egyedi fejlesztés, helyszíni képzés, adatmigráció, a te rendszereiden végzett integrációs munka, fuvarozói oldali változtatások. Ezeket általában külön áraznak. Ha ezt papíron rögzíted az aláírás előtt, elkerülöd a bevezetési súrlódások leggyakoribb és leginkább elkerülhető forrását: azt, hogy mindkét fél mást feltételezett a hatókörről.

Egyeztesd az onboarding-tervet az aláírás előtt

Nem utána. Fuvarozói prioritizálás, konfigurációs ütemterv, integrációs mérföldkövek, élesindítási kritériumok – mindezt rendezd, amíg még van alkupozíciód. Az a szállító, aki a szerződéskötési szakaszban nem tud egyértelmű onboarding-tervet adni, olyasmit árul el, amit az elköteleződés előtt érdemes tudni.

Az aláírás után: TMS-bevezetés és onboarding

A valódi kockázat nagy része az aláírás után él. Három dolog dönti el, hogyan alakul.

1. Adatmigráció

Fuvarozói szerződések, árlisták, címjegyzékek, korábbi küldemények. Döntsd el korán, mit kell átmigrálni, mit kell előbb megtisztítani, és ki végzi a munkát. A rendezetlen forrásadatok a leggyakoribb oka annak, hogy az élesindítási dátum egyre csúszik. Tisztítsd meg az adatokat a migráció előtt, ne közben.

2. Fuvarozói onboarding sorrendje

Nem csatlakoztatod az összes fuvarozót az első napon. Prioritizálj forgalom és kritikusság szerint, állítsd élőbe és validáld a legfontosabbakat, majd terjeszkedj onnan. Pontosan itt kamatoztatja a befektetett energiát az a fázisolt megközelítés, amelyről az értékelés során kérdeztél.

3. Felhasználói elfogadás

Azoknak az embereknek, akik naponta foglalnak küldeményeket, akarniuk kell az új rendszert használni. Vond be legalább egyiküket már az RFP-szakasztól kezdve, képezd ki őket megfelelően a hypercare (onboarding) időszakban, és győződj meg arról, hogy a napi munkafolyamat valóban gyorsabb, mint amit korábban csináltak. Egy technikailag hibátlan bevezetés, amelyet a csapat egyszerűen nem használ, még mindig sikertelen bevezetés.

10 gyakori TMS RFP-hiba

A leggyakrabban látott minták, egy helyen összegyűjtve:

• Nincs operatív háttérinformáció. A legnagyobb hiba. Nem adnak meg forgalmi adatokat, telephelystruktúrát, fuvarozói környezetet a szállítóknak. Pontosítási kör és általános árazás garantált.
• Minden kötelező. Ha minden követelmény kritikus, a prioritásoszlop értelmetlen, és nem lehet megkülönböztetni a valódi dealbreakert a „hasznos lenne"-tól.
• Homályos ütemterv. Dátumok nélkül a szállítók nem tudják megbecsülni az erőforrásigényt – az ajánlatok ugyanolyan homályosak lesznek.
• A „hogyan" túlspecifikálása. A technikai megvalósítás előírása az operatív eredmény helyett rossz okokból zárja ki a jó megoldásokat.
• Az ERP/TMS határ figyelmen kívül hagyása. Feltételezik, hogy a TMS kezeli azokat a pénzügyi folyamatokat, amelyeket valójában az ERP kezel – és ezt a bevezetés közepén veszik észre.
• Ár alapján dönteni. Az előfizetési fejlécdíj alapján választani hároméves modell nélkül, vagy a fuvarozói kapcsolódás és az integrációs őszinteség mérlegelése nélkül.
• Demó a bemutató helyett. A szállító csiszolt szekvenciáját nézni ahelyett, hogy a rendszert a valós forgatókönyveidre tesztelnéd.
• Nem illő referenciák. A lenyűgöző logókra nézni, miközben ezek a cégek teljesen más logisztikai működéssel rendelkezhetnek. Kérj a tiédhez hasonló referenciákat, majd kérdezd meg, hogyan ment az onboarding és az integráció.
• Az onboarding az aláírás utánra marad. Az alkupozícióval tárgyalt terv jobb, mint az alkupozíció nélkül tárgyalt.
• A folyamat túl nehéz a megfelelő szállítónak. A bürokratikus teher kiszűrheti azokat a modern platformokat, amelyek valójában a legjobban kiszolgáltak volna.

Ingyenes TMS RFP-sablonok

Öt sablont készítettünk azokból az RFP-kből, amelyekre válaszolunk – hogy ne kelljen üres lapból indulnod:

1. RFP-dokumentumsablon. Az útmutató teljes struktúrája.
2. Funkcionális követelmények pontozási lapja. Prioritizálva, szállítónkénti lefedettségi oszloppal.
3. Operatív információs ellenőrzőlista. A tíz kérdés kitölthető táblázatként.
4. Szállítói értékelési mátrix. Súlyozott pontozás szállítónként.
5. RFP-ütemterv sablon. Tevékenységek, dátumok, felelősök.

Töltsd le a csomagot – mind az öt, ingyenesen, e-mail-cím megadása nélkül. Vedd, ami hasznos, hagyd el a többit:

A teljes TMS RFP-sabloncsomag letöltése (.zip)

A Cargoson egy szállításkezelő rendszer, amelyet közepes méretű gyártók és nagykereskedők használnak Európa-szerte és Észak-Amerikában. Rendszeresen válaszolunk olyan RFP-kre, mint amilyet te is hamarosan megírsz – ha inkább átbeszélnéd a követelményeidet, mielőtt belevágsz, szívesen segítünk átgondolni, kötelezettség nélkül.

Foglalj ingyenes 30 perces konzultációt itt

Futtasd jól a folyamatot, és minden befektetett óra megéri majd.