Kuidas koostada TMS-i RFP: meie kogemus [+ 5 tasuta malli]

Me vastame veohaldustarkvara pakkumiskutsetele (RFP) iga nädal. Mõned on rõõm läbi töötada. Mõned on õppetund selles, mida mitte teha.

See artikkel on see, mida ma ise ehitaksin, kui alustaksin TMS-i valikuprotsessi täna nullist. See põhineb RFP-del, millele oleme vastanud, mustrite kordumisel eri ettevõtetes ja tööstusharudes, sellel, mida enamik neist sisaldab, ja milliseid levinud vigu me näeme.

Kui oled hankeekspert, tundub suurem osa sellest tuttav. Loodetavasti säästab see sulle vähemalt ühe tarbetu täpsustusvooru.

Mis on TMS-i RFP?

TMS-i RFP (pakkumiskutse) on struktureeritud dokument, mille saadad veohaldustarkvara tarnijatele. See kirjeldab sinu logistikaoperatsiooni ja palub igal tarnijal pakkuda välja, kuidas nende süsteem sellega hakkama saaks – samade nõuete alusel. Kogu mõte on võrreldavus. Samad küsimused, sama formaat, sama kontekst, nii et saabuvaid vastuseid saab kõrvuti seada, mitte lugeda viie eraldi müügipresentatsioonina.

RFP-d pole alati vaja. See tasub end ära siis, kui otsus on keeruline või kui pead seda organisatsioonisiseselt teistele põhjendama. Kui teie logistikaoperatsioonid on lihtsad, piisab toote demostratsioonist ja vestlusest mõne tarnijaga.

Kas sul on TMS-i RFP-hange üldse vaja?

Vale otsus siin on kogu TMS-i valikuprotsessi kõige kulukam viga. Otsusta see enne kõike muud.

Küsimus on sinu logistika keerukuses, mitte ettevõtte suuruses.

Korraldad struktureeritud TMS-i RFP-hange siis, kui saadad kaupu mitmest asukohast, kasutad mitut transpordiliiki ja vajad süsteemi ühendamist ERP-ga. Sellisel juhul on vaja kõik tarnijad kõrvuti seada, et miski oluline vahele ei jääks. Tarnijad ühenduvad vedajatega väga erinevalt. Üks nimetab seda „natiivseks", teine suunab selle vaikselt kellegi teise kaudu. Lõdvas protsessis ei märka seda enne, kui oled lepingu allkirjastanud. Siis on hilja.

Jäta formaalne RFP-hange ära siis, kui tegutsed ühest asukohast, sul on käputäis vedajaid ja tead juba, mida vajad. Miks? Sest niipea kui korraldad RFP, oled automaatselt ettevõttehinnaklassis. 2–3 head demot täpsete küsimustega annavad sageli parema süsteemi, odavamalt ja kiiremini. Räägi neile 2–3 tarnijale, mida saadad ja mida lahendada üritad, ning palu neil seda oma töötavas süsteemis näidata. Tunni ajaga on selge. Ja kui saadad peamiselt pakke, mitte aluseid või kaubakoormaid, ei pruugi sulle täielikku TMS-i üldse vaja minna – mitme vedaja logistikatarkvara on selleks otstarbeks mõeldud eraldi, kergem kategooria.

Ole enda vastu aus, kumba eelistad, enne kui alustad. Tarbetu RFP korraldamine on TMS-i ostmise aeglaseim ja kalleim viis.

Tarbetu RFP korraldamine on TMS-i ostmise aeglaseim ja kalleim viis.

Veel üks hoiatus, kui valid siiski täieliku RFP tee. Protsess, mis on täis haldusnõudeid, metoodikaraame ja fikseeritud hinna nõudmisi, võtab vastamiseks nädalaid – ja tarnijad, kes suudavad selle koormuse kanda, on tavaliselt suured, väljakujunenud ettevõtted. Nii et kui mõni kiirem ja kaasaegsem platvorm sobiks sulle tegelikult paremini, võib liiga bürokraatlik protsess need vaikselt välja filtreerida, enne kui jõuad üldse demoni.

Eesmärk on leida õige lahendus sinule. Kujunda protsess selle ümber, mitte protsessi enda haldamise ümber.

TMS-i RFP protsess 9 sammuna

TMS-i valik ei pea olema keeruline. Kuid see vajab selget järjestust. Jäta samme vahele ja maksad selle eest hiljem – tavaliselt juurutamise käigus, kui eeldused, mis oleks pidanud vara selgeks saama, muutuvad kalliteks üllatusteks.

Hästi tehtuna võtab kogu protsess 8–12 nädalat. Lihtsa ulatuse puhul vähem, ja harva on vaja rohkem.

Siin on järjestus, mis toimib:

1. Turuülevaade. Enne kui kirjutad ühtegi nõuet, kuluta aega sellele, et mõista, mis turul saadaval on. TMS-i turg on viimase viie aastaga palju muutunud: on häid ettevõttetaseme platvorme, häid keskturu platvorme ja tõeliselt võimekaid kaasaegseid SaaS-põhiseid veohaldustarkvara lahendusi, mida viis aastat tagasi polnud olemas. Koosta pikk nimekiri 5–8 TMS-i tarnijast, kellega tasub läheneda.
2. Konfidentsiaalsuslepe (NDA). Saada see varakult. Jagad operatiivseid andmeid – mahud, vedajate nimed, sisemiste süsteemide üksikasjad – ja allkirjastatud NDA enne RFP väljasaatmist on standardpraktika, mis kaitseb mõlemat poolt.
3. RFI (valikuline). Lühike teabenõue (Request for Information) on mõistlik, kui su pikk nimekiri on lai ja soovid enne täieliku RFP protsessi investeerimist filtreerida. Hoia see ühel leheküljel: ettevõtte taust, põhivõimekused, ligikaudne hinnavahemik. Piisavalt, et eelvalida, ilma et tarnijad peaksid esseesid kirjutama.
4. RFP. Põhidokument. See annab igale tarnijale selle, mida nad vajavad täpse pakkumise koostamiseks. Lähemalt järgmises peatükis.
5. Küsimuste voor. Lisa see alati. Tarnijatel on küsimusi, ja vastused parandavad sageli kõiki saabuvaid pakkumisi. Korraldage see kirjalikult ja jagage kõiki küsimusi ning vastuseid kõigi tarnijatega samaaegselt. Hoiab protsessi korras ja võrreldavana.
6. Eelvalik ja esitlused. Hinda kirjalikud pakkumised, seejärel kutsu 2–3 tarnijat esitlema. Esitlus peaks sisaldama töötava süsteemi läbivaatust sinu tegelike kasutusjuhtude põhjal, mitte üldist demot. Kui tarnija ei suuda sinu stsenaariumi oma süsteemis näidata, on see juba iseenesest oluline info.
7. Teine voor (vajadusel). Keeruka otsuse puhul tasub korraldada sügavam sessioon, mis keskendub konkreetsetele puudujääkidele – turvalisus, integratsioon, äritingimused. Ära planeeri seda, kui sul pole päriselt lahtisi küsimusi.
8. Otsus ja leping. Jõua organisatsioonisiseselt kokkuleppele enne läbirääkimiste alustamist. Tea oma tingimusteta nõudeid, vastuvõetavaid kompromisse ja punaseid jooni.
9. Kasutuselevõtt. See ei lõpe allkirjaga. Parimate RFP tulemuste puhul on kasutuselevõtu plaan kokku lepitud enne lepingu allkirjastamist.

TMS-i RFP ajakava, mida saad kopeerida

Ligikaudne kestus ulatuse järgi:

• Üks lihtne asukoht: 6–8 nädalat (täielik RFP ei pruugi olla vajalik).
• Mitu asukohta + ERP-integratsioon: 8–12 nädalat.
• Globaalne, mitme üksusega, keeruka integratsiooniga: 12–20 nädalat, tõenäoliselt kahe esitlusvooruga.

Laadi alla RFP ajakava mall (.docx)

Mida TMS-i RFP dokument peaks sisaldama

RFP dokument on selle protsessi kõige olulisem tööriist. Hea RFP teeb suurema osa hindamistööst sinu eest ära, seega hoia see fokuseerituna. Tihe 10-leheküljeline RFP on parem kui 30-leheküljeline, mis üritab kõike katta.

1. Kaaskiri ja eesmärk

Üks lehekülg. Kes te olete, mida otsite, miks praegu. Hoia see faktiline. Tarnijad ei vaja visiooniavaldust – nad peavad lihtsalt mõistma sinu operatiivset probleemi.

2. Ajakava

Selge graafik päris kuupäevadega: RFP väljastamine, küsimuste tähtaeg, esitamine, esitluste aken, otsus. Tarnijad planeerivad oma vastamisjõupingutuse selle järgi. Ebamäärased tähtajad toovad ebamääraseid pakkumisi.

3. Ettevõtte ja operatiivne taust

Siin jäävad enamik RFP-sid lühikeseks – ja just see on vahe võrreldavate pakkumiste ja täpsustusvooru vahel. Ära kirjelda ainult oma äri, vaid kirjelda oma logistikaoperatsiooni. Mitu asukohta. Mitu juriidilist isikut. Millised transpordiliigid (pakid, LTL, FTL, õhk, meri, raudtee). Millised piirkonnad. Ligikaudsed mahud. Praegused süsteemid. See, mis on „hea", erineb ka sektori lõikes – elektroonika, masinaehituse, keemia või trüki- ja pakendtootjate nõuded ei ole samad. See on kontekst, mida tarnijad vajavad täpse pakkumise koostamiseks. Kui sa siin piisavalt üksikasju ei esita, kulutad kaks nädalat täpsustusküsimustele vastamisele, mida oleks saanud täielikult vältida. Sellel on oma eraldi peatükk allpool.

4. Funktsionaalsed nõuded

Tabel sellest, mida süsteem tegema peab, tähtsuse järgi prioritiseeritud: kohustuslik / soovitav / tore oleks (Excel sobib). Palu tarnijatel vastata igale nõudele oma kaetuse tasemega: a) natiivne, b) kolmas osapool, c) kohandamine või d) ei toetata. See teeb pakkumised võrreldavaks. Lähemalt sellest, kuidas seda nimekirja koostada, allpool.

5. Hindamiskriteeriumid

Ütle tarnijatele, kuidas otsuse teed: funktsionaalsus, hind, juurutamise lähenemine, viited, turvalisus, meeskond. Jaga kaalud, kui oled selleks valmis. Mida läbipaistvam oled, seda paremad on pakkumised.

6. Hinnamudel

Küsi täielikku jaotust: tellimustasu, juurutamine, tehingutasud, tugi, kõik muu. Küsi võimalusel näidisarvet. Hinnastruktuurid erinevad tarnijate vahel palju, ja varjatud kulud kipuvad ilmuma hilja. Püüa need varakult välja selgitada.

7. Vastuse formaat

Ütle tarnijatele täpselt, kuidas soovid pakkumist struktureerida, ja kui esitad mallid, nõua nende kasutamist. Võrreldavad pakkumised säästavad hindamisel päevi, ja formaat on täielikult sinu kontrolli all.

Laadi alla RFP dokumendi mall, et alustada ülaltoodud täieliku struktuuriga:

Laadi alla RFP dokumendi mall (.docx)

Operatiivne teave, mida enamik TMS-i RFP-sid ei sisalda – ja miks see on kõige olulisem

See on peatükk, mida sooviksin, et iga TMS-i RFP koostaja loeks kõigepealt.

Me vastame paljudele TMS-i hangetele. Peaaegu iga pakkumine, mille kirjutame, vajab täpsustusvooru – ja harva sellepärast, et nõuded olid ebaselged. Põhjus on selles, et operatiivne kontekst puudus: mahud, asukohtade struktuur, vedajate maastik, praegused süsteemid.

RFP-del, mis nõudsid täielikku täpsustusvooru, on peaaegu alati üks ühine joon:

Oleme näinud ettevõtteid, kes kulutavad nädalaid hindamiskriteeriumide ja nõuete nimekirjade koostamisele, saadavad seejärel RFP, mis ei maini mitu saadetist nad kuus töötlevad.

Ilma selleta arvavad tarnijad. Ja kui nad arvavad, tulevad pakkumised tagasi üldised, hinnad pole lõplikud ja pole midagi konkreetset, mida võrrelda.

Näiteks vajab globaalne tootja 10 laoga ja SAP-iga täiesti erinevat pakkumist kui ühe asukohaga turustaja, kes juhib logistikat tabelarvutustes. Kui tarnija ei suuda aru saada, kumb sa oled, jätab ta endale tagavariant – ja sa saad pakkumisi, mis ei kohusta millekski.

Lahendus võtab ühe pärastlõuna. Vasta neile kümnele küsimusele RFP-s enne selle väljasaatmist.

1. Organisatsioon ja ulatus. Mitu juriidilist isikut ja asukohta on ulatuses? Kas juurutamine on paralleelne või faasidena? Kui iseseisvalt asukohad tegutsevad – eraldi vedajalepingud, eraldi meeskonnad?
2. Saadetiste mahud. Igakuised ja igapäevased saadetiste arvud asukoha kohta, keskmine ja tipp. Hooajalisus. Sissetuleva ja väljamineva jaotus.
3. Transpordiliikide jaotus. Milline osa on pakid, LTL, FTL, õhk, meri? Millised liigid kasvavad? Millised on operatiivselt kõige kriitilisemad?
4. Vedajate maastik. Mitu vedajat asukoha ja transpordiliigi kohta? Ühised üle asukohtade või hallatavad kohalikult? Kas on strateegilisi vedajaid, keda tuleb prioritiseerida, või kliendi määratud vedajaid, keda ei saa vahetada?
5. Geograafia ja kaubateed. Millised piirkonnad on ulatuses? Millised teed on kõige olulisemad: riigisisene, piiriülene, mandritevaheline? Peamised sadamad või logistikakeskused?
6. Praegune olukord. Kuidas saadetisi täna planeeritakse, tellitakse ja jälgitakse? ERP-s, tabelarvutustes, vedajate portaalides, e-postiga? Millised on praeguse protsessi peamised valupunktid?
7. Finantsseadistus. Kes maksab transpordi eest – üks üksus või mitu? Kas on kolmanda osapoole või kliendi kontonumbreid? Kuidas veokulud täna kirjendatakse ja valideeritakse?
8. Ärimudel. B2B, B2C? Kui mõlemat, siis mis jaotuses. Operatiivsed ja süsteeminõuded erinevad üsna oluliselt.
9. Integratsioonide maastik. Millised süsteemid peavad TMS-iga ühenduma: ERP, WMS, CRM? Kas on olemasolevaid vedajate integratsioone, mida säilitada? Kui automatiseeritud peab see olema esimesest päevast?
10. Ajakava ja piirangud. Kas on käivitamise sihtkuupäev? Kas on sisemisi verstaposte – majandusaasta lõpp, tippperiood, süsteemide migratsioonid –, mis mõjutavad ajakava?

Midagi siin pole keeruline kirja panna. Kuid see muudab kõike selles, mis tagasi tuleb.

Laadi alla operatiivse teabe kontrollnimekiri, et muuta need kümme küsimust täitmistabeliks, mille saad otse oma RFP-sse lisada:

Laadi alla operatiivse teabe kontrollnimekiri (.docx)

Kuidas koostada TMS-i funktsionaalseid nõudeid

Funktsionaalsed nõuded on RFP süda. Tee need õigesti ja saad selge, võrreldava pildi sellest, mida iga tarnija suudab ja ei suuda. Tee need valesti ja võid veeta nädalaid vastuste dekodeerimisele, kus kõik ütlevad „jah".

Eesmärk pole pikim nimekiri. Eesmärk on kõige ausam nimekiri.

Prioritiseeri halastamatult: kohustuslik, soovitav, tore oleks

Kõik, mida soovid, pole võrdselt oluline. Kasuta kolme kategooriat ja pea neist kinni:

1. Kohustuslik (K): mittekompromissne. Tarnija, kes seda ei täida, langeb välja, olenemata muust.
2. Soovitav (S): oluline, kuid saad hakkama ajutise lahenduse või lähituleviku arenguplaani lubadusega.
3. Tore oleks (T): hea teada, kuid jääb kõige eelneva taha.

Enamikus nimekirjades on kohustuslikke nõudeid liiga palju. Kui kõik on kriitiline, pole miski seda. Ole aus selle suhtes, mis tõeliselt takistaks süsteemi toimimist, ja märgi ainult need kohustuslikuks.

Palu tarnijatel klassifitseerida funktsionaalsuse kaetus: natiivne / kolmas osapool / kohandamine

Iga nõude kohta peavad nad vastama ühega järgmistest:

See veerg on koht, kus pakkumised usalduse teenivad või kaotavad. Tarnija, kes vastab ausalt ja kirjutab ei toetata seal, kus see tõsi on, näitab, kuidas ta partnerina käitub. Tarnija, kes vastab natiivne kõigele, räägib sulle samuti midagi olulist.

Ole küsimuses täpne

„Kas süsteem toetab vedajate hindade kuvamist?" annab sulle kasutuskõlbmatu „jah". „Kas süsteem suudab arvutada veohinnad iga vedaja jaoks, sealhulgas nende jaoks, kellel pole hinna API-t, ja kuvada neid saadetise kohta kõrvuti?" annab midagi, mida saad tegelikult hinnata.

Kus lõpeb ERP ja algab TMS?

Üks levinumaid segadusallikaid veohaldustarkvara hindamisel on see, kus TMS lõpeb ja ERP algab.

Finantsprotsessid nagu pearaamatu kodeerimine, maandumiskulu ja veokulude audit käsitletakse sageli ERP poolel, kusjuures TMS edastab andmed ERP-sse. See on normaalne ja sageli õige seadistus. Kuid see tuleb selgelt välja kirjutada. Kui tarnija vastab „käsitletakse ERP-integratsiooni kaudu" mõnele sinu kohustuslikule nõudele, uuri täpselt, mida see sinu juurutuse jaoks tähendab, ja kes selle ehitab.

Kirjelda eesmärki, mitte tehnilist lahendust

Kirjelda, mida pead saavutama, mitte seda, kuidas süsteem seda tehniliselt peaks tegema. Liiga täpsed tehnilised nõuded lükkavad head lahendused välja valel põhjusel. Jäta tarnijatele ruumi näidata paremat viisi, kui sul endal meeles oli, sest mõnikord on neil see olemas.

30-realine aus, prioritiseeritud nõuete nimekiri ütleb sulle rohkem kui 150-realine tabelarvutus, kus kõik on kriitiline ja iga tarnija on kõik kastid linnukesega märkinud.

Algnimekiri TMS-i nõuetest, mida kohandada

Enamik esmakordseid ostjaid soovib nimekirja koostamisel eelise saada, seega siin on meie kogemusest pärit näidisnimekiri, juba kategoriseeritud, mida saad oma operatsiooni jaoks kohandada. Täielik nimekiri on allpool allalaaditavas hindamislehes, kuid see annab piisava ülevaate.

Laadi alla funktsionaalsete nõuete hindamisleht, mis on juba koostatud prioriteetide ja kaetuse veeruga iga tarnija kohta:

Laadi alla funktsionaalsete nõuete hindamisleht (.docx)

Kuidas võrrelda TMS-i kulusid (ja koostada 3-aasta mudel)

„Kui palju TMS maksab?" on küsimus, mida ostjad kõige rohkem tahavad vastatud ja mida tarnijad armastavad vältida. Kuid tellimustasu on harva sinu lõplik kulu. Keskmise suurusega mitme asukohaga veotellija jaoks võivad juurutamine ja integratsioon kolme aasta kogukulust rohkem moodustada kui igakuine tasu – ja just see rida jääb tarnijatel kõige ebamäärasemaks. Seega on oskus siin küsimus nii struktureerida, et vastused tuleksid tagasi võrreldavad ja tegelik kulu oleks nähtav.

Ligikaudse orientiirina: keskturu pilvepõhine veohaldustarkvara maksab tavaliselt mõnisada kuni mõni tuhat eurot kuus, samas kui traditsioonilised ettevõttetaseme süsteemid maksavad kümnetest tuhandetest kuni üle miljoni euro aastas, juurutamisega, mis võib ulatuda kuue- või seitsmekohaliseks. See on lai vahemik – ja just seetõttu on võrreldav mudel olulisem kui ükski üksik arv. Tegeliku TMS-i tarnijate hindade kohta vaata meie uuringut parimate TMS-i tarnijate kohta.

TMS-i hinnakomponendid

Peaaegu iga TMS-i pakkumine on mingi kombinatsioon järgmistest:

Koosta kolme aasta kulumudel enne võrdlemist

Tarnija, kes tundub tellimustasu poolest odav, võib osutuda kõige kallimaks, kui juurutamine, tehingutasud ja vedajate lisamise kulud arvesse võtta. Käivita iga tarnija läbi sama mudeli:

3-aasta kulu = juurutamine + (aastane tellimustasu × 3) + (saadetise tasu × aastane maht × 3) + tugi + eeldatavad vedajate ja integratsioonide lisad.

Kasuta oma tegelikke mahtusid, mitte tarnija korralikku näidet. See üks tabel kipub eelvaliku järjestust ümber loksutama.

Jälgi erinevaid hinnakomponente, mitte ainult baastasu

Mõned tarnijad hindavad tellimustasu madalalt ja teenivad selle tagasi tehingutasude või vedajapõhiste tasudega. See pole iseenesest halb, kuid muudab seda, kes on odavaim, kui kasvad. Kui sinu maht tõuseb, võib saadetisepõhine mudel tasase hinnaga mudeli kiiresti ületada. Küsi näidisarvet ja tellimustingimusi, et võrrelda seda, mida tegelikult maksad, mitte reklaamitud hinda.

Üks küsimus, mida tasub igale tarnijale esitada: kas uued vedajate integratsioonid on hinna sees või arvestatakse iga kord eraldi? Mõned TMS-i platvormid küsivad 5 000–10 000 eurot uue vedaja integratsiooni eest ja see võtab kuid, teised ehitavad uusi vedajate integratsioone ilma lisatasuta. Keskmise suurusega veotellija jaoks, kes aastate jooksul vedajaid lisab, võib see üks vastus kolme aasta kogukulust rohkem mõjutada kui kogu tellimustasu rida.

Kuidas hinnata TMS-i pakkumisi peale hinna

Pakkumised on käes. Kõik tunduvad mõistlikud, enamik ütleb sinu nõuetele jah, ja hinnad on sarnases vahemikus. Mis nüüd?

Just selles kohas langevad meeskonnad vaikselt tagasi hinna peale, sest kõik muu tundub raskemini võrreldav. Ära tee seda. Siin on see, mis neid tegelikult eristab.

1. Vedajate ühenduvus.

TMS-i puhul on vedajate ühenduvus vundament. Kuidas tarnija vedajatega tegelikult ühendub – otseste API/EDI integratsioonide, kolmanda osapoole agregaatorite kaudu või üldse mitte (e-post + PDF-tellimused olenemata nende IT-võimekusest)? Mis juhtub, kui vajad vedajat, keda nad veel ei toeta – kui kaua see võtab ja mida maksab?

Tarnija, kellel on sügavad, otsesed vedajate ühendused, on erinev loom sellest, kes suunab kõik läbi vahekihi. Erinevust tunned tellimuste usaldusväärsuses, jälgimise kvaliteedis ja selles, kas saad vedaja lisada ilma iga kord uut äriläbirääkimist alustamata.

2. Vedajate teenustaseme ühtlustamine – see on olulisem, kui enamik inimesi mõistab.

Vedajate digitaalsed võimekused pole võrdsed. Mõnel on keerukad API-d, mis katavad reaalajas hindade päringu, ETA prognoosimise, aadressi valideerimise, kaubaetikettide genereerimise ja üksikasjalikud jälgimissündmused. Teised saadavad sulle tellimuse kinnituse e-postiga ja sellega vestlus lõpeb. Enamikus vedajate võrgustikes on mõlemat tüüpi korraga.

See muutub sinu probleemiks hetkel, kui ühendad oma ERP-i või WMS-i TMS-iga. Kui sinu integratsioon eeldab igalt vedajalt täielikku andmekogumit – tellimuse kinnitus, jälgimislink, kaubaetikett, kuluprognoos –, kuid mõned vedajad ei suuda seda pakkuda, tekivad erandid, käsitsi lahendused ja augud sinu andmetes. Üks nõrk vedaja rikub kogu töövoo järjepidevuse.

Erinevad veohaldustarkvara pakkujad lahendavad seda kahel viisil, ja tasub otsustada, kumba soovid, enne kui ühtegi pakkumist loed:

• Õhem TMS edastab läbi selle, mida iga vedaja pakub, ja lünkadega tegelemine jääb sinu ERP-le või käsitsi tööle. Lihtsam integratsioon, rohkem erandeid sinu poolel.
• TMS, mis normaliseerib andmed ja täidab lüngad ise: arvutab veohinnad sinu üleslaaditud hinnakirja põhjal, kui hinna API puudub; hindab tarneaega, kui vedaja ETA-t ei paku; genereerib kaubaetikette, kui vedaja seda ei suuda; kui jälgimine puudub, laseb vedajatel jälgimise verstaposte käsitsi sisestada, ja muud. Tarkvara täidab sinu vedajate tehniliste võimekuste lüngad ja sinu ERP näeb ühtset struktuuri.

Pakkumisi hinnates küsi tarnijatelt otse: kuidas käsitlete vedajaid, kellel on piiratud digitaalsed võimekused? Vastus räägib palju sellest, kui küps nende platvorm tegelikult on.

3. Integratsiooni ausus.

Pööra tähelepanu sellele, kuidas tarnijad kirjeldavad integratsiooni ulatust (kes mida teeb). Pakkumine, mis ütleb selgelt „ERP-poolne arendus on teie ülesanne, siin on see, mida meie pakume ja kuidas toetame", on usaldusväärsem kui see, mis vihjab „sujuvale integratsioonile", selgitamata, kumb pool millise integratsiooni eest vastutab – sina või nemad. Integratsiooniga seotud üllatused on üks levinumaid põhjusi, miks TMS-i projektid aja- ja eelarvepiiridest üle lähevad.

4. Juurutamise lähenemine.

Faasidena lähenemine – esmalt käsitsi operatiivne valideerimine, seejärel automatiseerimine – on tavaliselt väiksema riskiga kui kõik-korraga käivitamine. Saad kinnitada, et süsteem töötab sinu tegelike töövoogude jaoks, enne kui toetud sellele kogu operatsiooniga. Meie kogemusest: tarnijad, kes pakuvad seda ilma küsimata, on tavaliselt läbi elanud keerulise käivitamise. Need, kes müüvad täielikku automatiseerimist esimesest päevast, sageli pole.

5. Viited

Küsi viiteid ettevõtetelt, kellel on sarnased operatsioonid, mitte ainult sarnane suurus või töötajate arv. Viide ühe asukohaga turustajalt pole eriti kasulik, kui juhid mitme asukohaga tootmisoperatsiooni SAP-integratsiooniga. Ja küsi konkreetseid küsimusi: „Kuidas läks vedajate liitmine?" „Kuidas läks integratsioonprotsess?" „Mis juhtus, kui midagi ei töötanud ootuspäraselt?"

6. Pakkumine ise.

See, kuidas TMS-i tarnija sinu RFP-le vastab, on eelvaade sellest, kuidas ta partnerina käitub. Kas nad vastasid sinu küsimustele otse, või mähkisid kõik reservatsioonidesse? Kas nad tõid lüngad ausalt välja, või väitsid täielikku kaetust iga nõude puhul? Kas nad näitasid, et mõistsid sinu operatsiooni, või saatsid sulle oma standardpresentatsiooni veidi muudetud versiooni?

Pakkumine, mis tunnistab ei toetata kahes kohas ja selgitab miks, on väärtuslikum kui see, mis kõigele jah ütleb. Tõe saad teada mõlemal juhul. Parem avastada see hindamise ajal kui käivitamisel.

Laadi alla tarnijate hindamismaatriks, et hinnata tarnijaid kaalutud kriteeriumide alusel:

Laadi alla tarnijate hindamismaatriks (.docx)

TMS-i tarnija esitlusvoor

Kirjalikud pakkumised räägivad sulle seda, mida tarnija väidab. Esitlused näitavad, kas nad suudavad seda tõestada.

Selleks hetkeks peaks sul olema eelvalik 2–3 tarnijast. Esitlusvooru eesmärk on panna pakkumine tõelise surve alla ja vaadata, kas süsteem töötab sinu tegelike stsenaariumide puhul.

Küsi töötavat läbivaatust, mitte demot

Demo on ettevalmistatud järjestus, mis näitab süsteemi parimal kujul. Läbivaatus on see, kui ütled: „Näita mulle, kuidas käsitleksite seda saadetist meie Hollandi laost, meie vedajaga, meie kokkulepitud hinnaga," ja vaatad, mis tegelikult juhtub.

Valmista enne kohtumist ette 2–3 päris stsenaariumi oma operatsioonist: tavaline väljaminev veotellimus, saadetis, mis vajab spot-hinnapakkumist, ja midagi keerulist – näiteks hilinenud saadetis või vedaja, kes jälgimist ei paku. Kui tarnija kaldub pidevalt tagasi lihvitud demo juurde, selle asemel et sinu stsenaariumi läbi mängida, on see juba vastus.

Seisa silmitsi lünkadega

Igas TMS-i pakkumises on neid. Mine otse nende kohtade juurde, kus tarnija vastas osaliselt või kus sul on kahtlusi, ja jää sinna. Ära lase neil libiseda tagasi millegi juurde, mis töötab suurepäraselt. Kuidas see täpselt töötab? Kes mida teeb? Mis juhtub, kui see ei tööta ootuspäraselt?

Too õiged inimesed tuppa

TMS-i tarnija poolel peaksid esitlejad olema need, kes tegelikult sinu juurutuse kallal töötavad, mitte ainult müügimeeskond. Küsi seda selgesõnaliselt. Sinu poolel too kaasa keegi IT-st (kui integratsioon on ulatuses) ja vähemalt üks inimene, kes süsteemi iga päev tegelikult kasutab. Nad küsivad teistsuguseid küsimusi kui hankeosakond, ja soovid mõlemat küsimuste komplekti esitada.

Teine voor ainult vajadusel

Keeruka otsuse puhul tasub korraldada teine sessioon, mis keskendub konkreetsetele teemadele. Näited teemadest:

• Turvalisus ja andmekaitse – küsi läbitungimistesti aruannet või turvasdokumentatsiooni, kui sinu IT- või infoturbe meeskond seda nõuab
• Integratsiooni arhitektuur – tehniline sessioon sinu IT-meeskonna ja tarnija vahel
• Äritingimused – vaata leping, SOW ja eeldused rida-realt läbi enne ametlike läbirääkimiste alustamist

Ära broneeri seda ainult selleks, et esimene kohtumine rohkemate inimestega uuesti läbi mängida. Kas see lahendab konkreetsed lahtised küsimused, või ei peaks seda üldse toimuma.

Kinnita kohustused kirjalikult

Kõik, mida tarnija koosolekul lubab, kuid mis pole kirjalikus pakkumises, tuleb enne edasiliikumist kirjalikult kinnitada. Suulised lubadused ei ela lepinguläbirääkimistest üle. Kui TMS-i tarnija ütleb millegi olulise kohta „jah, me suudame seda teha", saada samal päeval e-kiri ja palu neil kinnitada.

TMS-i leping ja töökirjeldus (SOW): mida enne allkirjastamist kontrollida

Oled tarnija valinud. Enamik meeskondi „hingab välja" selles kohas. Soovitan seda mitte teha, sest just siin muutuvad hindamise käigus tähelepanuta jäänud üksikasjad vaikselt sinu probleemiks.

Jõua organisatsioonisiseselt kokkuleppele enne läbirääkimisi

Tea oma tingimusteta nõudeid, vastuvõetavaid kompromisse ja punaseid jooni enne vestluse algust. Nõuete muutmine läbirääkimiste keskel võtab aega, kulutab usaldust ja võib mõnikord kaotada sulle TMS-i tarnija, keda tegelikult tahtsid. Lahenda see esmalt organisatsioonisiseselt, seejärel läbirääkimised.

Mõista, mida ostad: SaaS, mitte litsents

Kaasaegsed TMS-i platvormid on SaaS-tellimused, mitte tarkvaralitsentsid. Tellid teenust, mida tarnija majutab, hooldab ja uuendab – sa ei osta süsteemi täielikult. See muudab seda, mida leping peab katma: tellimustingimused, lõpetamine, andmete omand ja ekspordiõigused, tööaja kohustused, toe reageerimisajad. Standardsed hanke mallid pole selle mudeli jaoks kirjutatud, seega veendu, et sinu omad on järele jõudnud.

SOW on sama oluline kui leping

Töökirjeldus täpsustab, mis tarnitakse, kelle poolt ja millal: konto konfigureerimine, vedajate liitmine, integratsioonitoe, koolitus ja vastuvõtukriteeriumid, mis ütlevad, et juurutamine on tegelikult lõpetatud. Kui seda pole SOW-s, pole see hinna sees, olenemata sellest, mida koosolekul või e-postis öeldi. Loe eelduste jaotist eriti hoolikalt. Seal on ulatus tingimuslikult määratletud. Kui sinu vedajate nimekiri osutub suuremaks kui märgitud, või sinu ERP vajab mittestandardset integratsiooniformaati, otsustab eelduste jaotis, kas see on kiire vestlus või hinnastatav muudatustaotlus.

Ole selgesõnaline selles, mis on ulatusest väljas

Kohandatud arendus, kohapealne koolitus, andmete migratsioon, integratsioonitöö sinu süsteemides, vedajapoolsed muudatused. Need on tavaliselt eraldi hinnastatud. Selle paberile saamine enne allkirjastamist eemaldab kõige levinuma ja kõige välditavama juurutushõõrdumise allika: kaks poolt, kes kumbki eeldasid, et midagi erinevat on hinna sees.

Lepi kasutuselevõtu plaan kokku enne allkirjastamist

Mitte pärast. Vedajate prioritiseerimine, konfiguratsiooni ajakava, integratsiooni verstapostid, käivitamiskriteeriumid – lahenda kõik see siis, kui sul on veel läbirääkimisjõud. Tarnija, kes ei suuda lepingufaasis selget kasutuselevõtu plaani anda, räägib sulle midagi, mida soovid teada enne kohustuse võtmist.

Pärast allkirjastamist: TMS-i juurutamine ja kasutuselevõtt

Suurem osa tegelikust riskist elab pärast allkirjastamist. Kolm asja otsustavad, kuidas see läheb.

1. Andmete migratsioon

Vedajalepingud, hinnakirjad, aadressiraamatud, ajaloolised saadetised. Otsusta varakult, mida pead üle migreerima, mis puhastatakse esmalt ja kes töö eest vastutab. Korratu lähteandmestik on kõige levinum põhjus, miks käivitamise kuupäev edasi lükkub. Puhasta see enne migreerimist, mitte migreerimise ajal.

2. Vedajate liitmise järjestus

Kõiki vedajaid ei ühendata esimesel päeval. Prioritiseeri mahu ja kriitilisuse järgi, vii esimesed mõned ellu ja valideeri, seejärel laienda. Just siin tasub end ära see faasidena lähenemine, mille kohta hindamise ajal küsisid.

3. Kasutajate omaksvõtt

Inimesed, kes iga päev saadetisi tellivad, peavad tahma uut süsteemi kasutada. Kaasa vähemalt üks neist juba RFP faasist alates, koolitada neid korralikult kasutuselevõtu (hypercare) ajal ja veendu, et igapäevane töövoog on tõeliselt kiirem kui see, mida nad varem tegid. Tehniliselt laitmatu juurutus, mida meeskond lihtsalt ei kasuta, on ikkagi ebaõnnestunud juurutus.

10 levinud TMS-i RFP viga

Mustrid, mida näeme kõige sagedamini, kõik ühes kohas:

• Operatiivne kontekst puudub. Suurim viga. Tarnijatele ei esitata mahtusid, asukohtade struktuuri ega vedajate maastikku. Täpsustusvoor ja üldised hinnad on garanteeritud.
• Kõik on kohustuslik. Kui iga nõue on kriitiline, on prioriteetide veerg kasutu kaal ja sa ei suuda eristada dealbreakerit tore-oleks-nõudest.
• Ebamäärane ajakava. Kuupäevade puudumine tähendab, et tarnijad ei suuda oma pingutust hinnata, seega tulevad pakkumised sama ebamäärased.
• Liigne tehniline täpsustamine. Tehnilise lahenduse ette kirjutamine operatiivse tulemuse asemel lükkab head lahendused välja valel põhjusel.
• ERP/TMS piiri ignoreerimine. Eeldatakse, et TMS omab finantsprotsesse, mida ERP tegelikult omab, ja avastatakse see juurutuse keskel.
• Hinnale tagasilangmine. Valimine tellimustasu pealkirja järgi ilma kolme aasta mudelita või vedajate ühenduvust ja integratsiooni ausust kaalumata.
• Demo asemel läbivaatuse nõudmata jätmine. Tarnija lihvitud järjestuse vaatamine, selle asemel et lasta süsteemil sinu tegelikke stsenaariume testida.
• Viited, mis ei vasta sinu operatsioonile. Muljetavaldavate logode vaatamine, kuid need ettevõtted võivad omada logistikaoperatsioone, mis ei sarnane sinu omaga üldse. Küsi viiteid, mis sarnanevad sinuga, seejärel küsi neilt, kuidas kasutuselevõtt ja integratsioon tegelikult läksid.
• Kasutuselevõtu jätmine allkirjastamise järgseks. Plaan, mille läbirääkimised pead läbirääkimisjõuga, on parem kui see, mille pead ilma selleta.
• Protsess, mis on õige tarnija jaoks liiga koormav. Bürokraatia koormus, mis võib välja filtreerida kaasaegsed platvormid, mis oleksid sind kõige paremini teeninud.

Tasuta TMS-i RFP mallid

Koostasime viis malli RFP-dest, millele vastame, et sa ei peaks tühja lehe ees alustama:

1. RFP dokumendi mall. Täielik struktuur sellest juhendist.
2. Funktsionaalsete nõuete hindamisleht. Prioritiseeritud, kaetuse veeruga iga tarnija kohta.
3. Operatiivse teabe kontrollnimekiri. Kümme küsimust täitmistabelina.
4. Tarnijate hindamismaatriks. Kaalutud punktisummad tarnijate lõikes.
5. RFP ajakava mall. Tegevused, kuupäevad, vastutajad.

Laadi alla pakett – kõik viis, tasuta, e-posti aadressi pole vaja. Võta see, mis on kasulik, jäta ülejäänu:

Laadi alla täielik TMS-i RFP mallide pakett (.zip)

Cargoson on veohaldustarkvara, mida kasutavad keskmise suurusega tootjad ja hulgimüüjad üle Euroopa ja Põhja-Ameerika. Vastame sellistele RFP-dele nagu see, mida oled kirjutamas, pidevalt – seega kui soovid oma nõudeid enne kirjutamist läbi arutada, aitame hea meelega mõtted selgeks saada, ilma kohustuseta.

Broneeri tasuta 30-minutiline konsultatsioon siit

Vii protsess hästi läbi ja see on iga kulutatud tunni väärt.