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

Я взял оптовую компанию как поле исследования и разложил ее не на системы и отделы, а на конкретные повторяемые работы в продажах, закупках, складе, документах, дебиторке и управлении.

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

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

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

Но уже первый вопрос оказался слишком большим.

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

Если отвечать на него буквально, автоматизировать можно почти все: CRM. 1С. Склад. Прайсы. Заказы. Закупки. Документооборот. Контроль оплат. Отчеты. Логистику. Коммуникации с клиентами.

Для интегратора такой список нормален.
Для поиска повторяемых продуктовых функций такой список слишком крупный. Мне нужно было спуститься ниже.

Сначала я смотрел на системы и процессы

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

• CRM для B2B-продаж;
• учетную систему;
• интеграцию CRM и 1С;
• складской контур;
• электронный документооборот;
• личный кабинет дилера;
• автоматизацию закупок;
• аналитику;
• AI для обработки заявок.

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

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

Поэтому я изменил не технологию, а единицу исследования.

Вместо “автоматизировать отдел” я начал искать конкретную работу

Формулировка “автоматизация продаж” кажется конкретной, пока не начинаешь разбирать, что реально делает сотрудник.

Внутри продаж это могут быть совершенно разные работы:

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

Все это один отдел. Но для автоматизации это разные объекты.
У них разные данные, разные триггеры, разная цена ошибки и разная граница, где решение можно отдавать системе без человека.

В закупках та же история.
“Автоматизировать закупки” можно разложить на отдельные работы:

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

Когда я дошел до такого уровня, вопрос стал намного полезнее.
Не:

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

А:

Что произошло, кто после этого должен что-то сделать, что именно он делает и какой результат должен получиться?

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

В разговорах я перестал спрашивать про желаемый AI

Здесь мне помог и касдевный подход. Вопрос “какого AI-сотрудника вы бы хотели” слишком быстро переводит разговор в фантазию о будущем решении.

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

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

На таком разборе часто видно, что большая фраза “обработка заказа” состоит из нескольких разных работ.
Например:

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

Это уже гораздо ближе к функции, которую можно проверять отдельным пилотом.
И здесь не обязательно нужен один большой AI-агент.
Часть шагов может закрываться обычными правилами, часть - интеграцией, часть - OCR, часть - моделью, а часть должна остаться человеку.

Я прошел по оптовой компании отдел за отделом

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

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

Продажи

Здесь быстро появляются работы вокруг входящего запроса и следующего действия:

• разобрать заявку из почты или мессенджера;
• сопоставить свободный текст клиента с номенклатурой;
• проверить индивидуальные условия;
• получить актуальный остаток;
• собрать КП;
• обновить CRM после разговора;
• проверить наличие следующего шага;
• найти сделки, где обязательство уже просрочено;
• подготовить менеджеру контекст перед повторным контактом.

Закупки

В закупках много работы связано не с самим решением “у кого купить”, а с подготовкой данных для этого решения:

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

Склад и логистика

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

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

Документы и учет

Это отдельный большой слой повторяемой работы:

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

Дебиторка и финансы

Здесь особенно интересна event-driven логика:

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

Управление

У руководителя много времени забирает не одно большое решение, а сбор картины из разрозненных систем:

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

Этот проход дал мне важную мысль.
Оптовая компания интересна не как один большой объект автоматизации. Она интересна как плотный набор повторяемых работ, связанных данными и событиями.

Одни и те же механики повторяются в разных отделах

Когда я перестал смотреть только на названия отделов, начали повторяться одинаковые механики.
Например:

пришла неструктурированная информация -> нужно понять ее -> извлечь нужные данные -> записать результат в систему.

Так устроена и заявка клиента, и предложение поставщика, и входящий документ.

Другой паттерн:

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

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

Еще один:

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

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

Если одна механика повторяется в нескольких функциях, появляется шанс повторно использовать часть архитектуры.
Но это пока только гипотеза повторяемости.

Одинаковая механика не означает одинаковый продукт.
Цена ошибки при подготовке черновика КП и при изменении платежных условий разная. Источники данных разные. Права на действие разные. Human-in-the-loop тоже будет разным.

Почему я не стал сразу выбирать самые “AI-похожие” работы

На этом этапе очень легко выбрать задачи, где эффектно выглядит модель.
Разобрать письмо.
Сравнить документы.
Написать ответ.
Собрать отчет.

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

Меня интересует другое:

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

И только после этого имеет смысл обсуждать архитектуру.
AI здесь средство, а не критерий выбора работы.

Поисковые запросы тоже пришлось читать как язык работы

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

• AI для закупок;
• автоматизация закупок с AI;
• AI для логистики;
• автоматизация склада с AI;
• AI для работы с поставщиками.

Но здесь быстро появляется ловушка.
Человек может иметь реальную проблему и вообще не искать “AI для закупок”.

Он может искать:

• как сравнить коммерческие предложения;
• как контролировать сроки поставки;
• как автоматизировать прием заказов;
• как связать CRM и 1С;
• как контролировать остатки;
• как автоматизировать сверку документов.

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

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

Что в итоге стало моей единицей отбора

После нескольких проходов я пришел к рабочей карточке, по которой теперь удобнее смотреть на любую функцию в оптовой компании.

1. Триггер

Что запускает работу?
Письмо, звонок, новый заказ, изменение срока, поступление документа, дедлайн оплаты, изменение статуса.

2. Вход

Какие данные нужны, чтобы выполнить работу?

3. Исполнитель сейчас

Кто делает это руками и в каких системах?

4. Готовый результат

Что должно появиться на выходе?
Не “проанализировать”, а конкретный артефакт или измененное состояние системы.

5. Частота и объем

Работа возникает раз в квартал или сотни раз в день?

6. Цена ошибки

Что произойдет, если система ошибется?

7. Проверяемость

Можно ли достаточно объективно проверить, что работа выполнена правильно?

8. Данные и доступы

Можно ли получить нужный контекст без ручной сборки каждый раз?

9. Граница человека

Что можно выполнить автоматически, а где требуется подтверждение или эскалация?

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

Насколько следующий оптовик выполняет эту работу похоже?
Для меня именно эта карточка намного полезнее вопроса “какую систему внедрить”.
Система появляется позже.

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

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

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

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

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

Что этот проход изменил для меня

В начале вопрос звучал так:

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

После исследования я бы поставил его иначе:

Какая конкретная повторяемая работа в оптовой компании достаточно дорогая, частая и проверяемая, чтобы сначала передать системе ее стандартную часть, а затем проверить, повторяется ли эта экономика у других компаний?

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

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

Пока мой вывод простой:

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

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

• 1С:УНФ - автоматизация оптовой торговли - продажи, закупки, склад, заказы, платежи и учет.
• 1С:УНФ - автоматизация закупок - снабжение, остатки, заказы поставщикам и работа с номенклатурой.
• Битрикс24 - кейс автоматизации оптового бизнеса - пример сквозного контура продаж, закупок, поставок, CRM и 1С.