Kako napisati RFP za TMS: naše iskustvo [+ 5 besplatnih predložaka]

Svaki tjedan odgovaramo na RFP-ove (zahtjeve za ponudu) za sustav za upravljanje prijevozom. Neki su pravi užitak za obradu. Drugi su lekcija o tome što ne treba raditi.

Ovaj je članak ono što bih izgradio da danas od nule vodim proces odabira TMS-a. Temelji se na RFP-ovima na koje smo odgovarali, obrascima koji se ponavljaju u različitim tvrtkama i industrijama, onome što većina njih uključuje i kojim pogreškama smo najčešće svjedočili.

Ako ste specijalist za nabavu, veći dio ovoga će vam biti poznat. Nadamo se da će vam barem nešto od toga uštedjeti jedan nepotreban krug pojašnjenja.

Što je RFP za TMS?

RFP za TMS (zahtjev za ponudu) strukturirani je dokument koji šaljete dobavljačima softvera za upravljanje prijevozom. Opisuje vašu logističku operaciju i traži od svakog dobavljača da predloži kako bi njihov sustav to riješio — na temelju istog skupa zahtjeva. Cijela poanta je usporedivost. Ista pitanja, isti format, isti kontekst, kako bi ono što dobijete natrag moglo biti postavljeno jedno uz drugo umjesto da se čita kao pet zasebnih prodajnih prezentacija.

RFP nije uvijek potreban. Isplati se kada je odluka složena ili kada ćete je morati interno obrazložiti. Ako su vaše logističke operacije jednostavne, demonstracija softvera uz razgovor s nekoliko dobavljača sasvim je dovoljna.

Trebate li zaista provoditi natječaj za TMS putem RFP-a?

Pogrešna procjena ovdje najskuplja je pogreška u cijelom procesu odabira TMS-a. Odlučite o tome prije svega ostalog.

Sve se svodi na to koliko su vaše logističke operacije složene — ne na veličinu vaše tvrtke.

Provedite strukturirani RFP za TMS ako šaljete pošiljke s više lokacija, koristite više načina prijevoza i trebate da se sustav poveže s vašim ERP-om. Tada trebate sve dobavljače postavljene jednog uz drugog kako ništa važno ne bi promaklo. Dobavljači se na sasvim različite načine povezuju s prijevoznicima. Jedan to naziva „nativnim", drugi to tiho preusmjerava kroz nekoga drugog. U labavom procesu to nećete primijetiti sve dok ne potpišete ugovor. A tada je prekasno.

Preskočite formalni RFP ako upravljate jednom lokacijom s nekoliko prijevoznika i već znate što trebate. Zašto? Jer čim pokrenete RFP, automatski ste se svrstali u razred korporativnih cijena. 2–3 dobre demonstracije softvera s ciljanim pitanjima često vam donose bolji sustav, jeftinije i brže. Recite tim 2–3 dobavljačima što šaljete i koji problem rješavate, a zatim ih zamolite da vam to pokažu u svom stvarnom sustavu. Znat ćete unutar sat vremena. A ako uglavnom šaljete pakete umjesto paleta ili tereta, možda vam uopće ne treba puni TMS — softver za otpremu s više prijevoznika zasebna je, lakša kategorija namijenjena upravo tome.

Dakle, budite iskreni prema sebi o tome što preferirate prije nego što krenete. Pokretanje RFP-a koji vam nije bio potreban najsporiji je i najskuplji način kupnje TMS-a.

Pokretanje RFP-a koji vam nije bio potreban najsporiji je i najskuplji način kupnje TMS-a.

Još jedno upozorenje ako se ipak odlučite za potpuni RFP. Proces prepun upravljačkog jezika, metodoloških okvira i zahtjeva za fiksnom cijenom tjednima oduzima vrijeme za odgovor, a dobavljači koji mogu podnijeti taj teret obično su veliki, etablirani igrači. Ako bi vam zapravo bolje poslužila modernija i agilnija platforma, pretjerano birokratski proces može je tiho eliminirati prije nego što ikad vidite demonstraciju.

Cilj je pronaći pravo rješenje za vas. Osmislite proces oko toga, a ne oko upravljanja samim procesom.

RFP proces za TMS u 9 koraka

Odabir TMS-a ne mora biti kompliciran. Ali mora imati jasan redoslijed. Preskočite korake i platit ćete za to kasnije — obično tijekom implementacije, kada pretpostavke koje su trebale biti razjašnjene rano postanu skupi iznenađenja.

Dobro vođen proces traje 8 do 12 tjedana. Manje za jednostavan opseg, a rijetko treba više.

Evo redoslijeda koji funkcionira:

1. Pregled tržišta. Prije nego što napišete i jedan zahtjev, posvetite vrijeme razumijevanju što postoji na tržištu. Tržište TMS-a znatno se promijenilo u posljednjih pet godina: postoje dobre korporativne platforme, dobre platforme za srednje tržište i zaista sposobna moderna SaaS rješenja za upravljanje prijevozom koja prije pet godina nisu postojala. Sastavite dugačak popis od 5–8 dobavljača TMS-a vrijednih razmatranja.
2. NDA. Pošaljite ga rano. Dijelit ćete operativne podatke poput volumena, naziva prijevoznika i internih detalja sustava, a potpisani NDA prije slanja RFP-a standardna je praksa koja štiti obje strane.
3. RFI (neobavezno). Kratki zahtjev za informacije ima smisla ako je vaš dugački popis širok i želite filtrirati prije nego što uložite u potpuni RFP proces. Ograničite ga na jednu stranicu: pozadina tvrtke, ključne mogućnosti, okvirni raspon cijena. Dovoljno za sužavanje popisa bez traženja od dobavljača da pišu eseje.
4. RFP. Temeljni dokument. Svakom dobavljaču daje sve što mu je potrebno za preciznu ponudu. Više o tome u sljedećem poglavlju.
5. Prozor za pitanja i odgovore. Uvijek ga uključite. Dobavljači će imati pitanja, a odgovori često poboljšavaju svaku ponudu koju primite. Provedite ga pisanim putem i svim dobavljačima istovremeno podijelite sva pitanja i odgovore. To čuva proces čistim i usporedivim.
6. Uži popis i prezentacije. Ocijenite pisane ponude, a zatim pozovite 2–3 dobavljača na prezentaciju. Prezentacija treba uključivati demonstraciju živog sustava temeljenu na vašim stvarnim slučajevima korištenja, a ne generičku demonstraciju. Ako vam dobavljač ne može pokazati vaš scenarij u svom sustavu, to je sama po sebi korisna informacija.
7. Drugi krug (ako je potrebno). Za složenu odluku, dublja sesija usmjerena na specifične nedostatke — poput sigurnosti, integracije ili komercijalnih uvjeta — vrijedi uloženog vremena. Ne zakazujte je ako nemate stvarnih otvorenih pitanja.
8. Odluka i ugovor. Uskladite se interno prije nego što počnete pregovarati. Znajte što su vam apsolutni uvjeti, prihvatljivi kompromisi i granica ispod koje nećete ići.
9. Uvođenje sustava. Proces ne završava potpisom. Najbolji ishodi RFP-a imaju plan uvođenja dogovoren prije potpisivanja ugovora.

Vremenski plan RFP-a koji možete kopirati

Okvirno trajanje prema opsegu:

• Jedna jednostavna lokacija: 6 do 8 tjedana (možda uopće ne zahtijeva formalni RFP).
• Više lokacija + integracija s ERP-om: 8 do 12 tjedana.
• Globalna implementacija s više pravnih subjekata i složenim integracijama: 12 do 20 tjedana, vjerojatno s dva kruga prezentacija.

Preuzmite predložak vremenskog plana RFP-a (.docx)

Što uključiti u RFP dokument za TMS

RFP dokument vaš je najvažniji alat u ovom procesu. Dobar RFP dokument obavlja veći dio posla vrednovanja umjesto vas, pa ga držite fokusiranim. Sažet RFP od 10 stranica bolji je od onog od 30 stranica koji pokušava pokriti sve.

1. Popratno pismo i cilj

Jedna stranica. Tko ste, što tražite, zašto sada. Budite stvarni. Dobavljačima ne treba vizijska izjava — trebaju razumjeti vaš operativni problem.

2. Vremenski plan

Jasan raspored s konkretnim datumima: slanje RFP-a, rok za pitanja i odgovore, predaja ponuda, prozor za prezentacije, odluka. Dobavljači planiraju napor odgovora prema tome. Nejasni vremenski planovi donose nejasne ponude.

3. Pozadina tvrtke i operativni podaci

Tu većina RFP-ova zakazuje — a upravo to je razlika između usporedivih ponuda i kruga pojašnjenja. Ne opisujte samo svoje poslovanje, nego opišite svoju logističku operaciju. Koliko lokacija. Koliko pravnih subjekata. Koji načini prijevoza (paketi, LTL, FTL, zrak, more, željeznica). Koje regije. Okvirni volumeni. Trenutni sustavi. Ono što se smatra „dobrim" razlikuje se i po sektoru — zahtjevi za proizvođače elektronike, strojeva, kemikalija ili tiskare i ambalaže nisu isti. To je kontekst koji dobavljačima treba za precizno definiranje opsega ponude. Ako ovdje ne pružite dovoljno detalja, provest ćete dva tjedna odgovarajući na pitanja za pojašnjenje koja su se mogla u potpunosti izbjeći. Ovome je posvećeno zasebno poglavlje u nastavku.

4. Funkcionalni zahtjevi

Tablica što sustav treba raditi, prioritizirana po važnosti: obavezno / poželjno / dobrodošlo (Excel je sasvim dobar). Zamolite dobavljače da na svaki zahtjev odgovore razinom pokrivenosti: a) nativno, b) putem treće strane, c) prilagodbom ili d) nije podržano. To je ono što ponude čini usporedivima. Više o tome kako sastaviti ovaj popis u nastavku.

5. Kriteriji vrednovanja

Recite dobavljačima kako ćete donijeti odluku: funkcionalnost, cijena, pristup implementaciji, reference, sigurnost, tim. Podijelite pondere ako ste voljni. Što ste transparentniji, to su ponude bolje.

6. Model cijene

Zatražite potpuni pregled: pretplata, implementacija, naknade po transakciji, podrška i sve ostalo. Ako je moguće, zatražite primjer računa. Strukture cijena znatno se razlikuju između dobavljača, a skriveni troškovi imaju naviku pojavljivati se kasno. Pokušajte ih otkriti što ranije.

7. Format odgovora

Recite dobavljačima točno kako želite da bude strukturirana ponuda, a ako im dajete predloške, zahtijevajte njihovu upotrebu. Usporedive ponude štede vam dane tijekom vrednovanja, a format je u potpunosti u vašim rukama.

Preuzmite predložak RFP dokumenta i krenite od potpune strukture opisane gore:

Preuzmite predložak RFP dokumenta (.docx)

Operativni podaci koje većina RFP-ova za TMS izostavlja — i zašto su najvažniji

Ovo je poglavlje koje bih volio da svaki autor RFP-a za TMS pročita prvi.

Odgovaramo na mnogo natječaja za prijevoz. Gotovo svaka ponuda koju napišemo zahtijeva krug pojašnjenja — i to rijetko zato što zahtjevi nisu bili jasni. Razlog je što operativni kontekst nije bio prisutan: volumeni, struktura lokacija, mreža prijevoznika, trenutni sustavi.

RFP-ovi koji su zahtijevali potpuni krug pojašnjenja gotovo uvijek imaju jednu zajedničku stvar:

Vidjeli smo tvrtke koje tjednima pažljivo izrađuju kriterije vrednovanja i popise zahtjeva, a zatim pošalju RFP koji ne spominje koliko pošiljaka obrađuju mjesečno.

Bez toga dobavljači nagađaju. A kada nagađaju, ponude se vraćaju generičke, cijene nisu konačne i nema ničega konkretnog za usporedbu.

Na primjer, globalnom proizvođaču s 10 skladišta i SAP-om potrebna je potpuno drugačija ponuda nego distributeru s jednom lokacijom koji logistiku vodi u tablicama. Ako dobavljač ne može zaključiti koji ste od ta dva, zaštitit će se — i dobivate ponude koje se ni na što ne obvezuju.

Rješenje oduzima jedno poslijepodne. Odgovorite na ovih deset pitanja u RFP-u prije nego što ga pošaljete.

1. Organizacija i opseg. Koliko pravnih subjekata i lokacija je u opsegu? Je li uvođenje paralelno ili fazno? Koliko neovisno djeluju lokacije — zasebni ugovori s prijevoznicima, zasebni timovi?
2. Volumeni pošiljaka. Mjesečni i dnevni broj pošiljaka po lokaciji, prosjek i vršno opterećenje. Sezonalnost. Omjer ulaznih i izlaznih pošiljaka.
3. Raspodjela po načinima prijevoza. Koji udio čine paketi, LTL, FTL, zrak, more? Koji načini rastu? Koji su operativno najkritičniji?
4. Mreža prijevoznika. Koliko prijevoznika po lokaciji i po načinu prijevoza? Dijele li se između lokacija ili se njima upravlja lokalno? Postoje li strateški prijevoznici kojima treba dati prednost ili prijevoznici koje je odredio kupac i koje ne možete mijenjati?
5. Geografija i prometni pravci. Koje su regije u opsegu? Koji su pravci najvažniji: domaći, prekogranični, interkontinentalni? Ključne luke ili logistički čvorovi?
6. Trenutno stanje. Kako se danas planiraju, naručuju i prate pošiljke? U ERP-u, tablicama, portalima prijevoznika, e-poštom? Koji su glavni problemi u trenutnom procesu?
7. Financijska struktura. Tko plaća prijevoz — jedan subjekt ili više njih? Postoje li brojevi računa trećih strana ili kupaca? Kako se danas bilježe i provjeravaju troškovi prijevoza?
8. Poslovni model. B2B, B2C? Ako je mješovito, koji je omjer. Operativni i sistemski zahtjevi znatno se razlikuju.
9. Integracijski krajolik. Koji sustavi trebaju biti povezani s TMS-om: ERP, WMS, CRM? Postoje li postojeće integracije prijevoznika koje treba zadržati? Kolika razina automatizacije je potrebna od prvog dana?
10. Vremenski okvir i ograničenja. Postoji li ciljni datum puštanja u rad? Postoje li interni rokovi — kraj financijske godine, vršna sezona, migracije sustava — koji utječu na raspored?

Ništa od ovoga nije teško zapisati. Ali sve mijenja u onome što dobijete natrag.

Preuzmite kontrolni popis operativnih podataka i pretvorite ovih deset pitanja u tablicu za popunjavanje koju možete izravno umetnuti u vaš RFP:

Preuzmite kontrolni popis operativnih podataka (.docx)

Kako pisati funkcionalne zahtjeve za TMS

Funkcionalni zahtjevi srce su RFP-a. Napišite ih dobro i dobit ćete jasnu, usporedivu sliku što svaki dobavljač može i ne može. Napišite ih loše i možete provesti tjedne dešifriranjem odgovora koji svi kažu „da".

Cilj nije najduži popis. Nego najiskreniji.

Prioritizirajte bez milosti: obavezno, poželjno, dobrodošlo

Nije sve što želite jednako važno. Koristite tri kategorije i držite ih se:

1. Obavezno (O): nije pregovorljivo. Dobavljač koji to ne može ispuniti ispada, bez obzira na sve ostalo što nudi.
2. Poželjno (P): važno, ali možete živjeti s privremenim rješenjem ili obećanjem u bliskoj budućnosti.
3. Dobrodošlo (D): dobro je znati, ali dolazi iza svega navedenog gore.

Većina popisa ima previše obaveznih stavki. Ako je sve kritično, ništa nije. Budite iskreni prema sebi o tome što bi zaista spriječilo sustav da funkcionira za vas i označite samo to kao obavezno.

Tražite od dobavljača da klasificiraju pokrivenost funkcionalnosti: nativno / treća strana / prilagodba

Za svaki zahtjev neka odgovore jednom od sljedećih opcija:

Taj stupac je mjesto gdje ponude zaslužuju ili gube vaše povjerenje. Dobavljač koji odgovara iskreno i piše nije podržano tamo gdje je to istina pokazuje vam kako će se ponašati kao partner. Dobavljač koji na sve odgovara nativno također vam govori nešto važno.

Budite konkretni u pitanju

„Podržava li sustav cijene prijevoznika?" donosi vam beskoristan odgovor „da". „Može li sustav izračunati cijenu prijevoza za svakog prijevoznika, uključujući one bez API-ja za cijene, i prikazati ih jedne uz druge po pošiljci?" donosi vam nešto što zaista možete vrednovati.

Gdje završava ERP, a gdje počinje TMS?

Jedan od najčešćih izvora zabune u vrednovanju sustava za upravljanje prijevozom je gdje završava TMS, a gdje počinje ERP.

Financijski procesi poput GL kodiranja, troška slijetanja i provjere teretnih troškova često se obrađuju na strani ERP-a, pri čemu TMS šalje podatke u ERP. To je normalno i često ispravna postavka. Ali mora biti jasno definirano. Kada dobavljač odgovori „obrađuje se putem integracije s ERP-om" na jedan od vaših obaveznih zahtjeva, istražite točno što to znači za vašu implementaciju — i tko to gradi.

Definirajte cilj, ne tehničko rješenje

Opišite što trebate postići, a ne kako bi sustav to tehnički trebao postići. Pretjerano preskriptivni zahtjevi eliminiraju dobra rješenja iz pogrešnih razloga. Ostavite dobavljačima prostor da vam pokažu bolji način od onog koji ste imali na umu — jer ga ponekad imaju.

Popis od 30 iskrenih, prioritiziranih zahtjeva reći će vam više od tablice s 150 redaka gdje je sve kritično i gdje je svaki dobavljač označio svaki okvir.

Početni skup zahtjeva za TMS koji možete prilagoditi

Većina kupaca koji to rade prvi put želi prednost pri sastavljanju popisa, pa evo primjera iz našeg iskustva, već kategoriziranog, koji možete prilagoditi svojoj operaciji. Potpuni popis dostupan je za preuzimanje u tablici bodovanja u nastavku — ovo je dovoljno da vidite njegovu strukturu.

Preuzmite tablicu bodovanja funkcionalnih zahtjeva, već izrađenu s prioritetima i stupcem pokrivenosti po dobavljaču:

Preuzmite tablicu bodovanja funkcionalnih zahtjeva (.docx)

Kako usporediti troškove TMS-a (i izgraditi trogodišnji model)

„Koliko košta TMS?" pitanje je koje kupci najviše žele čuti, a dobavljači ga najradije izbjegavaju. No, naknada za pretplatu rijetko je vaš konačni trošak. Za srednje velikog naručitelja s više lokacija, implementacija i integracija mogu u trogodišnjem ukupnom iznosu nadmašiti čak i mjesečnu naknadu — a upravo o tome dobavljači ostaju najneodređeniji. Vještina je ovdje u strukturiranju pitanja tako da odgovori budu usporedivi i da stvarni trošak bude vidljiv.

Kao okvirna orijentacija, cloud-based TMS za srednje tržište obično se kreće od nekoliko stotina do nekoliko tisuća eura mjesečno, dok tradicionalni korporativni sustavi idu od desetaka tisuća do više od milijun eura godišnje, s implementacijom koja može doseći šest ili sedam znamenki. To je širok raspon, što je upravo razlog zašto usporedivi model vrijedi više od bilo kojeg pojedinačnog broja. Za uvid u to što stvarni dobavljači TMS-a naplaćuju, pogledajte naše istraživanje o vodećim dobavljačima TMS-a.

Komponente cijene TMS-a

Gotovo svaka ponuda za TMS kombinacija je nekih od sljedećih stavki:

Izgradite trogodišnji model troškova prije usporedbe

Dobavljač koji izgleda jeftino na pretplati može se pokazati najskupljim kada se uračunaju implementacija, naknade po transakciji i uvođenje prijevoznika. Svaki dobavljač procijenite kroz isti model:

Trošak za 3 godine = implementacija + (godišnja pretplata × 3) + (naknada po pošiljci × godišnji volumen × 3) + podrška + očekivani dodaci za prijevoznike i integracije.

Koristite svoje stvarne volumene, a ne uredan primjer dobavljača. Ta jedna tablica obično promiješa uži popis.

Pratite različite komponente cijene, ne samo osnovnu naknadu

Neki dobavljači postavljaju nisku pretplatu i nadoknađuju je naknadama po transakciji ili po prijevozniku. To samo po sebi nije loše, ali mijenja tko je najjeftiniji kako rastete. Ako vam volumen raste, model po pošiljci može brzo nadmašiti fiksni. Zatražite primjer računa i uvjete pretplate kako biste uspoređivali ono što ćete stvarno plaćati, a ne oglašenu stopu.

Jedno pitanje vrijedi postaviti svakom dobavljaču: jesu li nove integracije prijevoznika uključene ili se naplaćuju svaki put? Neke TMS platforme naplaćuju 5.000–10.000 € po novoj integraciji prijevoznika i za to trebaju mjesece, dok druge grade nove integracije prijevoznika bez dodatnih troškova. Za srednje velikog naručitelja koji s godinama dodaje prijevoznike, taj jedan odgovor može promijeniti trogodišnji ukupni iznos više nego što to ikad može linija pretplate.

Kako vrednovati ponude za TMS izvan cijene

Ponude su stigle. Sve izgledaju razumno, većina kaže da na vaše zahtjeve, a cijene su u sličnom rasponu. Što sada?

To je točka u kojoj timovi tiho padaju natrag na cijenu, jer sve ostalo izgleda teže za usporedbu. Nemojte. Evo što ih zapravo razlikuje.

1. Povezanost s prijevoznicima.

Za TMS, povezanost s prijevoznicima temelj je svega. Kako se dobavljač zapravo povezuje s prijevoznicima — putem izravnih API/EDI integracija, agregatorima trećih strana ili uopće ne (narudžbe e-poštom i PDF-om bez obzira na IT mogućnosti prijevoznika)? Što se događa kada trebate prijevoznika kojeg još ne podržavaju, koliko to traje i što košta?

Dobavljač s dubokim, izravnim vezama s prijevoznicima sasvim je drugačija stvar od onog koji sve preusmjerava kroz međusloj. Razliku osjećate u pouzdanosti naručivanja, kvaliteti praćenja i tome možete li dodati prijevoznika bez otvaranja novog komercijalnog pregovora svaki put.

2. Usklađivanje razine usluge prijevoznika — ovo je važnije nego što većina ljudi shvaća.

Prijevoznici nisu jednaki u svojim digitalnim mogućnostima. Neki imaju sofisticirane API-je koji pokrivaju cijene u stvarnom vremenu, predviđanje ETA-e, provjeru adrese, generiranje etiketa, detaljne događaje praćenja. Drugi vam šalju potvrdu narudžbe e-poštom i tu razgovor završava. Većina mreža prijevoznika ima obje vrste istovremeno.

To postaje vaš problem čim povežete ERP ili WMS s TMS-om. Ako vaša integracija očekuje potpun skup podataka od svakog prijevoznika — potvrdu narudžbe, link za praćenje, etiketu, procjenu troška — ali neki prijevoznici to ne mogu pružiti, dobivate iznimke, ručne zaobilaznice i rupe u podacima. Jedan slab prijevoznik narušava dosljednost cijelog tijeka rada.

Postoje dva načina na koja različiti softveri za upravljanje prijevozom rješavaju ovo, a vrijedi odlučiti koji želite prije nego što pročitate i jednu ponudu:

• Tanji TMS prosljeđuje sve što svaki prijevoznik pruža — vaš će problem biti rješavanje praznina u ERP-u ili ručnim radom. Jednostavnija integracija, više iznimaka s vaše strane.
• TMS koji normalizira podatke i sam popunjava praznine: izračunava cijenu prijevoza iz vaše učitane cjenika kada nema API-ja za cijene; procjenjuje vrijeme tranzita kada nema ETA-e od prijevoznika; generira etikete za pošiljke kada ih prijevoznik ne može proizvesti; kada nemaju praćenje, omogućuje prijevoznicima ručni unos ključnih točaka praćenja i još mnogo toga. Softver popunjava praznine u tehničkim mogućnostima vaših prijevoznika, a vaš ERP vidi jednu dosljednu strukturu.

Pri vrednovanju ponuda, pitajte dobavljače izravno: kako postupate s prijevoznicima koji imaju ograničene digitalne mogućnosti? Odgovor vam govori mnogo o tome koliko je njihova platforma zapravo zrela.

3. Iskrenost o integraciji.

Obratite veliku pozornost na to kako dobavljači opisuju opseg integracije (tko što radi). Ponuda koja jasno kaže „razvoj na strani ERP-a je na vama, evo što mi pružamo i kako to podržavamo" pouzdanija je od one koja implicira „besprijekornu integraciju" bez objašnjenja koja strana obrađuje koji dio integracije — vi ili oni. Iznenađenja pri integraciji jedan su od najčešćih razloga zašto TMS projekti prekoračuju vrijeme i proračun.

4. Pristup implementaciji.

Fazni pristup — prvo ručna operativna validacija, a zatim automatizacija — obično je manji rizik od pokretanja svega odjednom. Možete potvrditi da sustav funkcionira za vaše stvarne tijekove rada prije nego što na njega oslonite cijelu operaciju. S naše strane stola, dobavljači koji ovo predlažu bez poticaja obično su već prošli kroz kaotično puštanje u rad. Oni koji odmah nude punu automatizaciju od prvog dana često nisu.

5. Reference

Tražite reference od tvrtki sa sličnim operacijama, a ne samo sličnom veličinom ili brojem zaposlenika. Referenca od distributera s jednom lokacijom nije posebno korisna ako vodite višelokacijsku proizvodnu operaciju s integracijom SAP-a. I postavljajte konkretna pitanja: „Kako je teklo uvođenje prijevoznika?" „Kako je tekao proces integracije?" „Što se dogodilo kada nešto nije radilo kako se očekivalo?"

6. Sama ponuda.

Način na koji dobavljač TMS-a odgovara na vaš RFP pregled je toga kako će se ponašati kao vaš partner. Jesu li odgovorili na vaša pitanja izravno ili su sve omotali u ograde? Jesu li iskreno istaknuli nedostatke ili su tvrdili da u potpunosti pokrivaju svaki zahtjev? Jesu li pokazali da razumiju vašu operaciju ili su vam poslali malo modificiranu verziju svoje standardne prezentacije?

Ponuda koja na dva mjesta navodi nije podržano i objašnjava zašto vrijedi više od one koja na sve kaže da. Istinu ćete ionako saznati. Bolje je saznati je tijekom vrednovanja nego pri puštanju u rad.

Preuzmite matricu vrednovanja dobavljača za bodovanje prema ponderiranim kriterijima:

Preuzmite matricu vrednovanja dobavljača (.docx)

Krug prezentacija dobavljača TMS-a

Pisane ponude govore vam što dobavljač tvrdi. Prezentacije govore vam može li to i potvrditi.

U ovoj fazi trebali biste imati uži popis od 2–3 dobavljača. Cilj kruga prezentacija je staviti ponudu pod stvarni pritisak i vidjeti funkcionira li sustav u vašim stvarnim scenarijima.

Tražite demonstraciju uživo, ne standardnu prezentaciju

Standardna prezentacija uvježbana je sekvenca koja prikazuje sustav u najboljem svjetlu. Demonstracija uživo je kada vi kažete „pokažite mi kako biste obradili ovu pošiljku, iz našeg skladišta u Nizozemskoj, s našim prijevoznikom, po našoj dogovorenoj cijeni" — i gledate što se zapravo dogodi.

Pripremite 2–3 stvarna scenarija iz vlastite operacije prije sastanka: standardna izlazna narudžba, pošiljka koja zahtijeva spot ponudu i nešto nezgodno poput odgođene pošiljke ili prijevoznika koji ne pruža praćenje. Kada dobavljač stalno skreće natrag na uglačanu prezentaciju umjesto da provodi vaš scenarij, to je već vaš odgovor.

Izazovite nedostatke

Svaka ponuda za TMS ih ima. Idite ravno na dijelove gdje je dobavljač odgovorio djelomično ili gdje imate sumnje i ostanite tamo. Ne dopustite im da se vrate na ono što funkcionira besprijekorno. Kako točno ovo funkcionira? Tko što radi? Što se događa kada ne funkcionira kako se očekuje?

Dovedite prave ljude u sobu

Na strani dobavljača TMS-a, osobe koje prezentiraju trebale bi biti one koje će zapravo raditi na vašoj implementaciji — ne samo prodajni tim. Izričito to zatražite. Sa svoje strane, dovedite nekoga iz IT-a (ako je integracija u opsegu) i barem jednu osobu koja će sustav koristiti svaki dan. Oni postavljaju drugačija pitanja od nabave, a vi želite oba skupa pitanja.

Drugi krug, samo ako je potrebno

Za složenu odluku, druga sesija usmjerena na specifične teme vrijedi uloženog vremena. Primjeri tema za obradu:

• Sigurnost i zaštita podataka — zatražite izvješće o penetracijskom testiranju ili sigurnosnu dokumentaciju ako to zahtijeva vaš IT ili tim za informacijsku sigurnost
• Integracijska arhitektura — tehnička sesija između vašeg IT tima i tima dobavljača
• Komercijalni uvjeti — prođite kroz ugovor, SOW i pretpostavke redak po redak prije nego što uđete u formalne pregovore

Ne zakazujte je samo da biste ponovili prvi sastanak s više ljudi u sobi. Ili rješava konkretna otvorena pitanja, ili se ne treba održati.

Potvrdite obveze pisanim putem

Sve što dobavljač preuzme kao obvezu na sastanku, a nije u pisanoj ponudi, mora biti potvrđeno pisanim putem prije nego što nastavite. Usmene obveze ne preživljavaju pregovore o ugovoru. Ako dobavljač TMS-a kaže „da, to možemo" za nešto važno, istog dana pošaljite e-poštu i zamolite ga da to potvrdi.

Ugovor i SOW za TMS: što provjeriti prije potpisivanja

Odabrali ste dobavljača. Većina timova u tom trenutku „odahne". Preporučujem da ne odahnete, jer upravo tu detalji koje je svako preskočio tijekom vrednovanja tiho postaju vaš problem.

Uskladite se interno prije pregovora

Znajte što su vam apsolutni uvjeti, prihvatljivi kompromisi i granica ispod koje nećete ići prije nego što razgovor počne. Mijenjanje zahtjeva usred pregovora troši vrijeme, narušava povjerenje i povremeno vam oduzima dobavljača TMS-a kojeg ste zapravo željeli. Riješite to interno, a zatim pregovarajte.

Razumijte što kupujete: SaaS, ne licencu

Moderne TMS platforme su SaaS pretplate, a ne softverske licence. Pretplaćujete se na uslugu koju dobavljač hostira, održava i ažurira — ne kupujete sustav u vlasništvo. To mijenja što ugovor mora pokrivati: uvjeti pretplate, raskid, vlasništvo nad podacima i prava na izvoz, obveze o dostupnosti sustava, vremena odgovora podrške. Standardni predlošci za nabavu nisu pisani za ovaj model, pa provjerite je li vaš u koraku s tim.

SOW je jednako važan kao i ugovor

Izjava o radu (SOW) precizira što se isporučuje, tko to radi i do kada: konfiguracija računa, uvođenje prijevoznika, podrška pri integraciji, obuka i kriteriji prihvaćanja koji potvrđuju da je implementacija zaista završena. Ako nije u SOW-u, nije uključeno — bez obzira na to što je rečeno na sastanku ili u e-pošti. Posebno pažljivo pročitajte odjeljak o pretpostavkama. Tu je opseg uvjetno definiran. Ako se vaš popis prijevoznika pokaže većim od navedenog ili vaš ERP zahtijeva nestandardni format integracije, odjeljak o pretpostavkama odlučuje je li to kratki razgovor ili zahtjev za promjenom s cijenom.

Budite eksplicitni o tome što nije u opsegu

Prilagođeni razvoj, obuka na licu mjesta, migracija podataka, integracijski rad na vašim sustavima, promjene na strani prijevoznika. Ovo se obično posebno naplaćuje. Stavljanje toga na papir prije potpisivanja uklanja najčešći i najizbjegljiviji izvor trenja pri implementaciji: dvije strane koje su svaka pretpostavljale da je nešto drugačije uključeno.

Dogovorite plan uvođenja prije potpisivanja

Ne nakon. Prioritizacija prijevoznika, vremenski plan konfiguracije, ključne točke integracije, kriteriji puštanja u rad — sve to dogovorite dok još imate polugu. Dobavljač koji vam ne može dati jasan plan uvođenja u fazi ugovaranja govori vam nešto što ćete htjeti znati prije nego što se obvežete.

Nakon potpisivanja: implementacija i uvođenje TMS-a

Većina stvarnog rizika živi nakon potpisa. Tri stvari odlučuju kako će to ići.

1. Migracija podataka

Ugovori s prijevoznicima, cjenici, adresari, povijesne pošiljke. Rano odlučite što trebate migrirati, što se prvo čisti i tko je odgovoran za taj posao. Neuredni izvorni podaci najčešći su razlog zašto se datum puštanja u rad pomiče sve dalje. Očistite ih prije migracije, a ne za vrijeme nje.

2. Redoslijed uvođenja prijevoznika

Ne povezujete sve prijevoznike prvog dana. Prioritizirajte prema volumenu i kritičnosti, pustite u rad i validirajte prvih nekoliko, a zatim se širite. Upravo tu fazni pristup koji ste tražili tijekom vrednovanja isplaćuje svoju vrijednost.

3. Prihvaćanje od strane korisnika

Ljudi koji svaki dan naručuju pošiljke moraju htjeti koristiti novi sustav. Uključite barem jednog od njih od faze RFP-a nadalje, pravilno ih obučite tijekom hypercare faze (uvođenja) i pobrinite se da je svakodnevni tijek rada zaista brži od onoga što su radili prije. Tehnički besprijekorno uvođenje koje tim jednostavno ne koristi i dalje je neuspješno uvođenje.

10 čestih pogrešaka u RFP-u za TMS

Obrasci koje najčešće viđamo, sve na jednom mjestu:

• Nema operativnog konteksta. Najveća pogreška. Dobavljačima nisu dostavljeni podaci o volumenima, strukturi lokacija ni mreži prijevoznika. Krug pojašnjenja i generične cijene zajamčeni su.
• Sve je obavezno. Kada je svaki zahtjev kritičan, stupac prioriteta je mrtav teret i ne možete razlikovati uvjet koji je apsolutno neophodan od onoga koji bi bio lijepo imati.
• Nejasan vremenski plan. Bez datuma dobavljači ne mogu procijeniti potreban napor, pa se ponude vraćaju jednako neodređene.
• Pretjerano propisivanje načina. Propisivanje tehničke implementacije umjesto operativnog ishoda eliminira dobra rješenja iz pogrešnih razloga.
• Zanemarivanje granice ERP/TMS. Pretpostavljanje da TMS posjeduje financijske procese koje zapravo posjeduje ERP, a zatim shvaćanje toga usred implementacije.
• Odlučivanje samo na temelju cijene. Odabir prema oglašenoj pretplati bez trogodišnjeg modela ili bez uzimanja u obzir povezanosti s prijevoznicima i iskrenosti o integraciji.
• Standardna prezentacija umjesto demonstracije uživo. Gledanje uglačane sekvence dobavljača umjesto testiranja sustava na vašim stvarnim scenarijima.
• Reference koje ne odgovaraju vašoj operaciji. Gledanje impresivnih logotipa, ali te tvrtke možda imaju logističke operacije koje nimalo ne nalikuju vašima. Tražite reference koje liče na vas, a zatim ih pitajte kako su zaista tekli uvođenje i integracija.
• Ostavljanje uvođenja za nakon potpisivanja. Plan koji pregovarate s polugom bolji je od onog koji pregovarate bez nje.
• Proces pretežak za pravog dobavljača. Birokratski teret koji može eliminirati moderne platforme koje bi vam zapravo najbolje poslužile.

Besplatni predlošci za RFP za TMS

Izgradili smo pet predložaka na temelju RFP-ova na koje odgovaramo, kako ne biste morali krenuti od prazne stranice:

1. Predložak RFP dokumenta. Potpuna struktura iz ovog vodiča.
2. Tablica bodovanja funkcionalnih zahtjeva. Prioritizirana, s stupcem pokrivenosti po dobavljaču.
3. Kontrolni popis operativnih podataka. Deset pitanja kao tablica za popunjavanje.
4. Matrica vrednovanja dobavljača. Ponderirano bodovanje po dobavljačima.
5. Predložak vremenskog plana RFP-a. Aktivnosti, datumi, odgovornosti.

Preuzmite paket — svih pet, besplatno, bez e-pošte. Uzmite što vam je korisno, ostatak zanemarite:

Preuzmite potpuni paket predložaka za RFP za TMS (.zip)

Cargoson je sustav za upravljanje prijevozom koji koriste srednje veliki proizvođači i veletrgovci diljem Europe i Sjeverne Amerike. Svakodnevno odgovaramo na RFP-ove poput onog koji ćete uskoro pisati, pa ako biste radije razgovorali o svojim zahtjevima prije nego što počnete pisati, rado ćemo vam pomoći da to promislite — bez ikakvih obveza.

Zakažite besplatnu konzultaciju od 30 minuta ovdje

Vodite proces dobro i svaki uloženi sat bit će vrijedan truda.