ИИ для закупок: как сравнивать цены, поставщиков и прошлые покупки

Отдел снабжения получил три предложения. В первом ниже цена за единицу, во втором включена доставка, в третьем товар есть на складе, но продаётся крупной упаковкой. В таблице можно быстро выделить минимальное число — и всё равно выбрать самый дорогой или неподходящий вариант.

ИИ для закупок полезен прежде всего как помощник в приведении разрозненных предложений к сопоставимому виду. Он собирает данные из писем и файлов, связывает их с номенклатурой и прошлыми закупками, показывает неизвестные условия. Решение становится прозрачнее, если за каждой строкой можно открыть источник. Разберём, как построить такой процесс для обычного бизнеса.

Чтобы сравнить поставщиков, нужно знать, что компания действительно покупает: характеристики, количество, единицы, место и крайний срок поставки, допустимые аналоги. Если потребность не определена, ИИ будет сравнивать формально похожие предложения без общего основания.

Например, «кабель для объекта» недостаточно конкретен. Имеют значение марка, сечение, исполнение, метраж и требования проекта. Даже одинаковое разговорное название не гарантирует взаимозаменяемость. Для другой категории существенными будут срок годности, комплектность или сервис.

Полезно создать карточку потребности с обязательными и желательными условиями. Обязательные работают как фильтр допустимости: вариант, который им не соответствует, нельзя сделать победителем высоким баллом за низкую цену. Желательные помогают выбирать среди уже пригодных предложений.

Поставщики отвечают в разных форматах: письмо, PDF, Excel, изображение или ссылка на прайс. Система извлекает позиции и условия, сохраняя связь с оригиналом, датой получения и версией. При неразборчивом поле нужен статус «требует проверки», а не уверенная догадка.

Для сравнения обычно нужны наименование и идентификатор товара, количество, единица продажи, состав упаковки, цена, валюта, доставка, срок, минимальный заказ и условия оплаты. Состав полей зависит от категории; универсальная таблица редко покрывает все закупки компании.

Идентификаторы помогают избежать случайного сопоставления. GS1 US отдельно описывает GTIN, внутренний SKU и уровень упаковки в данных товара. Для проектирования закупочной базы важен сам принцип: код позиции и упаковка должны быть явными полями, а не частью свободного описания, которую приходится каждый раз угадывать. GS1 US · Product Field Definitions ↗

Даже при наличии кода проверяйте версию и комплектность. Внутренние артикулы разных поставщиков могут совпасть случайно, а один и тот же привычный товар продаваться поштучно или коробками.

Сначала определите, какую поставку сравниваете: одинаковое количество пригодного товара в одном месте к согласованному сроку. Затем учтите обязательные дополнительные расходы, минимальную партию и различия условий.

Цена за единицу без доставки не сопоставима с итогом «до склада». Цена коробки не равна цене штуки. Валютные предложения требуют согласованной даты и источника курса. Налоговые условия и возможность учёта соответствующих сумм определяются правилами компании и проверяются её специалистами; модель не должна выбирать их самостоятельно.

Нормализация должна сохранять исходные данные рядом с пересчитанными. Иначе закупщик увидит красивый итог, но не сможет проверить, откуда он получен и какие допущения применены. Неизвестную доставку нельзя превращать в нулевую только ради завершения таблицы.

Рассмотрим вымышленную закупку 100 одинаковых пригодных единиц товара. Все суммы условные, в рублях, на одной согласованной базе расчёта; налоги и дополнительные расходы вне таблицы не моделируются.

Поставщик А предлагает товар дешевле за единицу, но с доставкой сумма выше, чем у Б. У В цена единицы ещё ниже, однако минимальный заказ увеличивает сумму и оставляет 20 лишних единиц. Если они действительно нужны в следующем периоде, это отдельный сценарий; автоматически считать излишек бесплатной выгодой нельзя.

При жёстком сроке в три дня Б не проходит условие даже с минимальной суммой. Компания должна выбрать среди допустимых вариантов или изменить потребность. ИИ помогает показать последствия каждого условия, а не прячет их в одном непрозрачном рейтинге.

История закупок отвечает на полезные вопросы: покупали ли уже эту позицию, у кого, в каком количестве и на каких условиях? Она также может показать возвраты, недопоставки и реальные сроки, если такие события достоверно фиксируются в системе.

Но прошлогодняя цена не является готовым нормативом для сегодняшней. Могли измениться объём, комплектация, курс, доставка и условия оплаты. Сначала приведите данные к сопоставимому виду, затем покажите расхождение и его возможные объяснения.

Разделяйте заказ, поступление и оплату. Цена в заявке может отличаться от фактически оплаченной после корректировки, а запланированный срок — от даты полного получения. Для оценки истории поставщика важно понимать, какое событие используется.

Если прошлые записи неполны, система должна сообщать об ограничении. Отсутствие зарегистрированных претензий не доказывает безупречное качество. Возможно, претензии обсуждались в почте и не попали в доступный источник.

Единый балл удобен, но способен скрыть важные различия. Поставщик с хорошей ценой и слабой историей сроков может быть приемлем для плановой закупки и неприемлем для аварийной. Вес критериев выбирает компания под конкретную ситуацию.

Полезнее сначала показать факты: подтверждённые поставки, число наблюдений, долю поставок в срок по согласованному определению, возвраты, условия оплаты. Затем можно добавить объяснимую оценку с видимыми весами и исключениями.

Не смешивайте отсутствие данных с плохой репутацией. Новый контрагент не обязательно ненадёжен; по нему просто меньше подтверждённых наблюдений. Так же несколько успешных небольших заказов не доказывают способность выполнить крупную срочную поставку.

ИИ может сформулировать вопросы для проверки и кратко объяснить различия. Неподтверждённые подозрения, выводы о мошенничестве и «чёрные списки» по впечатлению модели не должны становиться частью закупочного решения.

Хорошие кандидаты на автоматизацию — сбор ответов в карточку, извлечение полей, поиск истории, расчёт сопоставимых сумм и выделение пропусков. Для точной арифметики и обязательных правил полезна обычная программная проверка.

Сопоставление неоднозначных товаров, принятие нового аналога, изменение требований и выбор при конфликте сроков и цены требуют компетенции ответственного сотрудника. Отправка заказа, изменение реквизитов и платёж рассматриваются как отдельные действия с установленными полномочиями.

Система может подготовить проект запроса уточнений: подтвердить срок, расшифровать комплектацию, назвать стоимость доставки. Однако подготовленный текст и отправленный поставщику запрос — разные состояния. Автоматическая отправка требует заранее определённых границ.

Если предложение содержит срочную просьбу обойти согласование, это не меняет правила процесса. Право поставщика сообщать условия не означает права управлять вашим агентом.

Для проверяемого сравнения храните ссылку на исходное предложение, дату, страницу или строку, использованную единицу и правило пересчёта. При исправлении OCR сохраняйте связь с подтверждением сотрудника. Тогда итог можно воспроизвести после обновления прайса.

В стандарте W3C PROV происхождение данных описывается через связи между данными, действиями и участниками. Для закупочного процесса это полезная идея: можно проследить, из какого документа получена строка и кто подтвердил изменение. Это не означает, что для пилота обязательно внедрять весь стандарт. W3C · PROV Overview: data provenance ↗

Ссылки должны учитывать права. Сводная таблица не должна раскрывать закупочные цены сотруднику, которому закрыт исходный документ. И наоборот, ответственный закупщик должен иметь возможность открыть доказательство, не разыскивая его заново по почте.

Начните с времени на подготовку сопоставимой таблицы и её проверку. Дополнительно измеряйте долю корректно извлечённых ключевых полей, число пропущенных обязательных условий и количество повторных уточнений. Ошибка в единице или доставке важнее косметического недостатка формулировки.

Экономию закупочной цены считайте относительно определённой базы: реально доступного сопоставимого варианта или утверждённого бюджета. Разница с произвольной максимальной ценой из трёх предложений ещё не доказывает, что компания сэкономила именно эту сумму.

Не складывайте без разбора снижение цены, предотвращённые потери и стоимость освобождённого времени. Эти эффекты имеют разные основания и могут пересекаться. На пилоте достаточно честно показать, где уменьшилась ручная работа и где решение стало лучше подтверждено.

Выберите повторяющуюся категорию с понятными характеристиками и несколькими типовыми поставщиками. Подготовьте примеры предложений и доступную историю, определите поля сравнения и обязательные условия. Начните с чтения и подготовки рекомендаций, проверяя реальные источники и права.

AI Office рассматривает закупочную роль и сопоставление документов как возможные сценарии проекта. Конкретная номенклатура, интеграции, автоматические действия и критерии качества фиксируются отдельно. Иллюстрация в статье не означает готового универсального коннектора или гарантированной экономии.

Когда закупщик видит сопоставимые условия, неизвестные данные и историю с источниками, ему проще объяснить выбор. Именно такой результат стоит требовать от ИИ для закупок: меньше ручной сборки и больше проверяемых оснований для решения.