Водій повідомив про закритий в’їзд, диспетчер переслав повідомлення колегам, клієнт очікує доставку за початковим графіком. Інформація вже є, але рішення ще ніхто не прийняв. Керівнику транспортної операції потрібна черга винятків, у якій видно власника, вплив на замовлення та наступну дію. Нижче пропонуємо модель такої роботи на умовному рейсі: вона задає відповідальність і перевірки, а не універсальні строки реагування.
Відокремте сигнал від операційного рішення
В умовному прикладі автомобіль везе шість палет до магазину. О 09:10 водій повідомляє, що погоджений в’їзд перекрито; вікно приймання триває до 10:00. TMS містить заявку та контакт одержувача, телематика показує місце автомобіля, а WMS підтвердила відвантаження. Жодне з цих джерел окремо не відповідає, чи можна використати інший в’їзд і чи встигне склад прийняти вантаж.
Створіть задачу з ідентифікатором рейсу, конкретною зупинкою, типом перешкоди та початковим доказом. У запропонованій моделі час виявлення, час реєстрації та час прийняття роботи — різні поля. Диспетчер підтверджує прийняття, перевіряє контакт і визначає наступний крок. Автоматичне призначення на групу ще не означає, що хтось почав діяти.
EPCIS від GS1 відокремлює час події від часу запису в репозиторії. Ця різниця корисна і для нашої черги: повідомлення може надійти пізніше за саму перешкоду. Пропонована операційна модель не вимагає впроваджувати EPCIS, але використовує розділення часу, щоб запізнілий сигнал не виглядав новою подією і не приховав втрату часу.
Джерела: [1]
Надайте власнику повноваження і маршрут ескалації
Диспетчер перевіряє альтернативний в’їзд з одержувачем. Якщо зміна не змінює договірної обіцянки та не потребує додаткової оплати, він може діяти в межах затверджених повноважень. Якщо потрібне перенесення вікна або платне очікування, задача передається тому, хто має право погодити саме цю зміну. Передача містить варіанти, їх наслідки, потрібне рішення та строк, після якого варіант втрачає сенс.
Для прикладу команда встановила наступну перевірку на 09:25. Це умовний робочий строк, а не галузева норма. Коли до нього немає рішення, система сповіщає чергового керівника. Водночас початкова обіцянка клієнту до 10:00 не пересувається автоматично. У журналі окремо зберігається прогноз, погоджене нове вікно та особа, яка повідомила клієнта.
Пауза потребує причини, власника очікуваної відповіді й часу повторного огляду. Очікування клієнта не скасовує ризик доставки та не зупиняє всі годинники одночасно. Вкажіть, які внутрішні строки враховують робочий календар, а які вимірюють календарний час. При зміні чергового підтверджуйте передачу відкритих задач; неприйняті задачі повертаються керівнику зміни.
Зберіть докази без дублювання задач
Телематика, повідомлення водія та дзвінок клієнта можуть описувати ту саму перешкоду. Пов’язуйте їх із чинною задачею за рейсом, зупинкою та типом проблеми, а суперечливі факти залишайте видимими. Не об’єднуйте автоматично різні пошкодження або різні адреси лише тому, що вони виникли близько в часі. Після закриття повторний сигнал має пройти перевірку: це запізнілий запис чи нова проблема.
OpenAPI описує контракт HTTP API, зокрема запити та відповіді. Контракт обміну для задачі потрібно доповнити бізнесовими правилами: стабільним ідентифікатором повідомлення, версією зміни, дозволеними переходами та поведінкою при повторі. Сам опис API не визначає, хто може погодити перенесення доставки. Це рішення власника процесу, яке команда має реалізувати та перевірити.
На час недоступності TMS передбачте контрольований резервний журнал із локальним ідентифікатором і відповідальним. Після відновлення інтеграція звіряє журнал із чергою, а диспетчер підтверджує нерозпізнані збіги. Зберігайте первинне повідомлення, результат перевірки, вибраний варіант і підставу закриття. Технічна доставка повідомлення не повинна автоматично завершувати операційну задачу.
↔ Прокрутіть таблицю горизонтально
| Стан | Власник | Перевірка |
|---|---|---|
| Сигнал зареєстровано | Черговий диспетчер | Прийняти або передати задачу |
| Потрібне погодження | Уповноважений керівник | Рішення та строк його чинності |
| Перешкоду усунуто | Диспетчер | Факт відновлення і повідомлення |
| Залишилась спірна доплата | Фінансовий менеджер | Окреме рішення за витратою |
Джерела: [2]
Закривайте наслідок і перевіряйте роботу черги
У прикладі одержувач підтверджує інший в’їзд, автомобіль прибуває, а приймання завершується в погодженому вікні. Диспетчер перевіряє подію приймання та документ, після чого закриває перешкоду. Якщо виникла доплата за очікування, її розгляд лишається окремою пов’язаною задачею фінансів. Так операційне завершення не маскує відкритий грошовий наслідок і не блокує вже відновлену доставку.
Приймальний тест повинен відтворити повтор сигналу, неприйняте призначення, пропущений строк, зміну диспетчера та пізнє надходження документа. Перевірте, що клієнт отримав лише актуальне погоджене повідомлення, а нова зміна не стерла попередньої обіцянки. Збережіть усі тестові ідентифікатори та журнал переходів. Керівник зміни підписує результат лише після перевірки черги під своєю робочою роллю.
Для контролю рахуйте частку задач без прийнятого власника серед усіх відкритих на поточний момент. Вік неперевіреної задачі — поточний час мінус час її реєстрації; після першої змістовної перевірки задача виходить із цієї вибірки. Кількість повторних відкриттів групуйте за причиною за завершену зміну. Джерело — журнал переходів, власник — керівник зміни. Частку оновлюйте при зміні задачі, вік — щохвилини, повторні відкриття — після завершення зміни. Це запропонована частота контролю. Пороги встановіть після вимірювання власної операції; перевищення має запускати перевірку навантаження та повноважень.
Контрольний список
- Визначте ключ винятку та правила приєднання повторних сигналів.
- Призначте власника рішення, його заступника та підтвердження прийняття роботи.
- Розділіть строк наступної дії, прогноз і погоджену обіцянку клієнту.
- Перевірте резервний журнал, відновлення та докази закриття на умовному рейсі.
Запитання та відповіді
Чи можна залишити повідомлення в робочому чаті?
Чат може залишатися каналом сигналу. Посилання на повідомлення додають до задачі, де зберігаються відповідальний, строк, рішення та результат. Саме задача є контрольним записом.
Хто вирішує, чи повідомляти клієнта?
Власник процесу визначає умови повідомлення та уповноважену роль. Диспетчер готує перевірені факти й варіант дії; непогоджений прогноз не слід видавати за нову обіцянку.