Автоматизация закупок в оптовой компании: какие работы я бы проверял первыми

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

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

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

Начал с закупок.
И почти сразу столкнулся с той же проблемой, только уровнем ниже.

Что автоматизировать в закупках?

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

Я снова получил не объект автоматизации, а название большого бизнес-процесса.
Значит, его тоже нужно было дробить.

Что уже автоматизирует обычная ERP в закупках

Значительная часть классического закупочного контура автоматизируется без всякого ИИ.

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

Поэтому меня интересует уже не общий вопрос:

Можно ли автоматизировать закупки?

Гораздо полезнее другой:

Какая работа между этими системными точками до сих пор остаётся человеку?

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

Я разложил закупки на цепочку отдельных работ

Если сильно упростить, закупочная цепочка может выглядеть так:

появилась потребность -> определить, что нужно купить -> найти возможных поставщиков -> запросить условия -> собрать ответы -> сравнить -> выбрать вариант -> оформить заказ -> проконтролировать выполнение.

Но почти каждый блок внутри этой цепочки снова можно разделить.

Например, фраза «собрать и сравнить предложения поставщиков» на практике может означать:

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

Фраза «сравнить коммерческие предложения» скрывает внутри много механической и интеллектуальной работы.
А значит, её уже можно исследовать по частям.

Самой интересной мне показалась работа до принятия решения

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

Для первого пилота я бы пока не начинал именно с него.

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

Цена неправильного решения здесь может быть высокой.

Поэтому для меня интереснее слой до принятия решения:

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

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

Для первого уровня автоматизации такая граница выглядит понятной:

система готовит, человек решает.

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

Где здесь нужен ИИ, а где достаточно обычной автоматизации

Часть этой цепочки вообще не требует ИИ.
Например:

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

Это обычная автоматизация.
ИИ становится интересен там, где появляется менее структурированная работа:

• разные форматы документов;
• разные названия одной позиции;
• свободный текст;
• таблицы разной структуры;
• необходимость понять смысл строки;
• неоднозначное сопоставление;
• необходимость классифицировать исключение.

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

Поисковый спрос показывает интерес к теме, но не доказывает продукт

Параллельно я посмотрел на поисковые формулировки.
В нашем исследовательском семантическом ядре есть измеренный спрос по нескольким запросам:

• ai для закупок - Broad 43, Exact 2;
• автоматизация закупок с ии - Broad 10, Exact 2;
• ии агент для закупок - Broad 37, Exact 2;
• нейросеть для поиска поставщиков - Broad 10, Exact 3.

Для меня эти цифры полезны прежде всего как сигнал языка рынка.
Люди уже связывают ИИ и закупки, но Exact по этим формулировкам небольшой. И даже высокий поисковый спрос сам по себе не доказывал бы willingness-to-pay или повторяемость будущего продукта.

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

• автоматизация сбора коммерческих предложений;
• автоматическое сравнение коммерческих предложений;
• автоматизация работы с поставщиками;
• контроль сроков поставки.

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

Как я теперь смотрю на одну работу закупщика

После декомпозиции у меня получилась рабочая карточка.

1. Что запускает работу

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

2. Что приходит на вход

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

3. Что человек делает сейчас

Какие файлы открывает, что переносит руками, что сверяет, где ищет информацию, кому пишет и что рассчитывает.

4. Что является готовым результатом

«Проанализировать предложения» для меня слишком размыто.
Готовым результатом может быть:

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

Такой результат уже можно проверять.

5. Как часто это происходит

Один раз в квартал и сто раз в день - две разные продуктовые экономики.

6. Сколько ручного труда уходит сейчас

Без baseline нельзя честно говорить об экономии после автоматизации.

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

7. Как проверить результат

Можно ли достаточно однозначно проверить:

• позиции сопоставлены правильно;
• цена извлечена правильно;
• валюта определена правильно;
• срок не потерян;
• условия не перепутаны.

Если результат нельзя нормально проверить, безопасная автоматизация становится заметно сложнее.

8. Какова цена ошибки

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

9. Где остаётся человек

Для первого пилота я бы оставлял закупщику:

• спорное сопоставление;
• необычные условия;
• выбор поставщика;
• изменение критичных параметров;
• подтверждение заказа.

10. Насколько работа повторяется между компаниями

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

Какие работы закупок я бы сейчас проверял первыми

После декомпозиции получается не один «агент по закупкам», а несколько отдельных кандидатов.

Сбор и нормализация коммерческих предложений

Вход:

письма, PDF, Excel и другие предложения поставщиков.

Результат:

единая структурированная таблица.

Сопоставление номенклатуры

Вход:

позиции поставщиков с разными названиями.

Результат:

сопоставление с внутренним каталогом плюс список неоднозначных случаев.

Подготовка сравнения поставщиков

Вход:

нормализованные предложения.

Результат:

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

Контроль изменения условий поставки

Вход:

обещанный срок и новое событие от поставщика.

Результат:

найденное отклонение и список затронутых заказов или обязательств.

Я не считаю эти четыре работы продуктовыми гипотезами одинаковой силы.
Пока это shortlist для следующего этапа исследования.

Где заканчивается карта и начинается настоящее исследование

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

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

И только после этого имеет смысл обсуждать минимальный пилот.

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

Что я пока не считаю доказанным

После этого прохода у меня нет основания утверждать:

• что оптовые компании уже являются главным ICP нового направления;
• что закупки - лучшая первая вертикаль;
• что на конкретный контур есть подтверждённый willingness-to-pay;
• что найденная работа одинаково устроена у разных компаний;
• что сравнение коммерческих предложений уже является готовым продуктом;
• что финальный выбор поставщика стоит передавать системе автоматически.

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

Что изменилось в моём вопросе

Начал я с:

Как автоматизировать закупки в оптовой компании?

Сейчас вопрос для меня выглядит иначе:

Какая конкретная работа закупщика достаточно часто повторяется, забирает заметное ручное время, имеет проверяемый результат и достаточно похожа у разных компаний, чтобы её имело смысл проверить отдельным цифровым исполнителем?

Наиболее интересным кандидатом для следующей проверки пока выглядит не автономный «ИИ-закупщик», а более узкая работа:

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

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

Если нет - карта станет ещё уже.
И это тоже полезный результат исследования.

Источники и внешние ориентиры

• 1С:ERP - управление закупками - возможности классического закупочного контура: поставщики, условия, заказы, контроль исполнения, цены, графики поставок и платежей.
• Fogsoft - автоматизация сравнения коммерческих предложений - внешний пример того, как рынок описывает отдельную работу вокруг сбора и сопоставления предложений.