Kā uzrakstīt TMS RFP: mūsu pieredze [+ 5 bezmaksas veidnes]

Mēs katru nedēļu atbildam uz transporta vadības sistēmas RFP (piedāvājumu pieprasījumiem). Daži ir patīkami izstrādāt. Citi ir labs mācību piemērs tam, kā nevajadzētu darīt.

Šis raksts ir tas, ko es pats veidotu, ja šodien no nulles uzsāktu TMS atlases procesu. Tas balstās uz RFP, uz kuriem esam atbildējuši, uz atkārtotiem modeļiem dažādos uzņēmumos un nozarēs, uz to, ko lielākā daļa no tiem ietver, un uz kļūdām, ko mēs regulāri novērojam.

Ja esat iepirkumu speciālists, liela daļa no šī jums šķitīs pazīstama. Cerams, ka vismaz viena lieta ietaupīs jums kādu nevajadzīgu precizēšanas kārtu.

Kas ir TMS RFP?

TMS RFP (piedāvājumu pieprasījums) ir strukturēts dokuments, ko nosūtāt transporta vadības sistēmu piegādātājiem. Tajā aprakstīta jūsu loģistikas darbība un katram piegādātājam tiek lūgts ierosināt, kā viņu sistēma to apstrādātu — atbildot uz vienādām prasībām. Visa jēga ir salīdzināmībā. Vienādi jautājumi, vienāds formāts, vienāds konteksts — lai saņemtās atbildes varētu salīdzināt vienu ar otru, nevis lasīt kā piecus atsevišķus pārdošanas piedāvājumus.

RFP nav vienmēr nepieciešams. Tas atmaksājas tad, kad lēmums ir sarežģīts vai kad tas iekšēji jāpamato citiem. Ja jūsu loģistikas darbība ir vienkārša, pietiks ar produkta demonstrāciju un sarunu ar dažiem piegādātājiem.

Vai jums tiešām ir vajadzīgs TMS RFP konkurss?

Kļūda šajā posmā ir visdārgākā visā TMS atlases procesā. Izlemiet to pirms jebkā cita.

Viss atkarīgs no jūsu loģistikas sarežģītības, nevis uzņēmuma lieluma.

Rīkojiet strukturētu TMS RFP konkursu, ja sūtījumus veicat no vairākiem objektiem, izmantojat vairākus transporta veidus un sistēmai jāintegrējas ar jūsu ERP. Tieši tad jums ir nepieciešams, lai visi piegādātāji būtu salīdzināmi viens ar otru, lai nekas svarīgs nepaslīdētu garām. Pārvadātāji savienojas ļoti atšķirīgos veidos. Viens to sauc par "natīvu", nākamais klusi novirza caur kādu citu. Brīvā procesā to nepamanīsiet, kamēr nebūsiet parakstījuši līgumu. Tad jau būs par vēlu.

Atteicieties no formāla RFP konkursa, ja strādājat ar vienu objektu, nedaudziem pārvadātājiem un jau zināt, kas jums nepieciešams. Kāpēc? Tāpēc, ka brīdī, kad uzsākat RFP, jūs automātiski nonākat uzņēmumu līmeņa cenu kategorijā. 2–3 labas demonstrācijas ar precīziem jautājumiem bieži vien dod labāku sistēmu, lētāk un ātrāk. Pastāstiet tiem 2–3 piegādātājiem, ko sūtāt un ko mēģināt atrisināt, un lūdziet parādīt to viņu reālajā sistēmā. Stundas laikā jums būs skaidrs priekšstats. Un, ja galvenokārt sūtāt pakas, nevis paletes vai kravas, iespējams, pilna TMS jums vispār nav vajadzīga — vairāku pārvadātāju piegādāžu programmatūra ir atšķirīga, vieglāka kategorija, kas paredzēta tieši tam.

Tāpēc pirms sākšanas esiet godīgi pret sevi par to, kurš variants jums der labāk. RFP, kas nebija nepieciešams, ir lēnākais un dārgākais veids, kā iegādāties TMS.

RFP, kas nebija nepieciešams, ir lēnākais un dārgākais veids, kā iegādāties TMS.

Vēl viens brīdinājums, ja tomēr izvēlaties pilnu RFP procesu. Uz procesu, kas pārslogots ar pārvaldības valodu, metodoloģijas ietvariem un fiksētas cenas prasībām, atbildēšana aizņem nedēļas, un piegādātāji, kas spēj absorbēt šādu slogu, mēdz būt lielākie, nostiprinātākie. Tāpēc, ja liesāka, modernāka platforma jums patiesībā kalpotu labāk, pārmērīgi birokrātisks process var to klusi izfiltrēt, pirms jūs vispār redzat demonstrāciju.

Mērķis ir atrast pareizo risinājumu jums. Veidojiet procesu ap to, nevis ap paša procesa pārvaldību.

TMS RFP process 9 soļos

TMS atlase nav jābūt sarežģītai. Taču tai ir nepieciešama skaidra secība. Izlaidiet soļus — un par to maksāsiet vēlāk, parasti ieviešanas laikā, kad pieņēmumi, kas būtu bijuši jāprecizē jau sākumā, kļūst par dārgiem pārsteigumiem.

Labi organizēts process aizņem 8–12 nedēļas. Vienkāršākam apjomam — mazāk, un reti kad ir nepieciešams vairāk.

Lūk, secība, kas darbojas:

1. Tirgus izpēte. Pirms rakstāt kaut vienu prasību, veltiet laiku, lai izprastu, kas tirgū ir pieejams. TMS tirgus pēdējo piecu gadu laikā ir ievērojami mainījies: ir labas uzņēmumu līmeņa platformas, labas vidējā tirgus platformas un patiešām spējīgi moderni SaaS transporta vadības programmatūras risinājumi, kas pirms pieciem gadiem vēl nepastāvēja. Izveidojiet garāko sarakstu ar 5–8 TMS piegādātājiem, kurus ir vērts apsvērt.
2. NDA. Nosūtiet to agri. Jūs dalīsieties ar operacionāliem datiem — apjomiem, pārvadātāju nosaukumiem, iekšējo sistēmu informāciju — un parakstīts NDA pirms RFP nosūtīšanas ir standarta prakse, kas aizsargā abas puses.
3. RFI (neobligāts). Īss informācijas pieprasījums ir lietderīgs, ja jūsu garākais saraksts ir plašs un vēlaties filtrēt pirms pilna RFP procesa uzsākšanas. Saglabājiet to vienas lappuses apjomā: uzņēmuma pamatinformācija, galvenās iespējas, aptuvens cenu diapazons. Pietiekami, lai atlasītu kandidātus, nelūdzot piegādātājus rakstīt garākus aprakstus.
4. RFP. Galvenais dokuments. Tas sniedz katram piegādātājam visu nepieciešamo, lai piedāvājumu varētu sagatavot precīzi. Sīkāk par to nākamajā nodaļā.
5. Jautājumu un atbilžu logs. Vienmēr iekļaujiet to. Piegādātājiem būs jautājumi, un atbildes bieži uzlabo visus saņemtos piedāvājumus. Veiciet to rakstiski un visus jautājumus un atbildes nosūtiet visiem piegādātājiem vienlaicīgi. Tas uztur procesu tīru un salīdzināmu.
6. Īsais saraksts un prezentācijas. Novērtējiet rakstiskos piedāvājumus, pēc tam uzaiciniet 2–3 piegādātājus prezentēt. Prezentācijā jāietver sistēmas tiešraides apskate, kas balstīta uz jūsu reālajiem lietošanas gadījumiem, nevis vispārīga demonstrācija. Ja piegādātājs nevar parādīt jūsu scenāriju savā sistēmā, tas pats par sevi ir noderīga informācija.
7. Otrā kārta (ja nepieciešams). Sarežģīta lēmuma gadījumā padziļināta sesija, kas vērsta uz konkrētiem jautājumiem — drošību, integrāciju, komerciālajiem nosacījumiem — ir tā vērta. Neplānojiet to, ja vien jums nav palikuši reāli neatbildēti jautājumi.
8. Lēmums un līgums. Panāciet iekšēju vienošanos pirms sarunu uzsākšanas. Ziniet savas neapstrīdamās prasības, pieļaujamos kompromisus un robežu, pie kuras esat gatavi atkāpties.
9. Ieviešana. Tas nebeidzas ar parakstu. Labākajos RFP rezultātos ieviešanas plāns ir saskaņots pirms līguma parakstīšanas.

TMS RFP grafiks, ko varat kopēt

Aptuvens ilgums pēc apjoma:

• Viens vienkāršs objekts: 6–8 nedēļas (pilns RFP var nebūt nepieciešams).
• Vairāki objekti + ERP integrācija: 8–12 nedēļas.
• Globāls, vairāku uzņēmumu projekts ar sarežģītu integrāciju: 12–20 nedēļas, visticamāk ar divām prezentāciju kārtām.

Lejupielādēt RFP grafika veidni (.docx)

Kas jāiekļauj TMS RFP dokumentā

RFP dokuments ir jūsu svarīgākais instruments šajā procesā. Labs RFP dokuments lielāko daļu vērtēšanas darba paveic jūsu vietā, tāpēc saglabājiet to fokusētu. Kompakts 10 lappušu RFP ir labāks par 30 lappušu dokumentu, kas cenšas aptvert visu.

1. Pavadvēstule un mērķis

Viena lappuse. Kas jūs esat, ko meklējat, kāpēc tieši tagad. Saglabājiet to faktisku. Piegādātājiem nav nepieciešams vīzijas paziņojums — viņiem vienkārši jāsaprot jūsu operacionālā problēma.

2. Grafiks

Skaidrs grafiks ar reāliem datumiem: RFP nosūtīšana, jautājumu un atbilžu termiņš, iesniegšana, prezentāciju logs, lēmums. Piegādātāji plāno savu atbildes sagatavošanas darbu, pamatojoties uz šo. Neskaidri grafiki dod neskaidrus piedāvājumus.

3. Uzņēmuma un operacionālā pamatinformācija

Šeit lielākā daļa RFP ir nepilnīgi — un tieši tas nosaka atšķirību starp salīdzināmiem piedāvājumiem un precizēšanas kārtu. Neaprakstiet tikai savu uzņēmumu, bet aprakstiet savu loģistikas darbību. Cik objektu. Cik juridisko personu. Kādi transporta veidi (pakas, LTL, FTL, gaiss, jūra, dzelzceļš). Kādi reģioni. Aptuvenie apjomi. Pašreizējās sistēmas. Tas, kas tiek uzskatīts par labu, atšķiras arī pēc nozares — prasības elektronikas, mašīnbūves, ķīmijas vai poligrāfijas un iepakojuma ražotājiem nav vienādas. Šis ir konteksts, kas piegādātājiem nepieciešams, lai precīzi sagatavotu piedāvājumu. Ja šeit nesniedzat pietiekami daudz informācijas, pavadīsiet divas nedēļas, atbildot uz precizēšanas jautājumiem, no kuriem varēja izvairīties pavisam. Šai tēmai ir veltīta atsevišķa nodaļa tālāk.

4. Funkcionālās prasības

Tabula ar to, kas sistēmai jāspēj, prioritizēta pēc nozīmīguma: obligāti / vēlami / labi būtu (Excel ir piemērots). Lūdziet piegādātājiem atbildēt uz katru prasību ar seguma līmeni: a) natīvs, b) trešās puses, c) pielāgošana vai d) neatbalstīts. Tieši tas padara piedāvājumus salīdzināmus. Sīkāk par to, kā veidot šo sarakstu, lasiet tālāk.

5. Vērtēšanas kritēriji

Pastāstiet piegādātājiem, kā pieņemsiet lēmumu: funkcionalitāte, cena, ieviešanas pieeja, atsauces, drošība, komanda. Ja esat gatavi, dalieties ar svērumiem. Jo pārredzamāki esat, jo labāki piedāvājumi.

6. Cenu modelis

Pieprasiet pilnu sadalījumu: abonements, ieviešana, darījumu maksas, atbalsts un viss pārējais. Ja iespējams, lūdziet parauga rēķinu. Cenu struktūras dažādiem piegādātājiem ievērojami atšķiras, un slēptās izmaksas parasti parādās vēlu. Centieties tās noskaidrot jau sākumā.

7. Atbildes formāts

Precīzi norādiet piegādātājiem, kā vēlaties, lai piedāvājums būtu strukturēts, un, ja sniedzat veidnes, pieprasiet to izmantošanu. Salīdzināmi piedāvājumi ietaupa dienas vērtēšanas laikā, un formāts ir pilnībā jūsu kontrolē.

Lejupielādējiet RFP dokumenta veidni, lai sāktu ar pilnu iepriekš aprakstīto struktūru:

Lejupielādēt RFP dokumenta veidni (.docx)

Operacionālā informācija, ko lielākā daļa TMS RFP izlaiž — un kāpēc tā ir vissvarīgākā

Šī ir nodaļa, ko es vēlētos, lai katrs TMS RFP autors izlasītu pirmais.

Mēs atbildam uz daudziem TMS konkursiem. Gandrīz katram piedāvājumam, ko rakstām, ir nepieciešama precizēšanas kārta — un reti kad tāpēc, ka prasības nebija skaidras. Parasti tāpēc, ka trūkst operacionālā konteksta: apjomi, objektu struktūra, pārvadātāju aina, pašreizējās sistēmas.

RFP, kuriem bija nepieciešama pilna precizēšanas kārta, gandrīz vienmēr ir viena kopīga iezīme:

Esam redzējuši uzņēmumus, kas nedēļām veido vērtēšanas kritērijus un prasību sarakstus, bet pēc tam nosūta RFP, kurā nav minēts, cik sūtījumu viņi apstrādā mēnesī.

Bez šīs informācijas piegādātāji min. Un, kad viņi min, piedāvājumi atgriežas vispārīgi, cenas nav galīgas un nav nekā konkrēta, ko salīdzināt.

Piemēram, globālam ražotājam ar 10 noliktavām un SAP ir nepieciešams pilnīgi atšķirīgs piedāvājums nekā viena objekta izplatītājam, kurš loģistiku pārvalda ar izklājlapām. Ja piegādātājs nevar noteikt, kurš jūs esat, viņš izvairās no konkrētiem apgalvojumiem — un jūs saņemat piedāvājumus, kas neko negarantē.

Labojums prasa pēcpusdienu. Atbildiet uz šiem desmit jautājumiem RFP dokumentā pirms tā nosūtīšanas.

1. Organizācija un apjoms. Cik juridisko personu un objektu ir iekļauti? Vai ieviešana notiek paralēli vai pa posmiem? Cik neatkarīgi darbojas objekti — atsevišķi pārvadātāju līgumi, atsevišķas komandas?
2. Sūtījumu apjomi. Ikmēneša un ikdienas sūtījumu skaits katrā objektā, vidējais un maksimālais. Sezonalitāte, ja tāda ir. Ienākošo un izejošo sūtījumu sadalījums.
3. Transporta veidu sadalījums. Kāda daļa ir pakas, LTL, FTL, gaiss, jūra? Kuri veidi aug? Kuri ir operacionāli kritiskākie?
4. Pārvadātāju aina. Cik pārvadātāju katrā objektā un katram transporta veidam? Vai tie ir kopīgi visiem objektiem vai pārvaldīti lokāli? Vai ir stratēģiski pārvadātāji, kuriem jāpiešķir prioritāte, vai klientu norādīti pārvadātāji, kurus nevar mainīt?
5. Ģeogrāfija un tirdzniecības maršruti. Kādi reģioni ir iekļauti? Kuri maršruti ir svarīgākie: iekšzemes, pārrobežu, starptautiskie? Galvenās ostas vai loģistikas centri?
6. Pašreizējais stāvoklis. Kā sūtījumi šobrīd tiek plānoti, pasūtīti un izsekoti? ERP, izklājlapās, pārvadātāju portālos, e-pastā? Kādi ir galvenie sāpju punkti pašreizējā procesā?
7. Finanšu struktūra. Kurš maksā par transportu — viena juridiskā persona vai vairākas? Vai ir trešo pušu vai klientu kontu numuri? Kā transporta izmaksas šobrīd tiek reģistrētas un validētas?
8. Biznesa modelis. B2B, B2C? Ja jaukts — sadalījums. Operacionālās un sistēmu prasības ievērojami atšķiras.
9. Integrāciju ainava. Kādas sistēmas jāsavieno ar TMS: ERP, WMS, CRM? Vai ir esošas pārvadātāju integrācijas, kas jāsaglabā? Cik automatizētam tam jābūt no pirmās dienas?
10. Grafiks un ierobežojumi. Vai ir noteikts darbības uzsākšanas termiņš? Vai ir iekšēji atskaites punkti — finanšu gada beigas, sezonas maksimums, sistēmu migrācijas —, kas ietekmē grafiku?

Nekas no šī nav grūti uzrakstāms. Taču tas pilnībā maina to, kas atgriežas atpakaļ.

Lejupielādējiet operacionālās informācijas kontrolsarakstu, lai šos desmit jautājumus pārvērstu aizpildāmā tabulā, ko tieši ievietojat savā RFP:

Lejupielādēt operacionālās informācijas kontrolsarakstu (.docx)

Kā rakstīt TMS funkcionālās prasības

Funkcionālās prasības ir RFP sirds. Izdariet to pareizi — un iegūsiet skaidru, salīdzināmu priekšstatu par to, ko katrs piegādātājs var un ko nevar. Izdariet nepareizi — un varbūt pavadīsiet nedēļas, atšifrējot atbildes, kurās visur rakstīts "jā".

Mērķis nav garākais saraksts. Mērķis ir godīgākais saraksts.

Prioritizējiet stingri: obligāti, vēlami, labi būtu

Ne viss, ko vēlaties, ir vienlīdz svarīgs. Izmantojiet trīs kategorijas un ievērojiet tās:

1. Obligāti (O): neapstrīdami. Piegādātājs, kurš to nevar nodrošināt, tiek izslēgts neatkarīgi no pārējā.
2. Vēlami (V): svarīgi, taču varat samierināties ar pagaidu risinājumu vai tuvākā laika attīstības plāna solījumu.
3. Labi būtu (L): noderīgi zināt, taču atrodas aiz visa iepriekšminētā.

Lielākajā daļā sarakstu ir pārāk daudz obligāto prasību. Ja viss ir kritisks, nekas nav kritisks. Esiet godīgi par to, kas patiešām liegtu sistēmai darboties jūsu vajadzībām, un atzīmējiet tikai to kā obligātu.

Lūdziet piegādātājus klasificēt funkcionalitātes segumu: natīvs / trešās puses / pielāgošana

Katrai prasībai lieciet viņiem atbildēt ar vienu no šiem:

Šī sleja ir vieta, kur piedāvājumi nopelna vai zaudē jūsu uzticību. Piegādātājs, kurš atbild godīgi un raksta neatbalstīts tur, kur tas ir patiesība, parāda, kā viņš uzvedīsies kā partneris. Piegādātājs, kurš uz visu atbild natīvs, arī jums kaut ko saka.

Esiet konkrēti jautājumā

"Vai sistēma atbalsta pārvadātāju cenas?" dos jums bezjēdzīgu "jā". "Vai sistēma var aprēķināt kravas cenu katram pārvadātājam, tostarp tiem bez cenu API, un parādīt tos blakus katram sūtījumam?" — tas jau ir kaut kas, ko var novērtēt.

Kur beidzas ERP un sākas TMS?

Viens no biežākajiem neskaidrību avotiem transporta vadības sistēmu vērtēšanā ir robeža starp TMS un ERP.

Finanšu procesi, piemēram, GL kodēšana, izkraušanas izmaksas un kravas audits, bieži tiek apstrādāti ERP pusē, un TMS nodod datus uz ERP. Tas ir normāli un bieži vien pareizā pieeja. Taču tas ir jāprecizē. Kad piegādātājs uz kādu no jūsu obligātajām prasībām atbild "apstrādāts caur ERP integrāciju", noskaidrojiet precīzi, ko tas nozīmē jūsu ieviešanai — un kurš to veido.

Norādiet mērķi, nevis tehnisko risinājumu

Aprakstiet, kas jums jāsasniedz, nevis kā sistēmai tas tehniski jāpaveic. Pārāk detalizētas prasības izslēdz labus risinājumus nepareizu iemeslu dēļ. Atstājiet piegādātājiem iespēju parādīt labāku veidu, nekā jūs bijāt iecerējuši, jo dažreiz viņiem tāds ir.

30 rindu saraksts ar godīgām, prioritizētām prasībām pateiks vairāk nekā 150 rindu izklājlapa, kurā viss ir kritisks un katrs piegādātājs ir atzīmējis katru lodziņu.

Sākotnējs TMS prasību kopums pielāgošanai

Lielākā daļa pirmo reizi pircēju vēlas sākt ar gatavu sarakstu, tāpēc šeit ir piemēru kopums no mūsu pieredzes, jau kategorizēts, ko varat pielāgot savai darbībai. Pilns saraksts ir lejupielādājams zemāk esošajā vērtēšanas lapā — šis ir pietiekami, lai redzētu tā struktūru.

Lejupielādējiet funkcionālo prasību vērtēšanas lapu, kas jau ir sagatavota ar prioritātēm un seguma sleju katram piegādātājam:

Lejupielādēt funkcionālo prasību vērtēšanas lapu (.docx)

Kā salīdzināt TMS izmaksas (un veidot trīs gadu modeli)

"Cik maksā TMS?" ir jautājums, ko pircēji visvairāk vēlas noskaidrot un ko piegādātāji labprāt izvairās atbildēt. Taču abonēšanas maksa reti ir jūsu galīgās izmaksas. Vidēja lieluma, vairāku objektu uzņēmumam ieviešana un integrācija var pat vairāk ietekmēt trīs gadu kopsummu nekā ikmēneša maksa — un tieši šī pozīcija piegādātājiem ir visnenoteiktākā. Tāpēc prasme šeit ir strukturēt jautājumu tā, lai atbildes būtu salīdzināmas un reālās izmaksas būtu redzamas.

Aptuvenas orientācijas nolūkos: vidējā tirgus mākoņdatošanas TMS parasti maksā no dažiem simtiem līdz dažiem tūkstošiem eiro mēnesī, savukārt tradicionālās uzņēmumu sistēmas — no desmitiem tūkstošu līdz vairāk nekā miljonam gadā, ar ieviešanu, kas var sasniegt sešu vai septiņu ciparu skaitļus. Tas ir plašs diapazons — tieši tāpēc salīdzināms modelis ir svarīgāks par jebkuru atsevišķu skaitli. Lai gūtu priekšstatu par to, ko reāli iekasē TMS piegādātāji, skatiet mūsu pētījumu par vadošajiem TMS piegādātājiem.

TMS cenu komponenti

Gandrīz katrs TMS piedāvājums ir kāds no šo elementu sajaukums:

Veidojiet trīs gadu izmaksu modeli pirms salīdzināšanas

TMS piegādātājs, kas izskatās lēts pēc abonēšanas maksas, var izrādīties visdārgākais, tiklīdz tiek ņemta vērā ieviešana, darījumu maksas un pārvadātāju pievienošana. Palaidiet katru piegādātāju caur vienu un to pašu modeli:

3 gadu izmaksas = ieviešana + (gada abonements × 3) + (maksa par sūtījumu × gada apjoms × 3) + atbalsts + paredzamie pārvadātāju un integrāciju papildinājumi.

Izmantojiet reālos apjomus, nevis piegādātāja sakārtoto piemēru. Šī viena tabula bieži vien pārkārto īso sarakstu.

Sekojiet dažādajiem cenu komponentiem, nevis tikai pamata maksai

Daži piegādātāji nosaka zemu abonēšanas maksu un atgūst to ar darījumu maksām vai maksām par katru pārvadātāju. Tas pats par sevi nav slikti, taču tas maina to, kurš ir lētākais, augot jūsu apjomiem. Ja apjomi pieaug, maksa par sūtījumu var ātri pārsniegt fiksēto maksu. Lūdziet parauga rēķinu un abonēšanas nosacījumus, lai salīdzinātu to, ko patiešām maksāsiet, nevis virsraksta likmi.

Viens jautājums, ko ir vērts uzdot katram piegādātājam: vai jaunu pārvadātāju integrācija ir iekļauta vai tiek rēķināta katru reizi? Dažas TMS platformas iekasē 5 000–10 000 € par katru jaunu pārvadātāja integrāciju un aizņem mēnešus, citas veido jaunas pārvadātāju integrācijas bez papildu maksas. Vidēja lieluma uzņēmumam, kas gadu gaitā pievieno pārvadātājus, šī viena atbilde var mainīt trīs gadu kopsummu vairāk nekā jebkad abonēšanas pozīcija.

Kā vērtēt TMS piedāvājumus ārpus cenas

Piedāvājumi ir saņemti. Visi izskatās saprātīgi, lielākā daļa atbild apstiprinoši uz jūsu prasībām un cenas ir līdzīgā diapazonā. Kas tālāk?

Šajā brīdī komandas klusi atgriežas pie cenas, jo viss pārējais šķiet grūtāk salīdzināms. Nedariet to. Lūk, kas tos patiesībā atšķir.

1. Savienojamība ar pārvadātājiem.

TMS gadījumā savienojamība ar pārvadātājiem ir pamats. Kā piegādātājs faktiski savienojas ar pārvadātājiem — caur tiešām API/EDI integrācijām, trešo pušu agregatoriem vai nemaz (e-pasts + PDF pasūtījumi neatkarīgi no viņu IT iespējām)? Kas notiek, ja jums nepieciešams pārvadātājs, kuru viņi vēl neatbalsta — cik ilgi tas aizņem un cik maksā?

Piegādātājs ar dziļām, tiešām pārvadātāju integrācijām ir pavisam citāds risinājums nekā tas, kurš visu novirza caur starpniekprogrammatūras slāni. Atšķirību jūtat pasūtīšanas uzticamībā, izsekošanas kvalitātē un tajā, vai varat pievienot pārvadātāju, neveicot katru reizi jaunu komerciālu sarunu.

2. Pārvadātāju pakalpojumu līmeņu harmonizācija — tas ir svarīgāk, nekā lielākā daļa apzinās.

Pārvadātāji nav vienādi savās digitālajās iespējās. Dažiem ir sarežģīti API, kas aptver reāllaika cenas, ETA prognozēšanu, adrešu validāciju, etiķešu ģenerēšanu, detalizētus izsekošanas notikumus. Citi nosūta pasūtījuma apstiprinājumu pa e-pastu — un ar to arī beidzas. Lielākajā daļā pārvadātāju tīklu vienlaikus ir abi veidi.

Tas kļūst par jūsu problēmu brīdī, kad savienojat savu ERP vai WMS ar TMS. Ja jūsu integrācija sagaida pilnu datu kopu no katra pārvadātāja — pasūtījuma apstiprinājumu, izsekošanas saiti, etiķeti, izmaksu aplēsi —, bet daži pārvadātāji to nevar nodrošināt, jūs saņemat izņēmumus, manuālus risinājumus un robus datos. Viens vājš pārvadātājs izjauc visa darbplūsmas konsekvenci.

Dažādi transporta vadības programmatūras piegādātāji ar to tiek galā divos veidos, un ir vērts izlemt, kuru vēlaties, pirms lasāt kaut vienu piedāvājumu:

• Plānāka TMS nodod tālāk visu, ko katrs pārvadātājs nodrošina, un jūsu problēma būs tikt galā ar robu jūsu ERP vai manuālajā darbā. Vienkāršāka integrācija, bet vairāk izņēmumu no jūsu puses.
• TMS, kas normalizē datus un pati aizpilda robus: aprēķina kravas cenu no jūsu augšupielādētās cenu lapas, ja nav cenu API; novērtē piegādes laiku, ja pārvadātājs nenodrošina ETA; ģenerē sūtījumu etiķetes, ja pārvadātājs to nevar; ja nav izsekošanas, ļauj pārvadātājiem manuāli ievadīt izsekošanas atskaites punktus — un vēl vairāk. Programmatūra aizpilda robus jūsu pārvadātāju tehniskajās iespējās, un jūsu ERP redz vienu konsekventu struktūru.

Vērtējot piedāvājumus, jautājiet piegādātājiem tieši: kā jūs rīkojaties ar pārvadātājiem, kuriem ir ierobežotas digitālās iespējas? Atbilde daudz pasaka par to, cik nobriedusi viņu platforma patiesībā ir.

3. Godīgums par integrāciju.

Pievērsiet uzmanību tam, kā piegādātāji apraksta integrācijas apjomu (kurš ko dara). Piedāvājums, kurā skaidri teikts "ERP puses izstrāde ir jūsu ziņā, lūk, ko mēs nodrošinām un kā atbalstām" ir uzticamāks par tādu, kas norāda uz "nemanāmu integrāciju", nepaskaidrojot, kura puse ko apstrādā. Integrācijas pārsteigumi ir viens no biežākajiem iemesliem, kāpēc TMS projekti pārsniedz laiku un budžetu.

4. Ieviešanas pieeja.

Pakāpeniska pieeja — vispirms manuāla operacionālā validācija, pēc tam automatizācija — parasti ir mazāk riskanta nekā vienreizēja palaišana. Jūs varat pārliecināties, ka sistēma darbojas jūsu reālajām darbplūsmām, pirms uz to balstāt visu savu darbību. No mūsu puses: piegādātāji, kas to ierosina bez pamudināšanas, parasti jau ir piedzīvojuši sarežģītu palaišanu. Tie, kas piedāvā pilnu automatizāciju no pirmās dienas, bieži vien nav.

5. Atsauces

Lūdziet atsauces no uzņēmumiem ar līdzīgām darbībām, nevis tikai līdzīgu lielumu vai darbinieku skaitu. Atsauce no viena objekta izplatītāja nav īpaši noderīga, ja vadāt vairāku objektu ražošanas uzņēmumu ar SAP integrāciju. Un uzdodiet konkrētus jautājumus: "Kā noritēja pārvadātāju pievienošana?" "Kā noritēja integrācijas process?" "Kas notika, kad kaut kas nedarbojās kā gaidīts?"

6. Pats piedāvājums.

Tas, kā TMS piegādātājs atbild uz jūsu RFP, ir priekšskatījums tam, kā viņš uzvedīsies kā jūsu partneris. Vai viņi atbildēja uz jūsu jautājumiem tieši, vai visu ietina atrunu slāņos? Vai viņi godīgi norādīja uz robu, vai apgalvoja pilnu segumu visām prasībām? Vai viņi parādīja, ka saprot jūsu darbību, vai nosūtīja nedaudz pielāgotu standarta prezentāciju?

Piedāvājums, kurā divos punktos atzīts neatbalstīts un paskaidrots kāpēc, ir vērtīgāks par tādu, kas uz visu atbild apstiprinoši. Patiesību jūs uzzināsiet tā vai tā. Labāk to uzzināt vērtēšanas laikā, nevis palaišanas dienā.

Lejupielādējiet piegādātāju vērtēšanas matricu, lai novērtētu piegādātājus pēc svērtiem kritērijiem:

Lejupielādēt piegādātāju vērtēšanas matricu (.docx)

TMS piegādātāju prezentāciju kārta

Rakstiskie piedāvājumi pasaka, ko piegādātājs apgalvo. Prezentācijas parāda, vai viņi to var pierādīt.

Šajā posmā jums vajadzētu būt īsajam sarakstam ar 2–3 piegādātājiem. Prezentāciju kārtas mērķis ir pakļaut piedāvājumu reālam spiedienam un pārbaudīt, vai sistēma darbojas jūsu faktiskajos scenārijos.

Lūdziet tiešraides apskati, nevis demonstrāciju

Demonstrācija ir iepriekš sagatavota secība, kas parāda sistēmu tās labākajā pusē. Apskate ir tad, kad jūs sakāt: "Parādiet, kā jūs apstrādātu šo sūtījumu no mūsu Nīderlandes noliktavas, ar mūsu pārvadātāju, par mūsu saskaņoto cenu" — un skatāties, kas faktiski notiek.

Pirms tikšanās sagatavojiet 2–3 reālus scenārijus no savas darbības: standarta izejošais pasūtījums, sūtījums, kam nepieciešams spot piedāvājums, un kaut kas sarežģīts — piemēram, aizkavēts sūtījums vai pārvadātājs, kas nenodrošina izsekošanu. Ja piegādātājs pastāvīgi cenšas atgriezties pie noslīpētās demonstrācijas, nevis izpilda jūsu scenāriju — tas pats par sevi ir atbilde.

Izaiciniet robus

Katram TMS piedāvājumam tie ir. Dodieties tieši pie vietām, kur piegādātājs atbildēja daļēji vai kur jums ir šaubas, un palieciet tur. Neļaujiet viņiem atgriezties pie kaut kā, kas darbojas lieliski. Kā tieši tas darbojas? Kurš ko dara? Kas notiek, ja tas nedarbojas kā gaidīts?

Nodrošiniet pareizos cilvēkus telpā

TMS piegādātāja pusē prezentētājiem jābūt tiem, kas faktiski strādās pie jūsu ieviešanas, nevis tikai pārdošanas komandai. Lūdziet to skaidri. No jūsu puses ielūdziet kādu no IT (ja integrācija ir iekļauta apjomā) un vismaz vienu cilvēku, kurš sistēmu izmantos katru dienu. Viņi uzdod citādus jautājumus nekā iepirkumi, un jums ir vajadzīgi abi jautājumu kopumi.

Otrā kārta — tikai ja nepieciešams

Sarežģīta lēmuma gadījumā otrā sesija, kas vērsta uz konkrētām tēmām, ir tā vērta. Piemēru tēmas:

• Drošība un datu aizsardzība — lūdziet iespiešanās testēšanas ziņojumu vai drošības dokumentāciju, ja to pieprasa jūsu IT vai informācijas drošības komanda
• Integrācijas arhitektūra — tehniska sesija starp jūsu IT komandu un piegādātāja komandu
• Komerciālie nosacījumi — izskatiet līgumu, darbu apjoma dokumentu un pieņēmumus rindu pa rindai pirms formālo sarunu uzsākšanas

Neplānojiet to tikai tāpēc, lai atkārtotu pirmo tikšanos ar vairāk cilvēkiem telpā. Vai nu tā atrisina konkrētus atklātus jautājumus, vai arī tai nevajadzētu notikt.

Apstipriniet saistības rakstiski

Jebkas, ko piegādātājs apņemas tikšanās laikā un kas nav rakstiskajā piedāvājumā, pirms turpināšanas jāapstiprina rakstiski. Mutiski solījumi neizdzīvo līguma sarunās. Ja TMS piegādātājs kaut ko svarīgu saka "jā, mēs to varam izdarīt", tajā pašā dienā nosūtiet e-pastu un lūdziet apstiprinājumu.

TMS līgums un darbu apjoma dokuments: ko pārbaudīt pirms parakstīšanas

Esat izvēlējušies piegādātāju. Lielākā daļa komandu šajā brīdī "atvieglojas". Es iesaku to nedarīt, jo tieši šeit detaļas, kuras vērtēšanas laikā tika ignorētas, klusi kļūst par jūsu problēmu.

Panāciet iekšēju vienošanos pirms sarunu uzsākšanas

Ziniet savas neapstrīdamās prasības, pieļaujamos kompromisus un robežu, pie kuras esat gatavi atkāpties, pirms saruna sākas. Prasību maiņa sarunu vidū izmaksā laiku, grauj uzticību un dažreiz liek zaudēt TMS piegādātāju, kuru patiesībā vēlējāties. Vispirms sakārtojiet to iekšēji, un tikai tad sāciet sarunas.

Saprotiet, ko pērkat: SaaS, nevis licenci

Mūsdienu TMS platformas ir SaaS abonēšanas pakalpojumi, nevis programmatūras licences. Jūs abonējat pakalpojumu, ko piegādātājs mitina, uztur un atjaunina — jūs nepērkat sistēmu pilnībā. Tas maina to, kas līgumam jāaptver: abonēšanas nosacījumi, izbeigšana, datu īpašumtiesības un eksporta tiesības, darbspējas saistības, atbalsta atbildes laiki. Standarta iepirkumu veidnes nebija rakstītas šim modelim, tāpēc pārliecinieties, ka jūsējās ir atjauninātas.

Darbu apjoma dokuments ir tikpat svarīgs kā līgums

Darbu apjoma dokuments precizē, kas tiek piegādāts, kurš to dara un kad: konta konfigurācija, pārvadātāju pievienošana, integrācijas atbalsts, apmācība un pieņemšanas kritēriji, kas apliecina, ka ieviešana ir faktiski pabeigta. Ja tas nav darbu apjoma dokumentā, tas nav iekļauts — neatkarīgi no tā, kas tika teikts tikšanās vai e-pastā. Īpaši uzmanīgi izlasiet sadaļu pieņēmumi. Tur apjoms ir nosacīti definēts. Ja jūsu pārvadātāju saraksts izrādās lielāks nekā norādīts, vai jūsu ERP prasa nestandarta integrācijas formātu, pieņēmumu sadaļa izlemj, vai tas ir īsa saruna vai apmaksāts izmaiņu pieprasījums.

Esiet skaidri par to, kas ir ārpus apjoma

Pielāgota izstrāde, apmācība uz vietas, datu migrācija, integrācijas darbs jūsu sistēmās, pārvadātāju puses izmaiņas. Parasti tie tiek aprēķināti atsevišķi. Iegūstot to uz papīra pirms parakstīšanas, tiek novērsts visbiežākais un visvairāk novēršamais ieviešanas berzes avots: divas puses, kuras katra pieņēma, ka kaut kas atšķirīgs bija iekļauts.

Saskaņojiet ieviešanas plānu pirms parakstīšanas

Nevis pēc. Pārvadātāju prioritizācija, konfigurācijas grafiks, integrācijas atskaites punkti, darbības uzsākšanas kritēriji — nokārtojiet visu, kamēr jums vēl ir sviras efekts. Piegādātājs, kurš līguma posmā nevar sniegt skaidru ieviešanas plānu, jums pasaka kaut ko, ko vēlēsieties zināt pirms apņemšanās.

Pēc parakstīšanas: TMS ieviešana un onboarding

Lielākā daļa reālā riska pastāv pēc parakstīšanas. Trīs lietas izlemj, kā tas noritēs.

1. Datu migrācija

Pārvadātāju līgumi, cenu lapas, adrešu grāmatas, vēsturiskie sūtījumi. Agri izlemiet, kas jāmigrē, kas vispirms jāsakārto un kurš ir atbildīgs par darbu. Nekārtīgi avota dati ir visbiežākais iemesls, kāpēc darbības uzsākšanas datums tiek atlikts arvien tālāk. Sakārtojiet tos pirms migrācijas, nevis migrācijas laikā.

2. Pārvadātāju pievienošanas secība

Jūs nepievienojat visus pārvadātājus pirmajā dienā. Prioritizējiet pēc apjoma un kritiskuma, palaidiet un validējiet galvenos, pēc tam paplašiniet. Tieši šeit pakāpeniskā pieeja, par kuru jautājāt vērtēšanas laikā, atmaksājas.

3. Lietotāju pieņemšana

Cilvēkiem, kas katru dienu pasūta sūtījumus, ir jāvēlas izmantot jauno sistēmu. Iesaistiet vismaz vienu no viņiem jau no RFP posma, pienācīgi apmāciet viņus ieviešanas laikā un pārliecinieties, ka ikdienas darbplūsma ir patiešām ātrāka nekā iepriekšējā. Tehniski nevainojama ieviešana, ko komanda vienkārši neizmanto, joprojām ir neveiksmīga ieviešana.

10 biežākās TMS RFP kļūdas

Modeļi, ko mēs redzam visbiežāk — visi vienā vietā:

• Nav operacionālā konteksta. Galvenā kļūda. Piegādātājiem nav sniegti apjomi, objektu struktūra, pārvadātāju aina. Precizēšanas kārta un vispārīgas cenas ir garantētas.
• Viss ir obligāts. Kad katra prasība ir kritiska, prioritāšu sleja ir bezjēdzīga un nevar atšķirt neapstrīdamo no labi būtu.
• Neskaidrs grafiks. Bez datumiem piegādātāji nevar novērtēt savu darba apjomu, tāpēc piedāvājumi atgriežas tikpat neskaidri.
• Pārmērīga tehniskā specifikācija. Tehniskās ieviešanas, nevis operacionālā rezultāta noteikšana izslēdz labus risinājumus nepareizu iemeslu dēļ.
• ERP/TMS robežas ignorēšana. Pieņemot, ka TMS apstrādā finanšu procesus, ko faktiski apstrādā ERP, un to apzinoties ieviešanas vidū.
• Cenas prioritizēšana. Izvēle, pamatojoties uz abonēšanas virsrakstu bez trīs gadu modeļa vai neņemot vērā savienojamību ar pārvadātājiem un godīgumu par integrāciju.
• Demonstrācija, nevis apskate. Piegādātāja noslīpētās secības vērošana, nevis sistēmas pārbaude ar reālajiem scenārijiem.
• Atsauces, kas neatbilst jūsu darbībai. Iespaidīgu logo skatīšanās, taču šiem uzņēmumiem var būt loģistikas darbības, kas neko nelīdzinās jūsējām. Lūdziet atsauces, kas izskatās kā jūs, un pēc tam jautājiet, kā faktiski noritēja ieviešana un integrācija.
• Ieviešanas atstāšana uz laiku pēc parakstīšanas. Plāns, ko saskaņojat ar sviras efektu, ir labāks par to, ko saskaņojat bez tā.
• Pārāk smags process pareizajam piegādātājam. Birokrātijas slogs, kas var izfiltrēt modernās platformas, kuras jums būtu kalpojušas vislabāk.

Bezmaksas TMS RFP veidnes

Mēs izveidojām piecas veidnes, pamatojoties uz RFP, uz kuriem atbildam, lai jums nebūtu jāsāk no tukšas lapas:

1. RFP dokumenta veidne. Pilna struktūra no šī ceļveža.
2. Funkcionālo prasību vērtēšanas lapa. Prioritizēta, ar seguma sleju katram piegādātājam.
3. Operacionālās informācijas kontrolsaraksts. Desmit jautājumi aizpildāmas tabulas formātā.
4. Piegādātāju vērtēšanas matrica. Svērtā vērtēšana starp piegādātājiem.
5. RFP grafika veidne. Darbības, datumi, atbildīgie.

Lejupielādējiet komplektu — visas piecas, bezmaksas, e-pasts nav nepieciešams. Ņemiet to, kas noderīgs, pārējo ignorējiet:

Lejupielādēt pilno TMS RFP veidņu komplektu (.zip)

Cargoson ir transporta vadības sistēma, ko izmanto vidēja lieluma ražotāji un vairumtirgotāji visā Eiropā un Ziemeļamerikā. Mēs regulāri atbildam uz RFP, tādu kā tas, ko jūs gatavojaties rakstīt — tāpēc, ja vēlaties pārrunāt savas prasības pirms rakstīšanas uzsākšanas, mēs labprāt palīdzēsim to pārdomāt, bez jebkādām saistībām.

Rezervējiet bezmaksas 30 minūšu konsultāciju šeit

Vadiet procesu labi — un tas atmaksāsies ar katru ieguldīto stundu.