Внедрение TMS системы: 5 наиболее распространенных ошибок

Сегодня из-за последствий пандемии коронавируса условия ведения бизнеса для FMCG-компаний радикально изменились. Цены на доставку взлетели, перевозчики не идут на уступки, из-за удаленной работы упала эффективность операционистов. Кроме того, процессы стали непрозрачными, сотрудники выгорают и увольняются, а клиенты хотят, чтобы их товар доставляли чаще и меньшими партиями. Одним словом, постковидный мир — страшный сон для директора по логистике.

В этой ситуации компании ищут все возможные способы повышения эффективности управления доставкой и снижения зависимости от линейного персонала. Одно из решений — внедрение TMS-системы.

В предыдущих статьях мы рассказали о том, как выбрать TMS-систему и подрядчика, а также поделились методикой оценки экономии от ее использования (и даже подготовили калькулятор!).

В этой статье речь пойдет о том, какие накладки могут быть при внедрении системы и как не оказаться у разбитого корыта после нескольких месяцев выполнения проекта.

Кстати, если вы хотите узнать, как лидеры рынка справились с внедрением TMS-системы, почитайте их кейсы: Johnson&Johnson, Bacardi, Ecolab/Nalco.

Какие баги могут быть при внедрении TMS?

Рассмотрим типичную ситуацию: компания выбрала подходящую TMS-систему и подрядчика для ее внедрения. Обе стороны пожали друг другу руки, подписали договор и утвердили план-график работ. Счастливый директор по логистике ожидает, что через 3 месяца вся работа отдела будет автоматизирована, а компания начнет экономить деньги. Но ни через 3, ни даже через 6 месяцев счастливое будущее так и не наступает. Сотрудники заказчика обвиняют подрядчика в срыве проекта, подрядчик обвиняет их в ответ, а руководитель не может разобраться, на чьей стороне правда.

Что же могло пойти не так в этой ситуации? Мы выполнили десятки проектов по внедрению TMS и не понаслышке знаем, с какими ошибками чаще всего сталкиваются компании в процессе внедрения.

Ошибка №1. Не был проведен этап бизнес-анализа до старта внедрения

Чаще всего при реализации проекта заказчик приходит к подрядчику с заранее подготовленным ТЗ. Для качественного выполнения проекта подрядчик должен получить не только ТЗ, но и провести этап бизнес-анализа: самостоятельно разобраться в текущих (AS IS) процессах заказчика и согласовать целевую картину бизнес-процессов (TO BE) с учетом функционала TMS-системы.

Если не выполнить этот важный шаг, то подрядчик начнет дорабатывать систему согласно заявленному ТЗ, а в процессе проекта выяснится, что ее функционал не ложится на процессы заказчика. В итоге придется либо дорабатывать систему, либо менять процессы заказчика.

Пример из практики. Мы внедряли TMS-систему в одном крупном холдинге, состоявшем из нескольких юрлиц. В процессе бизнес-анализа обнаружили, что процесс заказа транспорта в одном из юрлиц кардинально отличался от стандартного процесса и не ложился на архитектуру системы. Было два возможных выхода из этой ситуации: изменить процесс на стороне заказчика или значительно переработать систему. Заказчик выбрал первый вариант, для того чтобы не раздувать бюджет проекта.

Ошибка №2. Заказчик не выделил достаточно ресурсов для выполнения проекта

Есть распространенное заблуждение — для внедрения TMS нужно лишь подписать договор с подрядчиком и можно расслабиться: дальше произойдет магия и система внедрится сама собой. Но, к сожалению, это не так. Любой проект требует активного участия двух сторон.

Вот типичный список активностей, в которых заказчик должен обязательно участвовать:

• Проработка будущего бизнес-процесса работы в системе на этапе бизнес-анализа
• Утверждение требований к будущей системе, подготовленных подрядчиком
• Регулярное участие в демо системы
• Приемка разработанного функционала
• Обучение работе в системе
• Подключение к системе 3-х сторон (перевозчики, 3PL-оператор и прочие)
• Координация внутренних служб компании (например, IT), участвующих в проекте
• Подготовка данных для загрузки в систему

В зависимости от сложности реализуемого проекта он может потребовать от нескольких часов в день до выделенного сотрудника или даже нескольких сотрудников на все время жизни проекта.

Пример из практики. При планировании одного из проектов мы выяснили, что активная фаза внедрения продукта выпадает на высокий сезон у заказчика. То есть когда все сотрудники будут физически недоступны для каких-либо иных работ за рамками операционной деятельности. Мы подсветили этот риск заказчику, и он решил выделить дополнительный ресурс для проекта на время высокого сезона.

Ошибка №3. Не были зафиксированы подробные критерии приемки внедряемой системы

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

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

Пример из практики. Стороны в рамках проекта зафиксировали следующие критерии успешного внедрения модуля планирования заказов:

• 100 % заказов успешно загружается из SAP в TMS по интеграционному каналу
• Для каждого заказа система находит оптимальный способ доставки в соответствии с загруженными тарифами
• % успешно спланированных заказов в течение двух последовательных недель превышает 95 %

В этом примере критерии четко зафиксированы и не допускают каких-либо споров между сторонами.

Ошибка №4. На старте не просчитали ожидаемый экономический эффект от внедрения системы

Любая система внедряется с целью сокращения ручного труда и экономии денег компании. Чтобы ожидания от внедрения TMS совпали с реальностью, подрядчик совместно с заказчиком на старте проекта должны четко зафиксировать:

● какой (и за счет чего!) ожидается эффект от внедрения системы — в деньгах или часах
● как именно мы будем измерять, был ли он достигнут по итогам проекта

Все расчеты и допущения должны делаться обязательно двумя сторонами. Поскольку лишь заказчик может реалистично оценить свои текущие временные затраты (AS IS), и только подрядчик может сказать, какое влияние на эти затраты окажет его система после внедрения (TO BE).

Пример из практики. В рамках проекта по внедрению TMS заказчик планировал использовать несколько модулей системы, включая модуль выбора оптимального способа доставки. Наши совместные расчеты с заказчиком показали, что этот модуль будет выгоден компании и окупит свою стоимость. Но заказчик все же не был на 100% уверен, что на практике вся ожидаемая экономия реализуется. В итоге был согласован следующий подход:

● Была запущена базовая версия системы, в которой заказчик начал работать, вручную подбирая оптимальный способ доставки
● По истечении двух месяцев мы подключили модуль выбора оптимального способа доставки и запустили его на исторических данных
● Результаты работы алгоритма мы сравнили с ручным планированием заказчика

Оказалось, что реальная экономия была несколько ниже плановой, но все же с лихвой окупала стоимость модуля. В результате заказчик принял решение его использовать, так как теперь уже был полностью уверен в эффективности выбранного решения.

Ошибка №5. При планировании не учли влияние третьих сторон на ход выполнения проекта

В проекте по внедрению TMS всегда участвуют несколько сторон: бизнес-заказчик, подрядчик, 3PL-оператор, перевозчики, IT-отдел заказчика. Каждая из этих сторон может оказать радикальное влияние на ход проекта.

Если окажется, что IT-отдел заказчика из-за нехватки ресурсов не сможет доработать ERP-систему для отправки заказов в TMS, то это способно заблокировать весь ход проекта. Если на берегу заказчик не убедился, что все его перевозчики готовы принимать заявки в TMS-системе, то после внедрения часть перевозчиков может отказаться работать в ней. Тогда эффект от автоматизации не будет полностью реализован.

Кстати, по этой причине стратегия нашей TMS-системы Pooling Plus включает в себя интеграцию со всеми лидирующими перевозчиками на рынке. Это избавляет наших клиентов от необходимости заставлять своих перевозчиков работать в новом для них инструменте.

Пример из практики. При планировании проекта мы выяснили, что команда SAP на стороне заказчика загружена другими задачами на ближайшие 6 месяцев и не сможет настроить отправку данных из SAP в TMS. Мы подсветили этот риск заказчику, и он решил запускать систему с ручной загрузкой заказов на период ожидания готовности команды SAP.

Выводы

Успешное выполнение проекта по внедрению TMS-системы — это всегда слаженная работа заказчика и подрядчика. Выбор качественного подрядчика, проведение детального бизнес-анализа на старте, выделение ресурсов и учет наиболее часто встречающихся рисков — вот рецепт успешного выполнения проекта в максимально сжатые сроки.

---

Вы намерены внедрить TMS-систему после прочтения этой статьи? Мы рады предложить вам наше решение. Pooling Plus — это облачная TMS-система, обеспечивающая управление доставкой на всех этапах. Работать в ней можно из любой точки мира при наличии компьютера и интернета.

Подробнее о продукте:

https://plus.pooling.me/

Связаться с нами