Руководитель логистики видит, что обещанный срок доставки прошёл, но последнее сообщение перевозчика устарело. Если считать время получения сообщения временем самого события, система объявит задержку доказанной. Если ждать следующего статуса без задачи и ответственного, исключение может остаться без реакции.
Рабочий результат контроля поставок другой: диспетчер получает одну конкретную задачу. В ней указаны поставка, план, последнее событие, время события и приёма, причина сигнала, ответственный и следующее действие. Такое правило помогает обработать исключение, но не доказывает физическую задержку до появления актуальных данных.
Какую задачу решает этот процесс
Представим ситуацию руководителя логистики. Поставка уже отправлена, обещанный интервал заканчивается, а в потоке событий нет свежего подтверждения доставки. Руководителю нужен не список всех грузов и не ещё один экран со статусами. Ему нужно понять, возникло ли исключение, кто его проверяет и на каких данных основано решение.
Процесс начинается после отправки. Он сравнивает план с событиями перевозчика, оценивает свежесть данных и создаёт диспетчеру задачу, когда требуется проверка. В задаче сохраняются доказательства сигнала: обещанный срок, код и время последнего события, время его получения, применённое правило и назначенный ответственный.
Граница материала — обработка исключений после отправки. Первичный сбор транспортной заявки разобран в отдельном руководстве. Здесь нет справочного трекера статуса заказа, планирования рейса, выбора транспорта или построения маршрута.
Какие данные и правила подготовить
Сначала зафиксируйте словарь полей. Для каждого поля нужны источник, владелец и правило обработки. Иначе одинаковое слово «время» может обозначать обещанный срок, момент события у перевозчика или момент, когда сообщение дошло до вашей системы.
| Поле | Обязательность | Источник | Кто отвечает | Правило |
|---|---|---|---|---|
| Поставка | Обязательное | Учётная запись отправки | Логистика | Использовать устойчивый идентификатор во всех событиях и задачах |
| Обещанный интервал | Обязательное | Согласованный план доставки | Логистика | Хранить начало и конец интервала либо явно заданный крайний срок |
| Перевозчик | Обязательное | Назначение на отправку | Логистика | Связать с поставкой и справочником контактов |
| Код события | Обязательное | Сообщение перевозчика | Перевозчик; за приём отвечает интеграция | Сопоставить с внутренним состоянием |
| Время события | Обязательное | Сообщение перевозчика | Перевозчик; формат проверяет интеграция | Не заменять временем получения |
| Время получения | Обязательное | Журнал интеграции | Технический контур | Использовать для расчёта задержки доставки события; свежесть оценивать на момент контроля |
| Ответственный | Обязательное | Матрица ответственности | Руководитель логистики | Назначать по типу исключения, направлению или перевозчику |
| Причина отклонения | Условное | Сообщение перевозчика или проверка диспетчера | Перевозчик либо диспетчер | Не выдумывать, если источник её не сообщил |
| Подтверждение получения задачи | Условное | Внутренний трекер | Назначенный сотрудник | Фиксировать отдельно от статуса груза |
| Фактическое местоположение | Неизвестное до проверки | Актуальный ответ перевозчика | Перевозчик | Не выводить из старого события |
| Новый ETA | Неизвестное до проверки | Новое событие или ответ перевозчика | Перевозчик | Не рассчитывать без согласованной модели и данных |
| Физическая причина задержки | Неизвестное до проверки | Подтверждение перевозчика | Перевозчик; проверяет диспетчер | Не подменять техническим диагнозом канала |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Короткий синтетический образец без клиентских данных:
| Поле | Условное значение |
|---|---|
| Поставка | D18 |
| Обещанный срок | до 16:00 |
| Перевозчик | «Перевозчик А» |
| Последнее событие | in_transit в 12:00 |
| Получено системой | в 17:00 |
| Ответственный | Анна, диспетчер |
| Причина сигнала | Срок прошёл, свежий статус не подтверждён |
| Подтверждение задачи | Ожидается во внутреннем трекере |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
До настройки также согласуйте часовой пояс, допустимые форматы времени и ключ повтора. Без этого два одинаково записанных часа могут относиться к разным зонам, а повторная доставка одного сообщения — создавать лишние инциденты.
Какие события нужны для контроля доставки
Названия перевозчиков различаются, поэтому внешние коды нужно переводить в небольшой внутренний словарь состояний:
| Внешний смысл | Внутреннее состояние | Действие контроля |
|---|---|---|
| Отправлено | Отправка подтверждена | Начать наблюдение после отправки |
| В пути | Перевозка продолжается | Проверить свежесть и обещанный интервал |
| Исключение | Требуется проверка | Обновить или создать один инцидент |
| Получено / delivered | Кандидат на закрытие | Проверить событие перед закрытием |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Точное соответствие кодов нельзя угадать по названию. Перед внедрением владелец процесса показывает реальные статусы перевозчика, а специалист логистики утверждает их внутренний смысл. Неизвестный код уходит человеку на разбор, а не автоматически приравнивается к задержке или доставке.
Актуальность определяется временем события, а не порядком прихода сообщений. Например, событие «в пути» от 12:00 может поступить после события delivered от 18:10 из-за задержки канала. Поздно принятое старое сообщение не должно откатить поставку из состояния «получено» обратно в «в пути».
Для защиты от повторов можно использовать составной ключ: идентификатор поставки, код события и время события. Повтор с тем же ключом обновляет техническую отметку получения, но не создаёт новую задачу. Если перевозчик присылает собственный идентификатор события, возможность использовать его проверяют отдельно.
Как выделить задержку и недоставку
Для решения нужны три независимые величины:
- задержка доставки события = время получения − время события;
- свежесть данных = контрольное время − время последнего события;
- контрольное отклонение = контрольное время − конец обещанного интервала.
Первая величина показывает, сколько сообщение шло от источника до системы. Вторая — возраст последних сведений в момент проверки. Третья — насколько контрольный момент вышел за пределы плана. Ни одна из них сама по себе не подтверждает местоположение груза.
Если в 17:00 система получила событие от 12:00 и сразу провела проверку, задержка доставки события и его возраст равны пяти часам. Если обещанный срок закончился в 16:00, контрольное отклонение равно одному часу. Корректный сигнал: «Срок прошёл на один час, актуальный статус не подтверждён». Некорректный вывод: «Груз точно опаздывает на пять часов».
Потеря связи и физическая задержка — разные исключения. При потере связи диспетчер проверяет канал, журнал приёма и контакт перевозчика. Физическую задержку подтверждает актуальное событие, новый ETA или ответ перевозчика. Недоставку также нельзя устанавливать только по отсутствию нового сообщения: сначала нужно исключить задержку обмена данными.
Уровни эскалации задаёт владелец процесса. Для учебного примера можно принять условные пороги:
- Событие старше двух часов — диспетчер проверяет источник и канал.
- Обещанный срок прошёл, а свежих данных нет — ответственному создаётся одна задача.
- Перевозчик подтвердил исключение или сообщил ETA позже плана — руководитель получает уведомление по согласованному правилу.
Это не отраслевые нормативы. Перед запуском пороги заменяют значениями заказчика с учётом интервалов поставки, расписания обмена и допустимого времени реакции.
Как закрыть отклонение с ответственным
На один инцидент нужна одна задача. Её ключ связывает поставку и тип отклонения, например D18 + пропущенный срок. Новые сообщения дополняют эту задачу: сохраняют историю событий, уточняют причину, меняют следующее действие. Они не создают отдельную задачу на каждый повтор статуса.
В задаче полезно хранить:
- доказательство сигнала: план, последнее событие и оба времени;
- назначенного ответственного и срок реакции;
- контакт перевозчика;
- подтверждённое следующее действие;
- результат проверки и основание закрытия.
Клиентский трекер и внутренний контроль решают разные задачи. Клиенту можно показывать согласованный статус доставки. Внутри компании остаются назначение сотрудника, срок реакции, журнал контактов и подтверждение выполнения. Эти сведения не нужно автоматически публиковать во внешнем трекере.
Статус delivered — только кандидат на закрытие. Человек или согласованное правило проверяет идентификатор поставки, время события, отсутствие более позднего конфликтующего события и подтверждение получения. Поздняя доставка закрывает инцидент с результатом «доставлено с задержкой», а не стирает историю отклонения.
Учебный пример: путь от входных данных до результата
Ниже — синтетический пример, а не клиентский кейс, файл или результат внедрения Switch On AI. Все обозначения, имена, пороги и значения времени условны.
Поставка D18 должна прийти до 16:00. Система в 17:00 получает последнее событие in_transit, созданное источником в 12:00, и сразу проводит проверку. Задержка доставки события и его возраст на момент контроля одинаковы: 17:00 − 12:00 = 5 часов. Затем система сравнивает контрольное время с планом: 17:00 − 16:00 = 1 час.
| Поставка | План | Событие источника | Свежесть | Отклонение | Ответственный |
|---|---|---|---|---|---|
| D18 | до 16:00 | in_transit: событие 12:00, принято 17:00 | 5 ч | +1 ч по контрольному времени; физическая задержка пока не подтверждена | Анна, диспетчер — условное имя |
| D18 | до 16:00 | delivered: событие 18:10, принято 18:15 | 5 мин | +2 ч 10 мин фактического опоздания | Анна, диспетчер — условное имя |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Промежуточное решение: проверить канал и запросить у перевозчика актуальное состояние. Поскольку обещанный срок уже прошёл, система создаёт один инцидент D18 с формулировкой «Срок прошёл на один час, актуальный статус не подтверждён». Доказательства внутри задачи: план до 16:00, последнее событие от 12:00, приём в 17:00.
Позднее приходит условное событие delivered: оно создано в 18:10 и принято в 18:15. Свежесть равна пяти минутам. Фактическое опоздание рассчитывается по времени доставки: 18:10 − 16:00 = 2 часа 10 минут.
Delivered не закрывает задачу автоматически. Диспетчер сверяет поставку D18, время события, отсутствие более позднего конфликта и подтверждение получения. После проверки тот же инцидент закрывается с результатом «доставлено с задержкой на 2 часа 10 минут». История первоначального сигнала сохраняется.
Как проверить результат перед запуском
Проверка должна охватывать нормальный путь, потерю свежести и позднее закрытие. Для каждого сценария заранее запишите ожидаемый результат, сигнал ошибки и действие человека.
| Сценарий | Ожидаемый результат | Сигнал ошибки | Действие человека |
|---|---|---|---|
| Свежее delivered до 16:00 | Инцидент задержки не создаётся; событие сохраняется | Сообщение не сопоставилось с поставкой | Проверить идентификатор и таблицу соответствия статусов |
| В 17:00 последнее событие датировано 12:00 | Создаётся одна задача о пропущенном сроке и устаревших данных | Появились дубли либо время приёма записано как время события | Проверить журнал и связаться с перевозчиком |
| Поздний delivered от 18:10 | Обновляется тот же инцидент; закрытие возможно после сверки | Задача закрылась автоматически без проверки | Подтвердить событие и записать фактическое отклонение |
Если таблица не помещается, прокрутите её вправо. С клавиатуры используйте стрелки.
Отдельно повторите одинаковое событие. Вторая доставка сообщения не должна создавать новую задачу или повторное уведомление. Затем передайте старое событие после более нового: внутреннее состояние не должно откатиться назад.
При проверке сопоставьте исходное сообщение, запись журнала и задачу. Время события и время приёма должны оставаться разными полями. Если код неизвестен или обязательное поле отсутствует, система передаёт ситуацию человеку и не выдумывает статус, ETA или причину.
Эта проверка относится к контролю исключений после отправки. Она не проверяет первичный сбор заявки и не включает планирование маршрута в предлагаемую услугу.
Что согласовать для внедрения
Готовый инструмент может закрывать отдельные части процесса: принимать события, приводить статусы к общему словарю, проверять свежесть, исключать повторы и ставить задачу. Но наличие таких компонентов не доказывает совместимость с конкретным перевозчиком. До выбора решения нужно проверить доступные статусы, API или другой канал обмена, права, форматы времени, частоту обновления и качество данных.
Собственная интеграция нужна, если готового подключения нет или его правила не соответствуют процессу. Её границы определяют после проверки данных и API. Тарифы, права доступа и ограничения внешних продуктов также сверяют отдельно; эта статья не подтверждает партнёрство, выполненный проект или совместимость с каким-либо вендором.
Switch On AI может разработать ИИ-помощника, бота или интеграцию для описанной операции. Формат зависит от действия сотрудника:
- интеграция принимает события, нормализует их и создаёт задачу по фиксированным правилам;
- бот даёт диспетчеру диалоговый способ запросить проверку или подтвердить следующее действие;
- ИИ-помощник может готовить сводку из разрешённых данных, но критические решения и правила эскалации остаются под контролем человека.
Цель такого проекта — чтобы диспетчер получал конкретную задачу по задержке с доказательством и ответственным. Объём можно обсудить на странице услуг Switch On AI. Прототип проверяет согласованный фрагмент сценария и не равен полноценному внедрению.
В этот объём не входят внедрение PIM, WMS, ITAM, ЭДО, электронного архива, Process Mining, полноценного B2B-портала, управление запасами, маршрутизация перевозок, корпоративное обучение и работа с 1С. Бухгалтерские, юридические, кадровые и отраслевые правила задаёт и проверяет специалист заказчика.
Покажите доступные статусы перевозчика — разберём одну операцию контроля задержки и согласуем прототип ИИ-помощника, бота или интеграции после проверки данных и API. Срок, состав работ и ожидаемый эффект можно определить только по вашим исходным данным; гарантированный результат или полное отраслевое внедрение здесь не обещаются.
Вопросы по этой задаче
Что считать задержкой?
Задержку определяют по согласованному плану и актуальному подтверждению. Само отсутствие свежего сообщения ещё не доказывает физическое опоздание. Сначала фиксируют, что срок прошёл и актуальный статус не подтверждён, затем проверяют канал или связываются с перевозчиком.
Как отличить недоставку от отсутствия данных?
Нужно хранить отдельно время события и время его получения. Старое событие показывает недостаточную свежесть данных, но не местоположение груза. Недоставку подтверждают актуальным событием, новым ETA или ответом перевозчика по согласованному правилу.
Кто закрывает инцидент?
Назначенный ответственный либо согласованное правило после проверки идентификатора поставки, времени события, отсутствия более позднего конфликта и подтверждения получения. Один статус delivered не должен автоматически стирать историю задержки.