Навіть найкращі системи дають збій, коли робота відбувається в умовах екстремального навантаження. У логістиці робота завжди відбувається в умовах екстремального навантаження — програмне забезпечення має встигати за темпом або просто не заважати. Як команда, що з 2009 року розробляє логістичне програмне забезпечення для таких компаній, як Nova Post та Ecolines, ми у Stfalcon бачили це на власні очі.
У цій статті пояснюється, чому розробка логістичного програмного забезпечення часто закінчується невдачею, чому одних лише технічних талантів недостатньо та на які ознаки насправді слід звертати увагу під час оцінки партнера з розробки.
3 типові причини невдач у розробці логістичного програмного забезпечення (і чому аутсорсинг усуває кожну з них)
З нашого досвіду ми виділяємо три типові причини, через які розробка логістичного програмного забезпечення йде на дно.
Схема № 1: Програмне забезпечення, яке не може впоратися з винятковими ситуаціями
Коли в грудні 2022 року зимовий шторм порушив розклад рейсів Southwest Airlines, їхня застаріла система планування роботи екіпажів не змогла перерозподілити пілотів та бортпровідників на доступні літаки. Члени екіпажу дзвонили на гарячу лінію та чекали на лінії годинами, деякі — цілу ніч. Дві третини рейсів було скасовано, через що два мільйони пасажирів залишилися без можливості продовжити подорож. Міністерство транспорту наклало штраф у розмірі 140 мільйонів доларів.
Southwest розробила цю систему самостійно і припустилася помилки.
Така ситуація є типовою для логістики: команди розробників створюють і тестують систему на «ідеальному сценарії» за нормальних умов роботи (заплановані екіпажі, передбачувані погодні умови, наявність ресурсів згідно з планом). Реальні логістичні операції — це саме це. Відмова від доставки, неявка перевізника, перенесення часу зустрічі на чотири години вперед становлять 30–40 % щоденних операцій, а не є винятковими випадками.
Досвідчені операційні команди знають, що спочатку треба проектувати з урахуванням збоїв, бо вони неминучі, і коли вони трапляються, програмне забезпечення або справляється з ними, або стає вузьким місцем. Коли ви доручаєте роботу команді, яка не спеціалізується на логістиці, ви за замовчуванням отримуєте мислення, орієнтоване на «ідеальний сценарій», оскільки вони не знають, на які винятки слід враховувати при розробці.
Шаблон № 2: Розробники, яким бракує галузевих знань
Капітан, який завантажував контейнери, помітив, що його судно занурюється глибше та нахиляється більше, ніж очікувалося, тому він зателефонував планувальникам. Розробник провів розслідування та виявив, що програмне забезпечення надсилало брутто-вагу в систему, яка очікувала нетто-вагу — помилка в 3 000 кг на контейнер. Те, що він тоді вважав «нудним логістичним програмним забезпеченням, де найгірше, що могло статися, — це втрата контейнера на день-другий», виявилося гірким пробудженням.
Розробник не знав, чого він не знав, і це ще одна закономірність, яку ми спостерігаємо.
Логістичне програмне забезпечення взаємодіє з фізичним світом у спосіб, якого більшість розробників ніколи не бачить. Термінологія має значення (брутто проти нетто, тара проти корисного навантаження, об’єм проти щільності), але так само важливі й операційні реалії: які обмеження ваги спричиняють перевірки Міністерства транспорту (DOT), як розподіл навантаження впливає на стабільність транспортного засобу, коли, здавалося б, незначна затримка призводить до пропущених вікон зустрічей у трьох штатах.
Якщо ви залучаєте до роботи команди, які не мають галузевої експертизи, ви розраховуєте, що вони задаватимуть правильні питання під час аналізу потреб. Більшість цього не робить.
Шаблон № 3: Проєкти трансформації, що ігнорують операційні реалії
У 2024 році компанія Gartner виявила, що 76% проектів трансформації логістики не досягають показників ефективності. Причиною цього є не технології — і навіть не бюджет. Виною всьому є суперечливі пріоритети (46 %), недостатня потужність команди (36 %) та опір з боку інших відділів (35 %).
Постачальники розробляють для своїх клієнтів амбітні дорожні карти трансформації, не беручи до уваги той факт, що операційна команда:
- працює на 110 % потужності
- не може виділити персонал для навчання/тестування
- буде чинити опір усьому, що додає складності до їхнього й без того хаотичного робочого дня
Постачальники програмного забезпечення пропонують те, що мало б працювати: нові складні системи, «оптимізовані робочі процеси», потужні інтеграції. Чого вони не бачать, наприклад, так це того, що менеджер з відправлень обробляє понад 200 відправлень на день і не може зупинитися, щоб освоїти нове програмне забезпечення.
Випадок компанії Beaver Street Fisheries (американський виробник і дистриб’ютор заморожених морепродуктів) є тут класичним прикладом. Вони найняли консультантів для налаштування систему Blue Yonder WMS. Консультанти «багато обіцяли, але не виконали своїх зобов’язань». Місяці виставлення рахунків — жодних корисних результатів. Постачальники знали програмне забезпечення, але не розуміли реальних умов роботи клієнта.
Ці три закономірності, які ми бачимо? Усі вони випливають з однієї й тієї ж першопричини: ставлення до логістичного програмного забезпечення як до будь-якого іншого проекту з розробки.
Потрібне програмне забезпечення, здатне впоратися з вашими операційними реаліями?
Ми розробляємо індивідуальні логістичні технології для сучасних ланцюгів постачання.
Аліна
Менеджерка по роботі з клієнтами
Чому технічних фахівців недостатньо для розробки логістичного програмного забезпечення
Ви, мабуть, чули щось подібне (і, ймовірно, занадто багато разів):
«Ми оптимізуємо ваші операції за допомогою розумної автоматизації!»
Люди, які не знаються на цій сфері, вважають, що логістика є складною через «погане» програмне забезпечення, яке потребує модернізації. Через півроку вони виявляють, що складність полягає в самій галузі.
Неможливо обійти в коді той факт, що 30–40 % логістичних операцій — це крайні випадки. Неможливо розробляти дорожні карти трансформації, коли операційна команда вже працює на 110 % своєї потужності. Не можна розраховувати на те, що дані надходитимуть у єдиному форматі та в повному обсязі, коли логістика працює в умовах неузгоджених форматів накладних (BOL), тайм-аутів API у пікові періоди та затримок через погодні умови, що поширюються на сусідні штати.
Саме експертиза у галузі відрізняє надійне програмне забезпечення від того, яке ігнорують на користь Excel та телефонних дзвінків.
Як оцінити партнера з розробки логістичного програмного забезпечення
Тож як визначити, чи дійсно партнер з розробки має експертизу в галузі логістики, крім гучних заяв на його веб-сайті? Ось на що слід звернути увагу.
Справжня експертиза в галузі логістики проявляється у 4 аспектах
Перш ніж дзвонити вперше, зверніть увагу на такі моменти.
| ✔ Вони точно описують ваші робочі процеси | ✔ Вони запитують «що не працює?» ще до того, як запитати «які функції потрібні?» |
| ✔ Вони природно говорять про логістику | ✔ Вони передбачають запас часу на випадок проблем із даними |
- Вони можуть описати вам вашу діяльність своїми словами. Не просто повторювати те, що ви сказали, а показати, що розуміють обмеження. Наприклад, коли ви описуєте диспетчеризацію, вони повинні помітити проблеми, про які ви не згадали: «Тож коли ліміт робочого часу водія вичерпується посеред маршруту, як ви вирішуєте питання передачі вантажу?»
- Вони хочуть знати, що не працює, перш ніж створювати щось нове. «Що відбувається, коли перевізник не з’являється?», а не «Які функції панелі управління вам потрібні?»
- Вони вільно володіють термінологією логістики. Їм не потрібно, щоб ви пояснювали терміни, і вони не використовують неправильні слова для позначення речей.
- Їхній графік передбачає запас часу на вирішення проблем з інтеграцією та даними: збої в API перевізників, невідповідність форматів EDI, очищення даних.
Як ми реалізуємо логістичні проєкти в Stfalcon: 3 основні принципи
За понад 16 років розробки програмного забезпечення для логістики та індивідуальних транспортних рішень ми зрозуміли, що структура взаємодії має не менше значення, ніж технічні навички. Ось три основні принципи, яких ми завжди дотримуємося, проілюстровані історіями наших клієнтів.
Вивчення: відображення операційної реальності
На етапідіагностики в логістичних проєктах ми знайомимося з операційною командою клієнта. Іноді це власник продукту, який охоплює всі операційні аспекти, іноді — міжфункціональна команда (менеджер з логістики, операційний відділ, фінансовий відділ, технічний керівник). У будь-якому разі ми спілкуємося з людьми, які знають, що працює, а що ні в повсякденній діяльності.
Ми аналізуємо 8 операційних сфер, які визначають, як програмне забезпечення працюватиме в реальних умовах:
- Життєвий цикл замовлення (від запиту до закриття)
- Логіка відправлення (ручна, напівавтоматична або повністю автоматизована)
- Планування та оптимізація маршрутів
- Управління автопарком та водіями
- Обробка виняткових ситуацій (затримки, скасування, зміни, інциденти)
- Оновлення статусу та комунікаційні потоки
- Виставлення рахунків та розрахунки
- Інтеграція із зовнішніми системами (ERP, TMS, телематика, GPS-трекери, паливні системи, облік робочого часу)
Результатом етапу «Діскавері» є схеми процесів для ключових сценаріїв, маршрути взаємодії користувачів для кожної ролі, схеми інтеграції, що ілюструють потоки даних між системами, а також попередня кошторисна оцінка з поетапними термінами реалізації. Цей пакет стає основою, що запобігає розширенню обсягу робіт та пропущенню вимог на пізніших етапах.
| Приклад етапу «Discovery» компанії Stfalcon для логістичних проєктів | ||
|---|---|---|
АНАЛІЗ 8 НАПРЯМКІВ
| ПІДГОТУВАТИ 4 РЕЗУЛЬТАТИ
| РЕЗУЛЬТАТ План, що запобігає розширенню обсягу робіт та пропуску вимог |
Приклад: Nova Post, найбільша служба доставки в Україні
Керівництво Nova Post планувало графіки роботи у 13 000 відділень за допомогою Excel. Потреби у персоналі в відділеннях залежали від місцезнаходження, сезону, місцевих подій та обсягу посилок. Використання електронних таблиць для управління цією мінливістю стало… складним: керівники щодня витрачали години на ручне планування.
На етапі аналізу ми визначили операційні обмеження:
- Як змінюються потреби в персоналі під час пікових навантажень?
- Що відбувається, коли невеликі відділення стикаються з несподіваним сплеском кількості доставок?
- Які ручні обхідні рішення змушує менеджерів застосовувати Excel?
Створена система (Nova Headcount) автоматизує 99% ручної роботи з планування та обробляє дані про кадрове забезпечення по всій країні в 4 рази швидше, ніж попередній ручний процес.
Управління: операційні KPI, а не швидкість розробки
Ми пов’язуємо KPI з оперативними викликами. Більшість клієнтів звертаються до нас з метою оптимізації витрат, тому економічні показники зазвичай мають пріоритет. Але ми рекомендуємо збалансувати їх за чотирма категоріями.
| Структура KPI для проєктів з розробки логістичного програмного забезпечення | |
|---|---|
ОПЕРАЦІЙНА ЕФЕКТИВНІСТЬ
| ЕКОНОМІЧНІ ПОКАЗНИКИ
|
ЯКІСТЬ ОБСЛУГОВУВАННЯ
| ТЕХНІЧНІ ПАРАМЕТРИ
|
Операційна ефективність
- Рівень своєчасності доставки: відсоток доставок, здійснених вчасно
- Середній час доставки: середній час від завантаження до доставки
- Ефективність маршруту: співвідношення запланованого та фактичного маршруту
- Коефіцієнт завантаження: відсоток завантаження автопарку або водіїв
Економічні показники
- Вартість однієї доставки: загальна вартість доставки, поділена на кількість доставок
- Ефективність використання палива або пробігу: споживання палива або пробіг на одне замовлення
- Дохід на транспортний засіб/водія: дохід, отриманий на одиницю транспорту або водія
Якість обслуговування
- Відсоток невдалих доставок: відсоток доставок, які не вдалося здійснити з першої спроби
- Задоволеність клієнтів (CSAT/NPS)
- Середній час реагування (на замовлення або інцидент)
Технічні показники роботи системи
- Час безвідмовної роботи системи: відсоток доступності системи
- Час на призначення замовлення: час від створення замовлення до призначення водія
- Частота помилок або інцидентів: кількість технічних збоїв
На початку проекту достатньо вибрати 3–4 KPI, які відповідають вашим найгострішим операційним проблемам. Для більшості логістичних проєктів ми рекомендуємо почати з показників своєчасності доставки, вартості однієї доставки, коефіцієнта завантаження та відсотка невдалих доставок. У міру вдосконалення системи додавайте додаткові показники з інших категорій.
Приклад: мобільний додаток Ecolines
Ecolines, міжнародний автобусний перевізник, що обслуговує маршрути по всій Європі, мав мобільний додаток, який технічно працював. Користувачі могли переглядати розклади, перевіряти час відправлення та бачити маршрути. Але вони не купували квитки. Негативні відгуки в App Store вказували на заплутаний процес бронювання та незрозумілу цінову політику.
З огляду на це ми відстежували коефіцієнт конверсії: відсоток користувачів, які перейшли від перегляду маршрутів до завершення покупки. Кожне дизайнерське рішення перевірялося на відповідність одному питанню:
Чи зменшує це бар’єри між переглядом маршрутів та бронюванням?
Оновлений додаток подвоїв кількість бронювань квитків, а ми «досягли нашої головної мети — зробити бронювання для пасажирів максимально простим», — зазначив Томас, керівник відділу електронної комерції Ecolines.
Впровадження: поетапний запуск у періоди поза піковим навантаженням
Ми запускаємо проект поетапно: спочатку основну функціональність, а потім — складні інтеграції. Для берлінської платформи бронювання автобусних квитків це означало спочатку запустити функції бронювання та резервування, а потім додати інтеграції з партнерами. Для систем, критично важливих для роботи компанії, ми проводимо паралельну експлуатацію перед повним переходом на нову систему. Як, наприклад, у випадку з новою системою планування Nova Post.
Наша команда розробників експлуатувала її паралельно з існуючим процесом на базі Excel протягом кількох тижнів. Менеджери могли порівнювати результати та виявляти крайні випадки. Моніторинг після запуску був зосереджений на реальних експлуатаційних навантаженнях: сплесках обсягів у святкові дні, закритті офісів в останній момент або раптовій нестачі персоналу.
3 компанії з аутсорсингу розробки програмного забезпечення для логістики, на які варто звернути увагу
Якщо ви зараз розглядаєте можливість співпраці з технологічним постачальником, то знайдете багато компаній, які заявляють, що розуміються на логістиці. А де докази?
Нижче наведено три компанії з розробки програмного забезпечення, орієнтовані на логістику (включно з нами), що мають перевірені кейси.
Stfalcon
- Рейтинг на Clutch: 4,9/5 (56 відгуків)
- Офіси: Україна, Естонія
- Діапазон вартості проектів: від 10 тис. до 200 тис. доларів і більше
- Спеціалізація:ланцюги постачання, управління автопарком, а також системи обробки замовлень і доставки. Сертифікат ISO 9001:2015 з управління якістю.
Докази компетентності:
- Система планування змін Nova Post автоматизує 99% ручної роботи та обробляє дані в 4 рази швидше.
- Капітальна модернізація мобільного додатку Ecolines подвоїла кількість бронювань квитків.
- Берлінський автобусний стартап завоював понад 40% частки ринку завдяки своїй платформі бронювання.
- Штучний інтелект на базі Gemini скоротив час обробки митних документів на 67%.
Працюйте з командою, яка розуміє вашу галузь
Замовте безкоштовну 30-хвилинну консультацію, щоб обговорити ваш логістичний проєкт.
Аліна
Менеджерка по роботі з клієнтами
Cleveroad
- Рейтинг на Clutch: 4,9/5 (77 відгуків)
- Офіси: Норвегія, США, Україна
- Діапазон вартості проєктів: від 10 тис. до 250 тис. доларів і більше
- Спеціалізація: Системи управління транспортом, управління автопарком, складські операції, доставка «останньої милі». Сертифіковано за стандартом ISO 9001:2015 у сфері управління якістю та за стандартом ISO/IEC 27001:2013 у сфері інформаційної безпеки.
Докази компетентності:
- Створено систему управління транспортом (TMS) для американської логістичної компанії (складське господарство + міжміські перевезення) з автоматизованим плануванням маршрутів, що дозволило скоротити час простою на 27–36%.
- Інтегрована з існуючими системами WMS та CRM.
- Платформа MoveUp обслуговує пасажирів з медичними потребами та потребами у доступності за допомогою відстеження в режимі реального часу та вибору маршруту за допомогою штучного інтелекту.
Limeup
- Рейтинг на Clutch: 5,0 (11 відгуків)
- Офіси: Велика Британія, Німеччина, Польща
- Діапазон вартості проєктів: від 30 тис. доларів
- Спеціалізація: управління складами, вантажні платформи, міжнародні системи ланцюгів постачання.
Докази компетентності:
- Система управління складом WareSync WMS забезпечила час безвідмовної роботи 99,95% під навантаженням, опрацювала понад 1 млн оновлень запасів у перші 3 місяці та вдвічі пришвидшила підключення постачальників.
- Вантажна платформа Logifleet обробляє понад 500 тис. подій геолокації щотижня, час відгуку скоротився на 40%.
- Створено веб- та мобільні додатки з функцією відстеження в режимі реального часу та внутрішньододатковою комунікацією.
Висновок
Для лідерів логістичної галузі, які оцінюють партнерів з розробки, питання полягає не в тому, «Чи зможуть вони виконати роботу вчасно?», а в конкретних деталях, таких як: «Чи розуміють вони, чому статус робочого часу водія може бути важливішим за оптимізований маршрут?»
У Stfalcon ми вже понад 16 років розробляємо логістичне програмне забезпечення, яке не відстає навіть тоді, коли операції працюють на межі можливостей. Якщо ми здаємося вам підходящим партнером, давайте обговоримо ваш проєкт.
