როგორ დავწეროთ TMS RFP: ჩვენი გამოცდილება [+ 5 უფასო შაბლონი]

ჩვენ სატრანსპორტო მართვის სისტემის RFP-ებს (წინადადებების მოთხოვნა) ყოველ კვირა ვპასუხობთ. ზოგი სიამოვნებით გადის. ზოგი კი — გაკვეთილია იმაში, რა არ უნდა გაკეთდეს.

ეს სტატია ის არის, რასაც დღეს ავაშენებდი, თუ TMS-ის შერჩევის პროცესს ნულიდან ვაწყობდი. ის ეფუძნება ჩვენ მიერ გაცემულ პასუხებს, კომპანიებსა და ინდუსტრიებში განმეორებად შაბლონებს, RFP-ების ყველაზე გავრცელებულ შემადგენლობას და ყველაზე ხშირ შეცდომებს.

თუ შესყიდვების სპეციალისტი ხართ, ამის უმეტესი ნაწილი ნაცნობი მოგეჩვენებათ. იმედია, ეს მასალა გადაარჩენს თქვენ სულ მცირე ერთ ზედმეტ დამაზუსტებელ რაუნდს.

რა არის TMS RFP?

TMS RFP (წინადადებების მოთხოვნა) არის სტრუქტურირებული დოკუმენტი, რომელსაც სატრანსპორტო მართვის სისტემების მომწოდებლებს უგზავნით. ის აღწერს თქვენს ლოგისტიკურ ოპერაციას და სთხოვს თითოეულს, შემოგთავაზოს, როგორ გაუმკლავდება მათი სისტემა ამ ოპერაციას — ერთსა და იმავე მოთხოვნების ნაკრების მიხედვით. მთელი მიზანი შედარებადობაა. ერთი და იგივე კითხვები, ერთი და იგივე ფორმატი, ერთი და იგივე კონტექსტი — რათა მიღებული პასუხები გვერდიგვერდ დაეწყოს, და არა ხუთ ცალ-ცალკე სარეკლამო პრეზენტაციად წაიკითხოს.

RFP ყოველთვის საჭირო არ არის. ის თავის ფასს ამართლებს მაშინ, როდესაც გადაწყვეტილება რთულია ან შიდა დასაბუთება სჭირდება. თუ თქვენი ლოგისტიკური ოპერაციები მარტივია, პროდუქტის დემო-ჩვენება და ზარი რამდენიმე მომწოდებელთან სავსებით საკმარისი იქნება.

მართლა გჭირდებათ TMS RFP ტენდერის ჩატარება?

ამ კითხვაზე არასწორი პასუხი TMS-ის შერჩევის მთელ პროცესში ყველაზე ძვირადღირებული შეცდომაა. ამ გადაწყვეტილებას ყველაფრის წინ მიიღეთ.

საქმე ლოგისტიკის სირთულეშია, და არა კომპანიის ზომაში.

ჩაატარეთ სტრუქტურირებული TMS RFP ტენდერი, თუ რამდენიმე ობიექტიდან ახდენთ გადაზიდვას, იყენებთ სხვადასხვა სატრანსპორტო სახეობას და გჭირდებათ სისტემის ERP-თან ინტეგრაცია. სწორედ ამ შემთხვევაში გჭირდებათ ყველა მომწოდებლის გვერდიგვერდ დაყენება, რათა მნიშვნელოვანი დეტალები არ გამოგრჩეთ. გადამზიდავებთან კავშირი მომწოდებლებს სრულიად განსხვავებულად აქვთ მოწყობილი. ერთი ამბობს „native", მეორე კი ჩუმად სხვის სისტემას იყენებს. თავისუფალ პროცესში ამას ხელმოწერის შემდეგ ვერ გაიგებთ. ძალიან გვიანი იქნება.

გამოტოვეთ ფორმალური RFP ტენდერი, თუ ერთი ობიექტი გაქვთ, რამდენიმე გადამზიდავი და უკვე იცით, რა გჭირდებათ. რატომ? იმიტომ, რომ RFP-ის გაშვების მომენტიდანვე საწარმო-დონის ფასების კატეგორიაში ხვდებით. 2–3 კარგი დემო-ჩვენება კონკრეტული კითხვებით ხშირად უკეთეს სისტემას გაძლევთ — უფრო იაფად და სწრაფად. უთხარით 2–3 მომწოდებელს, რას ახდენთ გადაზიდვას და რა პრობლემის გადაჭრა გინდათ, შემდეგ სთხოვეთ, პირდაპირ მათ სისტემაში გაჩვენონ. ერთ საათში ყველაფერი გასაგები გახდება. და თუ ძირითადად ამანათებს ახდენთ გადაზიდვას, და არა პალეტებს ან ტვირთს, შეიძლება სრული TMS საერთოდ არ გჭირდებოდეთ — მრავალი გადამზიდავის გადაზიდვის პროგრამული უზრუნველყოფა სხვა, მსუბუქი კატეგორიაა, სწორედ ამ საჭიროებისთვის შექმნილი.

ამიტომ, პირდაპირ იყავით საკუთარ თავთან — გადაწყვიტეთ, რომელი გჭირდებათ, სანამ დაიწყებთ. RFP, რომელიც არ გჭირდებოდათ, TMS-ის შეძენის ყველაზე ნელი და ძვირი გზაა.

RFP, რომელიც არ გჭირდებოდათ, TMS-ის შეძენის ყველაზე ნელი და ძვირი გზაა.

კიდევ ერთი გაფრთხილება, თუ სრულ RFP-ს მაინც ირჩევთ. პროცესი, სავსე მმართველობის ენით, მეთოდოლოგიური ჩარჩოებით და ფიქსირებული ფასის მოთხოვნებით, პასუხის გასაცემად კვირეებს მოითხოვს — და ამ ტვირთის ატანა შეუძლიათ ჩვეულებრივ მსხვილ, დამკვიდრებულ მომწოდებლებს. ასე რომ, თუ უფრო მოქნილი, თანამედროვე პლატფორმა სინამდვილეში უკეთ გამოგადგებოდათ, ზედმეტად ბიუროკრატიული პროცესი შეიძლება ჩუმად გამოფილტრავდეს მათ, სანამ ერთ დემო-ჩვენებასაც კი ნახავდეთ.

მიზანია თქვენთვის სწორი გადაწყვეტის პოვნა. პროცესი ამ მიზნის გარშემო ააგეთ, და არა პროცესის მართვის გარშემო.

TMS RFP პროცესი 9 ეტაპად

TMS-ის შერჩევა რთული არ უნდა იყოს. მაგრამ მას სჭირდება მკაფიო თანმიმდევრობა. გამოტოვეთ ეტაპები და მოგვიანებით გადაიხდით — ჩვეულებრივ დანერგვის დროს, როდესაც ადრე გასარკვევი ვარაუდები ძვირადღირებულ სიურპრიზებად იქცევა.

კარგად ჩატარებული პროცესი 8–12 კვირას გრძელდება. მარტივი მოცულობისთვის — ნაკლებს, და იშვიათად სჭირდება მეტი.

აი, მუშა თანმიმდევრობა:

1. ბაზრის სკანირება. სანამ ერთ მოთხოვნასაც ჩამოწერთ, დაუთმეთ დრო იმის გასაგებად, რა არსებობს ბაზარზე. TMS ბაზარი ბოლო ხუთ წელში მნიშვნელოვნად შეიცვალა: არსებობს კარგი საწარმო-დონის პლატფორმები, კარგი საშუალო ბაზრის პლატფორმები და ნამდვილად შესაძლებლობიანი თანამედროვე SaaS სატრანსპორტო მართვის პროგრამული უზრუნველყოფის გადაწყვეტილებები, რომლებიც ხუთი წლის წინ არ არსებობდა. შეადგინეთ 5–8 TMS მომწოდებლის გრძელი სია, ვისთანაც ღირს მიახლოება.
2. NDA. გაგზავნეთ ადრე. გაუზიარებთ საოპერაციო მონაცემებს — მოცულობებს, გადამზიდავების სახელებს, შიდა სისტემების დეტალებს — და ხელმოწერილი NDA RFP-ის გაგზავნამდე სტანდარტული პრაქტიკაა, რომელიც ორივე მხარეს იცავს.
3. RFI (სურვილისამებრ). მოკლე ინფორმაციის მოთხოვნა (Request for Information) აზრიანია, თუ გრძელი სია ფართოა და სრული RFP პროცესში ინვესტირებამდე გაფილტვრა გინდათ. შეინახეთ ერთ გვერდზე: კომპანიის ფონი, ძირითადი შესაძლებლობები, სავარაუდო ფასების დიაპაზონი. საკმარისი მოკლე სიის შესადგენად, მომწოდებლებისგან ესეების მოთხოვნის გარეშე.
4. RFP. ძირითადი დოკუმენტი. ის ყველა მომწოდებელს აძლევს იმას, რაც სჭირდება ზუსტი წინადადების შესადგენად. ამაზე მეტი — შემდეგ თავში.
5. კითხვა-პასუხის ფანჯარა. ყოველთვის ჩართეთ. მომწოდებლებს კითხვები ექნებათ, და პასუხები ხშირად ყველა მიღებულ წინადადებას აუმჯობესებს. ჩაატარეთ წერილობით, ყველა კითხვა და პასუხი ყველა მომწოდებელს ერთდროულად გაუზიარეთ. ეს პროცესს სუფთა და შედარებადს ინარჩუნებს.
6. მოკლე სია და პრეზენტაციები. შეაფასეთ წერილობითი წინადადებები, შემდეგ 2–3 მომწოდებელი პრეზენტაციაზე მოიწვიეთ. პრეზენტაცია უნდა მოიცავდეს სისტემის პირდაპირ ჩვენებას თქვენი რეალური სცენარების მიხედვით, და არა ზოგად დემო-ჩვენებას. თუ მომწოდებელი ვერ გიჩვენებთ თქვენს სცენარს მათ სისტემაში, ეს თავისთავად სასარგებლო ინფორმაციაა.
7. მეორე რაუნდი (საჭიროების შემთხვევაში). რთული გადაწყვეტილებისთვის ღირს კონკრეტულ ხარვეზებზე — უსაფრთხოება, ინტეგრაცია, კომერციული პირობები — ორიენტირებული სიღრმისეული სესია. არ დანიშნოთ, თუ ნამდვილი კითხვები არ გაქვთ.
8. გადაწყვეტილება და კონტრაქტი. მოლაპარაკებამდე შიდა კონსენსუსს მიაღწიეთ. იცოდეთ თქვენი აუცილებელი პირობები, მისაღები კომპრომისები და გასვლის წერტილები.
9. ონბორდინგი. ეს ხელმოწერით არ მთავრდება. საუკეთესო RFP შედეგებს ახლავს ონბორდინგის გეგმა, რომელზეც კონტრაქტის გაფორმებამდე შეთანხმდნენ.

TMS RFP გრაფიკი, რომლის კოპირებაც შეგიძლიათ

სავარაუდო ხანგრძლივობა მოცულობის მიხედვით:

• ერთი მარტივი ობიექტი: 6–8 კვირა (სრული RFP შეიძლება საერთოდ არ დაგჭირდეთ).
• რამდენიმე ობიექტი + ERP ინტეგრაცია: 8–12 კვირა.
• გლობალური, მრავალსუბიექტიანი, რთული ინტეგრაცია: 12–20 კვირა, სავარაუდოდ პრეზენტაციის ორი რაუნდით.

ჩამოტვირთეთ RFP გრაფიკის შაბლონი (.docx)

რა უნდა შეიცავდეს TMS RFP დოკუმენტი

RFP დოკუმენტი ამ პროცესში თქვენი ყველაზე მნიშვნელოვანი ინსტრუმენტია. კარგი RFP დოკუმენტი შეფასების სამუშაოს უმეტეს ნაწილს თავად ასრულებს, ამიტომ ფოკუსირებული შეინახეთ. მჭიდრო 10-გვერდიანი RFP სჯობს 30-გვერდიანს, რომელიც ყველაფრის დაფარვას ცდილობს.

1. სამოტივაციო წერილი და მიზანი

ერთი გვერდი. ვინ ხართ, რას ეძებთ, რატომ ახლა. ფაქტობრივად შეინახეთ. მომწოდებლებს ხედვის განცხადება არ სჭირდებათ — მათ უბრალოდ თქვენი საოპერაციო პრობლემის გაგება სჭირდებათ.

2. გრაფიკი

რეალური თარიღებით მკაფიო განრიგი: RFP-ის გაგზავნა, კითხვა-პასუხის ვადა, წარდგენა, პრეზენტაციის ფანჯარა, გადაწყვეტილება. მომწოდებლები ამის მიხედვით გეგმავენ პასუხის მომზადებას. ბუნდოვანი გრაფიკი ბუნდოვან წინადადებებს გიბრუნებთ.

3. კომპანიისა და ოპერაციის ფონი

სწორედ აქ ჩამოუვარდება RFP-ების უმეტესობა, და ეს არის განსხვავება შედარებად წინადადებებსა და დამაზუსტებელ რაუნდს შორის. არ აღწეროთ მხოლოდ თქვენი ბიზნესი — აღწეროთ თქვენი ლოგისტიკური ოპერაცია. რამდენი ობიექტი. რამდენი იურიდიული პირი. რა სატრანსპორტო სახეობები (ამანათი, LTL, FTL, საჰაერო, საზღვაო, სარკინიგზო). რომელი რეგიონები. სავარაუდო მოცულობები. მიმდინარე სისტემები. „კარგი" ასევე სხვადასხვა სექტორში სხვადასხვა ნიშნავს — ელექტრონიკის, მანქანათმშენებლობის, ქიმიური ან სტამბა-შეფუთვის მწარმოებლების მოთხოვნები ერთი და იგივე არ არის. ეს ის კონტექსტია, რომელიც მომწოდებლებს სჭირდებათ წინადადების ზუსტად შესადგენად. თუ საკმარის დეტალს არ მიაწვდით, ორ კვირას გაატარებთ დამაზუსტებელ კითხვებზე პასუხის გაცემაში, რომლებიც სრულად თავიდან ასაცილებელი იყო. ამ თემას ცალკე განვიხილავთ შემდეგ თავში.

4. ფუნქციური მოთხოვნები

სისტემის ფუნქციების ცხრილი, მნიშვნელობის მიხედვით პრიორიტეტიზებული: აუცილებელი / სასურველი / კარგი-ქონა (Excel გამოდგება). სთხოვეთ მომწოდებლებს, თითოეულ მოთხოვნაზე მიუთითონ დაფარვის დონე: ა) native, ბ) third-party, გ) customization, ან დ) არ არის მხარდაჭერილი. სწორედ ეს ხდის წინადადებებს შედარებადს. მოგვიანებით ვისაუბრებთ ამ სიის შედგენაზე.

5. შეფასების კრიტერიუმები

უთხარით მომწოდებლებს, როგორ მიიღებთ გადაწყვეტილებას: ფუნქციონალობა, ფასი, დანერგვის მიდგომა, რეფერენსები, უსაფრთხოება, გუნდი. გაუზიარეთ წონები, თუ მზად ხართ. რაც უფრო გამჭვირვალე ხართ, მით უკეთესი წინადადებები მოვა.

6. ფასწარმოქმნის მოდელი

მოითხოვეთ სრული დეტალიზაცია: გამოწერა, დანერგვა, ტრანზაქციის საფასური, მხარდაჭერა, ყველაფერი სხვა. სთხოვეთ ნიმუშ-ინვოისი, თუ შესაძლებელია. ფასწარმოქმნის სტრუქტურა მომწოდებლებს შორის ძალიან განსხვავდება, და ფარული ხარჯები ჩვეულებრივ გვიან ჩნდება. ეს ადრე გაარკვიეთ.

7. პასუხის ფორმატი

ზუსტად უთხარით მომწოდებლებს, როგორ გინდათ წინადადების სტრუქტურა, და თუ შაბლონებს მიაწვდით, მოითხოვეთ მათი გამოყენება. შედარებადი წინადადებები შეფასებისას დღეებს გიზოგავთ, და ფორმატი მთლიანად თქვენს კონტროლშია.

ჩამოტვირთეთ RFP დოკუმენტის შაბლონი ზემოთ მოცემული სრული სტრუქტურით:

ჩამოტვირთეთ RFP დოკუმენტის შაბლონი (.docx)

საოპერაციო ინფორმაცია, რომელსაც TMS RFP-ების უმეტესობა გამოტოვებს — და რატომ არის ის ყველაზე მნიშვნელოვანი

ეს ის თავია, რომლის პირველ რიგში წაკითხვასაც ყველა TMS RFP ავტორს ვუსურვებდი.

ჩვენ ბევრ TMS ტენდერს ვპასუხობთ. თითქმის ყველა წინადადება, რომელსაც ვწერთ, დამაზუსტებელ რაუნდს საჭიროებს — და იშვიათად იმიტომ, რომ მოთხოვნები გაუგებარი იყო. მიზეზი ის არის, რომ საოპერაციო კონტექსტი არ იყო: მოცულობები, ობიექტების სტრუქტურა, გადამზიდავების ლანდშაფტი, მიმდინარე სისტემები.

RFP-ებს, რომლებიც სრულ დამაზუსტებელ რაუნდს საჭიროებდნენ, თითქმის ყოველთვის ერთი საერთო ნიშანი ჰქონდათ:

ვნახეთ კომპანიები, რომლებიც კვირეებს ხარჯავდნენ შეფასების კრიტერიუმებისა და მოთხოვნების სიების შედგენაზე, შემდეგ კი RFP-ს გზავნიდნენ, სადაც არ იყო ნახსენები, რამდენ გადაზიდვას ამუშავებენ თვეში.

ამის გარეშე მომწოდებლები ვარაუდობენ. და როდესაც ვარაუდობენ, წინადადებები ბუნდოვანი ბრუნდება, ფასები საბოლოო არ არის და შედარებისთვის მყარი საფუძველი არ არსებობს.

მაგალითად, 10 საწყობიანი გლობალური მწარმოებელი SAP-ით სრულიად განსხვავებულ წინადადებას საჭიროებს, ვიდრე ერთი ობიექტის მქონე დისტრიბუტორი, რომელიც ლოგისტიკას ცხრილებში მართავს. თუ მომწოდებელს ვერ ეუბნებით, რომელი ხართ, ის ფრთხილობს — და ისეთ წინადადებებს იღებთ, რომლებიც არაფერს ადასტურებს.

გამოსწორება ნახევარ დღეს მოითხოვს. გაგზავნამდე RFP-ში უპასუხეთ ამ ათ კითხვას.

1. ორგანიზაცია და მოცულობა. რამდენი იურიდიული პირი და ობიექტი შედის მოცულობაში? განვრცობა პარალელური იქნება თუ ეტაპობრივი? რამდენად დამოუკიდებლად მუშაობენ ობიექტები — ცალ-ცალკე კონტრაქტები გადამზიდავებთან, ცალ-ცალკე გუნდები?
2. გადაზიდვის მოცულობები. ყოველთვიური და ყოველდღიური გადაზიდვების რაოდენობა ობიექტის მიხედვით, საშუალო და პიკური. სეზონურობა. შემომავალი და გამავალი გადაზიდვების თანაფარდობა.
3. სატრანსპორტო სახეობების განაწილება. რა წილი მოდის ამანათზე, LTL-ზე, FTL-ზე, საჰაერო, საზღვაო გადაზიდვაზე? რომელი სახეობები იზრდება? რომელი ყველაზე კრიტიკულია ოპერაციულად?
4. გადამზიდავების ლანდშაფტი. რამდენი გადამზიდავი ჰყავს თითოეულ ობიექტს და სახეობას? ობიექტებს შორის გაზიარებულია თუ ლოკალურად მართული? არის სტრატეგიული გადამზიდავები, რომლებიც პრიორიტეტული უნდა იყოს, ან კლიენტის მიერ დანიშნული გადამზიდავები, რომლებიც ვერ შეიცვლება?
5. გეოგრაფია და სავაჭრო მარშრუტები. რომელი რეგიონები შედის მოცულობაში? რომელი მარშრუტები ყველაზე მნიშვნელოვანია: შიდა, საზღვარგარეთი, კონტინენტთაშორისი? ძირითადი პორტები ან ლოგისტიკური კვანძები?
6. მიმდინარე მდგომარეობა. როგორ იგეგმება, იკვეთება და ითვალთვალება გადაზიდვები დღეს? ERP-ში, ცხრილებში, გადამზიდავების პორტალებში, ელ-ფოსტით? რა არის მიმდინარე პროცესის ძირითადი სუსტი წერტილები?
7. ფინანსური სტრუქტურა. ვინ იხდის ტრანსპორტისთვის — ერთი სუბიექტი თუ რამდენიმე? არის მესამე მხარის ან კლიენტის ანგარიშის ნომრები? როგორ ფიქსირდება და მოწმდება სატრანსპორტო ხარჯი დღეს?
8. ბიზნეს მოდელი. B2B, B2C? შერეულია — რა თანაფარდობით. საოპერაციო და სისტემური მოთხოვნები საკმაოდ მნიშვნელოვნად განსხვავდება.
9. ინტეგრაციის ლანდშაფტი. რომელი სისტემები უნდა დაუკავშირდეს TMS-ს: ERP, WMS, CRM? არის არსებული გადამზიდავის ინტეგრაციები, რომლებიც შენარჩუნება სჭირდება? რამდენად ავტომატიზირებული უნდა იყოს პირველი დღიდანვე?
10. გრაფიკი და შეზღუდვები. არის გაშვების სამიზნე თარიღი? შიდა ეტაპები — ფინანსური წლის დასასრული, პიკური სეზონი, სისტემის მიგრაცია — რომლებიც გრაფიკზე მოქმედებს?

ამის ჩაწერა რთული არ არის. მაგრამ ის სრულიად ცვლის იმას, რაც პასუხად მოვა.

ჩამოტვირთეთ საოპერაციო ინფორმაციის საკონტროლო სია, რომელიც ამ ათ კითხვას შევსებად ცხრილად გარდაქმნის და პირდაპირ RFP-ში ჩასაყრელია:

ჩამოტვირთეთ საოპერაციო ინფორმაციის საკონტროლო სია (.docx)

როგორ დავწეროთ TMS-ის ფუნქციური მოთხოვნები

ფუნქციური მოთხოვნები RFP-ის გული არის. სწორად შეადგინეთ და მიიღებთ მკაფიო, შედარებად სურათს იმის შესახებ, რა შეუძლია და რა არ შეუძლია თითოეულ მომწოდებელს. არასწორად — და შეიძლება კვირეები გაატაროთ პასუხების გაშიფვრაში, სადაც ყველა „დიახ"-ს ამბობს.

მიზანი ყველაზე გრძელი სია არ არის. ყველაზე გულწრფელი სია — ეს არის მიზანი.

პრიორიტეტიზება გადამჭრელად: აუცილებელი, სასურველი, კარგი-ქონა

ყველაფერი, რაც გინდათ, თანაბრად მნიშვნელოვანი არ არის. გამოიყენეთ სამი კატეგორია და მათ ერთგული დარჩით:

1. აუცილებელი (M): კომპრომისი გამორიცხულია. მომწოდებელი, რომელიც ამას ვერ ასრულებს, გარეთ არის — რაც არ უნდა სხვა მოიტანოს.
2. სასურველი (S): მნიშვნელოვანია, მაგრამ გამოსავლით ან ახლო ვადის გეგმის დაპირებით შეიძლება შეგუება.
3. კარგი-ქონა (N): სასარგებლოა ინფორმაციისთვის, მაგრამ ყველა ზემოთ ჩამოთვლილის შემდეგ მოდის.

სიების უმეტესობაში ბევრად მეტი „აუცილებელია" ვიდრე უნდა. თუ ყველაფერი კრიტიკულია, არაფერია კრიტიკული. გულწრფელად შეაფასეთ, რა ნამდვილად შეაჩერებდა სისტემის მუშაობას თქვენთვის, და მხოლოდ ის მონიშნეთ „აუცილებლად".

სთხოვეთ მომწოდებლებს ფუნქციონალობის დაფარვის კლასიფიკაცია: native / third-party / customization

ყოველი მოთხოვნისთვის მათ ამ ოთხიდან ერთ-ერთი პასუხი უნდა გასცენ:

სწორედ ეს სვეტი განსაზღვრავს, მოიპოვებს თუ დაკარგავს წინადადება თქვენს ნდობას. მომწოდებელი, რომელიც გულწრფელად პასუხობს და სადაც ჭეშმარიტია, „არ არის მხარდაჭერილი"-ს წერს, გიჩვენებთ, როგორ მოიქცევა პარტნიორად. მომწოდებელი, რომელიც ყველაფერზე „native"-ს პასუხობს, ასევე მნიშვნელოვან რამეს გეუბნებათ.

კონკრეტული იყავით კითხვაში

„მხარს უჭერს სისტემა გადამზიდავის ფასწარმოქმნას?" — ამაზე უსარგებლო „დიახ"-ს მიიღებთ. „შეუძლია სისტემას გამოთვალოს სატრანსპორტო ფასი ყველა გადამზიდავისთვის, მათ შორის ფასწარმოქმნის API-ის გარეშე, და გვერდიგვერდ აჩვენოს თითოეული გადაზიდვისთვის?" — ეს უკვე შეფასებადია.

სად მთავრდება ERP და სად იწყება TMS?

სატრანსპორტო მართვის სისტემების შეფასებაში ერთ-ერთი ყველაზე გავრცელებული გაუგებრობის წყარო TMS-ისა და ERP-ის საზღვრის განსაზღვრაა.

ფინანსური პროცესები, როგორიცაა GL კოდირება, landed cost და freight audit, ხშირად ERP-ის მხარეს ხდება, TMS კი მონაცემებს ERP-ს აწვდის. ეს ნორმალურია და ხშირად სწორი სტრუქტურაა. მაგრამ ეს ზუსტად უნდა იყოს გაწერილი. როდესაც მომწოდებელი თქვენს „აუცილებელ" მოთხოვნაზე „ERP ინტეგრაციით მოგვარდება"-ს პასუხობს, ზუსტად გაარკვიეთ, რას ნიშნავს ეს თქვენი დანერგვისთვის და ვინ ქმნის ამ ინტეგრაციას.

განსაზღვრეთ მიზანი, და არა ტექნიკური გადაწყვეტა

აღწერეთ, რის მიღწევა გჭირდებათ, და არა ის, როგორ უნდა მიაღწიოს ამას სისტემა ტექნიკურად. ზედმეტად დეტალური მოთხოვნები კარგ გადაწყვეტილებებს არასწორი მიზეზებით გამოფილტრავს. დაუტოვეთ მომწოდებლებს სივრცე, გაჩვენონ უკეთესი გზა, ვიდრე თქვენ გქონდათ მხედველობაში, რადგან ზოგჯერ ასეთი გზა მათ ნამდვილად აქვთ.

30 გულწრფელი, პრიორიტეტიზებული მოთხოვნა გეტყვით მეტს, ვიდრე 150-სტრიქონიანი ცხრილი, სადაც ყველაფერი კრიტიკულია და ყველა მომწოდებელმა ყველა ველი მონიშნა.

TMS მოთხოვნების საწყისი ნაკრები ადაპტაციისთვის

პირველად მყიდველების უმეტესობას სიის საწყისი პუნქტი სჭირდება, ამიტომ აქ მოცემულია ჩვენი გამოცდილებიდან ნაკრები მაგალითი, უკვე კატეგორიზებული, რომლის ადაპტაციაც შეგიძლიათ თქვენი ოპერაციისთვის. სრული სია ქვემოთ მოცემულ შეფასების ფურცელში ჩამოსატვირთია — ეს საკმარისია სტრუქტურის სანახავად.

ჩამოტვირთეთ ფუნქციური მოთხოვნების შეფასების ფურცელი, უკვე შედგენილი პრიორიტეტებითა და თითოეული მომწოდებლის დაფარვის სვეტით:

ჩამოტვირთეთ ფუნქციური მოთხოვნების შეფასების ფურცელი (.docx)

როგორ შევადაროთ TMS-ის ხარჯი (და ავაშენოთ 3-წლიანი მოდელი)

„რა ღირს TMS?" — ეს კითხვაა, რომლის პასუხსაც მყიდველები ყველაზე მეტად ელიან, ხოლო მომწოდებლები ყველაზე მეტად ერიდებიან. მაგრამ გამოწერის საფასური იშვიათად არის საბოლოო ხარჯი. საშუალო ზომის, მრავალობიექტიანი გამგზავნისთვის დანერგვა და ინტეგრაცია სამწლიანი ჯამის ჩამოყალიბებაში ხშირად ყოველთვიურ საფასურზე მეტ გავლენას ახდენს — და სწორედ ეს სტრიქონი ყველაზე ბუნდოვანია მომწოდებლებთან. ამიტომ ამ კითხვის ისე სტრუქტურირება, რომ პასუხები შედარებადი და რეალური ხარჯი ხილული იყოს — ეს არის ხელოვნება.

დაახლოებითი ორიენტირისთვის: საშუალო ბაზრის cloud-based TMS ჩვეულებრივ რამდენიმე ასიდან რამდენიმე ათასამდე ევრო თვეში ღირს, ხოლო ტრადიციული საწარმო სისტემები — ათეულ ათასიდან მილიონ ევრამდე წელიწადში, დანერგვის ხარჯებით, რომლებიც ექვს-შვიდ ნიშნულს შეიძლება მიაღწიოს. ეს ფართო დიაპაზონია — სწორედ ამიტომ ერთ-ერთ ნომერზე მეტად მნიშვნელოვანია ერთნაირ პირობებზე შედგენილი მოდელი. რეალური TMS მომწოდებლების ფასების სანახავად იხილეთ ჩვენი კვლევა საუკეთესო TMS მომწოდებლების შესახებ.

TMS ფასწარმოქმნის კომპონენტები

თითქმის ყველა TMS შეთავაზება ამ კომბინაციაა:

ააგეთ სამწლიანი ხარჯის მოდელი შედარებამდე

TMS მომწოდებელი, რომელიც გამოწერაზე იაფი ჩანს, შეიძლება ყველაზე ძვირი აღმოჩნდეს, როდესაც დანერგვა, ტრანზაქციის საფასური და გადამზიდავის ონბორდინგი ჩაირთვება. ყველა მომწოდებელი ერთი და იგივე მოდელით გაიარეთ:

3-წლიანი ხარჯი = დანერგვა + (წლიური გამოწერა × 3) + (გადაზიდვაზე საფასური × წლიური მოცულობა × 3) + მხარდაჭერა + მოსალოდნელი გადამზიდავის და ინტეგრაციის დამატებები.

გამოიყენეთ თქვენი რეალური მოცულობები, და არა მომწოდებლის მოწესრიგებული მაგალითი. ეს ერთი ცხრილი ხშირად მოკლე სიას ახელს.

ყურადღება მიაქციეთ სხვადასხვა ფასწარმოქმნის კომპონენტებს, და არა მხოლოდ საბაზო საფასურს

ზოგი მომწოდებელი გამოწერაზე დაბალ ფასს ადგენს და ტრანზაქციის საფასურით ან გადამზიდავის საფასურით ანაზღაურებს. ეს ავტომატურად ცუდი არ არის, მაგრამ ცვლის იმას, ვინ ყველაზე იაფია ზრდასთან ერთად. თუ თქვენი მოცულობა იზრდება, გადაზიდვაზე დაფუძნებული მოდელი სწრაფად შეიძლება გაასწრებს ფიქსირებულს. სთხოვეთ ნიმუშ-ინვოისი და გამოწერის პირობები, რათა შეადაროთ ის, რასაც ნამდვილად გადაიხდით, და არა სათაურის ფასი.

ერთი კითხვა, რომელიც ყველა მომწოდებელს ღირს დაუსვათ: ახალი გადამზიდავის ინტეგრაციები შედის ფასში, თუ ყოველ ჯერზე ცალ-ცალკე ანგარიშდება? ზოგი TMS პლატფორმა ახალ გადამზიდავის ინტეგრაციაზე 5 000–10 000 ევრო ითხოვს და თვეები სჭირდება, სხვები კი ახალ გადამზიდავის ინტეგრაციებს დამატებითი ხარჯის გარეშე ქმნიან. საშუალო ზომის გამგზავნისთვის, რომელიც წლების განმავლობაში გადამზიდავებს ამატებს, ეს ერთი პასუხი სამწლიანი ჯამის ჩამოყალიბებაში გამოწერის სტრიქონზე მეტ გავლენას შეიძლება ახდენდეს.

როგორ შევაფასოთ TMS წინადადებები ფასის მიღმა

წინადადებები მოვიდა. ყველა გონივრული ჩანს, უმეტესობა „დიახ"-ს ამბობს თქვენს მოთხოვნებზე, ფასები მსგავს დიაპაზონშია. ახლა რა?

სწორედ ამ მომენტში გუნდები ჩუმად ფასს ირჩევენ, რადგან ყველაფერი სხვა შედარება უფრო რთული ჩანს. ნუ გააკეთებთ ამას. აი, რა ნამდვილად განასხვავებს მათ.

1. გადამზიდავებთან კავშირი.

TMS-ისთვის გადამზიდავებთან კავშირი საფუძველია. როგორ უკავშირდება მომწოდებელი გადამზიდავებს სინამდვილეში — პირდაპირი API/EDI ინტეგრაციებით, მესამე მხარის აგრეგატორებით, თუ საერთოდ არა (ელ-ფოსტა + PDF შეკვეთები, მიუხედავად მათი IT შესაძლებლობებისა)? რა ხდება, როდესაც გჭირდებათ გადამზიდავი, რომელსაც ჯერ არ უჭერენ მხარს — რამდენ ხანს სჭირდება და რა ღირს?

მომწოდებელი ღრმა, პირდაპირი გადამზიდავის კავშირით სრულიად განსხვავებული ცხოველია იმისგან, ვინც ყველაფერს middleware-ის ფენით ატარებს. განსხვავებას შეგრძნობთ შეკვეთის საიმედოობაში, თვალყურის დევნების ხარისხში და იმაში, შეგიძლიათ თუ არა გადამზიდავის დამატება ყოველ ჯერზე ახალი კომერციული მოლაპარაკების გარეშე.

2. გადამზიდავის მომსახურების დონის ჰარმონიზაცია — ეს უფრო მნიშვნელოვანია, ვიდრე ადამიანების უმეტესობა ხვდება.

გადამზიდავები ციფრული შესაძლებლობებით თანაბარი არ არიან. ზოგს აქვს დახვეწილი API-ები, რომლებიც მოიცავს რეალურ დროში ფასწარმოქმნას, ETA პროგნოზს, მისამართის ვალიდაციას, ეტიკეტის გენერაციას, დეტალური თვალყურის დევნების მოვლენებს. სხვები გიგზავნიან შეკვეთის დადასტურებას ელ-ფოსტით — და ამით სრულდება კომუნიკაცია. გადამზიდავების ქსელების უმეტესობაში ორივე სახეობა ერთდროულად გვხვდება.

ეს თქვენი პრობლემა ხდება, როგორც კი ERP ან WMS TMS-ს დაუკავშირდება. თუ თქვენი ინტეგრაცია ყველა გადამზიდავისგან სრული მონაცემების მიღებას ელის — შეკვეთის დადასტურება, თვალყურის დევნების ბმული, ეტიკეტი, ხარჯის შეფასება — მაგრამ ზოგი გადამზიდავი ამას ვერ უზრუნველყოფს, გამონაკლისები, ხელით გამოსწორებები და მონაცემებში ხვრელები გაჩნდება. ერთი სუსტი გადამზიდავი მთელი სამუშაო პროცესის თანმიმდევრულობას არღვევს.

სხვადასხვა სატრანსპორტო მართვის პროგრამული უზრუნველყოფის მომწოდებლები ამ პრობლემას ორი გზით წყვეტენ, და ღირს გადაწყვიტოთ, რომელი გინდათ, სანამ ერთ წინადადებასაც კი წაიკითხავთ:

• თხელი TMS ატარებს ყველაფერს, რასაც თითოეული გადამზიდავი უზრუნველყოფს, და ხარვეზებთან გამკლავება თქვენი ERP-ის ან ხელით სამუშაოს პრობლემა გახდება. მარტივი ინტეგრაცია, მეტი გამონაკლისი თქვენი მხრიდან.
• TMS, რომელიც მონაცემებს ნორმალიზებს და ხარვეზებს თავად ავსებს: ითვლის სატრანსპორტო ხარჯს თქვენი ატვირთული სატარიფო ფურცლიდან, როდესაც ფასწარმოქმნის API არ არის; აფასებს მიწოდების დროს, როდესაც გადამზიდავი ETA-ს არ უზრუნველყოფს; ქმნის გადაზიდვის ეტიკეტებს, როდესაც გადამზიდავი ვერ ახდენს; სადაც თვალყურის დევნება არ არის, გადამზიდავებს საშუალებას აძლევს ხელით შეიყვანონ თვალყურის დევნების ეტაპები — და მეტი. პროგრამული უზრუნველყოფა ავსებს ხარვეზებს თქვენი გადამზიდავების ტექნიკურ შესაძლებლობებში, და თქვენი ERP ხედავს ერთ თანმიმდევრულ სტრუქტურას.

წინადადებების შეფასებისას პირდაპირ ჰკითხეთ მომწოდებლებს: როგორ ეპყრობიან შეზღუდული ციფრული შესაძლებლობების მქონე გადამზიდავებს? პასუხი ბევრს გეტყვით მათი პლატფორმის სიმწიფის შესახებ.

3. ინტეგრაციის გულწრფელობა.

განსაკუთრებული ყურადღება მიაქციეთ, როგორ აღწერენ მომწოდებლები ინტეგრაციის მოცულობას (ვინ რას აკეთებს). წინადადება, რომელიც პირდაპირ ამბობს „ERP-ის მხარის დამუშავება თქვენზეა, აი, რას ვუზრუნველყოფთ ჩვენ და როგორ ვუჭერთ მხარს" — უფრო სანდოა, ვიდრე ის, რომელიც „უწყვეტ ინტეგრაციას" გულისხმობს, მაგრამ არ ხსნის, ვინ რომელ ინტეგრაციას ახდენს — თქვენ თუ ისინი. ინტეგრაციის სიურპრიზები TMS პროექტების ვადებისა და ბიუჯეტის გადაჭარბების ერთ-ერთი ყველაზე გავრცელებული მიზეზია.

4. დანერგვის მიდგომა.

ეტაპობრივი მიდგომა — ჯერ ხელით ოპერაციული ვალიდაცია, შემდეგ ავტომატიზაცია — ჩვეულებრივ უფრო დაბალი რისკია, ვიდრე ერთდროული გაშვება. ამ გზით შეგიძლიათ დაადასტუროთ, რომ სისტემა თქვენი რეალური სამუშაო პროცესებისთვის მუშაობს, სანამ მთელ ოპერაციას მასზე დაეყრდნობით. ჩვენი მხრიდან: მომწოდებლები, რომლებიც ამას მოთხოვნის გარეშე გვთავაზობენ, ჩვეულებრივ უკვე გამოვლილი აქვთ ქაოტური გაშვება. ვინც სრულ ავტომატიზაციას პირველი დღიდანვე ჰპირდება — ხშირად არა.

5. რეფერენსები

სთხოვეთ რეფერენსები მსგავსი ოპერაციების მქონე კომპანიებიდან, და არა მხოლოდ მსგავსი ზომის ან თანამშრომელთა რაოდენობის. ერთი ობიექტის მქონე დისტრიბუტორის რეფერენსი განსაკუთრებით სასარგებლო არ არის, თუ SAP ინტეგრაციით მრავალობიექტიანი წარმოების ოპერაციას მართავთ. და კონკრეტული კითხვები დაუსვით: „როგორ წარიმართა გადამზიდავის ონბორდინგი?" „როგორ წარიმართა ინტეგრაციის პროცესი?" „რა მოხდა, როდესაც რაღაც მოსალოდნელად არ გამოვიდა?"

6. თავად წინადადება.

ის, თუ როგორ პასუხობს TMS მომწოდებელი თქვენს RFP-ს, წინასწარ გიჩვენებთ, როგორ მოიქცევა პარტნიორად. პასუხობდა თქვენს კითხვებს პირდაპირ, თუ ყველაფერს დათქმებში ახვევდა? გულწრფელად მიუთითებდა ხარვეზებზე, თუ ყველა მოთხოვნაზე სრულ დაფარვას ამტკიცებდა? ჩანდა, რომ გაიგო თქვენი ოპერაცია, თუ გამოგიგზავნა მათი სტანდარტული პრეზენტაციის ოდნავ შეცვლილი ვერსია?

წინადადება, რომელიც ორ ადგილას „არ არის მხარდაჭერილი"-ს აღიარებს და ხსნის რატომ, უფრო ღირებულია, ვიდრე ის, რომელიც ყველაფერზე „დიახ"-ს ამბობს. სიმართლეს ისედაც გაიგებთ. უმჯობესია შეფასებისას გაიგოთ, და არა გაშვებისას.

ჩამოტვირთეთ მომწოდებლების შეფასების მატრიცა მომწოდებლების შეწონილი კრიტერიუმებით შეფასებისთვის:

ჩამოტვირთეთ მომწოდებლების შეფასების მატრიცა (.docx)

TMS მომწოდებლის პრეზენტაციის რაუნდი

წერილობითი წინადადებები გეუბნებათ, რას ამტკიცებს მომწოდებელი. პრეზენტაციები გეუბნებათ, შეუძლია თუ არა ამის დამტკიცება.

ამ ეტაპზე უნდა გქონდეთ 2–3 მომწოდებლის მოკლე სია. პრეზენტაციის რაუნდის მიზანია წინადადების რეალური წნეხის ქვეშ დაყენება და სისტემის თქვენი რეალური სცენარებით შემოწმება.

სთხოვეთ პირდაპირ ჩვენება, და არა დემო

დემო — ეს რეპეტირებული თანმიმდევრობაა, სისტემის საუკეთესო მხარის ჩვენება. პირდაპირი ჩვენება — ეს ის არის, როდესაც ამბობთ: „მაჩვენეთ, როგორ გაუმკლავდებოდით ამ გადაზიდვას, ჩვენი ნიდერლანდების საწყობიდან, ჩვენი გადამზიდავით, ჩვენი შეთანხმებული ფასით" — და ხედავთ, რა ხდება სინამდვილეში.

შეხვედრამდე მოამზადეთ 2–3 რეალური სცენარი თქვენი ოპერაციიდან: სტანდარტული გამავალი შეკვეთა, გადაზიდვა, რომელსაც spot შეთავაზება სჭირდება, და რაღაც გართულებული — მაგალითად, დაგვიანებული გადაზიდვა ან გადამზიდავი, რომელიც თვალყურის დევნებას არ უზრუნველყოფს. როდესაც მომწოდებელი მუდმივად ბრუნდება გამართულ დემო-ჩვენებასთან, თქვენი სცენარის ნაცვლად — ეს თავისთავად პასუხია.

ხარვეზებს გაუმკლავდით

ყველა TMS წინადადებაში ისინი არსებობს. პირდაპირ გადადით იმ ნაწილებზე, სადაც მომწოდებელი ნაწილობრივ უპასუხა ან სადაც ეჭვი გეპარებათ, და იქ დარჩით. ნუ მისცემთ საშუალებას, კარგად მომუშავე ნაწილებზე გადაიტანოს ყურადღება. ზუსტად როგორ მუშაობს ეს? ვინ რას აკეთებს? რა ხდება, როდესაც მოსალოდნელად არ გამოდის?

სწორი ადამიანები მოიყვანეთ

TMS მომწოდებლის მხრიდან, პრეზენტაციაზე მყოფი ადამიანები უნდა იყვნენ ისინი, ვინც ნამდვილად იმუშავებს თქვენს დანერგვაზე, და არა მხოლოდ გაყიდვების გუნდი. ამის მოთხოვნა პირდაპირ გამოთქვით. თქვენი მხრიდან, მოიყვანეთ IT-ის წარმომადგენელი (თუ ინტეგრაცია მოცულობაშია) და სულ მცირე ერთი ადამიანი, ვინც სისტემას ყოველდღე გამოიყენებს. ისინი სხვა კითხვებს სვამენ, ვიდრე შესყიდვების განყოფილება — და ორივე კომპლექტი კითხვა გჭირდებათ.

მეორე რაუნდი — მხოლოდ საჭიროების შემთხვევაში

რთული გადაწყვეტილებისთვის კონკრეტულ თემებზე ორიენტირებული მეორე სესია ღირს. მაგალითი თემები:

• უსაფრთხოება და მონაცემთა დაცვა — სთხოვეთ pentest ანგარიში ან უსაფრთხოების დოკუმენტაცია, თუ IT ან ინფორმაციული უსაფრთხოების გუნდი ითხოვს
• ინტეგრაციის არქიტექტურა — ტექნიკური სესია თქვენი IT გუნდისა და მომწოდებლის გუნდს შორის
• კომერციული პირობები — კონტრაქტის, SOW-ისა და ვარაუდების სტრიქონ-სტრიქონ განხილვა ფორმალური მოლაპარაკებების დაწყებამდე

ნუ დანიშნავთ მხოლოდ იმისთვის, რომ პირველი შეხვედრა მეტი ადამიანით გაიმეოროთ. ან კონკრეტულ ღია კითხვებს წყვეტს, ან არ უნდა ჩატარდეს.

ვალდებულებები წერილობით დაადასტურეთ

ყველაფერი, რასაც მომწოდებელი შეხვედრაზე იკისრებს და წერილობით წინადადებაში არ არის, წინ გაგრძელებამდე წერილობით უნდა დადასტურდეს. ზეპირი ვალდებულებები კონტრაქტის მოლაპარაკებებს არ გადარჩება. თუ TMS მომწოდებელი მნიშვნელოვან საკითხზე „დიახ, ეს შეგვიძლია"-ს ამბობს, იმავე დღეს ელ-ფოსტით გამოეხმაურეთ და სთხოვეთ დადასტურება.

TMS კონტრაქტი და SOW (სამუშაოს განცხადება): რა უნდა შეამოწმოთ ხელმოწერამდე

მომწოდებელი შეარჩიეთ. გუნდების უმეტესობა ამ მომენტში „ამოისუნთქავს". გირჩევთ, ნუ გააკეთებთ ამას — სწორედ აქ ჩნდება ის დეტალები, რომლებიც შეფასებისას ყველამ გამოტოვა და ახლა თქვენი პრობლემა ხდება.

შიდა კონსენსუსი მოლაპარაკებამდე

სანამ საუბარი დაიწყება, იცოდეთ თქვენი აუცილებელი პირობები, მისაღები კომპრომისები და გასვლის წერტილები. მოლაპარაკების შუაში მოთხოვნების შეცვლა დროს ხარჯავს, ნდობას ანგრევს და ზოგჯერ TMS მომწოდებელს კარგავინებთ, რომელიც ნამდვილად გინდოდათ. ჯერ შიდა კონსენსუსს მიაღწიეთ, შემდეგ მოლაპარაკება დაიწყეთ.

გაიგეთ, რას ყიდულობთ: SaaS, და არა ლიცენზია

თანამედროვე TMS პლატფორმები SaaS გამოწერებია, და არა პროგრამული ლიცენზიები. თქვენ ეწერებით სერვისს, რომელსაც მომწოდებელი ჰოსტინგს, მოვლასა და განახლებებს უზრუნველყოფს — სისტემას სრულად არ ყიდულობთ. ეს ცვლის კონტრაქტის მოცულობას: გამოწერის პირობები, შეწყვეტა, მონაცემთა საკუთრება და ექსპორტის უფლებები, uptime-ის ვალდებულებები, მხარდაჭერის პასუხის დრო. სტანდარტული შესყიდვის შაბლონები ამ მოდელისთვის არ იყო შექმნილი — დარწმუნდით, რომ თქვენი შეესაბამება.

SOW კონტრაქტის ტოლფასია

სამუშაოს განცხადება (Statement of Work) განსაზღვრავს, რა მიეწოდება, ვის მიერ და როდის: ანგარიშის კონფიგურაცია, გადამზიდავის ონბორდინგი, ინტეგრაციის მხარდაჭერა, ტრენინგი და მიღების კრიტერიუმები, რომლებიც ადასტურებს, რომ დანერგვა ნამდვილად დასრულდა. თუ SOW-ში არ წერია, ეს არ შედის — რაც არ უნდა ითქვა შეხვედრაზე ან ელ-ფოსტაში. განსაკუთრებული ყურადღება მიაქციეთ ვარაუდების განყოფილებას. სწორედ იქ განისაზღვრება მოცულობა პირობითად. თუ გადამზიდავების სია მითითებულზე დიდი აღმოჩნდა, ან ERP-ს არასტანდარტული ინტეგრაციის ფორმატი სჭირდება, ვარაუდების განყოფილება წყვეტს, ეს სწრაფი საუბარია თუ ფასიანი ცვლილების მოთხოვნა.

მკაფიოდ განსაზღვრეთ, რა არ შედის

სპეციალური დამუშავება, ადგილზე ტრენინგი, მონაცემთა მიგრაცია, თქვენს სისტემებზე ინტეგრაციის სამუშაო, გადამზიდავის მხარის ცვლილებები — ეს ჩვეულებრივ ცალ-ცალკე ფასდება. ხელმოწერამდე ეს ქაღალდზე გაფორმება გამორიცხავს დანერგვის ყველაზე გავრცელებულ და ყველაზე თავიდან ასაცილებელ ხახუნის წყაროს: ორ მხარეს, რომელთაგან თითოეული ვარაუდობდა, რომ სხვა რამ შედიოდა.

ონბორდინგის გეგმაზე ხელმოწერამდე შეთანხმდით

და არა შემდეგ. გადამზიდავების პრიორიტეტიზება, კონფიგურაციის გრაფიკი, ინტეგრაციის ეტაპები, გაშვების კრიტერიუმები — ყველაფერი მოაგვარეთ, სანამ ჯერ კიდევ გაქვთ ბერკეტი. მომწოდებელი, რომელიც კონტრაქტის ეტაპზე მკაფიო ონბორდინგის გეგმას ვერ გაძლევთ, გეუბნებათ რაღაცას, რისი ცოდნაც გჭირდებათ ვალდებულების აღებამდე.

ხელმოწერის შემდეგ: TMS-ის დანერგვა და ონბორდინგი

რეალური რისკის უმეტესობა ხელმოწერის შემდეგ ცხოვრობს. სამი რამ წყვეტს, როგორ წარიმართება.

1. მონაცემთა მიგრაცია

გადამზიდავის კონტრაქტები, ფასების სიები, მისამართების წიგნები, ისტორიული გადაზიდვები. ადრე გადაწყვიტეთ, რის მიგრაცია გჭირდებათ, რა ჯერ გასუფთავდება და ვინ ახდენს ამ სამუშაოს. მოუწესრიგებელი წყარო მონაცემები ყველაზე გავრცელებული მიზეზია, რის გამოც გაშვების თარიღი სულ უფრო და უფრო იწევს. გაასუფთავეთ მიგრაციამდე, და არა მიგრაციის პროცესში.

2. გადამზიდავის ონბორდინგის თანმიმდევრობა

ყველა გადამზიდავს პირველ დღეს არ უკავშირდებით. პრიორიტეტი მოცულობისა და კრიტიკულობის მიხედვით მიანიჭეთ, ყველაზე მნიშვნელოვანი რამდენიმე გაუშვით და დაადასტურეთ, შემდეგ გააფართოვეთ. სწორედ ეს არის ის ადგილი, სადაც შეფასებისას გამოკითხული ეტაპობრივი მიდგომა ამართლებს.

3. მომხმარებლის ადოფცია

ადამიანები, რომლებიც ყოველდღე ახდენენ გადაზიდვების შეკვეთას, უნდა სურდეთ ახალი სისტემის გამოყენება. ჩართეთ მათგან სულ მცირე ერთი RFP ეტაპიდანვე, სათანადოდ გაწვრთნეთ hypercare (ონბორდინგის) პერიოდში და დარწმუნდით, რომ ყოველდღიური სამუშაო პროცესი ნამდვილად სწრაფია, ვიდრე ადრე. ტექნიკურად უნაკლო გაშვება, რომელსაც გუნდი უბრალოდ არ იყენებს, მაინც ჩაშლილი გაშვებაა.

TMS RFP-ის 10 გავრცელებული შეცდომა

ყველაზე ხშირად შეხვედრილი შაბლონები, ერთ ადგილას:

• საოპერაციო კონტექსტი არ არის. მთავარი. მოცულობები, ობიექტების სტრუქტურა, გადამზიდავების ლანდშაფტი მომწოდებლებს არ მიეწოდება. დამაზუსტებელი რაუნდი და ბუნდოვანი ფასები გარანტირებულია.
• ყველაფერი „აუცილებელია". როდესაც ყველა მოთხოვნა კრიტიკულია, პრიორიტეტების სვეტი უსარგებლოა და გადამწყვეტი ფაქტორი კარგი-ქონასგან ვერ განირჩევა.
• ბუნდოვანი გრაფიკი. თარიღების გარეშე მომწოდებლებს ძალისხმევის შეფასება არ შეუძლიათ, ამიტომ წინადადებებიც ისეთივე ბუნდოვანი ბრუნდება.
• „როგორ"-ის ზედმეტი დეტალიზაცია. ტექნიკური დანერგვის პრეცეპტირება, ოპერაციული შედეგის ნაცვლად, კარგ გადაწყვეტილებებს არასწორი მიზეზებით გამოფილტრავს.
• ERP/TMS საზღვრის იგნორირება. ვარაუდი, რომ TMS ფლობს ფინანსურ პროცესებს, რომლებსაც ERP სინამდვილეში ფლობს — და ამის გაგება დანერგვის შუაში.
• ფასზე ნაგულისხმევი ორიენტაცია. სამწლიანი მოდელის გარეშე გამოწერის სათაურის ფასით შერჩევა, ან გადამზიდავებთან კავშირისა და ინტეგრაციის გულწრფელობის გათვალისწინების გარეშე.
• დემო პირდაპირი ჩვენების ნაცვლად. მომწოდებლის გამართული თანმიმდევრობის ყურება, სისტემის თქვენი რეალური სცენარებით შემოწმების ნაცვლად.
• რეფერენსები, რომლებიც თქვენს ოპერაციას არ ემთხვევა.
შთამბეჭდავ ლოგოებს უყურებთ, მაგრამ ამ კომპანიებს შეიძლება სრულიად განსხვავებული ლოგისტიკური ოპერაციები ჰქონდეთ. სთხოვეთ თქვენს მსგავსი რეფერენსები, შემდეგ ჰკითხეთ, როგორ წარიმართა ონბორდინგი და ინტეგრაცია.
• ონბორდინგის ხელმოწერის შემდეგ გადადება. ბერკეტით მოლაპარაკებული გეგმა სჯობს ბერკეტის გარეშე მოლაპარაკებულს.
• სწორი მომწოდებლისთვის ზედმეტად მძიმე პროცესი. ბიუროკრატიული ტვირთი, რომელმაც შეიძლება გამოფილტროს ის თანამედროვე პლატფორმები, რომლებიც ყველაზე კარგად გამოგადგებოდათ.

უფასო TMS RFP შაბლონები

ჩვენ ხუთი შაბლონი ავაშენეთ იმ RFP-ებიდან, რომლებსაც ვპასუხობთ, რათა ცარიელი გვერდიდან არ დაიწყოთ:

1. RFP დოკუმენტის შაბლონი. ამ სახელმძღვანელოს სრული სტრუქტურა.
2. ფუნქციური მოთხოვნების შეფასების ფურცელი. პრიორიტეტიზებული, თითოეული მომწოდებლის დაფარვის სვეტით.
3. საოპერაციო ინფორმაციის საკონტროლო სია. ათი კითხვა შევსებადი ცხრილის სახით.
4. მომწოდებლების შეფასების მატრიცა. შეწონილი ქულები მომწოდებლების მიხედვით.
5. RFP გრაფიკის შაბლონი. აქტივობები, თარიღები, პასუხისმგებელი პირები.

ჩამოტვირთეთ კომპლექტი — ყველა ხუთი, უფასოდ, ელ-ფოსტის გარეშე. გამოიყენეთ სასარგებლო, დანარჩენი გამოტოვეთ:

ჩამოტვირთეთ TMS RFP შაბლონების სრული კომპლექტი (.zip)

Cargoson არის სატრანსპორტო მართვის სისტემა, რომელსაც იყენებენ საშუალო ზომის მწარმოებლები და საბითუმო კომპანიები მთელ ევროპასა და ჩრდილოეთ ამერიკაში. ჩვენ მუდმივად ვპასუხობთ RFP-ებს, ისეთებს, როგორსაც თქვენ წერთ — ამიტომ, თუ გირჩევნიათ მოთხოვნები ჩაწერამდე ჩვენთან განიხილოთ, სიამოვნებით დაგეხმარებით, ვალდებულების გარეშე.

დაჯავშნეთ უფასო 30-წუთიანი კონსულტაცია აქ

კარგად ჩაატარეთ პროცესი — და ყოველი დახარჯული საათი ღირდა.