Закупщик получил несколько коммерческих предложений на одну заявку. В первом цена за штуку, во втором — за упаковку, в третьем доставка включена только при заказе всей партии. Названия похожи, но характеристики различаются. Свести файлы в одну таблицу еще не значит сравнить предложения: сначала надо установить, какие строки вообще можно поставить рядом.
ИИ в закупках полезен на этой подготовительной работе. Система разбирает предложения, ищет соответствия в справочнике, выделяет расхождения и собирает основания для решения. Закупщик получает таблицу, в которой видно происхождение каждого значения и причины, по которым часть товаров нельзя сравнить. Разберем, как получить такой результат и что придется определить до разработки.
Сравнение начинается с закупочной заявки
У каждой позиции заявки должен быть набор обязательных характеристик. Для крепежа это могут быть размер, материал и класс прочности; для сырья — состав, фракция и требования к качеству. Часть признаков допускает замену, часть запрещает ее. Эти ограничения задает специалист, отвечающий за использование товара: технолог, инженер или внутренний заказчик.
Название позиции само по себе такого правила не содержит. Два подшипника могут различаться одним обозначением, от которого зависит пригодность для оборудования. Система должна сохранить различие, даже если большинство слов совпало. Иначе аккуратно заполненная сравнительная таблица приведет к покупке изделия, которое нельзя поставить на нужное место.
Начните с одной товарной категории. Для нее проще собрать образцы заявок, договориться о критичных признаках и назначить человека, который разрешает спорные замены. Попытка сразу описать сырье, оборудование, канцелярию и услуги дает слишком разные правила. Их сводят к общему показателю похожести, а затем закупщики перепроверяют почти каждую строку.
Точное соответствие и допустимый аналог — разные результаты
При сопоставлении номенклатуры системе нужны несколько исходов. Она может найти точное соответствие, предложить аналог с перечислением отличий, установить несовместимость или сообщить, что данных недостаточно. Если оставить только ответ «совпало», закупщик не узнает, где программа нашла тот же товар, а где предположила возможность замены.
Храните исходную строку предложения рядом с нормализованной. Сокращения, обозначения производителя и единицы удобно привести к общему виду для поиска, но специалисту нужен оригинал. Он должен открыть конкретную строку файла и проверить, не потерялся ли при обработке суффикс марки, размер или оговорка о комплектации.
Для разрешенного аналога сохраняют основание: какие параметры совпали, какое отклонение допустимо и кто его подтвердил. Такое решение действует в пределах конкретных условий. Разрешение заменить материал в одной партии не означает, что ту же замену можно автоматически применять ко всем будущим заказам и другим производственным участкам.
В проекте для производителя ферросплавов мы сопоставляли продукцию конкурентов по химическому составу, фракции и показателям качества. Особенно трудно было различать позиции с одним несовпадающим параметром. Помогли признаки из паспортов качества и штрафы за расхождения критичных характеристик. Спорные пары подтверждает аналитик.
Отчет в этом проекте стал готовиться за 30 минут вместо нескольких дней. Это кейс ценообразования: его результат относится к сравнению продукции и работе с ценами. Он показывает, почему характеристики важнее похожего названия. Автоматические закупки и выбор поставщика в опубликованном кейсе не описаны; переносить на них результат проекта было бы неверно.
Языковая модель разбирает текст, справочники ограничивают выбор
В одном предложении характеристики стоят в таблице, в другом — в примечании, в третьем — в приложенном паспорте. Большая языковая модель, или LLM, может извлечь их в заданные поля. После этого значения надо проверить: существует ли такая единица, допустим ли формат характеристики, относится ли примечание к нужной строке.
Для поиска соответствий не обязательно поручать модели каждую пару товаров. Артикулы, известные обозначения и ранее подтвержденные соответствия обрабатывают по справочникам. Для менее очевидных случаев используют сравнение признаков и модели машинного обучения. Выбор между LLM и классической моделью зависит от того, какую неопределенность нужно снять на конкретном шаге.
Например, модель извлекла материал и размер, но не нашла класс прочности. Система может предложить кандидатов из каталога, однако итоговый статус останется «не хватает характеристики». Высокая похожесть названий не заполняет отсутствующее поле. В рабочей таблице такая строка получает вопрос поставщику или задачу специалисту, который вправе уточнить требование.
Справочник соответствий тоже требует владельца. Производитель меняет обозначение, товар снимают с поставки, в каталоге появляется новая модификация. Для сохраненной пары нужны дата проверки и признаки, на которых она основана. Если критичная характеристика изменилась, прежнее соответствие отправляют на пересмотр. Иначе система постепенно накопит устаревшие решения и будет уверенно использовать их даже при безошибочном чтении новых документов.
Цена сравнима только вместе с условиями
Одно предложение может закрывать позицию заявки несколькими строками: основной товар, обязательная оснастка и упаковка. Бывает и обратное: поставщик дает цену комплекта, внутри которого несколько запрошенных изделий. Такую связь надо показывать явно. Если система механически ищет одну строку напротив другой, часть стоимости исчезнет из сравнения, а недорогой вариант окажется неполным. Закупщик должен видеть состав предложения до расчета общей суммы.
После сопоставления товаров надо привести предложения к одинаковому объему и составу поставки. Цена упаковки пересчитывается в цену единицы только при известном количестве внутри. Стоимость доставки распределяется по принятому в компании правилу. Налоги, валюта и условия оплаты сохраняются отдельными полями: их нельзя угадывать по привычному оформлению файла.
Коэффициент пересчета тоже должен иметь источник. Нельзя взять вместимость упаковки от другого производителя только потому, что наименование совпало. Если товар продается по массе, а заявка задана в штуках, нужен подтвержденный способ перевода для этой позиции. При отсутствии такого основания система сохраняет исходные единицы и выводит вопрос, вместо того чтобы получать внешне сопоставимую, но неверную цену.
Учебный пример: первый поставщик предлагает 100 изделий за 50 000 ₽, второй — упаковку из 20 изделий за 9 000 ₽. Во втором случае та же сотня стоит 45 000 ₽. Но минимальный заказ составляет 10 упаковок: купить придется 200 изделий за 90 000 ₽. Более низкая цена единицы еще не означает меньшие расходы по текущей заявке. Доставка и остальные условия в этом примере не учтены.
Полезная сравнительная таблица показывает оба значения: цену сопоставимого объема и фактическую сумму заказа с учетом ограничений. Закупщик видит, сколько придется купить сверх потребности, и может проверить, допустим ли запас. Если часть условий неизвестна, итоговая сумма остается предварительной с явным перечнем того, что в нее не вошло.
Срок поставки тоже требует основания. Формулировки «со склада», «после оплаты» и «после согласования спецификации» описывают разные условия начала отсчета. Система сохраняет исходную формулировку и событие, от которого зависит срок. Пока событие не определено, календарную дату лучше не рассчитывать: иначе таблица придаст неточному обещанию вид подтвержденного обязательства.
Отдельное поле — срок действия предложения. Цены в старом файле могут уже не действовать, хотя сам товар подходит. При повторном сравнении система отмечает просроченные условия и предлагает запросить подтверждение. Она не должна молча смешивать текущую цену одного поставщика с прошлогодними условиями другого: такое ранжирование выглядит убедительно только до проверки документов.
Итог не всегда сводится к одному победителю. Поставщик может выигрывать по цене, но не укладываться в срок; другой закрывает только часть объема. Показывайте это как варианты с ограничениями. Если компания использует балльную оценку, ее веса должны быть утверждены и доступны закупщику. Придуманный моделью общий балл скрывает управленческое решение: сколько компания готова заплатить за срок, комплектность или привычные условия оплаты.
У каждого значения должен оставаться источник
Для каждой строки результата сохраняйте файл, его редакцию и место, из которого взято значение: лист и ячейку таблицы, страницу документа, фрагмент письма. Если итоговая стоимость рассчитана, нужны также формула и исходные поля. Тогда специалист проверяет конкретное расхождение, вместо того чтобы заново разбирать весь комплект предложений.
Документы одного поставщика могут противоречить друг другу. В письме указана одна дата, в приложенном предложении — другая; в каталоге одна комплектация, в спецификации — сокращенная. Правило выбора источника согласуют заранее. Когда оно неприменимо, система показывает обе версии и оставляет вопрос открытым. Дата получения файла сама по себе не разрешает противоречие.
Версии важны и после решения. Закупщик согласовал сравнение, а поставщик прислал обновленное предложение. Программа должна показать изменившиеся поля и сбросить подтверждение для затронутых условий. Иначе решение будет выглядеть одобренным, хотя человек видел другую цену, другой срок или другой состав поставки. Старую версию сохраняют вместе с историей согласования.
Закупщику нужна очередь конкретных расхождений
Сообщение «проверьте предложение» возвращает специалисту всю исходную работу. Полезнее показать задачу: «Не указан материал», «Объем упаковки отличается от справочника», «Цена действует до согласования заказа». Рядом — исходный фрагмент, требование заявки и варианты следующего действия. Чем точнее причина проверки, тем меньше времени уходит на восстановление контекста.
- Не хватает характеристики — запросить ее у поставщика; строку не включать в окончательное сравнение.
- Предложен аналог — направить отличия специалисту, который отвечает за допустимость замены.
- Расходятся коммерческие условия — получить подтверждение нужной редакции предложения.
- Все обязательные данные подтверждены — передать сопоставимую строку в таблицу выбора.
Решение закупщика полезно сохранять, но не каждую правку следует автоматически превращать в новое правило. Исправление ошибочно прочитанной единицы можно использовать для проверки извлечения. Разовое разрешение на аналог требует отдельного срока и области действия. Если смешать эти виды обратной связи, система начнет распространять исключения на закупки, для которых их никто не разрешал.
Уточнения удобнее собирать в один запрос по предложению. Если по нескольким позициям неизвестен размер упаковки, поставщику не нужны отдельные письма на каждую строку. Система группирует вопросы, сохраняя связь с позициями. При поступлении ответа закупщик видит, что удалось закрыть и что осталось неопределенным. Уже подтвержденные поля не следует перезаписывать целиком только потому, что пришел новый файл.
Роль агента — собирать недостающее и вести состояние проверки
Агент добавляет к сравнению последовательность действий: получает новое предложение, проверяет комплектность, готовит уточнение, после ответа пересчитывает затронутые строки. Перечень доступных действий задают отдельно. Подготовить письмо, отправить его поставщику и разместить заказ — разные полномочия. Для первого запуска достаточно подготовки сравнения и задач на уточнение.
Такой процесс требует общего идентификатора закупки. По нему связывают заявку подразделения, предложения, переписку и решения специалистов. Если файлы лежат в папках без связи с заявками, сначала нужно наладить эту связь. Мы отдельно разбирали подготовку данных к автоматизации: модель не исправляет отсутствие источника, которому компания готова доверять.
Содержание предложения остается входными данными, а не командой для агента. Примечание поставщика не должно менять правила закупки или давать доступ к чужим предложениям. Инструменты агента ограничивают конкретной заявкой и разрешенными операциями; отправляемый наружу текст проверяют на лишние сведения. Это особенно важно, когда в одной системе сравниваются условия нескольких конкурирующих поставщиков.
Как проверить сопоставления на завершенных закупках
Для пилота соберите завершенные закупки выбранной категории: исходную заявку, все редакции предложений и подтвержденные соответствия. Часть примеров оставьте для итоговой проверки. Отдельно включите случаи, где товары почти одинаковы, но замена запрещена, и случаи с неполными условиями. На удобных файлах с одинаковыми названиями слабое решение тоже покажет хороший результат.
Оценивайте ошибки по последствиям. Неверно признать товары взаимозаменяемыми опаснее, чем отправить правильную пару на дополнительную проверку. Но слишком большая очередь проверки съест экономию времени. Поэтому нужны отдельные показатели ошибочных соответствий, пропущенных критичных отличий и доли строк, которые закупщик способен принять без повторного разбора документов.
Время измеряйте до готового сравнения, которым можно пользоваться. Включите исправление полей, запросы уточнений, ожидание решения технолога и повторную проверку обновленных предложений. Быстрое извлечение текста может почти не изменить полный срок закупки, если основная задержка связана с согласованием аналогов. Это основание изменить границы проекта, а не записать ускорение одного шага в общий эффект.
Оценку экономии закупочного бюджета ведите отдельно от экономии рабочего времени. Снижение цены может быть связано с объемом заказа, изменением рынка или переговорами. Чтобы отнести его к системе, нужны сопоставимые закупки и понятный способ расчета. До появления таких данных разумнее считать проверенные изменения трудозатрат по методике оценки окупаемости, не обещая скидку от самого факта внедрения ИИ.
Проверьте и полноту найденных предложений. Система может безошибочно сопоставить несколько удобных строк, потеряв все остальные еще при чтении таблицы. В отчете о проверке должны сходиться количества входных и обработанных позиций, а у каждой пропущенной строки нужна причина. Разделение на «не прочитано», «прочитано, но не сопоставлено» и «сопоставлено с оговоркой» помогает найти место ошибки и определить ответственного за исправление.
На первом этапе закупщик работает с результатом рядом с привычным сравнением. Он фиксирует каждую содержательную поправку и затраченное время. Если сотрудники правят выгрузку в личном файле, а система этих изменений не получает, результат пилота будет трудно проверить: в журнале останется успешная автоматизация, в реальности — дополнительная ручная работа. Поэтому место проверки и способ сохранения исправлений входят в проект наравне с обработкой документов.
Расширять охват стоит по категориям, для которых подтверждены правила. Если решение справилось с одинаково описанным расходным материалом, из этого ничего не следует о закупке оборудования с индивидуальной комплектацией. Для следующей категории заново проверяют состав характеристик, допустимые замены и устройство предложения. Общими останутся загрузка файлов, история решений и очередь вопросов; предметные правила потребуется дополнить.
Что подготовить для разбора вашей закупочной категории
Возьмите одну завершенную заявку с несколькими предложениями и отметьте места, где специалисту пришлось принимать решение. Приложите требования к товару, справочник, образец сравнительной таблицы и пояснения к допустимым заменам. Уберите сведения, которые нельзя передавать на предварительный разбор. Такой комплект показывает объем будущей работы лучше, чем общее пожелание автоматизировать снабжение.
Со стороны компании понадобятся закупщик, владелец требований к товару и специалист по учетной системе. На диагностике автоматизации закупочного процесса мы разберем этот комплект и составим список шагов: что можно сопоставлять автоматически, какие решения оставить специалистам и какие данные надо подготовить. Срок пилота оценим после проверки форматов и доступов к системам.