Kako napisati razpis za TMS: naše izkušnje [+ 5 brezplačnih predlog]

Na razpise za sistem za upravljanje prevozov (TMS RFP – Request for Proposal) odgovarjamo vsak teden. Nekateri so pravo zadovoljstvo. Drugi so pouk o tem, česa ne početi.

Ta članek je tisto, kar bi sam sestavil, če bi danes od začetka vodil postopek izbire TMS-a. Temelji na razpisih, na katere smo odgovarjali, na vzorcih, ki se ponavljajo pri različnih podjetjih in panogah, ter na najpogostejših napakah, ki jih opažamo.

Če ste specialist za nabavo, vam bo večina tega znana. Upamo, da vam vsaj en del prihrani kakšen nepotrebni krog pojasnil.

Kaj je razpis za TMS?

Razpis za TMS (Request for Proposal) je strukturiran dokument, ki ga pošljete ponudnikom sistemov za upravljanje prevozov. Opisuje vaše logistično poslovanje in vsakega ponudnika poziva, da predlaga, kako bi njihov sistem to obvladal – pri enakem naboru zahtev. Celoten namen je primerljivost. Enaka vprašanja, enaka oblika, enak kontekst, da je mogoče prejete odgovore postaviti drug ob drugega, namesto da beremo pet ločenih prodajnih predstavitev.

Razpisa ne potrebujete vedno. Smisel dobi, ko je odločitev zapletena ali ko jo boste morali utemeljiti pred drugimi v podjetju. Če je vaše logistično poslovanje preprosto, zadostujeta demonstracija izdelka in pogovor z nekaj ponudniki.

Ali res potrebujete formalni razpis za TMS?

Napačna odločitev na tej točki je najdražja napaka v celotnem postopku izbire TMS-a. To si razjasnite, preden naredite karkoli drugega.

Odločilna je kompleksnost vaše logistike, ne velikost podjetja.

Izvedite strukturiran razpis za TMS, če odpravljate pošiljke z več lokacij, uporabljate različne načine prevoza in potrebujete integracijo sistema z vašim ERP-om. Takrat morate imeti vse ponudnike postavljene drug ob drugega, da vam nič pomembnega ne uide. Ponudniki se med seboj zelo razlikujejo po tem, kako se povezujejo s prevozniki. Eden to imenuje »izvorna integracija«, drugi pa to tiho ureja prek tretje strani. V ohlapnem postopku tega ne boste opazili, dokler ne podpišete pogodbe. Takrat pa je prepozno.

Preskočite formalni razpis, če upravljate eno lokacijo z manjšim številom prevoznikov in že veste, kaj iščete. Zakaj? Ker v trenutku, ko izvedete razpis, se samodejno uvrstite v cenovni razred za velika podjetja. Dve ali tri dobre demonstracije z natančnimi vprašanji vam pogosto prinesejo boljši sistem, ceneje in hitreje. Povejte tem dvema ali trem ponudnikom, kaj pošiljate in kaj želite rešiti, nato pa jih prosite, da vam to pokažejo v svojem živem sistemu. V eni uri boste vedeli dovolj. In če pretežno pošiljate pakete namesto palet ali tovora, morda sploh ne potrebujete polnega TMS-a – programska oprema za pošiljanje preko več prevoznikov je drugačna, lažja kategorija, ki je namenjena prav temu.

Bodite torej iskreni do sebe, preden začnete. Razpis, ki ga niste potrebovali, je najpočasnejši in najdražji način za nakup TMS-a.

Razpis, ki ga niste potrebovali, je najpočasnejši in najdražji način za nakup TMS-a.

Še eno opozorilo, če se vseeno odločite za formalni razpis. Postopek, preobremenjen z upravljavskim jezikom, metodološkimi okviri in zahtevami po fiksnih cenah, vzame ponudnikom tedne za pripravo odgovora – in ponudniki, ki si tak obseg dela lahko privoščijo, so praviloma veliki, uveljavljeni akterji. Če bi vam v resnici bolje ustrezala sodobnejša, bolj vitka platforma, jo preveč birokratski postopek tiho izloči, še preden jo sploh vidite v akciji.

Cilj je najti pravo rešitev za vas. Postopek oblikujte glede na ta cilj, ne glede na upravljanje postopka samega.

Postopek razpisa za TMS v 9 korakih

Izbira TMS-a ni nujno zapletena. Zahteva pa jasno zaporedje. Preskočite korake in za to boste plačali pozneje – najpogosteje med implementacijo, ko predpostavke, ki bi jih morali razjasniti zgodaj, postanejo drage presenečitve.

Dobro voden postopek traja 8 do 12 tednov. Za preprost obseg manj, redko pa je potrebno več.

Zaporedje, ki deluje, je naslednje:

1. Pregled trga. Preden napišete eno samo zahtevo, si vzemite čas za razumevanje ponudbe na trgu. Trg TMS-ov se je v zadnjih petih letih močno spremenil: obstajajo dobre platforme za velika podjetja, dobre platforme za srednji trg in resnično zmogljive sodobne rešitve SaaS za upravljanje prevozov, ki pred petimi leti sploh niso obstajale. Sestavite daljši seznam 5 do 8 ponudnikov TMS-a, ki jih je vredno kontaktirati.
2. Sporazum o zaupnosti (NDA). Pošljite ga zgodaj. Delili boste operativne podatke, kot so obsegi pošiljk, imena prevoznikov in podrobnosti o internih sistemih – podpisan NDA pred pošiljanjem razpisa je standardna praksa, ki ščiti obe strani.
3. RFI (neobvezno). Kratka zahteva za informacije je smiselna, če je vaš daljši seznam širok in želite filtrirati ponudnike, preden se lotite polnega razpisa. Omejite jo na eno stran: ozadje podjetja, ključne zmogljivosti, okvirni cenovni razpon. Dovolj za ožanje seznama, brez zahteve po dolgih esejih.
4. Razpis (RFP). Osrednji dokument. Vsakemu ponudniku da vse, kar potrebuje za natančno ponudbo. Več o tem v naslednjem poglavju.
5. Okno za vprašanja in odgovore. Vedno ga vključite. Ponudniki bodo imeli vprašanja, odgovori pa pogosto izboljšajo vse prejete ponudbe. Postopek vodite pisno in vse odgovore hkrati posredujte vsem ponudnikom. Tako ostane postopek urejen in primerljiv.
6. Ožji seznam in predstavitve. Ocenite pisne ponudbe, nato povabite 2 do 3 ponudnike na predstavitev. Ta mora vključevati živi prikaz sistema na podlagi vaših dejanskih primerov uporabe, ne splošne demonstracije. Če vam ponudnik ne more pokazati vašega scenarija v svojem sistemu, je to že samo po sebi koristna informacija.
7. Drugi krog (po potrebi). Pri kompleksni odločitvi je poglobljena seja, osredotočena na konkretne odprte točke – varnost, integracijo, komercialne pogoje – vredna časa. Ne načrtujte je, razen če imate resnična odprta vprašanja.
8. Odločitev in pogodba. Uskladite se interno, preden začnete pogajanja. Vedite, kaj so vaše nujne zahteve, sprejemljivi kompromisi in točke, pri katerih ne popustite.
9. Uvedba. Postopek se ne konča s podpisom. Najboljši izidi razpisov imajo načrt uvedbe dogovorjen pred podpisom pogodbe.

Časovnica razpisa za TMS, ki jo lahko kopirate

Okvirno trajanje glede na obseg:

• Ena preprosta lokacija: 6 do 8 tednov (formalnega razpisa morda sploh ne potrebujete).
• Več lokacij z integracijo ERP: 8 do 12 tednov.
• Globalna uvedba z več pravnimi osebami in kompleksno integracijo: 12 do 20 tednov, verjetno z dvema krogoma predstavitev.

Prenesite predlogo časovnice razpisa (.docx)

Kaj vključiti v dokument razpisa za TMS

Dokument razpisa je vaše najpomembnejše orodje v tem postopku. Dober dokument razpisa opravi večino dela ocenjevanja namesto vas, zato ga ohranite osredotočenega. Jedrnat razpis na 10 straneh prekaša 30-stranskega, ki skuša pokriti vse.

1. Uvodno pismo in opredelitev cilja

Ena stran. Kdo ste, kaj iščete, zakaj zdaj. Ostanite pri dejstvih. Ponudniki ne potrebujejo vizijske izjave – potrebujejo razumeti vaš operativni problem.

2. Časovnica

Jasen razpored z resničnimi datumi: objava razpisa, rok za vprašanja, rok za oddajo ponudb, okno za predstavitve, datum odločitve. Ponudniki načrtujejo obseg svojega odgovora glede na to. Nejasne časovnice prinašajo nejasne ponudbe.

3. Ozadje podjetja in operativni kontekst

Tu večina razpisov odpove – in prav to je razlika med primerljivimi ponudbami in krogom pojasnil. Ne opisujte le svojega poslovanja, temveč opišite svojo logistično operacijo. Koliko lokacij. Koliko pravnih oseb. Kateri načini prevoza (paketi, LTL, FTL, letalski, pomorski, železniški). Katere regije. Okvirni obsegi pošiljk. Trenutni sistemi. Kaj pomeni »dobro« se razlikuje tudi po panogi – zahteve za elektroniko, strojništvo, kemikalije ali tiskarstvo in embalažo niso enake. To je kontekst, ki ga ponudniki potrebujejo za natančno pripravo ponudbe. Če tu ne navedete dovolj podrobnosti, boste dve tedni odgovarjali na vprašanja za pojasnila, ki bi se jim lahko v celoti izognili. Tej točki je namenjeno posebno poglavje v nadaljevanju.

4. Funkcionalne zahteve

Tabela tega, kar mora sistem znati, razvrščena po pomembnosti: nujno / zaželeno / prijetno imeti (Excel je povsem primeren). Ponudnike prosite, da za vsako zahtevo navedejo stopnjo pokritosti: a) izvorna, b) tretje-stranska, c) prilagoditev ali d) ni podprto. To je tisto, kar naredi ponudbe primerljive. Več o tem, kako sestaviti ta seznam, je v nadaljevanju.

5. Merila ocenjevanja

Ponudnikom povejte, kako boste sprejeli odločitev: funkcionalnost, cena, pristop k implementaciji, reference, varnost, ekipa. Delite uteži, če ste pripravljeni. Bolj ko ste transparentni, boljše ponudbe boste prejeli.

6. Cenovni model

Zahtevajte popolno razčlenitev: naročnina, implementacija, transakcijske pristojbine, podpora in vse ostalo. Če je mogoče, prosite za vzorčni račun. Cenovne strukture se med ponudniki zelo razlikujejo, skrite postavke pa imajo navado, da se pokažejo pozno. Potrudite se, da jih odkrijete zgodaj.

7. Oblika odgovora

Ponudnikom natančno povejte, kako naj bo ponudba strukturirana, in če jim zagotovite predloge, zahtevajte njihovo uporabo. Primerljive ponudbe vam prihranijo dneve pri ocenjevanju, oblika pa je povsem v vaši moči.

Prenesite predlogo dokumenta razpisa in začnite s celotno zgornjo strukturo:

Prenesite predlogo dokumenta razpisa (.docx)

Operativne informacije, ki jih večina razpisov za TMS izpusti – in zakaj so najpomembnejše

To je poglavje, ki bi ga rad prebral vsak avtor razpisa za TMS, preden začne pisati.

Odgovarjamo na veliko razpisov za TMS. Skoraj vsaka ponudba, ki jo pripravimo, zahteva krog pojasnil – in redko zato, ker zahteve niso bile jasne. Razlog je skoraj vedno odsotnost operativnega konteksta: obseg pošiljk, struktura lokacij, mreža prevoznikov, obstoječi sistemi.

Razpisi, ki so zahtevali poln krog pojasnil, imajo skoraj vedno eno skupno lastnost:

Videli smo podjetja, ki so tedne porabila za oblikovanje meril ocenjevanja in seznamov zahtev, nato pa poslala razpis, v katerem ni bilo omenjeno, koliko pošiljk obdelajo na mesec.

Brez tega ponudniki ugibajo. Ko ugibajo, so ponudbe splošne, cene niso dokončne in ni ničesar trdnega za primerjavo.

Na primer: globalni proizvajalec z 10 skladišči in sistemom SAP potrebuje popolnoma drugačno ponudbo kot distributer z eno lokacijo, ki logistiko vodi v preglednicah. Če ponudnik ne ve, kateri od teh ste vi, se zavaruje – in dobite ponudbe, ki se ne zavežejo k ničemur.

Rešitev vzame popoldne. Pred pošiljanjem razpisa odgovorite na teh deset vprašanj.

1. Organizacija in obseg. Koliko pravnih oseb in lokacij je vključenih? Ali bo uvedba vzporedna ali postopna? Kako neodvisno delujejo posamezne lokacije – ločene pogodbe s prevozniki, ločene ekipe?
2. Obseg pošiljk. Mesečno in dnevno število pošiljk po lokacijah, povprečje in konice. Morebitna sezonskost. Razmerje med vhodnimi in izhodnimi pošiljkami.
3. Razčlenitev po načinih prevoza. Kolikšen delež predstavljajo paketi, LTL, FTL, letalski, pomorski prevoz? Kateri načini rastejo? Kateri so operativno najpomembnejši?
4. Mreža prevoznikov. Koliko prevoznikov na lokacijo in na način prevoza? So skupni za vse lokacije ali jih upravljajo lokalno? Ali obstajajo strateški prevozniki, ki jih je treba prednostno obravnavati, ali prevozniki, ki jih določi stranka in jih ne morete zamenjati?
5. Geografija in transportne poti. Katere regije so vključene? Katere poti so najpomembnejše: domače, čezmejne, medcelinske? Ključna pristanišča ali logistična vozlišča?
6. Trenutno stanje. Kako danes načrtujete, naročate in sledite pošiljkam? V ERP-u, preglednicah, portalih prevoznikov, po e-pošti? Katere so glavne težave v obstoječem procesu?
7. Finančna ureditev. Kdo plačuje prevoz – ena pravna oseba ali več? Ali obstajajo številke računov tretjih strank ali strank? Kako danes beležite in preverjate stroške prevoza?
8. Poslovni model. B2B, B2C? Če oboje, kakšno je razmerje. Operativne in sistemske zahteve se precej razlikujejo.
9. Integracijska pokrajina. Kateri sistemi se morajo povezati s TMS-om: ERP, WMS, CRM? Ali obstajajo obstoječe integracije prevoznikov, ki jih je treba ohraniti? Kako avtomatiziran mora biti sistem od prvega dne?
10. Časovnica in omejitve. Ali obstaja ciljni datum zagona? Ali so kakšni interni mejniki – konec poslovnega leta, sezona konic, selitve sistemov – ki vplivajo na razpored?

Nič od tega ni težko zapisati. A vse skupaj bistveno vpliva na to, kaj boste prejeli nazaj.

Prenesite kontrolni seznam operativnih informacij in spremenite teh deset vprašanj v izpolnljivo tabelo, ki jo neposredno vstavite v razpis:

Prenesite kontrolni seznam operativnih informacij (.docx)

Kako napisati funkcionalne zahteve za TMS

Funkcionalne zahteve so jedro razpisa. Če jih pravilno oblikujete, dobite jasno in primerljivo sliko tega, kaj vsak ponudnik zmore in česa ne. Če jih oblikujete slabo, boste morda tedne porabili za dekodiranje odgovorov, ki vsi pravijo »da«.

Cilj ni najdaljši seznam. Cilj je najiskrenejši seznam.

Brezobzirno prioritizirajte: nujno, zaželeno, prijetno imeti

Vse, kar si želite, ni enako pomembno. Uporabite tri kategorije in se jih držite:

1. Nujno (N): brez kompromisov. Ponudnik, ki tega ne zmore, odpade, ne glede na vse ostalo.
2. Zaželeno (Z): pomembno, a sprejemljiva je začasna rešitev ali obljuba o bližnji nadgradnji.
3. Prijetno imeti (P): dobro vedeti, a stoji za vsem zgoraj navedenim.

Večina seznamov ima daleč preveč nujnih zahtev. Kadar je vse kritično, ni nič kritično. Bodite iskreni glede tega, kaj bi resnično onemogočilo delovanje sistema za vas, in le to označite kot nujno.

Ponudnike prosite za klasifikacijo pokritosti: izvorna / tretje-stranska / prilagoditev

Za vsako zahtevo morajo odgovoriti z eno od naslednjih možnosti:

Ta stolpec je tisti, kjer ponudbe pridobijo ali izgubijo vaše zaupanje. Ponudnik, ki odgovori iskreno in zapiše ni podprto, kadar je to res, vam pokaže, kako se bo obnašal kot partner. Ponudnik, ki na vse odgovori z izvorno, vam pove prav tako nekaj pomembnega.

Bodite natančni pri vprašanju

»Ali sistem podpira cene prevoznikov?« vam bo prineslo neuporaben »da«. »Ali sistem zna izračunati ceno prevoza za vsakega prevoznika, vključno s tistimi brez cenovnega API-ja, in jih prikazati drug ob drugem za vsako pošiljko?« vam da nekaj, kar dejansko lahko ocenite.

Kje se konča ERP in kje začne TMS?

Eden najpogostejših virov zmede pri ocenjevanju sistemov za upravljanje prevozov je vprašanje, kje se konča TMS in kje začne ERP.

Finančni procesi, kot so knjiženje v glavno knjigo, pristanskostni stroški in revizija prevoznin, se pogosto obravnavajo na strani ERP-a, pri čemer TMS posreduje podatke v ERP. To je normalno in pogosto prava ureditev. Toda to mora biti jasno opredeljeno. Ko ponudnik na eno od vaših nujnih zahtev odgovori »urejeno prek integracije z ERP-om«, natančno razjasnite, kaj to pomeni za vašo implementacijo in kdo to zgradi.

Opišite cilj, ne tehnične rešitve

Opišite, kaj morate doseči, ne kako naj to sistem tehnično izvede. Preveč predpisane zahteve izločijo dobre rešitve iz napačnih razlogov. Ponudnikom pustite prostor, da vam pokažejo boljši pristop od tistega, ki ste ga imeli v mislih – včasih ga namreč imajo.

Seznam 30 iskrenih, prioritiziranih zahtev vam pove več kot preglednica s 150 vrsticami, kjer je vse kritično in vsak ponudnik obkljukal vsako polje.

Izhodiščni nabor zahtev za TMS, ki ga prilagodite

Večina kupcev, ki se s tem srečuje prvič, želi oporo pri samem seznamu, zato je tu vzorčni nabor iz naših izkušenj, že razvrščen po kategorijah, ki ga prilagodite svoji operaciji. Celoten seznam je na voljo za prenos v ocenjevalnem listu spodaj – ta prikaz je dovolj, da vidite njegovo obliko.

Prenesite ocenjevalni list funkcionalnih zahtev, že sestavljen s prioritetami in stolpcem pokritosti za vsakega ponudnika:

Prenesite ocenjevalni list funkcionalnih zahtev (.docx)

Kako primerjati stroške TMS-a (in sestaviti triletni model)

»Koliko stane TMS?« je vprašanje, ki ga kupci najbolj želijo slišati, ponudniki pa ga najraje obidejo. A naročnina redko predstavlja vaš končni strošek. Pri srednje velikem naročniku prevoznih storitev z več lokacijami lahko implementacija in integracija skupni triletni strošek presežeta bolj kot mesečna naročnina – in prav ta postavka ostaja pri ponudnikih najbolj nejasna. Ključno je torej vprašanje strukturirati tako, da so odgovori primerljivi in so resnični stroški vidni.

Za grobo orientacijo: oblačni TMS za srednji trg se giblje od nekaj sto do nekaj tisoč evrov na mesec, medtem ko tradicionalni sistemi za velika podjetja stanejo od desettisoč do več kot milijon evrov letno, z implementacijo, ki lahko doseže šest ali sedem številk. To je širok razpon – in prav zato je primerljiv model pomembnejši od katerekoli posamezne številke. Za vpogled v dejanske cene ponudnikov TMS-a si oglejte naše raziskave o vodilnih ponudnikih TMS-a.

Sestavine cene TMS-a

Skoraj vsaka ponudba za TMS je neka kombinacija naslednjih elementov:

Sestavite triletni model stroškov, preden primerjate

Ponudnik TMS-a, ki je na videz poceni pri naročnini, se lahko izkaže za najdražjega, ko prištejete implementacijo, transakcijske pristojbine in vključevanje prevoznikov. Vsakega ponudnika ocenite po istem modelu:

3-letni strošek = implementacija + (letna naročnina × 3) + (pristojbina na pošiljko × letni obseg × 3) + podpora + pričakovani dodatki za integracije prevoznikov.

Uporabite svoje dejanske obsege, ne ponudnikovega urejenega primera. Ta ena tabela pogosto premeša vrstni red na ožjem seznamu.

Pazite na različne sestavine cene, ne le na osnovno pristojbino

Nekateri ponudniki imajo nizko naročnino in razliko nadoknadijo s transakcijskimi pristojbinami ali pristojbinami za posameznega prevoznika. To samo po sebi ni nujno slabo, a spremeni, kdo je najcenejši, ko rastete. Če vaš obseg narašča, model na pošiljko lahko hitro preseže pavšalni. Prosite za vzorčni račun in pogoje naročnine, da primerjate, kar boste dejansko plačali, ne le oglaševane cene.

Vsakemu ponudniku velja zastaviti vprašanje: ali so nove integracije prevoznikov vključene ali se zaračunajo posebej? Nekatere platforme TMS zaračunajo 5.000–10.000 EUR za vsako novo integracijo prevoznika in za to potrebujejo mesece, druge pa gradijo nove integracije brez dodatnih stroškov. Za srednje velikega naročnika, ki sčasoma dodaja prevoznike, ta en odgovor lahko premakne triletni skupni strošek bolj kot katera koli vrstica naročnine.

Kako oceniti ponudbe za TMS onkraj cene

Ponudbe so prispele. Vse se zdijo razumne, večina potrjuje vaše zahteve, cene so v podobnem razponu. Kaj zdaj?

Na tej točki ekipe tiho padejo nazaj na ceno, ker se vse ostalo zdi težje primerjati. Ne storite tega. Tukaj je tisto, kar jih dejansko loči.

1. Povezljivost s prevozniki.

Pri TMS-u je povezljivost s prevozniki temelj. Kako se ponudnik dejansko poveže s prevozniki – prek neposrednih integracij API/EDI, agregatov tretjih strani ali sploh ne (naročila po e-pošti in PDF ne glede na digitalne zmogljivosti prevoznika)? Kaj se zgodi, ko potrebujete prevoznika, ki ga še ne podpirajo – kako dolgo traja in koliko stane?

Ponudnik z globokimi, neposrednimi integracijami prevoznikov je povsem drugačna žival od tistega, ki vse usmerja prek vmesne plasti. Razliko začutite pri zanesljivosti naročanja, kakovosti sledenja in pri tem, ali lahko dodate prevoznika brez vsakokratnega odpiranja novih komercialnih pogajanj.

2. Poenotenje ravni storitev prevoznikov – to je pomembnejše, kot večina misli.

Prevozniki se med seboj zelo razlikujejo po digitalnih zmogljivostih. Nekateri imajo sofisticirane API-je, ki pokrivajo cene v realnem času, napoved ETA, preverjanje naslovov, generiranje etiket in podrobne dogodke sledenja. Drugi vam pošljejo potrditev naročila po e-pošti in s tem je konec. Večina omrežij prevoznikov ima obe vrsti hkrati.

To postane vaš problem v trenutku, ko povežete ERP ali WMS s TMS-om. Če vaša integracija pričakuje popoln nabor podatkov od vsakega prevoznika – potrditev naročila, povezavo za sledenje, etiketo, oceno stroškov – nekateri prevozniki pa tega ne morejo zagotoviti, dobite izjeme, ročne obvode in vrzeli v podatkih. En šibek prevoznik poruši doslednost celotnega delovnega toka.

Ponudniki programske opreme za upravljanje prevozov se s tem spopadajo na dva načina, in vredno je odločiti, kateri želite, preden preberete eno samo ponudbo:

• Tanjši TMS posreduje, kar vsak prevoznik zagotovi, reševanje vrzeli v vašem ERP-u ali z ročnim delom pa bo vaša skrb. Enostavnejša integracija, a več izjem za obvladovanje na vaši strani.
• TMS, ki podatke normalizira in sam zapolni vrzeli: izračuna stroške prevoza iz vaše naložene cenika, ko ni cenovnega API-ja; oceni čas tranzita, ko prevoznik ne zagotavlja ETA; generira etikete, ko prevoznik tega ne zmore; kadar nimajo sledenja, prevoznikom omogoči ročni vnos mejnikov sledenja in še več. Programska oprema zapolni vrzeli v tehničnih zmogljivostih vaših prevoznikov, vaš ERP pa vidi eno dosledno strukturo.

Pri ocenjevanju ponudb ponudnike neposredno vprašajte: kako ravnate s prevozniki z omejenimi digitalnimi zmogljivostmi? Odgovor vam pove veliko o tem, kako zrela je njihova platforma.

3. Poštenost glede integracije.

Natančno bodite pozorni na to, kako ponudniki opisujejo obseg integracije (kdo naredi kaj). Ponudba, ki jasno navaja »razvoj na strani ERP-a je vaša naloga, tukaj je, kar mi zagotovimo in kako vas podpiramo«, je zaupanja vrednejša od tiste, ki nakazuje »brezšivno integracijo«, ne da bi pojasnila, katera stran katero integracijo izvede. Presenečenja pri integraciji so eden najpogostejših razlogov, da projekti TMS prekoračijo čas in proračun.

4. Pristop k implementaciji.

Postopen pristop – najprej ročna operativna validacija, nato avtomatizacija – je praviloma manj tvegan od zagona vsega naenkrat. Preden se naslonite na sistem z vso svojo operacijo, potrdite, da deluje za vaše dejanske delovne tokove. Z naše strani: ponudniki, ki to predlagajo brez spodbude, so verjetno že doživeli kaotičen zagon. Tisti, ki od prvega dne obljubljajo popolno avtomatizacijo, pogosto niso.

5. Reference.

Prosite za reference podjetij s podobnim načinom delovanja, ne le podobno velikostjo ali številom zaposlenih. Referenca od distributerja z eno lokacijo ni posebej koristna, če upravljate proizvodnjo z več lokacijami in integracijo SAP. In zastavite konkretna vprašanja: »Kako je potekalo vključevanje prevoznikov?« »Kako je potekal postopek integracije?« »Kaj se je zgodilo, ko kaj ni delovalo po pričakovanjih?«

6. Ponudba sama po sebi.

Način, kako ponudnik TMS-a odgovori na vaš razpis, je napoved tega, kako se bo obnašal kot vaš partner. Ali so neposredno odgovorili na vaša vprašanja ali vse ovili v pogojnike? Ali so pošteno opozorili na vrzeli ali trdili, da pokrivajo vse zahteve? Ali so pokazali, da razumejo vaše poslovanje, ali so vam poslali nekoliko prirejeno standardno predstavitev?

Ponudba, ki na dveh mestih prizna ni podprto in pojasni zakaj, je vredna več od tiste, ki na vse odgovori z da. Resnico boste odkrili v vsakem primeru. Bolje med ocenjevanjem kot ob zagonu.

Prenesite matriko ocenjevanja ponudnikov za tehtano točkovanje ponudnikov po merilih:

Prenesite matriko ocenjevanja ponudnikov (.docx)

Krog predstavitev ponudnikov TMS-a

Pisne ponudbe vam povedo, kaj ponudnik trdi. Predstavitve pokažejo, ali to zmore tudi dokazati.

Na tej točki bi morali imeti ožji seznam 2 do 3 ponudnikov. Cilj kroga predstavitev je ponudbo postaviti pod resnični pritisk in preveriti, ali sistem deluje v vaših dejanskih scenarijih.

Zahtevajte živi prikaz, ne demonstracijo

Demonstracija je vnaprej pripravljeno zaporedje, ki prikazuje sistem v najboljši luči. Živi prikaz je, ko rečete »pokažite mi, kako bi obravnavali to pošiljko iz našega skladišča na Nizozemskem, z našim prevoznikom, po naši dogovorjeni ceni« – in opazujete, kaj se dejansko zgodi.

Pred sestankom pripravite 2 do 3 resnične scenarije iz lastnega poslovanja: standardno izhodno naročilo, pošiljko, ki zahteva spot ponudbo, in kaj zahtevnejšega – na primer zamudo pri dostavi ali prevoznika, ki ne zagotavlja sledenja. Ko ponudnik nenehno usmerja nazaj k pripravljeni demonstraciji namesto k vašemu scenariju, je to že samo po sebi odgovor.

Izzovite vrzeli

Vsaka ponudba za TMS jih ima. Takoj se lotite mest, kjer je ponudnik odgovoril delno ali kjer imate dvome, in ostanite pri tem. Ne dovolite jim, da se vrnejo k temu, kar deluje brezhibno. Kako točno to deluje? Kdo naredi kaj? Kaj se zgodi, ko ne deluje po pričakovanjih?

Zagotovite prave ljudi v sobi

Na strani ponudnika TMS-a bi morali predstavljati tisti, ki bodo dejansko delali na vaši implementaciji, ne le prodajna ekipa. To izrecno zahtevajte. Na vaši strani vključite nekoga iz IT-ja (če je integracija v obsegu) in vsaj eno osebo, ki bo sistem dejansko uporabljala vsak dan. Ti postavljajo drugačna vprašanja kot nabava – in želite oba sklopa vprašanj.

Drugi krog samo po potrebi

Pri kompleksni odločitvi je druga seja, osredotočena na konkretne teme, vredna časa. Primeri tem:

• Varnost in varstvo podatkov – zahtevajte poročilo o penetracijskem testiranju ali varnostno dokumentacijo, če to zahteva vaša IT ali informacijska varnostna ekipa
• Integracijska arhitektura – tehnična seja med vašo IT ekipo in ekipo ponudnika
• Komercialni pogoji – preglejte pogodbo, SOW in predpostavke vrstico za vrstico, preden vstopite v formalna pogajanja

Ne načrtujte je le zato, da bi ponovili prvi sestanek z več ljudmi v sobi. Bodisi razreši konkretna odprta vprašanja, bodisi je ne prirejajte.

Zaveze potrdite pisno

Vse, kar ponudnik obljubi na sestanku in kar ni v pisni ponudbi, mora biti pisno potrjeno, preden nadaljujete. Ustne zaveze ne preživijo pogajanj o pogodbi. Če ponudnik TMS-a za kaj pomembnega reče »da, to zmoremo«, mu še isti dan pošljite e-pošto in ga prosite za pisno potrditev.

Pogodba za TMS in SOW (izjava o obsegu dela): kaj preveriti pred podpisom

Izbrali ste ponudnika. Večina ekip na tej točki »oddahne«. Priporočam, da tega ne storite – ker prav tu se podrobnosti, ki so jih vsi med ocenjevanjem prezrli, tiho spremenijo v vaš problem.

Uskladite se interno, preden začnete pogajanja

Vedite, kaj so vaše nujne zahteve, sprejemljivi kompromisi in točke, pri katerih ne popustite, preden se pogovor sploh začne. Sprememba zahtev sredi pogajanj stane čas, ruši zaupanje in vas včasih stane ponudnika TMS-a, ki ste ga dejansko hoteli. Najprej se uskladite interno, šele nato pogajajte.

Razumejte, kaj kupujete: SaaS, ne licenco

Sodobne platforme TMS so naročnine SaaS, ne programske licence. Naročate se na storitev, ki jo ponudnik gosti, vzdržuje in posodablja – ne kupujete sistema v lasti. To premakne, kaj mora pogodba pokrivati: pogoje naročnine, odpoved, lastništvo podatkov in pravice do izvoza, zaveze glede razpoložljivosti, odzivne čase podpore. Standardne predloge za nabavo niso bile napisane za ta model, zato preverite, ali so vaše dohitele.

SOW je enako pomemben kot pogodba

Izjava o obsegu dela natančno določa, kaj se dostavi, kdo to naredi in kdaj: konfiguracija računa, vključevanje prevoznikov, podpora pri integraciji, usposabljanje in merila sprejema, ki potrjujejo, da je implementacija dejansko zaključena. Kar ni v SOW, ni vključeno – ne glede na to, kar je bilo rečeno na sestanku ali v e-pošti. Posebej pozorno preberite razdelek predpostavke. Tam je obseg pogojno opredeljen. Če se vaš seznam prevoznikov izkaže za večjega od navedenega ali vaš ERP zahteva nestandardno obliko integracije, predpostavke odločijo, ali gre za kratek pogovor ali za zaračunano zahtevo za spremembo.

Jasno opredelite, kaj je zunaj obsega

Razvoj po meri, usposabljanje na lokaciji, migracija podatkov, integracijska dela na vaših sistemih, spremembe na strani prevoznikov. Te postavke so praviloma ločeno cenjene. Pisna opredelitev pred podpisom odpravlja najpogostejši in najbolj izogibni vir trenj pri implementaciji: dve strani, ki sta vsaka predpostavljali, da je kaj drugega vključeno.

Dogovorite se o načrtu uvedbe pred podpisom

Ne po njem. Prioritizacija prevoznikov, časovnica konfiguracije, mejniki integracije, merila za zagon – vse to uredite, dokler imate še pogajalski vzvod. Ponudnik, ki vam pri sklenitvi pogodbe ne more dati jasnega načrta uvedbe, vam pove nekaj, kar boste radi vedeli, preden se zavežete.

Po podpisu: implementacija in uvedba TMS-a

Večina resničnega tveganja živi po podpisu. Tri stvari odločijo, kako bo potekalo.

1. Migracija podatkov

Pogodbe s prevozniki, ceniki, adresarji, zgodovinske pošiljke. Zgodaj se odločite, kaj morate prenesti, kaj je treba najprej očistiti in kdo je odgovoren za delo. Neurejeni izvorni podatki so najpogostejši razlog, da se datum zagona vedno znova pomika. Očistite jih pred migracijo, ne med njo.

2. Zaporedje vključevanja prevoznikov

Vseh prevoznikov ne povežete prvi dan. Prioritizirajte po obsegu in kritičnosti, najpomembnejše aktivirajte in validirajte, nato razširite. Prav tu postopni pristop, za katerega ste vprašali med ocenjevanjem, pokaže svojo vrednost.

3. Sprejetost med uporabniki

Ljudje, ki vsak dan naročajo pošiljke, morajo želeti uporabljati nov sistem. Vključite vsaj enega od njih že od faze razpisa naprej, jih ustrezno usposobite med fazo intenzivne podpore (uvedbe) in poskrbite, da je dnevni delovni tok resnično hitrejši od prejšnjega. Tehnično brezhibna uvedba, ki je ekipa preprosto ne uporablja, je še vedno neuspešna uvedba.

10 pogostih napak pri razpisih za TMS

Vzorci, ki jih vidimo najpogosteje, zbrani na enem mestu:

• Brez operativnega konteksta. Najpomembnejša napaka. Ponudnikom niso posredovani podatki o obsegu pošiljk, strukturi lokacij ali mreži prevoznikov. Krog pojasnil in splošne cene so zagotovljeni.
• Vse je nujno. Ko je vsaka zahteva kritična, je stolpec s prioritetami brez vrednosti in ne morete ločiti dealbrekerja od prijetnega dodatka.
• Nejasna časovnica. Brez datumov ponudniki ne morejo oceniti svojega obsega dela, zato so ponudbe prav tako nejasne.
• Preveč predpisano kako. Predpisovanje tehnične implementacije namesto operativnega izida izloči dobre rešitve iz napačnih razlogov.
• Prezrtje meje ERP/TMS. Predpostavka, da TMS obvladuje finančne procese, ki jih dejansko obvladuje ERP, in ugotovitev tega sredi implementacije.
• Odločanje zgolj na podlagi cene. Izbira na podlagi oglaševane naročnine brez triletnega modela ali brez upoštevanja povezljivosti s prevozniki in poštenosti glede integracije.
• Demonstracija namesto živega prikaza. Gledanje pripravljenega zaporedja ponudnika namesto testiranja sistema z vašimi dejanskimi scenariji.
• Reference, ki ne ustrezajo vašemu poslovanju. Osredotočanje na impresivna logotipa, a ta podjetja imajo morda logistično poslovanje, ki se v ničemer ne ujema z vašim. Prosite za reference, ki so podobne vam, nato jih vprašajte, kako sta dejansko potekala uvedba in integracija.
• Načrt uvedbe pustiti za po podpisu. Načrt, ki ga pogajate z vzvodom, je boljši od tistega brez njega.
• Preveč težak postopek za pravega ponudnika. Birokratska obremenitev, ki bi lahko izločila sodobne platforme, ki bi vam v resnici najbolj ustrezale.

Brezplačne predloge za razpis za TMS

Sestavili smo pet predlog na podlagi razpisov, na katere odgovarjamo, da vam ni treba začeti s prazno stranjo:

1. Predloga dokumenta razpisa. Celotna struktura iz tega vodnika.
2. Ocenjevalni list funkcionalnih zahtev. Prioritiziran, s stolpcem pokritosti za vsakega ponudnika.
3. Kontrolni seznam operativnih informacij. Deset vprašanj kot izpolnljiva tabela.
4. Matrika ocenjevanja ponudnikov. Tehtano točkovanje po ponudnikih.
5. Predloga časovnice razpisa. Aktivnosti, datumi, odgovorni.

Prenesite paket – vseh pet, brezplačno, brez e-pošte. Vzemite, kar je koristno, ostalo pustite:

Prenesite celoten paket predlog za razpis za TMS (.zip)

Cargoson je sistem za upravljanje prevozov, ki ga uporabljajo srednje velika proizvodna in veleprodajna podjetja po vsej Evropi in Severni Ameriki. Na razpise, kot je tisti, ki ga boste napisali, odgovarjamo redno – zato, če bi raje svoje zahteve preučili v pogovoru, preden začnete pisati, vam z veseljem pomagamo pri razmisleku, brez obveznosti.

Rezervirajte brezplačno 30-minutno posvetovanje tukaj

Postopek vodite dobro in vsaka ura bo vredna truda.