Сначала задайте вопрос таблице, а не модели
Задача разбора — не угадать, кто виноват, а понять, где именно процесс потерял время и какие сведения это подтверждают. Для одной строки поставки соберите идентификатор заказа, обещанную и фактическую даты, дату последнего подтверждения, текущий статус, код товара, перевозчика и ссылку на документ-основание. Не включайте телефоны, домашние адреса и личную переписку, если для анализа достаточно статуса или служебного письма. Если разные системы используют разные номера заказа, сохраните оба идентификатора и отдельно отметьте правило их сопоставления.
Подготовьте данные так, чтобы модель не склеила разные события
Перед загрузкой приведите даты к одному часовому поясу и формату, оставьте исходное значение рядом с нормализованным. Пустую дату не заменяйте нулём, а задержку не вычисляйте от даты создания заказа, если договор отсчитывает срок от подтверждения. Уберите дубли писем, но не сливайте сообщения с разными временными отметками: обновление «в пути» и последующее «ожидает оформления» описывают разные этапы. Попросите модель сначала перечислить строки с конфликтами и пропусками. Это часто полезнее немедленного вывода о причинах.
Разделите хронологию, объяснение и гипотезу
В запросе задайте три колонки результата: подтверждённое событие со ссылкой на строку источника; возможное объяснение, помеченное как гипотеза; вопрос сотруднику, который может подтвердить причину. Например, перенос даты дважды подтверждён письмами поставщика, но связь переноса с нехваткой сырья пока не доказана. Запретите модели приписывать мотив участнику, которого нет в документах, и просите возвращать «причина не установлена», если источник только показывает новый срок. Так сводка не превращает правдоподобный рассказ в факт.
Проверьте выборку вручную
Возьмите несколько поставок из каждой категории: вовремя, перенесена один раз, меняла статус несколько раз, не имеет финального подтверждения. Откройте все исходные документы и сверьте даты, товар и итоговый статус. Отдельно проверьте случаи, где номер заказа похож на другой: совпадение первых цифр не основание объединять записи. Если модель группирует причины, попросите указать точные строки, на которых основана каждая группа. Результат, который нельзя проследить до источника, не используйте в отчёте для решения.
Сделайте вывод пригодным для операционной команды
Вместо рейтинга «проблемных поставщиков» выпустите рабочую очередь: заказ, последний подтверждённый этап, сколько дней до обещанного срока или после него, чего не хватает и кто должен уточнить статус. Разделите системную просрочку, единичный сбой данных и ситуацию, где информация ещё не обновилась. Руководитель закупок определяет приоритет по договору, критичности товара и запасу; модель не должна менять статус заказа или отправлять претензию без проверки. В журнале сохраните дату выгрузки и версию правил, чтобы через неделю понять, почему цифры в отчёте изменились.
Пример запроса и критерий пилота
«Сопоставь строки только по точному ID заказа и коду товара. Не выводи причину задержки. Для каждого заказа верни обещанную дату, последнее подтверждённое событие, источник этой даты, конфликтующие значения и вопрос для сотрудника. Если подтверждения нет — напиши “не установлено”. Не меняй исходную таблицу». На тестовом наборе сравните сводку модели с ручной проверкой закупщика: ошибки дат, ложные объединения, пропуски и время на исправление. Успех — не красивый отчёт, а меньше ручной сверки без роста неверных выводов.
FAQ: что делать с неполными строками
Если нет подтверждённой даты, не просите ИИ рассчитать прогноз и не заменяйте пропуск средним сроком. Пометьте строку как требующую уточнения. Можно ли использовать результат для санкций? Нет, не без проверки договора, переписки и решения ответственного. Нужно ли загружать всю почту? Обычно нет: начните с реестра и документов по выбранной поставке, ограничив персональные данные. Что сохранить для аудита? Запрос, версии входных файлов, ссылки на первоисточники и исправления сотрудника.