Помилки впровадження TMS та шляхи їх вирішення
Чи завжди впровадження TMS дає бажані результати? Уявімо типову ситуацію: логістична компанія обрала собі партнера для розробки або впровадження системи. На папері все виглядає чудово, під проект відводять певний бюджет та виставляють йому терміни. Власники бізнесу чекають, що вже за півроку процеси можна буде поставити на цифрові рейки та скоротити витрати.
Але насправді ні за півроку, ні за дев'ять місяців проект не запускається. Навіть якщо технічна частина розробки загалом завершилася, на етапі впровадження виникають проблеми, що не вирішуються. Сторона клієнта звинувачує виконавця у зриві дедлайну, той у свою чергу вказує на об'єктивні проблеми, або звинувачує ще когось.
Що могло піти не так? Давайте розберемо нижче типові помилки діджиталізації логістичного бізнесу та позначимо шляхи їх вирішення.
Помилка: нерозуміння фінансових цілей проекту
Найкращим консультантом у виборі інструментів для бізнесу завжди буде калькулятор. Ви маєте ясно уявляти собі, наскільки доцільним буде для вас інвестиція в TMS-систему: скільки вона коштуватиме, скільки дозволить заощадити, у який термін окупиться.
Навіть здорові та логічні ініціативи можуть обернутися масштабним “зливом” бюджету, якщо не співвідносити їх з фінансовими цілями та можливостями компанії. Так проект перетворюється на "довгобуд", в який доводиться вкладати все більше і більше коштів без істотного результату.
Важливо, щоб усі розрахунки рентабельності робилися як на стороні клієнта, так і на стороні розробника, і щоб обидві сторони досягли єдності щодо фінансових очікувань від продукту.
Рішення: Ретельно підведіть під проект фінансову базу, оцініть його у перспективі найближчих 3-5 років. Вивчіть ринок подібних рішень - дуже часто впровадження чужого софту або хмарного рішення на перевірку виявляється не таким вже й вигідним, особливо для великих компаній. Використання стороннього сервісу може вимагати коштів, співставних з вартістю розробки нового софту.
У разі кастомної розробки хорошим рішенням для старту буде реліз MVP. Це продукт, який коштуватиме досить дешево і дозволить перевірити вихідні гіпотези на практиці. Згодом MVP можна розвивати, підключаючи до нього нові модулі.
Помилка: відсутність стратегії
Розробка будь-якого ІТ-продукту має починатися з якісної аналітики. З одного боку, необхідно розуміти ситуацію на ринку, з іншого - сформувати ясне уявлення про процеси та діяльність у компанії клієнта. Це дозволяє запропонувати стратегію трансформації процесів: що потрібно автоматизувати, які завдання потрібно спростити, які можливості моніторингу знадобляться менеджерам, etc.
Це фундамент проекту, від правильних передумов розробки безпосередньо залежить її кінцевий результат. Тим дивніше, що в індустрії все ще зустрічаються компанії, які готові відмовитися від етапу бізнес-аналітики, або ведуть його “для галочки”.
Результат такої розробки ймовірно формально відповідатиме ТЗ, і навіть може мати належний технічний рівень. Але при цьому він буде слабко відповідати вимогам та практиці компанії. Доведеться або підлаштовуватися під продукт, або переробляти систему, або забути про нього зовсім.
Рішення: якщо ви задумалися над створенням або впровадженням TMS, спробуйте провести попередній бізнес-аналіз самостійно та відштовхуватись від нього у подальшій роботі. Шукайте команди розробників із сильними аналітиками, і остерігайтесь аутсорсерів, які поспішають давати утопічні обіцянки та готові без питань втілювати у життя будь-яке ТЗ.
Помилка: низька залученість у розробку
Чимало логістичних гравців погано усвідомлюють або недооцінюють необхідність постійної участі в процесах розробки/впровадження софту. Декому хочеться просто перераховувати гроші розробникам і бачитися з ними на мітингах раз на пару тижнів (якщо не раз на місяць).
Але дійсно якісні проекти так не робляться. Для успіху клієнт має постійно бачити виробничий процес та впливати на нього: на етапі бізнес-аналізу, на етапі затвердження концепції, на етапі розробки. Розробникам дуже потрібні консультації, фідбек та участь клієнта у тестуванні модулів продукту.
Велике значення має координація внутрішніх служб компанії-клієнта та його сприяння у підключенні до системи 3-х сторін (перевізники, 3PL-оператори тощо).
Без фідбека від клієнта розробка може просто піти від його очікувань під вагою нових факторів. Зрештою, це важливо для підтримки морального духу розробників. Адже вони, як правило, не хочуть просто отримувати зарплату по рейту за відпрацьовані години, їм важливо “копати у правильному напрямку” і робити справді корисні речі.
Рішення: клієнту варто виділити в компанії одного або декількох людей, для яких ведення проекту TMS буде основною роботою. Це може бути product owner, технічний директор, внутрішні IT-фахівці, та не тільки. Головне, щоб вони добре розуміли бізнес-процеси і специфіку розробки, та могли оперативно давати розробникам весь необхідний фідбек.
Помилка: нестача уваги до персоналу
Впровадження нового софту – це завжди стрес для співробітників будь-якої компанії. Особливо якщо йдеться про такий масштабний і комплексний продукт, як TMS-платформа. Перехід на нове ПЗ зазвичай передбачає зміну формату роботи, тож неминуче стикається з інертністю і навіть невдоволенням частини команди.
Якщо у вашій компанії працюють десятки або навіть сотні людей, то серед них знайдуться критики будь-якого продукту. Комусь може не сподобатися новий інтерфейс (“ми звикли до старого”), комусь потрібне вивантаження даних у якомусь конкретному форматі (навіть якщо цей формат вже безнадійно застарів). Як показує практика, іноді справа доходить до пасивного опору інноваціям, що суттєво б'є за ефективністю проекту.
Рішення: якщо сторона клієнта була залучена в розробку та давала фідбек по продукту, то суттєвих проблем зазвичай не виникає. Навпаки, співробітники швидше за все оцінять новий UI та можливості системи. У розробці важливо приділити особливу увагу інтерфейсу, зробити ставку на кросплатформність та мобайл.
Компанії у будь-якому випадку варто виділити час на навчання та адаптацію команди, це прискорить процес впровадження. Водночас системи створюються для людей, тому не варто ігнорувати фідбек від співробітників. Хто, крім них, може дати конструктивні зауваження щодо подальшого розвитку платформи?
Помилка: нестача уваги до третіх сторін
Розробка та впровадження TMS-системи не може обійтися без участі третіх сторін. Це можуть бути постачальники іншого софту (наприклад, WMS або системи бухгалтерського обліку), партнери з фулфілменту та перевезень, 3PL-оператори, державні структури тощо.
І в комунікації з кожною з третіх сторін щось може піти не так, з серйозними наслідками для перебігу розробки/впровадження продукту. Найчастіше це проблеми комунікації та бюрократії, які просто з'їдають час. Але бувають і серйозніші випадки.
Суворий приклад із життя: у ході розробки нової TMS-платформи логістична компанія дізнається, що частина її партнерів прив'язана до власного legacy-софту, а тому не може (хоча швидше не хоче) пристосовуватися та працювати з новою системою. Як було вирішено проблему? Розробники написали окреме API для обміну даними між новою TMS та старим софтом, а через пару років партнери теж дійшли необхідності переходити на новий софт.
Рішення: комунікацію з усіма причетними до проекту сторонами слід вибудовувати заздалегідь, це один із найбільш ресурсозатратних аспектів менеджменту. І, звичайно, варто враховувати подібні ризики при формуванні термінів та бюджетів.
TMS та майбутнє логістики
Диджиталізація стає базовим стандартом індустрії перевезень. За оцінками Logistics management, глобальний ринок TMS досягне обсягу 11,37 млрд доларів до 2027 року, хоча ще 2019 року він становив 5,4 млрд. Галузь зростає із середньорічним сукупним темпом зростання в 9,6%, і ймовірно зростатиме ще швидше, адже грамотне застосування діджиталу дозволяє будувати більш сталі ланцюжки поставок.
Варто пам'ятати, що кожен логістичний бізнес є унікальним, і ключовим фактором успішності TMS є її відповідність операційним вимогам окремо взятої компанії. З кастомною системою досягти цього набагато простіше, в ній можна будь-якої миті змінювати і модернізувати все, аж до кольору кнопок в інтерфейсі. Команда WEZOM створила не одну таку систему та продовжує постійно розвивати їх.
Хай там що, логістичним компаніям сьогодні ніяк не обійтися без експертизи у диджиталі. Як показує практика, бізнес у цьому плані має два шляхи: формувати власні великі IT-підрозділи, або заручитися підтримкою команди розробників з досвідом і кейсами в індустрії логістики. Важливо не проспати tech-революцію, щоб не поступитися ринком перевезень більш спритним гравцям.
По темі:
Owner, CEO at WEZOM
