Как да напишем RFP за TMS: нашият опит [+ 5 безплатни шаблона]

Всяка седмица отговаряме на RFP (Request for Proposal) за система за управление на транспорта. Едни са удоволствие за работа. Други са урок в това какво не трябва да се прави.

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

Ако сте специалист по снабдяване, голяма част от това ще ви звучи познато. Надявам се поне нещо да ви спести един излишен кръг на уточнения.

Какво е RFP за TMS?

RFP за TMS (Request for Proposal) е структуриран документ, който изпращате до доставчици на системи за управление на транспорта. Той описва вашата логистична операция и иска от всеки от тях да предложи как тяхната система би се справила с нея — по едни и същи изисквания. Целта е сравнимост: еднакви въпроси, еднакъв формат, еднакъв контекст, така че получените отговори да могат да се наредят един до друг, вместо да се четат като пет отделни търговски презентации.

Не винаги имате нужда от 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. Изпратете го рано. Ще споделяте оперативни данни — обеми, имена на превозвачи, подробности за вътрешните системи — и подписан NDA преди изпращането на RFP е стандартна практика, която защитава и двете страни.
3. RFI (по избор). Кратък Request for Information има смисъл, ако дългият ви списък е широк и искате да го филтрирате, преди да инвестирате в пълен 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 да прочете първа.

Отговаряме на много търгове за 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.

Финансовите процеси като GL кодиране, приземени разходи и одит на товарни разходи често се обработват от страна на 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 (Statement of Work) за 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-минутна консултация тук

Проведете процеса добре и всеки вложен час ще си заслужи.