Дві вантажівки, одна рампа й три версії плану
Уявімо підприємство, яке приймає та відвантажує товари через кілька постів. Диспетчер переносить рейс після дзвінка перевізника. Склад і далі працює за попереднім графіком, а охорона має список, надрукований уранці. Водій уже на місці, але замовлення ще не підготовлене.
Подальші дзвінки допомагають розв’язати ситуацію, але зміна впливає на наступні автомобілі й роботу рампи. Потрібна спільна картина: що заплановано, хто прибув, які товари готові та де реально можна почати обслуговування. Самого календаря бронювань недостатньо.
Що зупиняє роботу?
Початкова ситуація
Вільне вікно не означає вільні ресурси
Завантаження відрізняються тривалістю, обладнанням і вимогами. Два бронювання можуть не перетинатися в календарі, але все одно потребувати тієї самої бригади або навантажувача.
Зміну дізнається лише одна людина
Перевізник повідомляє про запізнення, але склад і прохідна досі бачать попередній час. Кожна команда ухвалює логічне рішення на основі свого плану.
Неготовність виявляється біля рампи
Автомобіль має підтверджене бронювання, але документи, товар або потрібне обладнання не готові. Проблему помічають лише тоді, коли вона вже блокує обслуговування.
Одне бронювання поєднує план і події на території
Бронювання містить замовлення, тип операції, вимоги, перевізника та часове вікно. Окремо фіксуємо готовність товару, прибуття, початок обслуговування та виїзд. Так запланований час не видається за інформацію про фактичний перебіг.
Кожна роль отримує власний погляд на той самий процес. Диспетчер керує планом, склад — підготовкою, а прохідна — прибуттями. Зміни зберігають автора й причину, щоб можна було пояснити послідовність обслуговування.
Так може виглядати новий процес
Забронюйте час відповідно до операції
Доступність визначають години роботи, можливості поста та погоджені обмеження. Нетиповий вантаж або операція з додатковим ресурсом можуть потребувати погодження планувальника.
Перевірте готовність до прибуття
Склад підтверджує підготовку товару, а система вказує на відсутні дані й документи. Диспетчер бачить ризик раніше, ніж приїде водій.
Зафіксуйте події та спрямуйте автомобіль
Прибуття не запускає завантаження автоматично. Прохідна реєструє автомобіль, а уповноважена людина спрямовує його до поста відповідно до поточної доступності й правил підприємства.
Завершіть обслуговування зі збереженням історії
Завершення фіксує фактичний час і відхилення. Запізнення, відсутність товару або технічна проблема мають окремі причини, щоб процес можна було аналізувати без здогадок.
План має вміти прийняти запізнення
Запізнілий транспорт не повинен просто пересувати всі наступні бронювання. Визначаємо допустимі відхилення, порядок ранніх прибуттів і повторного призначення вікна. Система може показувати можливі варіанти, але рішення, що впливають на контрагентів або пріоритети, можуть потребувати людини. Одночасне бронювання одного ресурсу має вирішувати система, а не черговість оновлення екранів.
- Скасування звільняє ресурси, зберігаючи історію бронювання.
- Транспорт без бронювання потрапляє до чітко позначеного окремого процесу.
- Закриття рампи показує пов’язані операції, які потрібно перепланувати.
Кожен бачить стільки, скільки потрібно для його роботи
Перевізник може керувати власними прибуттями без доступу до плану інших компаній. Охороні потрібні ідентифікація автомобіля та інструкції, а не вся комерційна документація. Керівник складу бачить готовність і навантаження постів. Обсяг даних водія, строк їх видалення та канали сповіщень визначаємо свідомо, а повідомлення на телефоні проєктуємо без потреби працювати із широкою таблицею.
Почнімо з одного фрагмента, який працює.
Перше впровадження варто обмежити одним об’єктом і одним типом операції. Спільний календар, підтвердження готовності та фіксація прибуття й виїзду дадуть змогу перевірити значення статусів. Автоматичні сповіщення, самостійні бронювання перевізників та інтеграцію зі шлагбаумом додаємо після погодження основних правил і відповідальності.
Як зрозуміємо, що стало краще?
Це план вимірювання, а не обіцянка результату. Початкові показники визначаємо до впровадження.
Час очікування та час обслуговування
Відокремлюємо очікування на території від самого завантаження. Порівнюємо результати за типом операції, рампою та умовами, щоб не змішувати зовсім різні перевезення.
Причини змін у плані
Відстежуємо, які бронювання змінювалися й чому. Це дає змогу відрізнити запізнення перевізника від відсутності товару або проблем із доступністю поста.
Якість підготовки
Перевіряємо, скільки автомобілів прибуло без підтвердженої готовності та як рано виявили нестачу. Заповнений календар сам по собі не свідчить про злагоджену роботу.
Запитання, які варто поставити
Чи можуть перевізники самі обирати час?
Так, у відкритих для них межах. Бронювання може враховувати тип транспорту, дозволені пости й обмеження операції. У нестандартній ситуації краще передати запит планувальникові, ніж відкрити вікно, яке підприємство не зможе обслужити.
Чи потрібно відразу інтегрувати систему з ERP і прохідною?
Ні. Пілот може початися з ручного підтвердження подій в одному застосунку. Інтеграції добираємо за якістю даних та очікуваним ефектом. Потрібно визначити джерело статусу, поведінку під час збою й спосіб уникнути подвійної реєстрації операцій.
