В умовах інфраструктурного стресу, коли термінали переходять на генерацію, ваша маржа випаровуватиметься миттєво, адже в бюджеті тепер з'явиться непередбачувана стаття витрат – амортизація генераторів та логістика самого дизеля. Тож, якщо ваша система для управління продажами завантажує інформацію про затримку на кордоні в 120 годин не в режимі реального часу, ви швидко втратите ліквідність.
Що саме змінюється в управлінні логістикою
Логістичні компанії десятиліттями розробляли стратегії на 3-5 років наперед. Сьогодні ж в українських реаліях цей підхід може призвести до ще більших збитків, ніж постійно зростаючі податки та ціни на пальне. Річ у тім, що логістика остаточно перейшла в режим сценарного управління й потребує створення динамічного дерева рішень, де кожна гілка ризикує бути відрубаною інфраструктурним колапсом кожної миті. Наприклад, “найліпший маршрут” може перетворитися на пастку через незаплановане закриття мостів або ракетну загрозу.
Раніше планування спиралося на екстраполяцію: компанії спиралися на те, що відбувалося вчора й передбачали завтра. Але коли інфраструктура нестабільна, минуле вже не є релевантним джерелом інформації. Ба більше, в теперішні часи немає сенсу шукати найліпший варіант розвитку подій - треба шукати той, який принесе найменші втрати при найгіршому сценарії.
Який висновок? Якщо ваша платформа для бізнесу не пропонує 10,000+ варіантів розвитку подій за хвилину, ви, зрештою, гадатимете на кавовій гущі під світлом ліхтарика. Сучасна система повинна пропонувати цілий набір альтернативних маршрутів із розрахованим індексом ризику для кожної. Ось три основних принципи, які лягають в її основу:
Децентралізоване прийняття рішень. В реаліях, де затримка зв'язку через відсутність мережі може сягати годин, централізоване управління стає точкою вразливості. Тож, куди раціональніше переносити важливі обчислення саме на периферійні пристрої.
Використання локальних серверів. На великих хабах локальні сервери дозволяють водіям та операторам складів отримувати змінені протоколи дій від локальних вузлів, не чекаючи відповіді від центрального (зазвичай - хмарного) сервера, який опинився в мертвій зоні. Наприклад, ми створюємо системи, де кожен складський термінал є автономним обчислювальним вузлом, маючи достатньо даних та алгоритмічної бази, щоб діяти самостійно в умовах відімкненості від решти мережі.
Миттєве самовідновлення. Ви роками оптимізували бюджети, позбуваючись “зайвих” складів та співробітників? Сьогодні, без відмовостійкого ПЗ це призведе до повної зупинки ваших бізнес-процесів. Тож, якщо ваша система не здатна тримати удар і миттєво саморегенеруватися, ви автоматично опиняєтесь позаду ваших конкурентів.
Звідси випливає неочевидний висновок: те, що раніше здавалося надмірним, сьогодні перетворюється на капіталізацію виживаності вашого бізнесу. Тобто, виграє не той, хто привіз найдешевше, а той, хто привіз взагалі, поки інші стоять.
Роль цифрових рішень
Більшість логістичних компаній хибно вважають, що купівля ліцензії на хайпове SaaS-рішення допоможе їм автоматизувати все від “А до Я” й працювати безвідмовно в будь-якому середовищі.
Водночас наш досвід демонструє зовсім інше - річ у тім, що стандартні ERP та TMS-системи проєктуються для умов, де стабільний інтернет наявний за замовчуванням і не вважається за щастя, доступне лише в перервах між відключеннями; ба більше, майже всі такі системи мають або монолітну архітектуру, або архітектуру на базі мікросервісів, з щільною прив'язкою одне до одного. І, як тільки інфраструктура бізнесу, що використовує такі системи, починає збоїти (наприклад, з причини зникнення зв'язку між складом і центральним сервером або митним API), система припиняє працювати. Вона намагається завершити транзакцію, блокує базу даних і створює чергу з процесів, які неможливо завершити. І, навіть коли світло з'явиться, таке ПЗ продовжить ще якийсь час виснути, будучи не здатним швидко обробити накопичені помилки.
В цих випадках рятує розробка спеціалізованого ПЗ, яка полягає в реалізації локальних рішень на базі архітектури, що здатна синхронізуватися відразу, як тільки доступ до центрального хабу відновиться. Тобто, логістична платформа має працювати як месенджер: накопичувати дані локально на кожному вузлі й синхронізувати їх тоді, коли з’являється зв’язок.
Ще одна типова проблема - це розрив між логістикою та продажами. Готові системи для управління продажами часто працюють майже автономно, допускаючи інтеграцію лише з обмеженою кількістю сторонніх рішень. З цієї причини клієнти часто отримують хибні обіцянки щодо дати доставки (наприклад, завтра), коли реальний ланцюг поставок вже котру добу стоїть у заторі на митниці.
В протилежність їм, розробка програмного забезпечення з нуля спрямована на створення єдиного джерела істини - інформаційної бази, дані з якої автоматично оновлюватимуться на всіх вузлах цифрової інфраструктури конкретної компанії. Таким чином, затримка на кордоні, зміна температурного режиму в контейнері або будь-що інше миттєво спричинить релевантне оповіщення відповідальним відділам. А значить, з кастомною розробкою веб-платформи, ви отримаєте у своє розпорядження справжній ситуаційний центр, де ваші співробітники зможуть побачити симуляцію того, що станеться за кілька годин або навіть діб.
Гнучкість vs оптимізація
В той час, як більшість логістичних компаній роками оптимізували “останню милю” задля скорочення витрат на паливо на 1.5-2 відсотки, в умовах нестабільної інфраструктури ця набута економія вщент зруйнується при першому ж блекауті. То що ж краще в теперішніх реаліях - оптимізація чи таки гнучкість?
Насправді це питання риторичне. Оптимізація зазвичай означає позбавлення від надмірності - тобто, додаткових складів, запасних водіїв, дублюючих серверів тощо. Але, стикаючись із логістичним хаосом, саме ця надмірність (запас палива на тиждень, дублювання кадрів на випадок мобілізації або обстрілів, дзеркальні сервери в різних регіонах тощо) надає бізнесу свого роду страховий поліс у вигляді здатності до миттєвої переконфігурації.
Не менш важливим є й зміна того, від чого завжди відштовхувалися оптимізаційні стратегії - KPI. Якщо раніше основним KPI вважалася ціна за кілометр, сьогодні куди доцільніше використовувати метрики, які набули актуальності ще під час пандемії COVID-19, на кшталт:
Time to Recover, що визначає, скільки хвилин/годин потрібно системі, щоб відновити відвантаження після повного відключення живлення та зв’язку - за міжнародними стандартами ця метрика не повинна перевищувати 15 хвилин;
Elasticity Ratio, яка ідентифікує, чи здатна система масштабувати ресурси компанії у відповідь на різку зміну попиту або блокування шляхів;
Data Integrity Lag, тотожна часу між реальною подією та її відображенням у платформі для бізнесу в умовах поганого зв’язку;
Route Survival Index, що вираховується відсотками успішно завершених рейсів за умов активних інфраструктурних обмежень;
Shadow Logistics Latency, що означає час, який витрачається на ручну координацію процесів, коли автоматизація не працює.
Зважаючи на все це, можна зробити висновок, що гнучкість може потребувати перебудови (часом - радикальної) існуючої ІТ-архітектури, в серці якої лежить модульне ПЗ. В ньому, за потреби, завжди можна вимкнути частину бізнес-логіки, яка з якихось причин не працює, й перейти на ручні протоколи без зависання всієї системи.
Висновки
Нестабільність - не баг, а фіча нашої реальності, яка змінює фокус залежності логістичних компаній: теперь він полягає не у транспорті, а в ефективній ІТ-інфраструктурі. А отже, інвестиції у кастомну розробку платформи для бізнесу стають ледь не єдиним способом не стати банкрутом. Тож, ласкаво просимо в епоху алгоритмічного виживання, де місце під сонцем займають лише ті, в кого софт розумніший за обставини.
