Як скласти RFP для TMS: наш досвід [+ 5 безкоштовних шаблонів]

Ми щотижня відповідаємо на RFP (запити на пропозицію) щодо систем управління транспортом. Одні — справжнє задоволення. Інші — наочний урок того, як робити не варто.

Ця стаття — те, що я б побудував сам, якби сьогодні запускав процес вибору TMS з нуля. Вона ґрунтується на RFP, на які ми відповідали, на закономірностях, що повторюються в різних компаніях і галузях, на тому, що зазвичай до них включають — і на типових помилках, які ми бачимо знову і знову.

Якщо ви фахівець із закупівель, більша частина цього матеріалу буде вам знайома. Сподіваюся, щось із нього допоможе уникнути хоча б одного зайвого раунду уточнень.

Що таке RFP для TMS?

RFP для TMS (запит на пропозицію) — це структурований документ, який ви надсилаєте постачальникам систем управління транспортом. У ньому описується ваша логістична операція, і кожен постачальник має запропонувати, як його система впорається з нею — відповідаючи на однаковий набір вимог. Головна мета — порівнянність. Однакові запитання, однаковий формат, однаковий контекст: щоб отримані відповіді можна було порівняти між собою, а не читати як п'ять окремих комерційних презентацій.

RFP потрібен не завжди. Він виправдовує себе тоді, коли рішення складне або коли його доведеться обґрунтовувати перед іншими всередині компанії. Якщо ваша логістика проста, достатньо демонстрації продукту та розмови з кількома постачальниками.

Чи справді вам потрібен тендер RFP для TMS?

Помилитися тут — найдорожча помилка у всьому процесі вибору TMS. Вирішіть це питання раніше за все інше.

Усе залежить від складності вашої логістики, а не від розміру компанії.

Проводьте структурований тендер RFP для TMS, якщо ви відправляєте вантажі з кількох об'єктів, використовуєте різні види транспорту та потребуєте інтеграції системи з ERP. Саме тоді необхідно поставити всіх постачальників в однакові умови, щоб нічого важливого не вислизнуло. Постачальники підключаються до перевізників дуже по-різному: один називає це «нативним», інший тихо маршрутизує через третю сторону. У нечіткому процесі ви це не помітите — аж поки не підпишете договір. А тоді вже пізно.

Відмовтеся від формального тендеру RFP, якщо у вас один об'єкт, невелика кількість перевізників і ви вже розумієте, що вам потрібно. Чому? Тому що щойно ви запускаєте RFP, ви автоматично потрапляєте в корпоративний ціновий сегмент. 2–3 якісні демонстрації з конкретними запитаннями нерідко дають кращу систему, дешевше і швидше. Розкажіть цим 2–3 постачальникам, що ви відправляєте і яку проблему хочете вирішити, а потім попросіть показати це в їхній живій системі. За годину все стане зрозуміло. А якщо ви переважно відправляєте посилки, а не палети чи вантажі, повноцінна TMS вам може взагалі не знадобитися — програмне забезпечення для відправлення кількома перевізниками — це окрема, легша категорія, створена саме для цього.

Тому будьте чесні з собою щодо того, який варіант вам підходить, ще до початку процесу. Запускати RFP, який вам не потрібен, — це найповільніший і найдорожчий спосіб придбати TMS.

Запускати RFP, який вам не потрібен, — це найповільніший і найдорожчий спосіб придбати TMS.

Ще одне застереження для тих, хто все ж обирає повний RFP. Процес, перевантажений управлінською термінологією, методологічними фреймворками та вимогами фіксованої ціни, потребує тижнів на підготовку відповіді — і постачальники, здатні витримати такі витрати, як правило, є великими усталеними гравцями. Тому якщо більш сучасна і гнучка платформа насправді підійшла б вам краще, надмірно бюрократичний процес може тихо відсіяти її ще до того, як ви побачите демонстрацію.

Мета — знайти правильне рішення для вас. Будуйте процес навколо цього, а не навколо управління самим процесом.

Процес RFP для TMS: 9 кроків

Вибір TMS не обов'язково має бути складним. Але чітка послідовність кроків необхідна. Пропустіть якийсь — і заплатите за це пізніше, зазвичай під час впровадження, коли припущення, які мали бути з'ясовані заздалегідь, перетворюються на дорогі сюрпризи.

За умови правильної організації весь процес займає 8–12 тижнів. Для простого обсягу — менше, і рідко коли потрібно більше.

Ось послідовність, яка працює:

1. Аналіз ринку. Перш ніж формулювати будь-яку вимогу, витратьте час на вивчення того, що є на ринку. Ринок TMS суттєво змінився за останні п'ять років: з'явилися хороші корпоративні платформи, хороші платформи для середнього бізнесу та по-справжньому потужні сучасні SaaS-рішення для управління транспортом, яких п'ять років тому не існувало. Складіть довгий список із 5–8 постачальників TMS, вартих уваги.
2. NDA. Надішліть його якомога раніше. Ви ділитиметеся операційними даними — обсягами, назвами перевізників, деталями внутрішніх систем — і підписана угода про нерозголошення до відправлення RFP є стандартною практикою, що захищає обидві сторони.
3. RFI (необов'язково). Короткий запит на інформацію має сенс, якщо ваш довгий список широкий і ви хочете відфільтрувати кандидатів до повноцінного RFP. Обмежтеся однією сторінкою: загальна інформація про компанію, ключові можливості, орієнтовний ціновий діапазон. Достатньо для відбору, не змушуючи постачальників писати розгорнуті есе.
4. RFP. Основний документ. Він дає кожному постачальнику все необхідне для точної пропозиції. Детальніше — в наступному розділі.
5. Вікно для запитань і відповідей. Завжди передбачайте його. Постачальники матимуть запитання, а відповіді на них нерідко покращують усі отримані пропозиції. Ведіть листування письмово і надсилайте всі запитання та відповіді одночасно всім постачальникам. Це забезпечує чистоту і порівнянність процесу.
6. Короткий список і презентації. Оцініть письмові пропозиції, а потім запросіть 2–3 постачальників на презентацію. Презентація має включати живий огляд системи на основі ваших реальних сценаріїв використання, а не загальну демонстрацію. Якщо постачальник не може показати ваш сценарій у своїй системі — це вже відповідь.
7. Другий раунд (за потреби). Для складного рішення варто провести поглиблену сесію, зосереджену на конкретних прогалинах — безпеці, інтеграції, комерційних умовах. Не призначайте її, якщо реальних відкритих питань не залишилося.
8. Рішення та договір. Узгодьте позиції всередині компанії до початку переговорів. Знайте свої обов'язкові вимоги, прийнятні компроміси та межі, за якими ви готові відмовитися від угоди.
9. Впровадження. Процес не закінчується підписанням договору. Найкращі результати RFP — це ті, де план впровадження узгоджений до підписання контракту.

Графік RFP для TMS, який можна скопіювати

Орієнтовна тривалість залежно від обсягу:

• Один простий об'єкт: 6–8 тижнів (повноцінний RFP може не знадобитися).
• Кілька об'єктів + інтеграція з ERP: 8–12 тижнів.
• Глобальне впровадження з кількома юридичними особами та складною інтеграцією: 12–20 тижнів, найімовірніше з двома раундами презентацій.

Завантажити шаблон графіка RFP (.docx)

Що включити до документа RFP для TMS

Документ RFP — ваш найважливіший інструмент у цьому процесі. Хороший RFP виконує більшу частину оціночної роботи за вас, тому тримайте його сфокусованим. Чіткий RFP на 10 сторінок кращий за 30-сторінковий, що намагається охопити все.

1. Супровідний лист і мета

Одна сторінка. Хто ви, що шукаєте, чому зараз. Тримайтеся фактів. Постачальникам не потрібна декларація про бачення — їм потрібно зрозуміти вашу операційну проблему.

2. Графік

Чіткий розклад із реальними датами: відправлення RFP, дедлайн для запитань, подання пропозицій, вікно для презентацій, рішення. Постачальники планують зусилля на підготовку відповіді, орієнтуючись на ці дати. Розмиті терміни дають розмиті пропозиції.

3. Загальна інформація про компанію та операційний контекст

Саме тут більшість RFP зазнають невдачі — і саме це визначає різницю між порівнянними пропозиціями та раундом уточнень. Описуйте не просто свій бізнес, а свою логістичну операцію. Скільки об'єктів. Скільки юридичних осіб. Які види транспорту (посилки, LTL, FTL, авіа, море, залізниця). Які регіони. Приблизні обсяги. Поточні системи. Уявлення про «хороший результат» також різниться залежно від галузі — вимоги виробників електроніки, машинобудування, хімічної промисловості чи поліграфії та пакування суттєво відрізняються. Це контекст, який потрібен постачальникам для точного формування пропозиції. Якщо тут недостатньо деталей, ви витратите два тижні на відповіді на уточнювальні запитання, яких можна було б повністю уникнути. Цьому присвячено окремий розділ нижче.

4. Функціональні вимоги

Таблиця того, що система має вміти робити, пріоритизована за важливістю: обов'язково / бажано / добре мати (Excel цілком підійде). Попросіть постачальників відповісти на кожну вимогу, вказавши рівень покриття: а) нативне, б) стороннє, в) кастомізація або г) не підтримується. Саме це робить пропозиції порівнянними. Детальніше про те, як скласти цей список, — далі.

5. Критерії оцінювання

Поясніть постачальникам, як ви прийматимете рішення: функціональність, ціна, підхід до впровадження, рекомендації, безпека, команда. Якщо готові — поділіться вагами критеріїв. Чим прозоріші ви, тим кращі пропозиції отримаєте.

6. Модель ціноутворення

Запросіть повну розбивку: підписка, впровадження, транзакційні збори, підтримка та все інше. Якщо можливо — попросіть зразок рахунку-фактури. Структури ціноутворення у різних постачальників суттєво відрізняються, і приховані витрати мають звичку з'являтися в найнесподіваніший момент. Краще виявити їх заздалегідь.

7. Формат відповіді

Чітко вкажіть постачальникам, як має бути структурована пропозиція, і якщо ви надаєте шаблони — вимагайте їх використання. Порівнянні пропозиції економлять дні під час оцінювання, а формат повністю у вашій владі.

Завантажте шаблон документа RFP, щоб почати з повної структури, описаної вище:

Завантажити шаблон документа RFP (.docx)

Операційна інформація, яку більшість 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. Обов'язково (О): без компромісів. Постачальник, який не може виконати цю вимогу, вибуває — незалежно від усього іншого.
2. Бажано (Б): важливо, але можна прийняти тимчасове рішення або обіцянку в найближчому плані розвитку.
3. Добре мати (Д): корисно знати, але стоїть після всього вищезазначеного.

У більшості списків забагато обов'язкових вимог. Якщо все критично — нічого критичного немає. Будьте чесні щодо того, що справді зупинить роботу системи для вас, і позначайте обов'язковими лише ці пункти.

Вимагайте від постачальників класифікувати покриття: нативне / стороннє / кастомізація

На кожну вимогу вони мають відповісти одним із варіантів:

Саме ця колонка визначає, чи заслуговує пропозиція на довіру. Постачальник, який відповідає чесно і пише не підтримується там, де це правда, показує, яким партнером він буде. Постачальник, який скрізь відповідає нативне, теж говорить вам щось важливе.

Формулюйте запитання конкретно

«Чи підтримує система ціноутворення перевізників?» — дасть вам марне «так». «Чи може система розрахувати вартість перевезення для кожного перевізника, включно з тими, у кого немає API ціноутворення, і показати їх поруч для кожного відправлення?» — дасть вам щось, що можна реально оцінити.

Де закінчується ERP і починається TMS?

Одне з найпоширеніших джерел плутанини при виборі системи управління транспортом — це де закінчується TMS і починається ERP.

Фінансові процеси — кодування в головну книгу, розрахунок повної вартості, аудит фрахту — часто обробляються на стороні ERP, куди TMS передає дані. Це нормально і нерідко правильне рішення. Але це має бути чітко прописано. Коли постачальник відповідає «реалізовано через інтеграцію з ERP» на одну з ваших обов'язкових вимог — уточніть, що саме це означає для вашого впровадження і хто виконує цю роботу.

Описуйте мету, а не технічне рішення

Описуйте, чого потрібно досягти, а не те, як система має це технічно реалізувати. Надмірно деталізовані вимоги відсівають хороші рішення з неправильних причин. Залишайте постачальникам простір, щоб показати кращий спосіб, ніж той, що ви мали на увазі, — іноді він у них є.

Список із 30 чесних, пріоритизованих вимог скаже вам більше, ніж таблиця на 150 рядків, де все критично і кожен постачальник поставив галочки скрізь.

Стартовий набір вимог до TMS для адаптації

Більшість покупців, які вперше проходять цей процес, хочуть мати відправну точку для списку. Ось приклад із нашого досвіду — вже категоризований, — який можна адаптувати під свою операцію. Повний список доступний для завантаження в таблиці оцінювання нижче; тут достатньо, щоб зрозуміти загальну структуру.

Завантажте таблицю оцінювання функціональних вимог — вже з пріоритетами та колонкою покриття для кожного постачальника:

Завантажити таблицю оцінювання функціональних вимог (.docx)

Як порівнювати вартість TMS (і побудувати тривічну модель)

«Скільки коштує TMS?» — це запитання, яке покупці найбільше хочуть почути у відповідь, а постачальники найбільше уникають. Але плата за підписку рідко є вашою кінцевою вартістю. Для середнього багатооб'єктного відправника впровадження та інтеграція можуть навіть більше впливати на загальну суму за три роки, ніж щомісячна плата, — і саме ця стаття залишається найбільш розмитою у постачальників. Тому тут важливо правильно сформулювати запитання, щоб отримати порівнянні відповіді і побачити реальну вартість.

Для орієнтиру: середньоринкові хмарні TMS зазвичай коштують від кількох сотень до кількох тисяч євро на місяць, тоді як традиційні корпоративні системи — від десятків тисяч до понад мільйона на рік, із впровадженням, що може сягати шести-семизначних сум. Діапазон широкий — саме тому порівнянна модель важливіша за будь-яку окрему цифру. Щоб отримати уявлення про реальні ціни постачальників TMS, ознайомтеся з нашим дослідженням провідних постачальників TMS.

Складові ціноутворення TMS

Майже кожна пропозиція TMS є певним поєднанням цих елементів:

Побудуйте тривічну модель витрат до порівняння

Постачальник TMS, який виглядає дешевим за підпискою, може виявитися найдорожчим, коли врахувати впровадження, транзакційні збори та підключення перевізників. Пропустіть кожного постачальника через одну й ту саму модель:

Витрати за 3 роки = впровадження + (річна підписка × 3) + (плата за відправлення × річний обсяг × 3) + підтримка + очікувані додаткові витрати на перевізників та інтеграції.

Використовуйте реальні обсяги, а не акуратні приклади постачальника. Ця одна таблиця нерідко перетасовує короткий список.

Стежте за різними складовими ціноутворення, а не лише за базовою платою

Деякі постачальники встановлюють низьку підписку і компенсують це транзакційними зборами або платою за кожного перевізника. Це не обов'язково погано, але змінює те, хто є найдешевшим у міру вашого зростання. Якщо обсяги збільшуються, модель оплати за відправлення може швидко обігнати фіксовану. Попросіть зразок рахунку-фактури та умови підписки, щоб порівнювати те, що ви реально платитимете, а не заголовкову ставку.

Одне запитання, яке варто поставити кожному постачальнику: чи включено підключення нових перевізників, чи воно оплачується окремо? Деякі платформи TMS стягують €5 000–€10 000 за кожну нову інтеграцію з перевізником і витрачають на це місяці, тоді як інші підключають нових перевізників без додаткової плати. Для середнього відправника, що додає перевізників з часом, ця одна відповідь може вплинути на загальну суму за три роки більше, ніж будь-яка стаття підписки.

Як оцінювати пропозиції TMS поза ціною

Пропозиції отримано. Всі виглядають розумно, більшість відповідає «так» на ваші вимоги, і ціни приблизно в одному діапазоні. Що далі?

Саме тут команди мовчки повертаються до ціни, бо все інше здається складнішим для порівняння. Не варто. Ось що насправді їх розрізняє.

1. Підключення до перевізників.

Для TMS підключення до перевізників — це фундамент. Як постачальник насправді підключається до перевізників: через прямі API/EDI-інтеграції, сторонніх агрегаторів чи взагалі ні (замовлення електронною поштою та PDF незалежно від IT-можливостей перевізника)? Що відбувається, коли вам потрібен перевізник, якого вони ще не підтримують, — скільки це займає і скільки коштує?

Постачальник із глибокими прямими підключеннями до перевізників — це зовсім інша річ порівняно з тим, хто маршрутизує все через проміжний шар. Різницю відчуваєш у надійності замовлень, якості відстеження та в тому, чи можна додати перевізника без нових комерційних переговорів щоразу.

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 реальні сценарії зі своєї операції до зустрічі: стандартне вихідне замовлення, відправлення, що потребує разової пропозиції, і щось нетипове — наприклад, затримане відправлення або перевізник без відстеження. Якщо постачальник постійно намагається повернутися до відполірованої демонстрації замість того, щоб відпрацювати ваш сценарій — це вже відповідь.

Перевіряйте прогалини

Вони є в кожній пропозиції TMS. Одразу переходьте до місць, де постачальник відповів частково або де у вас є сумніви, і не відпускайте тему. Не дозволяйте повертатися до того, що працює бездоганно. Як саме це працює? Хто що робить? Що відбувається, коли щось іде не так?

Запросіть потрібних людей

З боку постачальника TMS презентувати мають ті, хто реально працюватиме над вашим впровадженням, а не лише команда продажів. Попросіть про це явно. З вашого боку — залучіть когось із IT (якщо інтеграція в обсязі) і хоча б одну людину, яка щодня користуватиметься системою. Вони ставлять інші запитання, ніж відділ закупівель, — і вам потрібні обидва набори запитань.

Другий раунд — лише за потреби

Для складного рішення окрема сесія з конкретних тем варта часу. Приклади тем:

• Безпека та захист даних — запросіть звіт про тестування на проникнення або документацію з безпеки, якщо цього вимагає ваша IT-команда або служба інформаційної безпеки
• Архітектура інтеграції — технічна сесія між вашою IT-командою та командою постачальника
• Комерційні умови — детальний розгляд договору, SOW та припущень рядок за рядком до початку формальних переговорів

Не призначайте його лише для того, щоб повторити першу зустріч із більшою кількістю людей. Або він вирішує конкретні відкриті питання — або його не варто проводити.

Фіксуйте зобов'язання письмово

Будь-яке зобов'язання, яке постачальник бере на себе під час зустрічі і якого немає в письмовій пропозиції, має бути підтверджено письмово до продовження. Усні домовленості не переживають переговорів щодо договору. Якщо постачальник TMS каже «так, ми можемо це зробити» щодо чогось важливого — того ж дня надішліть листа з проханням підтвердити.

Договір і SOW для TMS: що перевірити перед підписанням

Ви обрали постачальника. Більшість команд на цьому «видихають». Я б не рекомендував — саме тут деталі, на які всі заплющували очі під час оцінювання, тихо перетворюються на вашу проблему.

Узгодьте позиції всередині компанії до початку переговорів

Знайте свої обов'язкові вимоги, прийнятні компроміси та межі, за якими ви готові відмовитися від угоди, ще до початку розмови. Зміна вимог у середині переговорів коштує часу, підриває довіру і іноді призводить до втрати постачальника TMS, якого ви насправді хотіли. Спочатку розберіться всередині — і лише потім ведіть переговори.

Розумійте, що ви купуєте: SaaS, а не ліцензію

Сучасні платформи TMS — це SaaS-підписки, а не програмні ліцензії. Ви підписуєтеся на сервіс, який постачальник розміщує, підтримує та оновлює, а не купуєте систему у власність. Це змінює те, що має охоплювати договір: умови підписки, розірвання, право власності на дані та їх експорт, зобов'язання щодо доступності, час реагування підтримки. Стандартні шаблони закупівель не були написані для цієї моделі — переконайтеся, що ваші відповідають їй.

SOW не менш важливий, ніж договір

Технічне завдання (Statement of Work) визначає, що буде доставлено, ким і коли: налаштування облікового запису, підключення перевізників, підтримка інтеграції, навчання та критерії приймання, що підтверджують завершення впровадження. Якщо цього немає в SOW — це не включено, незалежно від того, що говорилося на зустрічі або в листах. Особливо уважно читайте розділ припущень. Саме там обсяг визначається умовно. Якщо ваш список перевізників виявиться більшим, ніж зазначено, або ваш ERP потребує нестандартного формату інтеграції — розділ припущень вирішить, чи це буде коротка розмова, чи оплачуваний запит на зміну.

Чітко визначте, що виходить за рамки

Кастомна розробка, навчання на місці, міграція даних, інтеграційні роботи на ваших системах, зміни на стороні перевізника — все це зазвичай оплачується окремо. Зафіксувати це на папері до підписання усуває найпоширенішу і найбільш уникнену причину тертя при впровадженні: дві сторони, кожна з яких вважала, що щось інше включено.

Узгодьте план впровадження до підписання

Не після. Пріоритетність перевізників, графік налаштування, контрольні точки інтеграції, критерії запуску — вирішіть усе це, поки у вас ще є важелі впливу. Постачальник, який не може надати чіткий план впровадження на етапі укладення договору, говорить вам щось, що варто знати до того, як ви зобов'яжетеся.

Після підписання: впровадження та онбординг TMS

Більшість реальних ризиків виникає після підписання. Три речі визначають, як усе пройде.

1. Міграція даних

Договори з перевізниками, прайс-листи, адресні книги, історія відправлень. Вирішіть заздалегідь, що потрібно перенести, що спочатку потребує очищення і хто відповідає за цю роботу. Брудні вихідні дані — найпоширеніша причина, через яку дата запуску постійно відкладається. Очищайте їх до міграції, а не під час.

2. Послідовність підключення перевізників

Не підключайте всіх перевізників одразу. Розставте пріоритети за обсягом і критичністю, запустіть і перевірте кількох ключових, а потім розширюйте. Саме тут поетапний підхід, про який ви питали під час оцінювання, виправдовує себе.

3. Прийняття користувачами

Люди, які щодня замовляють відправлення, мають хотіти користуватися новою системою. Залучіть хоча б когось із них ще з етапу RFP, належно навчіть під час гіперкеру (онбордингу) і переконайтеся, що щоденний робочий процес реально швидший за попередній. Технічноездійснений запуск, яким команда просто не користується, — це все одно невдалий запуск.

10 поширених помилок у RFP для TMS

Закономірності, які ми бачимо найчастіше, — усі в одному місці:

• Відсутність операційного контексту. Головна помилка. Постачальникам не надано ні обсягів, ні структури об'єктів, ні переліку перевізників. Раунд уточнень і загальне ціноутворення гарантовані.
• Все є обов'язковим. Коли кожна вимога критична, колонка пріоритетів — мертвий вантаж і неможливо відрізнити принципове від бажаного.
• Розмитий графік. Без дат постачальники не можуть оцінити свої зусилля — і пропозиції повертаються такими ж розмитими.
• Надмірна деталізація «як». Прописування технічної реалізації замість операційного результату відсіває хороші рішення з неправильних причин.
• Ігнорування межі ERP/TMS. Припущення, що TMS відповідає за фінансові процеси, які насправді належать ERP, — і усвідомлення цього в середині впровадження.
• Вибір за ціною. Рішення на основі заголовкової ставки підписки без тривічної моделі або без урахування підключення до перевізників і чесності щодо інтеграції.
• Демонстрація замість живого огляду. Перегляд відполірованої послідовності постачальника замість того, щоб змусити систему відпрацювати ваші реальні сценарії.
• Рекомендації, що не відповідають вашій операції. Увага до відомих логотипів, але ці компанії можуть мати логістику, що зовсім не схожа на вашу. Просіть рекомендації від схожих на вас — і питайте, як насправді пройшли онбординг та інтеграція.
• Відкладання онбордингу до підписання. План, узгоджений із важелями впливу, завжди кращий за той, що узгоджується без них.
• Процес, надто важкий для правильного постачальника. Бюрократичне навантаження, яке може відфільтрувати сучасні платформи, що підійшли б вам найкраще.

Безкоштовні шаблони RFP для TMS

Ми створили п'ять шаблонів на основі RFP, на які відповідаємо, — щоб вам не доводилося починати з чистого аркуша:

1. Шаблон документа RFP. Повна структура з цього посібника.
2. Таблиця оцінювання функціональних вимог. З пріоритетами та колонкою покриття для кожного постачальника.
3. Контрольний список операційної інформації. Десять запитань у вигляді таблиці для заповнення.
4. Матриця оцінювання постачальників. Зважене балування по постачальниках.
5. Шаблон графіка RFP. Активності, дати, відповідальні.

Завантажте весь пакет — усі п'ять, безкоштовно, без реєстрації. Беріть корисне, решту ігноруйте:

Завантажити повний пакет шаблонів RFP для TMS (.zip)

Cargoson — це система управління транспортом, якою користуються середні виробники та оптові компанії по всій Європі та Північній Америці. Ми постійно відповідаємо на RFP, схожі на той, що ви збираєтеся написати, — тому якщо хочете обговорити свої вимоги до того, як почнете, ми з радістю допоможемо розібратися, без жодних зобов'язань.

Замовте безкоштовну 30-хвилинну консультацію тут

Проведіть процес правильно — і кожна витрачена година окупиться.