Накратко
„Софтуер за управление на транспорта“ и „TMS“ не са две категории, разделени от нормативен акт. Това са търговски и функционални термини, които често се припокриват. Затова изборът само по името на продукта не е особено полезен.
За малко предприятие най-практичното разграничение е следното:
- прост софтуер за управление организира добре ежедневната вътрешна работа;
- по-структуриран TMS обикновено управлява по-голяма сложност при мрежи, превозвачи, тарифи, интеграции, изключения и контрол на разходите.
Това не е скала за качество. По-сложната система не е автоматично по-добра: тя е по-добра само ако тази сложност е необходима.
Няма правна граница между софтуера за управление и TMS
Никой закон не постановява, че един софтуер трябва да има „10 функции“, за да се нарича TMS, или че софтуерът за управление не може да планира. Терминът TMS описва семейство решения, а не сертификация.
Затова едно МСП трябва за няколко минути да остави търговското име настрана и да попита:
- кои процеси покрива;
- колко добре ги покрива;
- какви данни изисква;
- колко души трябва да го използват;
- колко струва внедряването и поддръжката му;
- колко лесно е да се излезе от него и да се извлекат данните.
Практическо сравнение
| Област | Прост софтуер за управление за малък автопарк | Структуриран TMS |
|---|---|---|
| Клиенти и обекти | Основна функция | Основна функция |
| Поръчки | Основна функция | Основна функция |
| Шофьори и собствени превозни средства | Често основна функция | Зависи от целевия пазар |
| Дневен план | Основна функция | Основна функция, често по-усъвършенствана |
| Приложение/комуникация за шофьори | Възможно | Възможно/интегрирано |
| Външни превозвачи | Ограничено или липсва | Често разширено |
| Търгове/снабдяване | Рядко | Често при корпоративни системи |
| Сложни тарифи | Основни или липсват | Често разширени |
| Оптимизация | Ограничена/по избор | По-често срещана |
| Одит на навлото | Рядко | Възможен/разширен |
| ERP/WMS/EDI/API | Прост или избирателен | Често съществен |
| Внедряване | Дни/седмици в прости случаи | Може да изисква специален проект |
| Конфигурация | Ограничена | Често обширна |
| Обучение | Ограничено | По-структурирано |
Таблицата е ориентировъчна: всеки продукт трябва да се провери поотделно.
Истинската разделителна линия: сложността на процеса
Броят на камионите има значение, но не е достатъчен. Две предприятия с по десет превозни средства могат да имат противоположни нужди.
Компания А
- редовни клиенти;
- относително стабилни маршрути;
- собствен автопарк;
- малко служители в офиса;
- поръчки, получавани по имейл;
- основна нужда: да се организират поръчката, камионът, шофьорът и промените.
Лек софтуер за управление може да е напълно достатъчен.
Компания Б
- десет собствени превозни средства, но и 80 външни превозвачи;
- стотици поръчки;
- различни тарифи според зона, тегло и клиент;
- EDI потоци;
- клиентски портал;
- одит на фактури на превозвачи;
- договорни KPI.
Тук броят на камионите вече не описва сложността. По-структуриран TMS може да е оправдан.
Пет признака, че е достатъчен прост софтуер за управление
1. Основният проблем е разпиляната информация
Ако истинската трудност е да се преписват поръчки от имейл в Excel и после да се звъни на шофьорите, приоритетът е да има единен източник.
2. Автопаркът е предимно собствен
Не е нужен механизъм за снабдяване с превозвачи, ако не се извършва снабдяване.
3. Планирането се решава чрез опита на диспечера
Добър календар и чисти данни могат да дадат повече стойност от механизъм за оптимизация, чието параметризиране отнема месеци.
4. В офиса работят малко хора
Система с десетки роли, одобрения и работни потоци може да се превърне в пречка.
5. Необходими са малко интеграции
Ако е достатъчно да се импортира Excel файл, да се експортират данни и да се свържат една или две услуги, корпоративната архитектура може да е излишна.
Пет признака, че е нужно нещо по-структурирано
1. Купува се много транспорт от трети страни
Изборът на превозвач, търговските условия, представянето и наличността се превръщат в основни процеси.
2. Тарифите вече не могат да се управляват ръчно
Многото комбинации от зона, тегло, палети, гориво, пътни такси и добавки изискват структурирани правила.
3. Поръчката трябва да премине през няколко системи
ERP, WMS, EDI, клиентски портали, платформи за проследяване и администрация изискват управление на интеграциите.
4. Грешките имат системна цена
Дублирани фактури, непредвидени разходи, SLA, неустойки и големи обеми правят автоматизирания контрол полезен.
5. Ръководството се нуждае от консолидирани данни
Не е достатъчно да се знае „какво правят камионите днес“: трябва да се измерват разходите, представянето и капацитетът в сложни мрежи.
Разходът не е само таксата: изчисляване на TCO
За да се сравнят две решения, е полезно да се оцени общата цена на притежание (Total Cost of Ownership) за поне три години.
Вземете предвид:
- лицензи за потребители/превозни средства/поръчки;
- разход за настройка;
- миграция на данни;
- обучение;
- консултации;
- разработка на API/EDI;
- допълнителни модули;
- премиум поддръжка;
- разходи за среди/тестове;
- евентуални устройства;
- вътрешното време на хората;
- поддръжка на интеграциите;
- договорни увеличения на цената;
- разход за излизане/бъдеща миграция.
Софтуер, който струва 100 евро месечно и изисква 15.000 евро персонализации, не струва 100 евро месечно. Обратно, малко по-скъп стандартен софтуер може да излезе по-евтино, ако избягва проект и текуща поддръжка.
Рискът от предоразмеряване
Предоразмеряването има конкретни последствия:
- повече полета за попълване;
- повече обучение;
- процеси, приспособени към софтуера, вместо към работата;
- оператори, които се връщат към Excel „за да стане по-бързо“;
- зависимост от консултанти;
- по-трудни надграждания;
- несъразмерни фиксирани разходи.
Предупредителен знак е, когато предприятието трябва да попълва информация, която никой няма да използва, за да управлява обикновена поръчка.
Обратният риск: твърде дълго оставане с нестабилни инструменти
Недостатъчното оразмеряване също струва. Ако Excel се е превърнал в централната система, но:
- има пет версии на файла;
- промени и поръчки се губят;
- никой не знае кой какво е променил;
- няма роли/права за достъп;
- шофьорите получават данните отделно;
- файлът се възстановява след всяка грешка;
- собственикът е единственият, който „знае как работи“,
разходът не се вижда във фактура, но съществува под формата на часове, грешки и зависимост от хората.
Преминаването към софтуер за управление трябва да стане преди файлът да стане невъзможен за замяна.
Пример: 8 камиона срещу мрежа от превозвачи
Предприятие с 8 собствени камиона
То получава 25 поръчки на ден. Двама души планират. Основният проблем е да се знае споделено кой шофьор ще извърши кое вземане и да се съобщават промените.
Приоритети:
- структурирана поръчка;
- дневен план;
- основни данни за шофьори/превозни средства;
- актуализации за шофьорите;
- история;
- експорт.
Простият софтуер за управление може да покрие почти цялата необходима стойност.
Оператор, който координира 120 превозвачи
Той получава 800 поръчки на ден, купува капацитет на пазара, използва няколко ценови листи, интегрира ERP и WMS и трябва да проверява фактури и SLA.
Приоритети:
- интеграция;
- снабдяване;
- тарифи;
- възлагане;
- изключения;
- проследяване;
- одит на разходите;
- анализ.
Тук TMS проектът е част от оперативната структура на предприятието.
Матрица за вземане на решение
Дайте от 0 до 2 точки за всяка позиция:
| Въпрос | 0 | 1 | 2 |
|---|---|---|---|
| Колко системи трябва да се интегрират? | 0-1 | 2-3 | 4+ |
| Колко външни превозвачи управляваме? | почти никакви | няколко | много |
| Сложност на тарифите | ниска | средна | висока |
| Брой изключения | малък | среден | голям |
| Нужда от снабдяване | няма | случайна | основна |
| Одит на разходите | прост ръчен | частичен | систематичен |
| Работни потоци/одобрения | почти никакви | няколко | много |
| Мрежа | местна/проста | национална | сложна мултимодална/международна |
Резултатът не създава математическа истина. Той служи да накара предприятието да опише собствената си сложност, преди да разглежда софтуер.
Контролен списък
- Избираме според името „TMS“ или според процесите?
- Кои три проблема трябва да се решат в рамките на 90 дни?
- Колко души действително ще използват системата?
- Колко интеграции са съществени?
- Управляваме ли основно собствен автопарк или външни превозвачи?
- Имаме ли сложни тарифи?
- Колко струва проектът за три години, а не само таксата?
- Можем ли да започнем малко и да добавяме модули?
- Можем ли да експортираме данните, ако сменим доставчика?
- Изисква ли системата повече дисциплина, отколкото организацията може да поддържа днес?