Лубрикантс × TenderScan: ИИ для тендерного отдела дистрибьютора моторных масел

Тендерный специалист в компании-дистрибьюторе моторных масел приходит на работу в 8:30 утра. Варит себе кофе, открывает ноутбук, заходит на zakupki.gov.ru. Дальше — два часа монотонной работы: перебор новых закупок по ключевым словам, поиск тех, что касаются моторных масел и смазочных материалов, проверка спецификаций, сравнение с текущим складом, отсеивание нерентабельных. К 10:30 он определяет четыре-пять закупок, на которые имеет смысл откликаться, и начинает готовить коммерческие предложения.

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

Именно с такой ситуацией в начале 2026 года ко мне пришёл директор одной компании, которая продаёт моторные масла брендов «ГазпромНефть», «Лукойл», Shell и нескольких других производителей. Я не буду называть её официальное название — клиент попросил оставить «Лубрикантс» как обобщённое имя, — но это действующий бизнес, реальный тендерный отдел, реальные закупки и реальные 250+ номенклатурных позиций на складе. И это — кейс, на котором мы вместе с командой TenderScan впервые довели продукт до момента, когда клиент после пилота сказал: «Да, мы хотим продолжать».

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

Контекст: три производителя, 250 позиций, два часа в день

Чтобы понять задачу, надо сначала понять, как устроен бизнес клиента. Компания — дистрибьютор, не производитель. Она покупает моторные масла и смазочные материалы у трёх ключевых производителей: «ГазпромНефть» (это основной поставщик, примерно 60% оборота), «Лукойл» (ещё около 30%) и несколько зарубежных брендов — Shell, Mobil, Castrol. В каталоге клиента — более 250 номенклатурных позиций: разные объёмы (1 литр, 4 литра, 5 литров, 20 литров, 200 литров), разные вязкости (5W-30, 5W-40, 10W-40, 15W-40), разные типы масел (моторные, трансмиссионные, гидравлические) и, конечно, разные марки.

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

Работа тендерного отдела состоит из трёх фаз. Фаза первая: поиск. Менеджер каждое утро просматривает новые закупки на zakupki.gov.ru, тендерплане и других платформах. Фаза вторая: сопоставление. Он сверяет список нужных заказчику позиций с текущим складом — есть ли у нас то, что запрашивают; в нужном ли количестве; по каким ценам мы можем предложить. Фаза третья: формирование КП. Если сопоставление прошло хорошо, менеджер готовит коммерческое предложение в фирменном шаблоне компании, прикрепляет спецификацию, подписывает и отправляет через электронные торговые площадки.

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

Почему классическое решение не сработало

Когда я услышал эту задачу впервые, первая моя мысль была — это же классический RPA-кейс, уровень L0 по шкале автономности процессов. Скрипт, который ходит на zakupki.gov.ru, скачивает закупки, парсит описание, сравнивает с каталогом — и всё. При чём здесь LLM?

А потом я посмотрел на реальные закупки. И увидел, почему это не RPA-задача.

В техзадании моторных масел может быть написано что угодно и как угодно. «Масло моторное Premium N 5W-40 синтетическое, 4 литра, допуск API SN/CF, производитель — ГазпромНефть» — это чистая строка, которую легко сопоставить. А теперь представьте другую формулировку: «Масла моторные, синтетические, для легковых автомобилей, вязкость согласно рекомендациям производителя, с допуском производителя для двигателей Евро-5, объём 4-5 литров, предпочтительно отечественного производства». Такую строку классический матчинг не поймёт — там нет ни ключевого слова, ни артикула, ни прямого сопоставления с каталогом. Но человек её понимает за три секунды: «это 5W-40 синтетика, 4-5 литров, допуск производителя, наше будет подходить».

Именно эта семантическая сложность делает задачу не RPA-шной, а LLM-ной. Это задача уровня L4 — автономный агент, который планирует, сопоставляет и готовит результат. Он должен не просто искать совпадения, а понимать смысл техзадания, сопоставлять его с семантикой склада и принимать решение. Для RPA это слишком сложно, для полной автономии — слишком рискованно (ошибка в КП — это реальные деньги и репутация). А вот для L4 с человеком в контуре финального решения — идеально.

Что мы делали: пайплайн TenderScan в действии

Мы начали пилот в феврале 2026 года. План был простой: за две недели настроить систему, загрузить склад клиента, подключить источники тендеров, запустить ежедневный pipeline, неделю поработать вместе с клиентом над тонкой настройкой, получить обратную связь, улучшить. К концу второй недели на столе у тендерного специалиста каждое утро должна была лежать карточка с 3–5 рекомендациями: «вот эти закупки подходят под наш склад, вот ориентировочная маржинальность, вот готовый черновик КП».

Первый шаг — загрузка склада. Мы дали клиенту шаблон CSV для выгрузки: ID позиции, наименование, цена, остаток, единица измерения, производитель, категория, характеристики. Клиент за один день выгрузил 267 позиций из своей 1С. Пример строки (упрощённо):

2389901151; ГазпромНефть Premium N 5W-40 4л; 1650; 80; шт;
ГазпромНефть; Моторные масла; Синтетическое моторное масло премиум-класса;
Вязкость=5W-40; Объём=4л; Тип=Синтетическое; Допуск API=SN/CF

Это была важная часть работы, потому что качество сопоставления напрямую зависит от качества характеристик. В первой версии выгрузки у 40% позиций не были заполнены ключевые поля — допуски, типы, объёмы. Мы прошлись по каталогу вместе с менеджером клиента и за два часа дополнили все позиции нужными характеристиками. Это был самый трудозатратный этап подготовки — но и самый важный.

Второй шаг — подключение источников тендеров. zakupki.gov.ru у нас был подключён сразу, это стандартный коннектор TenderScan. Тендерплан мы подключили по API-ключу клиента за час. Настроили умные фильтры: ОКПД2-коды, связанные с моторными маслами и смазочными материалами, плюс ключевые слова в описаниях. Сразу же появились первые закупки в системе.

Третий шаг — LLM-валидация и матчинг. Вот где начинается самое интересное. Для каждой новой закупки система запускала трёхэтапный процесс:

1. Извлечение номенклатуры. LLM читает файлы закупки (обычно это PDF с техзаданием плюс Excel-спецификация) и извлекает структурированный список позиций. Названия, количества, характеристики, требования.
2. Семантический матчинг со складом. Для каждой позиции из закупки LLM ищет в каталоге клиента наиболее подходящие товары — не по точному совпадению строки, а по смыслу. «Моторное масло 5W-40 синтетика 4л» из закупки → «ГазпромНефть Premium N 5W-40 4л» из склада.
3. Оценка маржинальности. Система считает, сколько позиций закупки мы можем закрыть из склада, на какую сумму, и помечает закупку статусом: «зелёный» (закрываем полностью, маржинальность хорошая), «жёлтый» (закрываем частично, нужно докупать), «красный» (не подходит — либо нет позиций, либо требуются специфические бренды).

Четвёртый шаг — генерация КП. По «зелёным» закупкам система автоматически формировала черновик коммерческого предложения в фирменном шаблоне клиента. Это не финальный документ — он всё равно требует вычитки менеджером перед отправкой — но 90% работы уже сделаны. Остаётся проверить цены, уточнить сроки, подписать.

Пятый шаг — доставка результата. Каждое утро в 9:00 менеджер клиента получал в Telegram сводку: три-пять закупок с цветовой разметкой, краткими описаниями, маржинальностью и ссылкой на черновик КП. Открыл, прочитал, принял решение — откликаться или нет.

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

💡 У вас похожая задача — тендерный отдел, ручная работа, ИИ должен её съесть? Мы в TenderScan предлагаем Managed Pilot — формат, в котором мы за фиксированную цену в 150 000 ₽ за две недели настраиваем систему под ваш склад и процессы, неделю работаем в ваших реальных тендерах и отдаём вам отчёт «вот эти три мы бы рекомендовали». Дальше — подписка на TenderScan по вашему решению. Это не продажа «коробочного SaaS», это совместный проект с прозрачным результатом. Обсудить Managed Pilot →

Где сломалось и как мы чинили

Было бы наивно рассказывать эту историю как гладкое «мы пришли — мы внедрили — всё заработало». Так не бывает, и я не буду врать. Давайте я честно расскажу, где именно мы спотыкались.

Проблема первая — качество OCR из PDF-документации. Большая часть закупок публикуется в виде PDF-файлов, и часть этих файлов — сканы, а не текстовые PDF. На сканах нашему OCR-слою иногда срывало крышу: он «читал» латинские буквы вместо русских, цифры путал с буквами, путал О с 0. В результате LLM получала на вход мусор и делала мусор на выходе. Решение — добавили проверку качества распознавания и, если уверенность ниже порога, откатываемся на более медленную, но точную модель OCR. Это замедлило пайплайн, но подняло качество.

Проблема вторая — семантический матчинг даёт false-positive. В первую неделю пилота система нашла одну закупку, где заказчику нужно было «моторное масло SAE 5W-40 для дизельных двигателей с допуском MB 228.5». LLM честно пометила это «зелёным», потому что у нас на складе было «ГазпромНефть Premium N 5W-40 синтетическое». Но допуск MB 228.5 — это очень специфическое требование Mercedes-Benz для тяжёлых дизелей, и у нашего масла такого допуска не было. Если бы менеджер отправил КП, он получил бы отказ, потому что предложение не соответствовало бы техтребованиям. Решение — добавили в пайплайн отдельный шаг проверки специфических допусков: если в ТЗ упоминаются MB-коды, ACEA-коды, API-коды, которых нет в характеристиках склада, — закупка автоматически уходит в «жёлтый», а не в «зелёный», даже если по остальным параметрам совпадение есть.

Проблема третья — клиент хочет видеть, как принимаются решения. Менеджер на второй день сказал: «Я не понимаю, почему эта закупка “жёлтая”, а эта “зелёная”. Можете показать?». В первой версии TenderScan возвращал только итоговый статус, без объяснения. Это было ошибкой. Мы добавили раскрываемую карточку, в которой видно: «вот эти 15 позиций из закупки → вот эти 15 позиций нашего склада, которые мы к ним подобрали, вот маржа по каждой, вот замечания LLM». Менеджер получил объяснимость каждого решения. После этого уровень доверия к системе вырос мгновенно.

Проблема четвёртая — шаблон КП не совсем правильный. В первой версии мы генерили черновик КП в нашем внутреннем шаблоне, который был «средним по больнице». Менеджер его посмотрел и сказал: «Хорошо, но у нас шапка документа другая, подписант другой, и формат цен другой — мы всегда указываем цену с НДС и без НДС, а не только одну». Мы взяли у клиента его реальный шаблон КП за последние три месяца и научили систему подстраиваться под него. Через два дня пайплайн выдавал черновики, которые почти не отличались от того, что менеджер делал вручную.

Все эти проблемы — это обычный режим работы любой системы первой недели жизни. Они не означают, что продукт плохой. Они означают, что продукт живой и адаптируется под реального клиента. Именно поэтому мы в TenderScan работаем в режиме Managed Pilot, а не продаём коробочный SaaS: мы знаем, что каждый клиент — это цикл «запустили — нашли проблему — починили — проверили», и готовы проходить этот цикл вместе.

Чему мы сами научились

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

Первое — качество склада важнее качества модели. Мы могли бы вливать огромные ресурсы в дообучение LLM на корпусе закупок, но 80% роста точности мы получили в момент, когда вместе с клиентом очистили и дополнили характеристики 267 позиций. Модель лучше — это плюс 5%. Склад лучше — это плюс 40%. Это урок, который теперь мы повторяем каждому следующему клиенту: инвестируйте в качество данных, прежде чем инвестировать в качество модели.

Второе — объяснимость важнее автоматизации. Менеджер не хочет «чёрный ящик, которому мы должны доверять». Он хочет инструмент, который помогает ему принимать решения. Это значит, что 30% нашей работы должно было уйти не в улучшение точности матчинга, а в улучшение интерфейса объяснения. И это правильно: даже если система ошибается, но ошибку можно понять и исправить, — она ценнее, чем система, которая работает идеально, но непрозрачно.

Третье — специфика индустрии выносится в правила, а не оставляется LLM. Допуски моторных масел (MB, ACEA, API) — это детерминированная область. LLM тут не нужна, нужна таблица с правилами. Мы вынесли такие специфические проверки в отдельный модуль — и это ускорило работу, удешевило запросы к LLM и сделало решения более надёжными. В мире внедрения AI это называется гибридной архитектурой: LLM делает то, что хорошо делает LLM, а для детерминированной логики — обычные правила. Чистая LLM-архитектура почти никогда не оптимальна в реальном бизнесе.

Что дальше

По результатам пилота с Лубрикантс мы с клиентом договорились о продолжении на подписку. Система работает ежедневно, в текущем режиме приносит 4–6 рекомендаций в сутки, из которых менеджер отправляет КП по 2–3 закупкам. Доля выигранных тендеров (относительно поданных) выросла — потому что система подбирает только те закупки, которые хорошо ложатся на склад, а не случайные.

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

Этот кейс — и ещё несколько параллельных внедрений, о которых я пока рассказать не могу, — стали доказательством концепции для TenderScan как продукта. Мы сейчас расширяем список поддерживаемых источников, работаем над ускорением запуска новых клиентов (чтобы «две недели» превратились в «пять дней»), и постепенно двигаемся в сторону других вертикалей — продуктового офиса, строительных материалов, фармацевтики.

И это — живая иллюстрация того, о чём я пишу в отдельной заметке «Почему мы не только консультируем, но и разрабатываем ПО». Когда я прихожу к следующему клиенту банковской программы и рассказываю про Уровень 4 шкалы автономности, я больше не показываю слайды из учебника. Я показываю реальный работающий пример, в котором мы сами прошли весь путь, набили все шишки и вынесли конкретные уроки.

Хотите такой же пайплайн в своей компании?

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

Мы работаем в формате Managed Pilot: за фиксированную цену 150 000 ₽ мы за две недели настраиваем систему под ваш склад, подключаем ваши источники тендеров, запускаем ежедневный пайплайн и неделю работаем в ваших реальных закупках. На выходе — отчёт: вот такой объём автоматизации получается, вот такие метрики качества, вот такие рекомендации. Дальше — вы сами решаете, переходить ли на постоянную подписку.

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

Обсудить Managed Pilot для вашего тендерного отдела →