Навіть найкращі системи дають збій, коли робота відбувається в умовах екстремального навантаження. У логістиці робота завжди відбувається в умовах екстремального навантаження — програмне забезпечення має встигати за цим темпом або просто не заважати. Як команда, що з 2009 року розробляє логістичне програмне забезпечення для таких компаній, як Nova Post та Ecolines, ми у Stfalcon бачили це на власні очі.
У цій статті пояснюється, чому розробка логістичного програмного забезпечення часто закінчується невдачею, чому одних лише технічних талантів недостатньо та на які ознаки насправді слід звертати увагу під час оцінки партнера з розробки.
3 типові причини невдач у розробці логістичного програмного забезпечення (і чому аутсорсинг розробки логістичного програмного забезпечення усуває кожну з них)
З нашого досвіду ми виділяємо три типові причини, через які розробка логістичного програмного забезпечення зазнає невдачі.
Схема № 1: Програмне забезпечення, яке не може впоратися з винятковими ситуаціями
Коли в грудні 2022 року зимовий шторм порушив розклад рейсів Southwest Airlines, їхня застаріла система планування роботи екіпажів не змогла перерозподілити пілотів і бортпровідників на доступні літаки. Члени екіпажу дзвонили на гарячу лінію й чекали на лінії годинами, а деякі — цілу ніч. Дві третини рейсів було скасовано, через що два мільйони пасажирів залишилися без можливості дістатися до місця призначення. Міністерство транспорту наклало штраф у розмірі 140 мільйонів доларів.
Southwest розробила цю систему самостійно, але припустилася помилки.
Така ситуація є типовою для логістики: команди розробників створюють і тестують систему на «ідеальному сценарії» за нормальних умов роботи (заплановані екіпажі, передбачувані погодні вікна, ресурси, доступні згідно з планом). Реальні логістичні операції — це саме це. Відмова від доставки, неявка перевізника, перенесення часу зустрічі на чотири години раніше — це 30–40 % щоденних операцій, а не поодинокі випадки.
Досвідчені операційні команди знають, що спочатку треба проектувати з урахуванням збоїв, бо вони неминучі, і коли вони трапляються, програмне забезпечення або справляється з ними, або стає вузьким місцем. Коли ви доручаєте роботу команді, яка не спеціалізується на логістиці, ви за замовчуванням отримуєте мислення, орієнтоване на «ідеальний сценарій», оскільки вони не знають, на які винятки слід враховувати при розробці.
Шаблон № 2: Розробники, яким бракує галузевих знань
Капітан, який завантажував контейнери, помітив, що його судно занурюється глибше й нахиляється сильніше, ніж очікувалося, тому він зателефонував планувальникам. Розробник розслідував ситуацію й виявив, що програмне забезпечення надсилало вагу брутто в систему, яка очікувала вагу нетто — помилка в 3 000 кг на контейнер. Те, що він тоді вважав «нудним логістичним програмним забезпеченням, де найгірше, що могло статися, — це втрата контейнера на день-другий», виявилося жорстким пробудженням.
Розробник не знав, чого він не знав, і це ще одна закономірність, яку ми спостерігаємо.
Логістичне програмне забезпечення взаємодіє з фізичним світом у спосіб, якого більшість розробників ніколи не бачить. Термінологія має значення (брутто проти нетто, тара проти корисного навантаження, об’єм проти щільності), але не менш важливі й операційні реалії: які обмеження ваги спричиняють інспекції Міністерства транспорту, як розподіл вантажу впливає на стабільність транспортного засобу, коли, здавалося б, незначна затримка призводить до пропущених вікон зустрічей у трьох штатах.
Якщо ви доручаєте розробку логістичного програмного забезпечення командам, які не мають галузевої експертизи, ви робите ставку на те, що вони задаватимуть правильні питання під час аналізу потреб. Більшість цього не робить.
Шаблон № 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 з оперативними викликами. Більшість клієнтів звертаються до нас з метою оптимізації витрат, тому економічні показники зазвичай мають пріоритет. Але ми рекомендуємо збалансувати їх у чотирьох категоріях.
| Структура КРІ для проєктів з логістичного програмного забезпечення | |
|---|---|
ОПЕРАЦІЙНА ЕФЕКТИВНІСТЬ
| ЕКОНОМІЧНІ ПОКАЗНИКИ
|
ЯКІСТЬ ОБСЛУГОВУВАННЯ
| ТЕХНІЧНІ ПАРАМЕТРИ
|
Операційна ефективність
- Рівень своєчасності доставки: відсоток доставок, здійснених вчасно
- Середній час доставки: середній час від завантаження до доставки
- Ефективність маршруту: співвідношення запланованого та фактичного маршруту
- Коефіцієнт завантаження: відсоток завантаження автопарку або водіїв
Економічні показники
- Вартість однієї доставки: загальна вартість доставки, поділена на кількість доставок
- Ефективність використання палива або пробігу: витрата палива або пробіг на одне замовлення
- Дохід на транспортний засіб/водія: дохід, отриманий на одиницю транспорту або водія
Якість обслуговування
- Відсоток невдалих доставок: відсоток доставок, які не вдалося здійснити з першої спроби
- Задоволеність клієнтів (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%.
- Створено веб- та мобільні додатки з функцією відстеження в режимі реального часу та внутрішньододатковою комунікацією.
Висновок
Для лідерів логістичної галузі, які оцінюють партнерів з розробки, питання полягає не в тому, «Чи зможуть вони вчасно виконати роботу?», а в таких деталях, як: «Чи розуміють вони, чому статус робочого часу водія може бути важливішим за оптимізований маршрут?»
У нашій компанії з розробки програмного забезпечення для логістики та транспорту ми з 2009 року створюємо індивідуальне програмне забезпечення, яке не відстає навіть тоді, коли операції працюють на межі можливостей. Якщо ми здаємося вам підходящим партнером, давайте обговоримо ваш проєкт.
