Закупка автозапчастей: 500 строк в день, 50 000 SKU и четыре ограничения снаружи базы 

Разговор про автоматизацию закупки почти всегда начинается с вопроса, на который у подрядчика нет честного ответа. Звучит он так: почему за это просят полмиллиона, если на маркетплейсе лежит обработка расчета потребности за десять тысяч рублей, а сервис автозаказа от вендора стоит 4 500 ₽ в месяц.

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

Разберем на профиле, который в опте и рознице автозапчастей встречается постоянно: ассортимент около 50 000 SKU, три склада, 300–500 строк закупки каждый день, полтора десятка поставщиков, 1С:УТ с историей доработок. Ниже — пять слоев автоматизации этой закупки, цена каждого и место, где заканчивается коробка.

Пять слоев закупки, и дорогой из них только один

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

Первые три слоя — товар с полки. Их незнание стоит дороже, чем их покупка: человек платит за разработку того, что уже стоит в его базе и просто не настроено. Дорогое начинается на четвертом слое, и вот почему.

Слой первый: обеспечение потребностей у вас уже есть

В УТ 11 механизм обеспечения потребностей закрывает арифметику «осталось два из пяти, продается по три в неделю, закажи семь». Способы обеспечения задаются по номенклатуре и складу: заказ под заказ клиента, поддержание запаса по минимуму и максимуму, поддержание запаса по норме, поддержание запаса по статистике продаж. Товары в пути механизм вычитает сам, страховой запас задается в настройках, горизонт планирования тоже.

Если задачу можно описать фразой «посчитай точку заказа по статистике и покажи, чего не хватает», проект не нужен. Нужен человек, который на неделю сядет и заполнит способы обеспечения по товарным группам. Это работа на настройку, и стоит она как несколько часов франчайзи.

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

Слой второй: прайсы поставщиков — задача решенная

Прайсы приезжают в XLSX с шапкой на четырех строках, в CSV с точкой вместо запятой, в XML формата YML и по ссылке на выгрузку. У каждого поставщика свой формат, и меняется он без предупреждения. Выглядит как боль, требующая разработки, но это самый населенный участок рынка: универсальные загрузчики прайсов и остатков в УТ, КА и ERP лежат на маркетплейсе готовыми, с настройкой колонок мышкой и пересчетом валюты.

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

Где типовое ломается: четыре ограничения снаружи базы

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

Ограничение 1: процент выкупа

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

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

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

Ограничение 2: кратность упаковки и логика склада

Нужно три свечи — берется пачка десять. Не потому, что арифметика ошиблась, а потому, что склад так принимает и раскладывает, и потому, что позиция иначе вылезет снова через два дня, и строку придется обрабатывать заново. Кратность упаковки в справочнике есть, но решение «округлить вверх до пачки» зависит от цены позиции, скорости продаж и от того, ходовая она или мертвая. На копеечной ходовой позиции округление вверх экономит рабочее время. На дорогой редкой оно замораживает деньги.

Ограничение 3: лаг возвратов

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

Ограничение 4: качество поставщика

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

Эта карта нигде не записана. Она есть в голове одного человека и пропадает вместе с его отпуском. При этом сигнал уже лежит в базе: когда приходит брак, оформляется возврат, и в комментарии пишется что-то вроде «паленка» или «не та резьба, вернули». Свободный текст, который не читает ни один отчет.

Кроссы и аналоги: одна деталь под пятью артикулами

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

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

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

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

Заказ под клиента и складская позиция — два разных потока

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

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

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

Комментарий в возврате как источник рейтинга поставщика

Разбор этих комментариев — единственное место в закупке, где языковая модель дает эффект, несопоставимый с ценой ее применения. Задача формулируется узко: взять историю возвратов за год, вытащить из текста причину и отнести ее к классу — брак, пересорт, подделка, повреждение при перевозке, ошибка заказа, — после чего свести в рейтинг «поставщик × товарная группа × доля проблемных поставок».

Дальше рейтинг работает как обычный числовой коэффициент в детерминированном выборе поставщика. Модель не участвует в решении, куда уходят деньги: она один раз превращает текст в число. Токенов такой разбор потребляет копейки: комментарий к возврату — это одна строка текста, а весь годовой массив укладывается в объем, который считается разово. Порядок сумм на инференс разбирали в разборе сметы ИИ-агентов.

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

Отдельная тонкость, которую стоит заложить сразу: рейтинг обязан быть объяснимым. Строка «взял здесь, дороже на 40 ₽, ноль возвратов за квартал по этой группе» — это то, что превращает подтверждение заказа в осознанное действие. Иначе первый же спорный выбор поставщика убивает доверие ко всей системе, и человек возвращается к ручной проверке всех 500 строк.

Где считает код и где работает модель

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

Подробно эту архитектуру и грабли ее сборки на кастомной конфигурации мы разбирали в статье про агента, который встраивается в 1С и не создает двойную работу; там же о том, почему система, останавливающаяся на выдаче списка рекомендаций, увеличивает объем ручной работы вместо того, чтобы его сокращать. Здесь не повторяемся и идем дальше — к деньгам.

Сколько это стоит по блокам

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

Рабочий минимум — первые пять блоков: система считает заказ, выбирает поставщика, показывает готовый результат, человек подтверждает. Это 520 000 ₽ и две-три недели плюс неделя тестов на реальных заказах. Полный охват с записью черновика в базу и подключением всех поставщиков — 740 000 ₽. Верхняя ступень с собственным сервером и автономным заказом по доверенным группам — от 1 150 000 ₽, и берется она частями, после того как нижняя отработала.

Работы до 300 000 ₽ оплачиваются разово, объем свыше разбивается на этапы. Права на код переходят заказчику после оплаты этапа. Прикинуть порядок под свой объем можно на калькуляторе, он показывает вилку без заявки и звонка.

Арифметика окупаемости, которая не сходится

Тут положено писать про экономию 40% и окупаемость за квартал. Посчитаем честно, на открытых числах, которые читатель может пересчитать под себя.

Закупщик с окладом 80 000 ₽ обходится компании примерно в 104 000 ₽ с учетом взносов. При 168 рабочих часах в месяце это около 619 ₽ за час. Если закупка забирает у него пять-семь часов в день при 22 рабочих днях, речь идет о 68 000 – 95 000 ₽ в месяц.

Делим 520 000 ₽ на эту вилку и получаем от шести до восьми месяцев до возврата вложений. Полный охват за 740 000 ₽ — от восьми до одиннадцати месяцев. Верхняя ступень окупается временем за год с лишним.

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

Проект окупается на втором плече, и оно считается по вашим цифрам, а не по нашим. Первое слагаемое — закупочная цена: на 300–500 строках в день разница даже в один процент средней закупки за год превращается в сумму, которая перекрывает бюджет проекта. Второе — брак: каждая партия подделки — это возврат клиента, повторная логистика, потерянная маржа и репутация. Третье, самое недооцененное, — привязанность к человеку: пока карта поставщиков живет в голове собственника или единственного закупщика, отпуск, болезнь или уход этого человека стоят компании отдельных денег.

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

Формула простая: годовой оборот закупки, умноженный на процент, который вы рассчитываете отыграть на выборе поставщика, плюс годовая сумма потерь на возвратах брака. Если результат заметно больше 520 000 ₽ — считайте дальше. Если сравним с этой суммой — не начинайте.

Когда этот проект делать не надо

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

• Меньше нескольких десятков строк закупки в день. На таком объеме разработка не отобьется никогда. Настройка обеспечения потребностей и готовый загрузчик прайсов закроют задачу целиком.
• Один заранее выбранный поставщик на позицию. Если выбирать не из кого, самый дорогой блок проекта теряет смысл, и остается обычный автозаказ — товар с полки.
• Нужны только ABC, XYZ и прогноз сезонности. Это готовые отчеты и сервисы; заказная разработка тут дороже без выигрыша.
• Справочник с дублями. Если одна и та же деталь живет в базе под тремя карточками с разными артикулами, любой автоматический расчет разнесет эту ошибку по всем заказам сразу. Сначала порядок в НСИ силами компании, потом разработка. Это неприятный, но обязательный порядок.
• Хочется, чтобы система отвечала на вопросы по базе. Читающий помощник, который показывает остатки и историю, но ничего не проводит, сегодня закрывается штатными средствами платформы и стоит около нуля. Платить за это разработку не надо.

В конфигурацию не лезем

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

Обратно система возвращает черновик документа «Заказ поставщику». Проведение остается за человеком до отдельного решения — это дешевая страховка от того, что ошибка расчета молча уедет в учет. Что именно ломается при таком обмене на конфигурации с историей, разобрано в статье про грабли агента в 1С, а вопросы прав и транзакционности — в материале про агента с правом записи. Техническую сторону обмена и выбор между реальным временем и расписанием закрывает интеграция по API — это же самый дешевый вход, если хочется начать с малого.

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

После заказа: приход, недовоз и пересорт

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

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

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

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

Приемка: по какому критерию считать, что работает

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

1. Совпадение с решением закупщика. Неделя тестов, каждый день человек сравнивает предложение системы со своим решением. Заранее фиксируется порог: на какой доле позиций предложение должно совпасть, чтобы работа считалась принятой. Это главный критерий, и проверяется он на живых заказах текущей недели. Историческая выборка тут не годится: на ней система всегда выглядит лучше, чем в бою.
2. Доля строк без ручной правки. Показывает, сколько потока система реально сняла. Растет по мере того, как правила достраиваются.
3. Время на формирование заказа. Замеряется секундомером до старта проекта и через месяц после. Единственное число, которое понятно собственнику без объяснений.

Здесь же полезно заранее договориться, что считать расхождением. Система предложила другого поставщика, но с той же ценой и тем же сроком — это равнозначный вариант. Округлила до упаковки — тоже штатное поведение. Расхождением считается решение, которое закупщик не принял бы: другой бренд, другой ценовой уровень, лишний объем. Без такой договоренности неделя тестов превращается в спор о процентах.

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

С чего начинать

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

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

Мы в MoranaLabs собираем такие контуры как ИИ-агентов с правом записи в 1С: строгий код на деньгах, языковая модель точечно на тексте возвратов, интеграция снаружи конфигурации. Если задача шире закупки и упирается в текстовые данные внутри учетной системы, ее закрывает направление ИИ в 1С — там первый процесс считается отдельно и стартует дешевле.

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