Kaip parašyti TMS RFP: mūsų patirtis [+ 5 nemokamos šablonų rinkinys]

Mes kiekvieną savaitę atsakome į transporto valdymo sistemos RFP (pasiūlymų užklausas). Vieni jų – tikras malonumas. Kiti – pamoka, kaip to nedaryti.

Šis straipsnis – tai, ką pats sukurčiau, jei šiandien nuo nulio organizuočiau TMS atrankos procesą. Jis grindžiamas RFP, į kuriuos esame atsakę, pasikartojančiais modeliais įvairiose įmonėse ir pramonės šakose, tuo, ką dauguma jų apima, ir dažniausiomis klaidomis, kurias pastebime.

Jei esate pirkimų specialistas, didžioji dalis šio turinio jums bus pažįstama. Tikimės, kad bent vienas nereikalingas patikslinimų etapas bus sutaupytas.

Kas yra TMS RFP?

TMS RFP (pasiūlymų užklausa) – tai struktūrizuotas dokumentas, siunčiamas transporto valdymo sistemų tiekėjams. Jame aprašoma jūsų logistikos operacija ir kiekvieno tiekėjo prašoma pasiūlyti, kaip jų sistema su ja susidorotų – pagal tuos pačius reikalavimus. Visas tikslas – palyginamumas. Tie patys klausimai, tas pats formatas, tas pats kontekstas, kad gautus atsakymus būtų galima sudėti greta, o ne skaityti kaip penkis atskirus pardavimų pasiūlymus.

RFP reikia ne visada. Jis atsipirka tada, kai sprendimas yra sudėtingas arba kai jį reikės pagrįsti kitiems žmonėms organizacijos viduje. Jei jūsų logistikos operacijos paprastos, pakaks produkto demonstracijos ir pokalbio su keliais tiekėjais.

Ar jums tikrai reikia vykdyti TMS RFP konkursą?

Klysti čia – brangiausia klaida visame TMS atrankos procese. Tai nuspręskite pirmiausia, prieš bet ką kita.

Viskas priklauso nuo jūsų logistikos sudėtingumo, o ne nuo įmonės dydžio.

Vykdykite struktūrizuotą TMS RFP konkursą, jei siunčiate krovinius iš kelių vietų, naudojate kelis transporto būdus ir sistemai reikia integruotis su jūsų ERP. Tokiu atveju būtina, kad visi tiekėjai būtų sugretinti vienas šalia kito – kad nieko svarbaus nepraslystų pro akis. Tiekėjai prie vežėjų jungiasi labai skirtingais būdais. Vienas tai vadina „natyviu", kitas tyliai nukreipia per tarpininką. Nestruktūrizuotame procese to nepastebėsite tol, kol nepasirašysite sutarties. O tada jau per vėlu.

Atsisakykite formalaus RFP konkurso, jei dirbate iš vienos vietos su keliais vežėjais ir jau žinote, ko jums reikia. Kodėl? Nes vos pradėjus RFP procesą, automatiškai patenkate į įmonių lygio kainodaros kategoriją. 2–3 kokybiški demonstraciniai pristatymai su konkrečiais klausimais dažnai leidžia gauti geresnę sistemą, pigiau ir greičiau. Pasakykite tiems 2–3 tiekėjams, ką siunčiate ir kokią problemą sprendžiate, ir paprašykite parodyti tai jų realioje sistemoje. Per valandą jau žinosite atsakymą. O jei daugiausia siunčiate siuntinius, o ne padėklus ar krovinius, gali būti, kad jums apskritai nereikia pilnos TMS – kelių vežėjų siuntimo programinė įranga yra atskira, lengvesnė kategorija, sukurta būtent tam.

Todėl prieš pradėdami būkite sąžiningi su savimi, kuris variantas jums tinkamesnis. Nereikalingas RFP procesas – lėčiausias ir brangiausias būdas įsigyti TMS.

Nereikalingas RFP procesas – lėčiausias ir brangiausias būdas įsigyti TMS.

Dar vienas įspėjimas tiems, kurie vis dėlto pasirenka pilną RFP. Procesas, perkrautas valdymo kalbos, metodologinių struktūrų ir fiksuotų kainų reikalavimų, atsakymui reikalauja savaičių, o tokią naštą lengviau pakelti didelėms, nusistovėjusioms įmonėms. Taigi, jei jums iš tiesų geriau tiktų lankstesnė, modernesnė platforma, pernelyg biurokratiškas procesas gali tyliai ją išfiltruoti dar prieš jums pamatant demonstraciją.

Tikslas – rasti tinkamą sprendimą jums. Kurkite procesą atsižvelgdami į tai, o ne į paties proceso valdymą.

TMS RFP procesas: 9 žingsniai

TMS atranka nebūtinai turi būti sudėtinga. Tačiau jai reikia aiškios sekos. Praleiskite žingsnius – ir už tai sumokėsite vėliau, paprastai diegimo metu, kai anksti nepatikslinti prielaidos virsta brangiais netikėtumais.

Gerai organizuotas procesas trunka 8–12 savaičių. Paprastesnei apimčiai – mažiau, ir retai kada reikia daugiau.

Štai seka, kuri veikia:

1. Rinkos apžvalga. Prieš rašydami bet kokį reikalavimą, skirkite laiko suprasti, kas yra rinkoje. TMS rinka per pastaruosius penkerius metus labai pasikeitė: yra gerų įmonių lygio platformų, gerų vidutinės rinkos platformų ir tikrai pajėgių modernių SaaS transporto valdymo programinės įrangos sprendimų, kurių prieš penkerius metus dar nebuvo. Sudarykite ilgąjį 5–8 TMS tiekėjų sąrašą, vertų kreiptis.
2. NDA (konfidencialumo sutartis). Siųskite ją anksti. Dalinsitės operaciniais duomenimis – apimtimis, vežėjų pavadinimais, vidinės sistemos detalėmis – o pasirašyta NDA prieš išsiunčiant RFP yra standartinė praktika, apsauganti abi puses.
3. RFI (neprivaloma). Trumpa informacijos užklausa praverčia, jei jūsų ilgasis sąrašas platus ir norite atfiltruoti tiekėjus prieš investuodami į pilną RFP procesą. Laikykitės vieno puslapio: įmonės pristatymas, pagrindiniai pajėgumai, apytikslė kainų riba. Pakankamai, kad sudarytumėte trumpąjį sąrašą, neprašydami tiekėjų rašyti esė.
4. RFP. Pagrindinis dokumentas. Jis suteikia kiekvienam tiekėjui viską, ko reikia tiksliam pasiūlymui. Daugiau apie tai – kitame skyriuje.
5. Klausimų ir atsakymų langas. Visada jį įtraukite. Tiekėjai turės klausimų, o atsakymai dažnai pagerina kiekvieną gautą pasiūlymą. Vykdykite raštu, visus klausimus ir atsakymus dalinkite su visais tiekėjais vienu metu. Tai palaiko proceso švarumą ir palyginamumą.
6. Trumpasis sąrašas ir pristatymai. Įvertinkite raštinius pasiūlymus, tada pakvieskite 2–3 tiekėjus pristatymui. Pristatymas turėtų apimti tiesioginę sistemos demonstraciją pagal jūsų realius naudojimo atvejus, o ne bendrą demonstraciją. Jei tiekėjas negali parodyti jūsų scenarijaus savo sistemoje, tai jau savaime yra svarbi informacija.
7. Antras etapas (jei reikia). Sudėtingam sprendimui verta skirti gilesnį susitikimą, skirtą konkretiems trūkumams – saugumui, integracijai, komercinėms sąlygoms. Neplanuokite jo, jei neturite realių likusių klausimų.
8. Sprendimas ir sutartis. Suderinkite pozicijas viduje prieš pradėdami derybas. Žinokite savo būtinuosius reikalavimus, priimtinus kompromisus ir ribas, kurių neperžengsite.
9. Diegimas. Tai nesibaigia pasirašius sutartį. Geriausi RFP rezultatai pasiekiami tada, kai diegimo planas suderinamas prieš pasirašant sutartį.

TMS RFP tvarkaraštis, kurį galite nukopijuoti

Apytikslė trukmė pagal apimtį:

• Viena nesudėtinga vieta: 6–8 savaitės (pilnas RFP gali būti nereikalingas).
• Kelios vietos + ERP integracija: 8–12 savaičių.
• Globalus, daugiaobjektis, sudėtinga integracija: 12–20 savaičių, tikėtini du pristatymų etapai.

Atsisiųsti RFP tvarkaraščio šabloną (.docx)

Ką įtraukti į TMS RFP dokumentą

RFP dokumentas – svarbiausias jūsų įrankis šiame procese. Geras RFP dokumentas atlieka didžiąją dalį vertinimo darbo už jus, todėl laikykitės tikslumo. Glaustas 10 puslapių RFP yra geresnis nei 30 puslapių dokumentas, bandantis apimti viską.

1. Lydraštis ir tikslas

Vienas puslapis. Kas esate, ko ieškote, kodėl dabar. Laikykitės faktų. Tiekėjams nereikia vizijos pareiškimo – jiems tereikia suprasti jūsų operacinę problemą.

2. Tvarkaraštis

Aiškus grafikas su realiomis datomis: RFP išsiuntimas, klausimų ir atsakymų terminas, pateikimas, pristatymų langas, sprendimas. Tiekėjai planuoja savo atsakymo pastangas pagal šį grafiką. Neaiškūs tvarkaraščiai duoda neaiškius pasiūlymus.

3. Įmonės ir operacinė informacija

Čia dauguma RFP atsilieka, ir tai yra skirtumas tarp palyginamų pasiūlymų ir patikslinimų etapo. Neapsiribokite verslo aprašymu – aprašykite savo logistikos operaciją. Kiek vietų. Kiek juridinių subjektų. Kokie transporto būdai (siuntiniai, LTL, FTL, oras, jūra, geležinkelis). Kurie regionai. Apytikslės apimtys. Dabartinės sistemos. Tai, kas laikoma „geru rezultatu", skiriasi priklausomai nuo sektoriaus – elektronikos, mašinų, chemijos ar spausdinimo ir pakuočių gamintojų reikalavimai nėra vienodi. Tai kontekstas, kurio tiekėjams reikia, kad galėtų tiksliai parengti pasiūlymą. Jei čia nepateiksite pakankamai detalių, pralesite dvi savaites atsakinėdami į patikslinimo klausimus, kurių buvo galima visiškai išvengti. Šiai temai skirtas atskiras skyrius toliau.

4. Funkciniai reikalavimai

Lentelė, kurioje nurodyta, ką sistema turi daryti, surikiuota pagal svarbą: būtina / pageidautina / pageidaujama (tinka „Excel"). Paprašykite tiekėjų prie kiekvieno reikalavimo nurodyti aprėpties lygį: a) natyvus, b) trečiosios šalies, c) pritaikymas arba d) nepalaikoma. Tai ir daro pasiūlymus palyginamais. Daugiau apie tai, kaip sudaryti šį sąrašą, – toliau.

5. Vertinimo kriterijai

Pasakykite tiekėjams, kaip priimsite sprendimą: funkcionalumas, kaina, diegimo metodas, rekomendacijos, saugumas, komanda. Jei esate pasirengę, pasidalinkite svoriais. Kuo skaidriau elgsitės, tuo geresni bus pasiūlymai.

6. Kainodaros modelis

Prašykite visiško išskaidymo: prenumerata, diegimas, sandorių mokesčiai, palaikymas ir visa kita. Jei įmanoma, paprašykite pavyzdinės sąskaitos faktūros. Tiekėjų kainodaros struktūros labai skiriasi, o paslėptos išlaidos turi įprotį pasirodyti vėlai. Stenkitės tai išsiaiškinti kuo anksčiau.

7. Atsako formatas

Tiksliai nurodykite tiekėjams, kaip norite, kad pasiūlymas būtų struktūrizuotas, o jei pateikiate šablonus – reikalaukite jų laikytis. Palyginami pasiūlymai vertinimo metu sutaupo dienas, o formatas visiškai priklauso nuo jūsų.

Atsisiųskite RFP dokumento šabloną, kad pradėtumėte nuo visos aukščiau aprašytos struktūros:

Atsisiųsti RFP dokumento šabloną (.docx)

Operacinė informacija, kurios dauguma TMS RFP neįtraukia – ir kodėl ji svarbiausia

Šis skyrius – tai, ką norėčiau, kad kiekvienas TMS RFP autorius perskaitytų pirmiausia.

Mes atsakome į daug TMS konkursų. Beveik kiekvienam pasiūlymui, kurį rašome, reikia patikslinimų etapo – ir retai dėl to, kad reikalavimai buvo neaiškūs. Priežastis paprastai ta, kad trūksta operacinio konteksto: apimčių, vietų struktūros, vežėjų sąrašo, dabartinių sistemų.

RFP, kuriems prireikė pilno patikslinimų etapo, beveik visada turi vieną bendrą bruožą:

Matome įmones, savaites praleidžiančias kuriant vertinimo kriterijus ir reikalavimų sąrašus, o paskui siunčiančias RFP, kuriame nė neužsimenama, kiek siuntų jos apdoroja per mėnesį.

Be šios informacijos tiekėjai spėlioja. O kai spėlioja – pasiūlymai grįžta bendro pobūdžio, kainos negalutinės ir nėra nieko konkretaus, ką būtų galima palyginti.

Pavyzdžiui, globaliam gamintojui su 10 sandėlių ir SAP reikia visiškai kitokio pasiūlymo nei vienos vietos distributoriui, tvarkančiam logistiką skaičiuoklėse. Jei tiekėjas negali nustatyti, kuris iš jų esate, jis apsidraudžia – ir gaunate pasiūlymus, kurie nieko neįpareigoja.

Šią problemą galima išspręsti per popietę. Prieš išsiunčiant RFP, atsakykite į šiuos dešimt klausimų.

1. Organizacija ir apimtis. Kiek juridinių subjektų ir vietų įtraukiama? Ar diegimas vykdomas lygiagrečiai, ar etapais? Kaip savarankiškai veikia vietos – atskiros vežėjų sutartys, atskiros komandos?
2. Siuntų apimtys. Mėnesiniai ir dienos siuntų skaičiai kiekvienoje vietoje, vidurkis ir pikas. Sezoniškumas. Gaunamų ir siunčiamų siuntų santykis.
3. Transporto būdų pasiskirstymas. Kokia dalis tenka siuntiniams, LTL, FTL, orui, jūrai? Kurie būdai auga? Kurie operaciniu požiūriu svarbiausi?
4. Vežėjų sąrašas. Kiek vežėjų kiekvienoje vietoje ir kiekvienam transporto būdui? Bendri visoms vietoms ar valdomi lokaliai? Ar yra strateginių vežėjų, kuriems reikia teikti pirmenybę, ar kliento nurodytų vežėjų, kurių negalima keisti?
5. Geografija ir prekybos maršrutai. Kurie regionai įtraukiami? Kurie maršrutai svarbiausi: vidaus, tarpvalstybiniai, tarpkontinentiniai? Pagrindiniai uostai ar logistikos mazgai?
6. Dabartinė situacija. Kaip šiandien planuojamos, užsakomos ir sekamos siuntos? ERP, skaičiuoklėse, vežėjų portaluose, el. paštu? Kokie pagrindiniai dabartinio proceso skausmo taškai?
7. Finansinė struktūra. Kas moka už transportą – vienas subjektas ar keli? Ar yra trečiųjų šalių ar kliento sąskaitų numerių? Kaip šiandien fiksuojamos ir tikrinamos transporto išlaidos?
8. Verslo modelis. B2B, B2C? Jei mišrus – santykis. Operaciniai ir sisteminiai reikalavimai gana ženkliai skiriasi.
9. Integracijos aplinka. Kurios sistemos turi jungtis prie TMS: ERP, WMS, CRM? Ar yra esamų vežėjų integracijų, kurias reikia išlaikyti? Kiek automatizuota turi būti nuo pirmosios dienos?
10. Tvarkaraštis ir apribojimai. Ar yra numatytas paleidimo terminas? Ar yra vidinių etapų – finansinių metų pabaiga, piko sezonas, sistemų migracijos – turinčių įtakos grafikui?

Visa tai nesunku užrašyti. Tačiau tai iš esmės keičia tai, kas grįžta atgal.

Atsisiųskite operacinės informacijos kontrolinį sąrašą, kad šiuos dešimt klausimų paverstumėte pildoma lentele, kurią tiesiog įkeliate į savo RFP:

Atsisiųsti operacinės informacijos kontrolinį sąrašą (.docx)

Kaip rašyti TMS funkcinius reikalavimus

Funkciniai reikalavimai – RFP širdis. Suformuluokite juos teisingai ir gausite aiškų, palyginamą vaizdą, ką kiekvienas tiekėjas gali ir ko negali. Suformuluokite neteisingai – ir galite praleisti savaites iššifruodami atsakymus, kuriuose visur parašyta „taip".

Tikslas – ne ilgiausias sąrašas, o sąžiningiausias.

Prioritetus nustatykite griežtai: būtina, pageidautina, pageidaujama

Ne viskas, ko norite, yra vienodai svarbu. Naudokite tris kategorijas ir jų laikykitės:

1. Būtina (B): nenuginčijama. Tiekėjas, kuris to negali įvykdyti, yra eliminuojamas, kad ir ką kita siūlytų.
2. Pageidautina (P): svarbu, tačiau galite susitaikyti su laikinu sprendimu ar artimiausio laikotarpio plano pažadu.
3. Pageidaujama (N): gerai žinoti, tačiau atsiduria po visko, kas išvardyta aukščiau.

Daugelyje sąrašų yra per daug būtinų reikalavimų. Jei viskas kritiškai svarbu – niekas nėra svarbu. Būkite sąžiningi dėl to, kas iš tiesų neleistų sistemai veikti jūsų atveju, ir tik tai žymėkite kaip būtina.

Prašykite tiekėjų klasifikuoti funkcionalumo aprėptį: natyvus / trečiosios šalies / pritaikymas

Prie kiekvieno reikalavimo jie turi atsakyti vienu iš šių variantų:

Šis stulpelis – tai vieta, kur pasiūlymai uždirba arba praranda jūsų pasitikėjimą. Tiekėjas, kuris atsako sąžiningai ir rašo nepalaikoma ten, kur tai tiesa, parodo, kaip elgsis kaip partneris. Tiekėjas, kuris į viską atsako natyvus, taip pat jums kažką pasako.

Klauskite konkrečiai

„Ar sistema palaiko vežėjų kainodarą?" duos nenaudingą „taip". „Ar sistema gali apskaičiuoti krovinio kainą kiekvienam vežėjui, įskaitant tuos, kurie neturi kainodaros API, ir rodyti juos greta kiekvienai siuntai?" – tai jau kažkas, ką galite iš tikrųjų įvertinti.

Kur baigiasi ERP ir prasideda TMS?

Vienas dažniausių painiavos šaltinių transporto valdymo sistemos vertinime – kur baigiasi TMS ir prasideda ERP.

Finansiniai procesai, tokie kaip DK kodavimas, nusileidimo kaina ir krovinių auditas, dažnai tvarkomi ERP pusėje, o TMS perduoda duomenis į ERP. Tai normalu ir dažnai tinkamas sprendimas. Tačiau tai turi būti aiškiai nurodyta. Kai tiekėjas atsako „tvarkoma per ERP integraciją" prie vieno iš jūsų būtinų reikalavimų, išsiaiškinkite tiksliai, ką tai reiškia jūsų diegimui, ir kas tai kuria.

Nurodykite tikslą, o ne techninį sprendimą

Aprašykite, ko reikia pasiekti, o ne kaip sistema tai turėtų techniškai įgyvendinti. Per daug išsamūs reikalavimai dėl netinkamų priežasčių eliminuoja gerus sprendimus. Palikite tiekėjams erdvės parodyti geresnį būdą nei tas, kurį turėjote galvoje – kartais jie jį turi.

30 eilučių sąžiningų, prioritetiškų reikalavimų pasakys daugiau nei 150 eilučių skaičiuoklė, kurioje viskas kritiškai svarbu ir kiekvienas tiekėjas pažymėjo kiekvieną langelį.

Pradinis TMS reikalavimų rinkinys, kurį galite adaptuoti

Dauguma pirmą kartą perkančiųjų nori turėti pradinį sąrašo pagrindą, todėl čia pateikiamas pavyzdinis rinkinys iš mūsų patirties, jau suskirstytas į kategorijas, kurį galite pritaikyti savo operacijai. Visas sąrašas atsisiunčiamas žemiau esančiame vertinimo lape – čia pateikiama tiek, kad suprastumėte jo struktūrą.

Atsisiųskite funkcinių reikalavimų vertinimo lapą, jau sudarytą su prioritetais ir aprėpties stulpeliu kiekvienam tiekėjui:

Atsisiųsti funkcinių reikalavimų vertinimo lapą (.docx)

Kaip palyginti TMS kainą ir sudaryti 3 metų modelį

„Kiek kainuoja TMS?" – tai klausimas, kurį pirkėjai labiausiai nori išgirsti, o tiekėjai mielai vengia atsakyti. Tačiau prenumeratos mokestis retai kada yra galutinė kaina. Vidutinio dydžio, daugiavietiam siuntėjui diegimas ir integracija gali lemti didesnę trijų metų sumą nei mėnesinis mokestis – ir tai yra eilutė, apie kurią tiekėjai kalba neaiškiausiai. Todėl čia svarbu struktūrizuoti klausimą taip, kad atsakymai grįžtų palyginami ir tikroji kaina būtų matoma.

Kaip apytikslė orientacija: vidutinės rinkos debesų pagrindu veikianti TMS paprastai kainuoja nuo kelių šimtų iki kelių tūkstančių eurų per mėnesį, o tradicinės įmonių lygio sistemos – nuo dešimčių tūkstančių iki daugiau nei milijono per metus, su diegimu, kuris gali siekti šešių ar septynių skaitmenų. Tai platus diapazonas – ir todėl palyginamas modelis yra svarbesnis nei bet koks vienas skaičius. Norėdami susidaryti vaizdą apie realias TMS tiekėjų kainas, žiūrėkite mūsų pagrindinių TMS tiekėjų apžvalgą.

TMS kainodaros komponentai

Beveik kiekvienas TMS pasiūlymas yra tam tikras šių elementų derinys:

Sudarykite trijų metų išlaidų modelį prieš lygindami

TMS tiekėjas, kuris atrodo pigus pagal prenumeratą, gali pasirodyti brangiausias, kai įskaičiuojamas diegimas, sandorių mokesčiai ir vežėjų prijungimas. Kiekvieną tiekėją vertinkite pagal tą patį modelį:

3 metų kaina = diegimas + (metinė prenumerata × 3) + (mokestis už siuntą × metinis kiekis × 3) + palaikymas + numatomi vežėjų ir integracijos priedai.

Naudokite realias apimtis, o ne tiekėjo tvarkingą pavyzdį. Ši viena lentelė dažnai pakeičia trumpojo sąrašo eilę.

Stebėkite skirtingus kainodaros komponentus, o ne tik bazinį mokestį

Kai kurie tiekėjai nustato žemą prenumeratos kainą ir atgauna ją per sandorių mokesčius ar mokesčius už vežėją. Tai savaime nėra blogai, tačiau keičia, kas yra pigiausias, augant jūsų verslui. Jei jūsų apimtys auga, mokestis už siuntą gali greitai viršyti fiksuotą tarifą. Paprašykite pavyzdinės sąskaitos faktūros ir prenumeratos sąlygų, kad lygintumėte tai, ką iš tikrųjų mokėsite, o ne reklaminio tarifo.

Vienas klausimas, kurį verta užduoti kiekvienam tiekėjui: ar naujos vežėjų integracijos įtrauktos, ar apmokestinamos kiekvieną kartą? Kai kurios TMS platformos ima 5 000–10 000 EUR už naują vežėjo integraciją ir tai užtrunka mėnesius, kitos kuria naujas vežėjų integracijas be papildomų išlaidų. Vidutinio dydžio siuntėjui, per metus prijungiančiam naujus vežėjus, šis vienas atsakymas gali pakeisti trijų metų sumą labiau nei prenumeratos eilutė.

Kaip vertinti TMS pasiūlymus ne tik pagal kainą

Pasiūlymai gauti. Visi atrodo pagrįsti, dauguma sako „taip" jūsų reikalavimams, o kainos panašios. Kas toliau?

Šiame etape komandos tyliai grįžta prie kainos, nes viskas kita atrodo sunkiau palyginama. Nedarykite to. Štai kas iš tikrųjų juos skiria.

1. Vežėjų jungtys.

TMS atveju vežėjų jungtys yra pagrindas. Kaip tiekėjas iš tikrųjų jungiasi prie vežėjų – per tiesiogines API/EDI integracijas, trečiųjų šalių agregatorius ar visai ne (el. paštu ir PDF užsakymais, neatsižvelgiant į jų IT pajėgumus)? Kas nutinka, kai reikia vežėjo, kurio jie dar nepalaiko – kiek tai užtrunka ir kiek kainuoja?

Tiekėjas su giliais, tiesioginiais vežėjų ryšiais yra visiškai kitoks dalykas nei tas, kuris viską nukreipia per tarpinę programinę įrangą. Skirtumą jaučiate užsakymų patikimume, sekimo kokybėje ir tame, ar galite pridėti vežėją be naujos komercinės derybos kiekvieną kartą.

2. Vežėjų paslaugų lygio harmonizavimas – tai svarbu labiau, nei dauguma supranta.

Vežėjų skaitmeniniai pajėgumai nėra vienodi. Vieni turi sudėtingas API, apimančias realaus laiko kainodarą, ETA prognozavimą, adresų tikrinimą, etikečių generavimą, išsamius sekimo įvykius. Kiti siunčia užsakymo patvirtinimą el. paštu – ir tuo viskas baigiasi. Daugumoje vežėjų tinklų vienu metu yra abiejų tipų.

Tai tampa jūsų problema tą akimirką, kai prie TMS prijungiate ERP ar WMS. Jei jūsų integracija tikisi gauti visą duomenų rinkinį iš kiekvieno vežėjo – užsakymo patvirtinimą, sekimo nuorodą, etiketę, kainos įvertinimą – bet kai kurie vežėjai to negali pateikti, gaunate išimtis, rankinius sprendimus ir spragas duomenyse. Vienas silpnas vežėjas suardo viso darbo srauto nuoseklumą.

Skirtingi transporto valdymo programinės įrangos tiekėjai su tuo susidoroja dviem būdais, ir verta nuspręsti, kurio norite, prieš skaitant bet kurį pasiūlymą:

• Plonesnė TMS perduoda tai, ką pateikia kiekvienas vežėjas, o spragas jūsų ERP ar rankiniame darbe teks spręsti jums patiems. Paprastesnė integracija, daugiau išimčių jūsų pusėje.
• TMS, kuri normalizuoja duomenis ir pati užpildo spragas: apskaičiuoja krovinio kainą iš jūsų įkelto kainų sąrašo, kai nėra kainodaros API; įvertina pristatymo laiką, kai vežėjas nepateikia ETA; generuoja siuntos etiketes, kai vežėjas to negali; kai vežėjai neturi sekimo, leidžia jiems rankiniu būdu įvesti sekimo etapus – ir dar daugiau. Programinė įranga užpildo jūsų vežėjų techninių pajėgumų spragas, o jūsų ERP mato vieną nuoseklią struktūrą.

Vertindami pasiūlymus, klauskite tiekėjų tiesiogiai: kaip jūs tvarkotės su vežėjais, turinčiais ribotus skaitmeninius pajėgumus? Atsakymas daug pasako apie tai, kiek brandi yra jų platforma.

3. Integracijos sąžiningumas.

Atidžiai stebėkite, kaip tiekėjai aprašo integracijos apimtį (kas ką daro). Pasiūlymas, kuriame aiškiai parašyta „ERP pusės kūrimas yra jūsų atsakomybė, štai ką mes teikiame ir kaip palaikome" yra patikimesnis nei tas, kuris užsimena apie „sklandžią integraciją" nepaaiškindamas, kuri šalis tvarko kurią integracijos dalį – jūs ar jie. Integracijos netikėtumai yra viena dažniausių priežasčių, kodėl TMS projektai viršija laiko ir biudžeto ribas.

4. Diegimo metodas.

Etapinis metodas – pirmiausia rankinis operacinis patvirtinimas, paskui automatizavimas – paprastai yra mažesnės rizikos nei vienkartinis paleidimas. Galite patvirtinti, kad sistema veikia jūsų realiems darbo srautams, prieš visa operacija ant jos pasiremdama. Iš mūsų pusės: tiekėjai, kurie tai siūlo be raginimo, paprastai jau yra išgyvenę chaotišką paleidimą. Tie, kurie siūlo visišką automatizavimą nuo pirmos dienos, dažnai – ne.

5. Rekomendacijos

Prašykite rekomendacijų iš įmonių, turinčių panašias operacijas, o ne tik panašų dydį ar darbuotojų skaičių. Rekomendacija iš vienos vietos distributoriaus nėra ypač naudinga, jei valdote daugiavietę gamybos operaciją su SAP integracija. Ir užduokite konkrečius klausimus: „Kaip vyko vežėjų prijungimas?" „Kaip sekėsi integracijos procesas?" „Kas nutiko, kai kažkas neveikė taip, kaip tikėtasi?"

6. Pats pasiūlymas.

Tai, kaip TMS tiekėjas atsako į jūsų RFP, yra jo elgesio kaip partnerio peržiūra. Ar jie atsakė į jūsų klausimus tiesiogiai, ar apgaubė viską išlygomis? Ar sąžiningai nurodė spragas, ar teigė visišką aprėptį kiekvienam reikalavimui? Ar parodė, kad suprato jūsų operaciją, ar atsiuntė šiek tiek pakeistą standartinę prezentaciją?

Pasiūlymas, kuriame dviejose vietose nurodyta nepalaikoma ir paaiškinama kodėl, yra vertingesnis nei tas, kuriame į viską atsakyta „taip". Tiesą sužinosite bet kuriuo atveju. Geriau – vertinimo metu, o ne paleidimo dieną.

Atsisiųskite tiekėjų vertinimo matricą, kad galėtumėte vertinti tiekėjus pagal svertiniais kriterijus:

Atsisiųsti tiekėjų vertinimo matricą (.docx)

TMS tiekėjų pristatymų etapas

Rašytiniai pasiūlymai pasako, ką tiekėjas teigia. Pristatymai parodo, ar jis gali tai pagrįsti.

Šiame etape turėtumėte turėti 2–3 tiekėjų trumpąjį sąrašą. Pristatymų etapo tikslas – pasiūlymą patikrinti realiu spaudimu ir pamatyti, ar sistema veikia pagal jūsų tikrus scenarijus.

Prašykite tiesioginės demonstracijos, o ne paruošto pristatymo

Paruošta demonstracija – tai repetuota seka, rodanti sistemą geriausiu kampu. Tiesioginė demonstracija – tai kai jūs sakote: „Parodykite, kaip tvarkytumėte šią siuntą iš mūsų Nyderlandų sandėlio, su mūsų vežėju, pagal mūsų sutartą kainą" – ir stebite, kas iš tikrųjų vyksta.

Prieš susitikimą paruoškite 2–3 realius scenarijus iš savo operacijos: standartinis siuntos išsiuntimas, siunta, kuriai reikia spot pasiūlymo, ir kažkas sudėtingesnio – pavyzdžiui, vėluojanti siunta ar vežėjas, neteikiantis sekimo. Kai tiekėjas nuolat grįžta prie poliruotos demonstracijos vietoj jūsų scenarijaus – tai jau yra atsakymas.

Išnagrinėkite spragas

Jos yra kiekviename TMS pasiūlyme. Eikite tiesiai prie vietų, kur tiekėjas atsakė iš dalies arba kur turite abejonių, ir ten pasilikite. Neleiskite jiems grįžti prie to, kas veikia puikiai. Kaip tiksliai tai veikia? Kas ką daro? Kas nutinka, kai tai neveikia taip, kaip tikėtasi?

Pasirūpinkite, kad kambaryje būtų tinkami žmonės

TMS tiekėjo pusėje pristatantys žmonės turėtų būti tie, kurie iš tikrųjų dirbs prie jūsų diegimo, o ne tik pardavimų komanda. Paprašykite to aiškiai. Jūsų pusėje atneškite ką nors iš IT (jei integracija yra apimtyje) ir bent vieną žmogų, kuris sistemą naudos kasdien. Jie užduoda kitokius klausimus nei pirkimų skyrius, ir jums reikia abiejų klausimų rinkinių.

Antras etapas – tik jei reikia

Sudėtingam sprendimui antras susitikimas, skirtas konkretiems klausimams, yra vertas laiko. Galimos temos:

• Saugumas ir duomenų apsauga – paprašykite įsiskverbimo testo ataskaitos ar saugumo dokumentacijos, jei to reikalauja jūsų IT ar informacinio saugumo komanda
• Integracijos architektūra – techninis susitikimas tarp jūsų IT komandos ir tiekėjo
• Komercinės sąlygos – peržiūrėkite sutartį, darbų aprašą ir prielaidas eilutė po eilutės prieš pradėdami formalias derybas

Neplanuokite jo vien tam, kad pakartotumėte pirmą susitikimą su daugiau žmonių kambaryje. Arba jis išsprendžia konkrečius atvirus klausimus, arba jo neturėtų būti.

Patvirtinkite įsipareigojimus raštu

Bet kas, ką tiekėjas įsipareigoja susitikime ir ko nėra rašytiniame pasiūlyme, turi būti patvirtinta raštu prieš tęsiant. Žodiniai įsipareigojimai neišgyvena sutarties derybų. Jei TMS tiekėjas sako „taip, mes tai galime" dėl kažko svarbaus – tą pačią dieną siųskite el. laišką ir paprašykite patvirtinti.

TMS sutartis ir darbų aprašas: ką patikrinti prieš pasirašant

Pasirinkote tiekėją. Dauguma komandų šiame etape „atsikvėpia". Rekomenduočiau to nedaryti, nes čia detalės, kurias visi praleido vertinimo metu, tyliai tampa jūsų problema.

Suderinkite pozicijas viduje prieš derybas

Žinokite savo būtinuosius reikalavimus, priimtinus kompromisus ir ribas, kurių neperžengsite, prieš pradedant pokalbį. Reikalavimų keitimas derybų viduryje kainuoja laiko, griauna pasitikėjimą ir kartais praranda tiekėją, kurį iš tikrųjų norėjote. Pirmiausia išspręskite tai viduje, o tada derėkitės.

Supraskite, ką perkate: SaaS, o ne licenciją

Modernios TMS platformos yra SaaS prenumeratos, o ne programinės įrangos licencijos. Jūs prenumeruojate paslaugą, kurią tiekėjas talpina, prižiūri ir atnaujina – ne perkate sistemą visam laikui. Tai keičia tai, ką turi apimti sutartis: prenumeratos sąlygos, nutraukimas, duomenų nuosavybė ir eksporto teisės, veikimo laiko įsipareigojimai, palaikymo reagavimo laikai. Standartiniai pirkimų šablonai nebuvo rašyti šiam modeliui, todėl įsitikinkite, kad jūsiškiai yra atnaujinti.

Darbų aprašas yra toks pat svarbus kaip sutartis

Darbų aprašas nurodo, kas pristatoma, kas tai daro ir kada: paskyros konfigūracija, vežėjų prijungimas, integracijos palaikymas, mokymai ir priėmimo kriterijai, patvirtinantys, kad diegimas iš tikrųjų baigtas. Jei tai nėra darbų apraše – tai neįtraukta, nesvarbu, kas buvo pasakyta susitikime ar el. laiške. Ypač atidžiai skaitykite prielaidų skyrių. Ten sąlyginai apibrėžiama apimtis. Jei jūsų vežėjų sąrašas pasirodys didesnis nei nurodyta, arba jūsų ERP reikia nestandartinio integracijos formato, prielaidų skyrius nusprendžia, ar tai bus greitas pokalbis, ar apmokestintas pakeitimo prašymas.

Aiškiai nurodykite, kas nepatenka į apimtį

Individualus kūrimas, mokymai vietoje, duomenų migracija, integracijos darbai jūsų sistemose, vežėjų pusės pakeitimai. Tai paprastai kainuoja atskirai. Tai įrašius į dokumentus prieš pasirašant pašalinama dažniausia ir labiausiai išvengiama diegimo trinties priežastis: dvi pusės, kiekviena mananti, kad kažkas kita buvo įtraukta.

Suderinkite diegimo planą prieš pasirašant

Ne po. Vežėjų prioritetizavimas, konfigūracijos tvarkaraštis, integracijos etapai, paleidimo kriterijai – visa tai suderinkite tol, kol dar turite svertą. Tiekėjas, kuris sutarties etape negali pateikti aiškaus diegimo plano, jums pasako kažką, ką norėsite žinoti prieš įsipareigodami.

Po pasirašymo: TMS diegimas ir paleidimas

Didžioji dalis realios rizikos slypi po parašo. Tris dalykus lemia, kaip viskas klostysis.

1. Duomenų migracija

Vežėjų sutartys, kainų sąrašai, adresų knygos, istorinės siuntos. Anksti nuspręskite, ką reikia perkelti, kas pirmiausia išvaloma ir kas atsakingas už darbą. Netvarkingų šaltinio duomenų – dažniausia priežastis, kodėl paleidimo data vis toliau stumiama. Išvalykite juos prieš migraciją, o ne jos metu.

2. Vežėjų prijungimo seka

Visų vežėjų pirmą dieną neprijungsite. Prioritetizuokite pagal apimtį ir svarbą, paleiskite ir patvirtinkite kelis svarbiausius, tada plėskitės. Tai kaip tik ta vieta, kur etapinis metodas, apie kurį klausėte vertinimo metu, atsiperka.

3. Vartotojų pritaikymas

Žmonės, kasdien užsakantys siuntas, turi norėti naudoti naują sistemą. Įtraukite bent vieną iš jų nuo RFP etapo, tinkamai apmokykite juos diegimo (hypercare) metu ir įsitikinkite, kad kasdieninis darbo srautas yra tikrai greitesnis nei tai, ką jie darė anksčiau. Techniškai nepriekaištingas diegimas, kuriuo komanda tiesiog nesinaudoja, vis tiek yra nesėkmingas diegimas.

10 dažniausių TMS RFP klaidų

Modeliai, kuriuos matome dažniausiai, visi vienoje vietoje:

• Nėra operacinio konteksto. Svarbiausia klaida. Tiekėjams nepateikiamos apimtys, vietų struktūra, vežėjų sąrašas. Patikslinimų etapas ir bendro pobūdžio kainos garantuotos.
• Viskas yra būtina. Kai kiekvienas reikalavimas kritiškas, prioritetų stulpelis netenka prasmės ir neįmanoma atskirti lūžio taško nuo pageidaujamo dalyko.
• Neaiškus tvarkaraštis. Be datų tiekėjai negali įvertinti savo pastangų, todėl pasiūlymai grįžta tokie pat neaiškūs.
• Per didelis techninio sprendimo detalizavimas. Techninės įgyvendinimo detalės vietoj operacinio rezultato dėl netinkamų priežasčių eliminuoja gerus sprendimus.
• ERP/TMS ribos ignoravimas. Prielaida, kad TMS valdo finansinius procesus, kuriuos iš tikrųjų valdo ERP, ir tai suvokiama diegimo viduryje.
• Sprendimas pagal kainą. Pasirinkimas pagal prenumeratos antraštę be trijų metų modelio arba neįvertinus vežėjų jungčių ir integracijos sąžiningumo.
• Demonstracija vietoj tiesioginės patikros. Stebima tiekėjo poliruota seka, o ne sistema tikrinama pagal jūsų realius scenarijus.
• Rekomendacijos, neatitinkančios jūsų operacijos. Žiūrima į įspūdingus logotipus, tačiau tos įmonės gali turėti logistikos operacijas, visiškai nepanašias į jūsų. Prašykite rekomendacijų iš panašių įmonių, tada klauskite, kaip iš tikrųjų vyko diegimas ir integracija.
• Diegimo plano atidėjimas iki po pasirašymo. Planas, kurį derybose turite svertą, yra geresnis nei tas, kurį derybose jo neturite.
• Per sunkus procesas tinkamam tiekėjui. Biurokratinė našta, galinti išfiltruoti modernias platformas, kurios jums būtų tarnavusios geriausiai.

Nemokomi TMS RFP šablonai

Sukūrėme penkis šablonus iš RFP, į kuriuos atsakome, kad jums nereikėtų pradėti nuo tuščio lapo:

1. RFP dokumento šablonas. Visa šio vadovo struktūra.
2. Funkcinių reikalavimų vertinimo lapas. Su prioritetais ir aprėpties stulpeliu kiekvienam tiekėjui.
3. Operacinės informacijos kontrolinis sąrašas. Dešimt klausimų kaip pildoma lentelė.
4. Tiekėjų vertinimo matrica. Svertinis vertinimas keliems tiekėjams.
5. RFP tvarkaraščio šablonas. Veiklos, datos, atsakingi asmenys.

Atsisiųskite rinkinį – visi penki, nemokamai, be el. pašto. Paimkite tai, kas naudinga, likusį ignoruokite:

Atsisiųsti visą TMS RFP šablonų rinkinį (.zip)

Cargoson – transporto valdymo sistema, kurią naudoja vidutinio dydžio gamintojai ir didmenininkai visoje Europoje ir Šiaurės Amerikoje. Mes nuolat atsakome į tokius RFP, kokį ruošiatės rašyti, todėl jei norėtumėte aptarti savo reikalavimus prieš pradėdami rašyti – mielai padėsime tai apgalvoti, be jokių įsipareigojimų.

Užsiregistruokite nemokamam 30 minučių konsultacijai čia

Gerai organizuotas procesas atsiperka kiekviena į jį investuota valanda.