TMS: какво е и как работи Transportation Management System

Накратко

TMS означава Transportation Management System. Няма обаче универсален списък от функции, които един софтуер трябва да притежава, за да се нарича TMS. На пазара терминът се използва за много различни продукти: от сравнително прости инструменти за планиране на курсове до корпоративни платформи, които управляват снабдяването с превозвачи, търгове, тарифи, международни мрежи, одити на разходите, проследяване, документация и интеграции с ERP и складови системи.

За МСП въпросът не е „нужен ли ми е TMS?“, а кои процеси трябва да контролирам и с каква сложност. Компания с пет камиона, която получава поръчки по имейл, има нужди, много различни от тези на логистичен оператор, който купува транспорт от стотици превозвачи или координира няколко европейски хъба.

Какво всъщност означава TMS

На практика TMS е информационна система, посветена на управлението на транспорта. Тя може да поддържа един или повече етапа:

заявка → поръчка → планиране → възлагане → изпълнение → наблюдение → документи → разходи → приключване → анализ

Дълбочината се променя значително при различните продукти. Една система може да се ограничи до планиране на собствен транспорт; друга може автоматично да избира между различни превозвачи според тарифа и услуга; трета може да управлява мултимодални маршрути, часове, SLA, фактури и сверявания.

Затова две оферти, наречени „TMS“, могат да имат напълно различни цени, срокове за внедряване и предназначени потребители.

Оперативният цикъл, който TMS може да управлява

1. Получаване на търсенето

Поръчките могат да пристигат чрез ръчно въвеждане, файлове, API, EDI, ERP, клиентски портали или други системи. Първата задача е разнородните заявки да се превърнат в използваеми данни.

2. Планиране

Системата съчетава дестинации, времеви прозорци, капацитет, ограничения, наличност на превозни средства и шофьори или наличност на превозвачи. В по-сложните системи могат да присъстват оптимизационни механизми; при по-простите планирането остава главно визуално и ръчно.

3. Възлагане

Курсът се възлага на вътрешно превозно средство/шофьор или на външен превозвач. При закупуване на транспортни услуги могат да влязат в действие тарифни листи, търгове, класации на доставчици и правила за снабдяване.

4. Изпълнение

Офисът, шофьорът и партньорите трябва да споделят статуси и промени: приет, пристигнал, натоварен, на път, доставен, отклонение и т.н.

5. Документи и доказателство за услугата

Системата може да свързва поръчката, транспортните документи, POD и приложенията. Наличието на документ в TMS обаче не означава, че той автоматично е правилен от правна, данъчна или техническа гледна точка.

6. Разходи и контрол

По-развитите TMS сравняват прогнозния и действителния разход, тарифите, надбавките, пътните такси, допълнителните услуги и фактурите, получени от превозвачите.

7. Анализ

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

Най-често срещаните модули

TMS може да включва:

• управление на поръчки;
• основни данни за клиенти, обекти и превозвачи;
• планиране на курсове;
• възлагане на превозни средства/шофьори;
• снабдяване и търгове за превозвачи;
• управление на тарифи;
• проследяване или интеграция с външно проследяване;
• управление на часове;
• документи и POD;
• контрол на разходите и одит на навлото;
• фактуриране или счетоводна интеграция;
• табла и KPI;
• портал за клиенти/доставчици;
• API, EDI и ERP/WMS интеграции;
• управление на изключения;
• функции за оптимизация.

Правилният въпрос по време на демонстрация не е „имате ли тази функция?“, а как работи тя в конкретния процес на компанията и какви данни изисква.

TMS, софтуер за управление на транспорта, FMS и телематиката не са синоними

Софтуер за управление на транспорта

Това е общ термин. Може да означава софтуер, насочен към административната и оперативната организация на малко предприятие: клиенти, поръчки, шофьори, камиони, дневен план и статуси.

TMS

Обикновено означава платформа с по-голяма дълбочина в планирането и контрола на транспорта и, в корпоративна среда, в управлението на мрежи, превозвачи, тарифи и интеграции.

FMS / Fleet Management System

Тя е по-ориентирана към автопарка: превозни средства, поддръжка, разход на гориво, срокове, използване, а евентуално и шофьори и разходи за превозното средство.

Телематика

Тя събира информация от превозното средство или устройства: местоположение, километри, CAN данни, когато са налични, диагностика, събития при шофиране и други сигнали. TMS може да получава тези данни, но по определение не е телематично устройство.

ERP

Тя управлява по-широки бизнес процеси: счетоводство, покупки, продажби, администрация, склад и управленски контрол. TMS може да бъде модул на ERP или отделна система, интегрирана с него.

За МСП е нормално да използва повече от един инструмент. Проблемът възниква, когато никой не знае коя система е официалният източник за всяка информация.

Кога сложният TMS е полезен

Сложността обикновено става оправдана, когато се увеличат някои променливи:

• стотици или хиляди поръчки;
• много места за товарене/разтоварване;
• транспорт, купуван от множество превозвачи;
• сложни тарифни листи и надбавки;
• национална/международна мрежа;
• повече видове транспорт;
• договорни SLA и KPI;
• силна нужда от интеграция с ERP/WMS;
• процеси на търгове и снабдяване;
• необходимост от систематичен одит на разходите.

В тези случаи платформата не служи само за „виждане на плана“, а става част от информационната архитектура на компанията.

Кога може да е прекалено голям

Микропредприятие с пет или десет камиона може да има много конкретен проблем: разпръснати поръчки, промени в WhatsApp, планиране в Excel и непрекъснати обаждания към шофьорите. За решаването му не е непременно полезно да се въвеждат:

• шестмесечен ERP проект;
• сложни тарифни конфигурации;
• механизъм за търгове;
• хранилище за данни;
• десетки роли и работни потоци;
• специализирани консултации за всяка промяна.

Прекалено големият софтуер може да премести проблема: от липсата на структура към трудността да се използва структурата.

Критерият трябва да бъде минималната достатъчна сложност: да покрие добре реалния процес днес и да остави място за растеж, без да се купуват години функции, които няма да се използват.

Данни и интеграции: частта, която наистина струва

Софтуерът е само един компонент. Значителна част от работата по TMS проект е свързана с данните.

Преди внедряването е полезно да се установи:

Основни данни. Кой почиства клиенти, адреси, превозни средства, шофьори, превозвачи и дублирани кодировки?

Източник на данните. Адресът на клиента възниква ли в CRM, ERP или TMS? Кой може да го променя?

Идентификатори. Имат ли поръчката, курсът и документът съгласувани кодове между системите?

Импортиране. Съществуващите файлове имат ли стабилни колони или всеки клиент използва различен формат?

API/EDI. Кои потоци са действително необходими? В реално време или на партиди?

Грешки. Какво се случва, ако интеграция не получи поръчка или я получи два пъти?

История. Колко стари данни трябва да бъдат мигрирани? Всичко, само основните данни или последните месеци?

Собственост. Може ли предприятието да експортира собствените си данни във формат за повторна употреба?

Лошото качество на данните не се решава автоматично от TMS: то просто се прехвърля в по-скъпа система.

Цифрови документи и eFTI: защо оперативната съвместимост става все по-важна

Регламент (ЕС) 2020/1056 относно електронната информация за товарния транспорт (eFTI) създава европейска рамка, която позволява на икономическите оператори да предоставят на компетентните органи определена регулаторна информация в електронен формат чрез платформи и услуги, съответстващи на рамката eFTI.

Европейската комисия посочва 9 юли 2027 г. като дата, от която рамката eFTI ще бъде напълно приложима и органите на държавите членки ще трябва да приемат информация, споделена по електронен път от операторите чрез сертифицирани eFTI платформи. От 2026 г. платформите и доставчиците могат да се подготвят за работа според пътя, предвиден от Комисията.

Това не означава, че от 2027 г. всяко малко предприятие трябва да купи „eFTI TMS“. Означава обаче, че при избора днес на система, предназначена да продължи години, има смисъл да се попита доставчикът:

• как експортира данните;
• дали разполага с API;
• как управлява стандарти и оперативна съвместимост;
• какви планове има за развитието на eFTI;
• дали евентуално обявените функции „eFTI compliant/certified“ действително се поддържат от изискваното сертифициране, когато е приложимо.

Европейската цифровизация върви към структурирани и обменяеми данни. Затова затворен архив, от който е трудно да се извлекат собствените данни, е по-голям риск, отколкото в миналото.

Как да оцените TMS, без да се водите от демонстрацията

Демонстрацията почти винаги показва идеалния път. Вместо това оценката трябва да използва реалните случаи на компанията.

Поискайте от доставчика да симулира поне:

1. нормална поръчка;
2. вземане с две доставки;
3. промяна след възлагането;
4. шофьор, недостъпен в последния момент;
5. поръчка, импортирана от Excel;
6. липсващ документ;
7. закъсняла доставка;
8. отменен курс;
9. грешка при интеграция;
10. пълен експорт на период на дейност.

След това измерете:

• колко стъпки са нужни;
• колко информация се въвежда отново;
• кой трябва да се намеси;
• какво вижда шофьорът;
• какво остава в историята;
• как се възстановяват грешките.

Контролен списък

• Кой процес искаме да подобрим първо?
• Продуктът предназначен ли е за собствен автопарк, за товародател или за спедитор?
• Наистина ли управлява нашия тип поръчка?
• Изисква ли модули, които няма да използваме?
• Планът разбираем ли е за операторите?
• Свързани ли са шофьорите и превозните средства с поръчките?
• Има ли история на промените?
• Могат ли данните да се експортират в използваеми формати?
• Включени ли са API или се заплащат отделно?
• Кои интеграции са стандартни и кои са проект?
• Какви разходи има извън лиценза?
• Колко време отнема внедряването?
• Как се управляват резервните копия, сигурността и непрекъснатостта?
• Кои функции са действително налични днес и кои са в пътната карта?
• Как се разглежда развитието на eFTI?