Марія БровінськаAgroTech
10 вересня 2026, 15:41
2026-09-10
Як «Кернел» зробив транспортні потоки на виробничих об’єктах прогнозованими за допомогою TransitHUB
Ще кілька років тому вночі під елеваторами «Кернел» стояли черги із зерновозів — десятки машин одразу. Водії ночували в кабінах, а охоронець із ліхтариком рахував машини і слідкував, щоб ніхто не проскочив уперед. Вантажівка могла простояти під воротами до трьох діб: перевізник у цей час не заробляв, компанія переплачувала за простій, закладений підрядниками в тариф, а підприємство не розуміло, коли саме приїде сировина.
Сьогодні цієї картини більше немає. Але, як з’ясувалося, прибрати живу чергу виявилося набагато складнішою задачею, ніж просто «зробити бронювання слотів». За понад шість років внутрішня платформа «Кернел» для управління транспортною логістикою — TransitHUB — з простого інструменту електронного запису виросла у виробничу систему високої критичності, від якої залежить приймання й відвантаження на 30 елеваторах, 6 заводах і 5 терміналах, а користуються нею близько 50 000 водіїв.
Ще кілька років тому вночі під елеваторами «Кернел» стояли черги із зерновозів — десятки машин одразу. Водії ночували в кабінах, а охоронець із ліхтариком рахував машини і слідкував, щоб ніхто не проскочив уперед. Вантажівка могла простояти під воротами до трьох діб: перевізник у цей час не заробляв, компанія переплачувала за простій, закладений підрядниками в тариф, а підприємство не розуміло, коли саме приїде сировина.
Сьогодні цієї картини більше немає. Але, як з’ясувалося, прибрати живу чергу виявилося набагато складнішою задачею, ніж просто «зробити бронювання слотів». За понад шість років внутрішня платформа «Кернел» для управління транспортною логістикою — TransitHUB — з простого інструменту електронного запису виросла у виробничу систему високої критичності, від якої залежить приймання й відвантаження на 30 елеваторах, 6 заводах і 5 терміналах, а користуються нею близько 50 000 водіїв.
Чому жива черга — це не про незручність, а про гроші
На перший погляд задача звучить просто: замість живої черги — електронна, водій реєструється і чекає виклику. Але жива черга — це не лише незручність для водія. Це ще й хронічна відсутність прогнозу.
У живій черзі водієві недостатньо просто приїхати — свою позицію ще треба «захищати»: стежити за рухом, не пропустити момент виклику, бути готовим відстоювати місце, якщо хтось намагається проскочити вперед. Для перевізника це проблема ефективності автопарку: поки машина стоїть у невизначеній черзі, складно спрогнозувати, коли вона звільниться для наступного рейсу. А для самого підприємства проблема ще ширша — біля КПП видно лише факт прибуття машин, але немає розуміння, скільки транспорту ще в дорозі, з яким вантажем і коли він прибуде.
Один рейс очима водія
Робота з системою для водія починається задовго до прибуття на об’єкт. Він створює рейс, фіксує виїзд, додає інформацію про перевезення — і машина стає «видимою» для системи підприємства ще до того, як фізично приїде на КПП.
Це дозволяє перевіряти документи заздалегідь. Водій завантажує ТТН (товарно-транспортну накладну) зі смартфона, і документ одразу йде на віддалену перевірку відповідальним працівникам підприємства — верифікація відбувається до прибуття, а не після. Якщо в документах є помилка, її можна виявити ще до того, як вантажівка фізично приїде, і не витрачати на це час на КПП.
Коли машина потрапляє у визначену геозону, водій реєструється в електронній черзі. Система при цьому працює не лише з фактом прибуття, а й з майбутнім потоком — розуміє, які машини вже в дорозі й коли їх очікувати. І працює це в обидва боки: на всіх заводах «Кернел» та на частині елеваторів TransitHUB використовується не лише для приймання врожаю, а й для відвантаження — синхронізуючи транспорт із виробничою готовністю, точками навантаження та потрібним моментом виклику.
Мультичерга: одна фізична, кілька логічних
Одна з функцій, яка найкраще показує різницю між живою чергою й TransitHUB, — мультичерга. Фізично на підприємстві може бути один потік машин, але з погляду виробництва цей потік розгалужується на кілька логічних черг — наприклад, за вантажем, перевізником чи поклажодавцем, який дає товар на зберігання, — і для кожного система задає власний темп проходження.
Тому машина, що зареєструвалась десятою, у певній виробничій ситуації може поїхати раніше за ту, що стоїть першою — якщо саме її вантаж потрібен виробництву прямо зараз. Електронна черга тут працює не як простий FIFO-список: порядок підлаштовується під поточну виробничу ситуацію, яка за день може мінятися неодноразово.
Для водіїв ця логіка не завжди інтуїтивна: типова реакція — «як це так, я стою першим, а машина, що приїхала пізніше, поїхала раніше». Це стало окремим продуктовим інсайтом команди: недостатньо побудувати правильний алгоритм — його логіка має бути зрозумілою користувачеві, інакше водії просто засипають підтримку й диспетчерів запитаннями.
Диспетчер нікуди не зник — але його робота змінилась
Тут доречна аналогія з авіадиспетчером: значна частина процесів в аеропорту автоматизована, але без людини літаки не сідають і не злітають. Так само в TransitHUB диспетчер працює з цифровим інтерфейсом і формалізованими правилами, але саме він керує винятками й приймає операційні рішення: викликає машини на навантаження чи розвантаження, окремо або групами, залежно від виробничої потреби.
Якщо викликана машина не приїхала вчасно — диспетчер повертає її в кінець черги. А ще система дозволяє службове переміщення на початок черги (наприклад, через вимоги служби безпеки) — і кожна така дія логується та публікується у відповідному каналі об’єкта, щоб водій міг побачити, чому саме його позиція в черзі змінилась. Формується свого роду аудиторський слід, який дозволяє відновити логіку зміни черги постфактум.
Цифровий формат диспетчеризації дав компанії й дещо непередбачуване: більше не потрібен окремий диспетчер на кожному об’єкті. Один фахівець або централізована група може віддалено керувати чергами одразу на кількох підприємствах — на практиці одна централізована команда вже обслуговує всі термінали цілого регіону.
Софт починається не з кнопки «створити чергу», а з карти місцевості
Впровадження TransitHUB на новому об’єкті стартує не з налаштування системи, а з аналізу фізичної логістики: команда разом із підприємством вивчає під’їзди, місця можливого накопичення транспорту, доступні стоянки, АЗС, маршрути руху — і лише потім проєктує геозону й буферну зону.
Геозона — це не універсальний радіус навколо об’єкта, а зона, розмір якої визначається реальною географією місцевості й тим, де водій може безпечно й комфортно чекати виклику. У деяких випадках це десятки кілометрів від самого підприємства — водій чекає не на узбіччі перед КПП, а на стоянці, АЗС чи в іншому придатному місці. Окремо проєктується буферна зона — проміжна точка, куди машина під’їжджає після виклику перед безпосереднім заїздом.
Виклик — це не дзвінок «під’їжджайте», а регламент
Для кожного об’єкта налаштований власний регламент прибуття після виклику — прив’язаний, зокрема, до географії геозони: якщо точки очікування розташовані за десятки кілометрів, водію потрібно дати реалістичний час на дорогу. Повідомлення про виклик іде одразу кількома каналами — push, Telegram, SMS і голосовий дзвінок, який може повторюватись автоматично до п’яти разів, якщо водій не відповідає. На відміну від живої черги, увесь цей час водій може нормально відпочивати, а не тримати позицію під ворітьми.
Якщо виникає суперечка щодо запізнення, у системі лишається цифровий слід: коли відправлено повідомлення, чи отримав його водій, чи відповів на дзвінок і коли саме сталася подія. У диспетчерському інтерфейсі етапи процесу підсвічуються зеленим, жовтим і червоним — від нормального перебігу до порушення регламенту, — тож увага диспетчера концентрується саме на відхиленнях, а не на рутинних рейсах, які система обробляє автоматично.
Що під капотом
Для водія TransitHUB — це кілька екранів у смартфоні. За ними — production-система з бекендом на Oracle APEX + PL/SQL, базою даних Oracle Autonomous Database, вебом на JavaScript + Vue.js і мобільним застосунком: Android уже в проді, iOS на Flutter — у розробці. Інфраструктура працює через Cloudflare, а над стабільністю системи окремо працює DevOps-напрям.
Цільовий SLA доступності TransitHUB — 99,8%, і це не формальна метрика. Раз на два роки система проходить зовнішній penetration test: незалежні фахівці шукають вразливості, класифікують їх за критичністю, а після усунення проводиться повторна перевірка.
Річ у тім, що для TransitHUB немає швидкого «ручного режиму». Як пояснює Максим Чайка, керівник ІТ-проєктів логістики «Кернел»: «Після переходу на електронну чергу змінюється сама операційна модель: машини більше не стоять перед воротами, а розосереджені в геозоні й рухаються за цифровими правилами. Якщо система стає недоступною, ми не можемо за кілька хвилин повернути старий порядок — потрібно заново координувати транспорт, повідомляти водіїв і фактично відновлювати процес. Тому стабільність TransitHUB — це не питання зручності ІТ-сервісу, а одна з умов безперервності приймання вантажів».
Найважче — не написати систему, а змінити звички людей
В умовах війни середній вік водіїв помітно зріс, а разом з ним зросла й частка користувачів, яким складніше швидко адаптуватися до цифрових інструментів. Тому підтримка тут — не формальний helpdesk, а частина щоденної експлуатації: перша лінія напряму працює з водіями й диспетчерами, допомагаючи з реєстрацією, рейсом, чергою. Звернутись можна, зокрема, через Telegram-бот; підтримка працює щодня з 7:00 до 22:00.
Технічне налаштування нового об’єкта сьогодні, після понад шести років роботи над продуктом, займає орієнтовно один-два робочих дні — але це не строк повного впровадження. Значно складніше — змінити звичний спосіб роботи людей. Як каже В’ячеслав Мельник, координатор із розвитку сервісу TransitHUB: «Перейти на електронну чергу — це не просто почати працювати в новому інтерфейсі. Потрібно змінити саму парадигму роботи. Люди роками звикали керувати живою чергою певним способом, і ці звички не зникають у момент запуску системи. Жива й електронна черги не можуть повноцінно працювати одночасно. Іноді саме робота з людьми на місцях стає одним із найскладніших етапів впровадження».
Окремий клас задач створюють умови, яких не було в початкових сценаріях: під час роботи засобів РЕБ GPS-сигнал може блокуватися або спотворюватись, тож система не може надійно визначити геолокацію водія. Для таких об’єктів у TransitHUB передбачили можливість вимикати перевірку геозони там, де РЕБ робить GPS-позиціонування ненадійним, — щоб зовнішнє технологічне обмеження не зупиняло операційний процес.
Що далі: врожай і перший зовнішній клієнт
Команда TransitHUB зараз пілотує новий сценарій — координацію транспорту під час навантаження в сезон збору врожаю, коли потрібно керувати машинами між кількома точками завантаження в різних населених пунктах одночасно. Ситуація там змінюється разом із темпом збору врожаю й погодою: на одній точці транспорту може накопичитись забагато, тоді як на іншій його бракує. Завдання пілота — бачити такі дисбаланси й оперативно перерозподіляти транспорт між точками.
А ще після понад шести років внутрішньої експлуатації TransitHUB почав пропонуватися зовнішньому ринку як SaaS-рішення. Разом із самим продуктом клієнт отримує накопичену експертизу з управління транспортним потоком — як будувати логіку черг, працювати з геозонами й буферами, налаштовувати регламенти. Операційна підтримка також лишається на стороні команди «Кернел»: клієнту не потрібно окремо будувати сервісну інфраструктуру навколо продукту.
Наразі команда проходить перше впровадження для зовнішнього комерційного клієнта — великого українського агрохолдингу — і готується до переходу в production. Після запуску команда планує окремо розповісти про цей кейс: як відбувалося підключення, з якими складнощами зіткнулися і які результати отримали в реальній експлуатації.
