Кейс

Завершено

KRPK Fleet — планування рейсів, водіїв і автопарку

Коли логістика компанії тримається на пам’яті однієї людини

KRPK Fleet — тиждень рейсів за маршрутами й днями, поруч рейтинг водіїв на заміну
Клієнт
Хлібозавод із 23 маршрутами доставки у трьох областях
Масштаб
20+ машин щодня, близько 180 призначень «водій — машина — рейс» на тиждень
Роль
Бізнес-аналітик, .NET-розробник
Розгортання
Працює в локальній мережі підприємства, без доступу до інтернету

Задача

Хлібозавод щодня відправляє понад двадцять машин на 23 маршрути доставки у трьох областях. Виїзди — з 3:30 до 6:30 ранку, за тиждень набирається близько 180 призначень «водій — машина — рейс».

Графік жив у п’яти пов’язаних Excel-таблицях: тижневий розклад рейсів, закріплення машин, річний розподіл, схема гаража та матриця допусків водіїв. Таблиці розійшлися між собою: один і той самий водій у різних таблицях числився на різних машинах, назви маршрутів мали по два-три написання, частина формул зламалася.

Але справжня проблема була не в таблицях. Правил підбору водія на заміну не існувало ніде. Хто знає який маршрут, яка машина фізично вмістить замовлення, хто може їхати сам, а кому потрібен супровід, — усе це трималося в головах двох-трьох працівників. Коли водій о шостій ранку дзвонив і казав, що не вийде, перекрити рейс міг лише той, хто пам’ятав ці правила.

Власник сформулював мету просто: щоб перепланувати графік міг будь-хто.

Рішення

Аналіз до розробки

Робота почалася з розбору наявних файлів. Він виявив те, чого компанія не бачила:

  • три маршрути обслуговували лише два водії, і другим на всіх трьох був той самий підмінний водій, тож його відсутність не лишала жодного резерву;
  • на один маршрут у матриці не було жодного водія з допуском, хоча він виходив щодня;
  • водій, якого вважали звичайним, мав допуск до десяти маршрутів і ніколи не залучався до підмін;
  • місткість машини була жорстким обмеженням лише на одному маршруті з 23, але там вона відсікала три чверті автопарку.

Ці висновки змінили проєкт. Систему будували не як зручнішу таблицю, а як спосіб перенести знання з пам’яті людей у базу даних.

Графік як робоче полотно

Головний екран повторює звичну для замовника структуру: маршрути — рядками, дні — стовпцями, у кожній клітинці водій і машина. Можна дивитися один тиждень, два-три тижні або цілий місяць.

Незакриті рейси підсвічуються окремо від днів, коли маршрут не ходить. Це різні ситуації, і плутанина між ними коштувала компанії зірваних виїздів. Підмінні водії автоматично отримують власний колір. Раніше менеджер зі збуту щотижня фарбував клітинки вручну, щоб на око перевірити, що ніхто не записаний у двох місцях одночасно.

Шаблони з циклами

Типовий тиждень задається шаблоном, і з нього генерується графік на будь-який період наперед. Частина маршрутів працює за двотижневим циклом, коли вихідні чергуються між двома водіями. Шаблон — це набір рівноправних позицій, а не «основний водій плюс винятки», тож такі ротації не потребують додаткових правил. Маршрути, що ходять через день або лише в певні дні, працюють на тому самому механізмі.

Підбір заміни

Це ключовий сценарій. Клік по незакритому рейсу відкриває панель кандидатів, відсортованих за придатністю. Для кожного видно оцінку знання маршруту, його машину, завантаження на тиждень і пояснення звичайною мовою: «був раз-два, потрібен супровід», «зайнятий: Умань-1», «не вміститься: 139 ящиків, максимум 100».

Придатність рахується для водія разом із його машиною. Людина може знати маршрут, але не взяти його, бо машина замала. Кандидати, які не підходять, не ховаються, а показуються приглушено з причиною, тож видно, що варіант розглядали.

Водії розбиті на черги залучення: штатні підмінні, вільні постійні водії та крайній випадок. Керівник, якого кличуть лише в аварійних ситуаціях, ніколи не опиниться на початку списку, але лишається доступним.

Система, яка попереджає

Перевірки працюють на двох рівнях. Червоний блокує дію: водій не знає маршруту, машина в ремонті, замовлення не вміщається. Жовтий попереджає, але дозволяє: сьомий робочий день поспіль, завантаження близьке до межі, потрібен супровід.

Система показує й наслідки. Якщо водія зняти з власного маршруту, на тому маршруті одразу з’являється незакритий рейс, і система прямо про це каже. Проблема не зникла — вона перемістилася, і тепер це видно.

Будь-яку дію можна скасувати одним кроком, а кожна зміна записується в журнал з автором і часом.

Аналітика ризиків

Окремий екран рахує покриття кожного маршруту — скільки водіїв можуть їздити на ньому самостійно — і показує, які маршрути лишаться без резерву, якщо відсутня конкретна людина. Цей екран дав керівництву картину, якої не показувала жодна таблиця.

Робота з неповними даними

Систему розраховано на довідники, що заповнюються поступово. Відсутня місткість не означає «нічого не вміщається», а відсутнє завантаження — не нуль: перевірка просто пропускається, а все інше працює далі. Завдяки цьому систему запустили ще до того, як зібрали всі характеристики автопарку.

Результат

Графік більше не існує у вигляді п’яти суперечливих таблиць. Щотижневе ручне фарбування, підрахунок робочих днів і звірку аркушів замінив один робочий простір, де незакритий рейс видно одразу, а система сама пропонує заміну.

Знання, які раніше жили в пам’яті кількох працівників, тепер у базі даних і показуються саме в момент ухвалення рішення. Перепланувати графік може будь-який працівник, а не лише той, хто пам’ятає всі правила.

Керівництво вперше побачило, наскільки логістика залежала від окремих людей, і отримало інструмент, що постійно вимірює цей ризик.

Технології

ASP.NET Core MVC Entity Framework Core Microsoft SQL Server Clean Architecture CQRS JavaScript HTML CSS

Інші кейси

Контакт