У завода с оборотом 5 млрд ₽ — 3000 тонн продукции на складе, но нет ответа, что производить завтра

К нам пришёл производитель автомобильных масел и смазочных материалов. Оборот — около 5 млрд ₽, около 500 SKU, 42 дистрибьютора, на складе — примерно 3000 тонн продукции, в месяц завод отгружает около 1500 тонн, несколько юрлиц и управленческая проблема, которую узнает почти любой завод: продажи есть, склад есть, 1С есть, Excel есть, совещания есть — но нет экрана, который утром отвечает на главные вопросы: что производить, что стопнуть, где деньги в складе и какие заказы могут сорваться.

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

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

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

Клиент пришёл после нашей статьи на VC.ru про AI-финансового директора. Он увидел не рекламный лендинг, а наш подход к бизнес-задачам — сначала разобраться в процессе, потом предлагать решение.

Мы не начали с коммерческого предложения. Не стали сразу продавать ERP, BI, AI, дашборды и «цифровую трансформацию». Первым шагом было интервью: понять, можем ли мы реально помочь или перед нами задача, которая нам не по зубам. Мы сразу обозначили рамку: мы слушаем, задаём вопросы и честно говорим, сможем помочь или нет.

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

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

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

Поэтому мы начали с карты болей.

3000 тонн на складе при средней отгрузке около 1500 тонн в месяц — это примерно два месяца продаж в остатках.

Для собственника склад — это не просто товар, а замороженные оборотные деньги: сырьё, тара, производство, хранение и логистика.

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

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

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

Одни SKU льются «по плану», другие — из-за срочного запроса клиента, третьи — «на всякий случай». В итоге по одним позициям склад переполнен, а по другим нечем закрывать заказы.

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

Поэтому системе важно отвечать на два вопроса: что производить сейчас и что лучше остановить.

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

Но часто эти данные живут в разных местах: в 1С, Excel, у коммерции, производства, склада и в голове планёра.

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

А директору приходится не принимать решение, а сначала разбираться, кому верить.

Отдельная боль производства — разные единицы измерения.

Коммерция смотрит на заказы в штуках. Производство планирует в литрах или килограммах. Склад живёт остатками и тарой. Финансы смотрят на всё в рублях.

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

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

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

Для производителя это постоянный конфликт: много товара — заморожены деньги; мало товара — риск дефицита и срыва отгрузок. Производить «на всякий случай» дорого, производить только под заказ — можно не успеть.

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

Производителю важно видеть не только sell-in — сколько он отгрузил дистрибьютору, но и sell-out — что реально ушло дальше в рынок.

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

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

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

Если просто требовать отчётность, дистрибьютор будет сопротивляться: для него это лишняя работа, риск раскрыть данные и непонятная польза.

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

В нём он видит свою динамику, остатки, риски затоваривания и дефицита, статусы заказов, рекомендации и аналитику по себе.

Так отчётность перестаёт быть обязанностью «потому что завод просит» и становится полезным инструментом для самого дистрибьютора.

На производстве нельзя смотреть на отгрузки отдельно от денег.

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

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

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

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

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

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

Если это не разобрать на старте, система будет красиво показывать неправильные цифры.

Поэтому первый слой проекта — не дизайн и не AI, а фундамент данных: источники, справочники, правила сопоставления, права доступа и контроль качества.

Отчёт сам по себе не решает проблему, особенно если приходит поздно или требует расшифровки.

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

Поэтому мы закладывали не просто дашборды, а управленческий контур, который сам подсвечивает проблемные зоны: дефицит, избыток, необеспеченные заказы, просрочку, отсутствие вторички от дистрибьютора или риск выпустить не тот SKU.

После первого созвона мы не ушли готовить красивое КП на две недели.

Для получения доступа к DEMO, напишите мне в Telegram.

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

Мы собрали прототип под их боли: с ролями, экранами, кабинетами, логикой заказов, склада, обеспеченности, дистрибьюторов, дебиторки и AI-агента.

Это был ключевой момент.

Потому что производитель не хочет слушать общие слова про цифровизацию. Он хочет увидеть: «А как это будет работать у нас?»

Первый блок — дашборд руководителя.

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

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

Второй блок — обеспеченность заказов.

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

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

Третий блок — рекомендации «лить / стоп».

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

Рекомендация должна быть объяснима планёру за 10 секунд. Иначе ей не будут пользоваться.

Четвёртый блок — кабинет дистрибьютора.

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

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

Пятый блок — финансовый контур.

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

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

Шестой блок — AI-агент.

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

Презентация и демо — это разные уровни доверия.

Для получения доступа к DEMO, напишите мне в Telegram.

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

Демо попало в боль. Клиент увидел не красивую IT-систему, а свою реальность, собранную в управляемый интерфейс.

Первое — контент сработал до продажи. Статья на VC.ru заранее показала наш подход: мы не продаём «AI ради AI», а разбираем бизнес-процесс и строим систему под него.

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

Третье — быстро сделали демо. Для клиента это сильнее любого КП: он увидел не обещание, а направление будущей системы.

Четвёртое — мы не обещали лишнего. Не продавали суперсервер там, где объём данных небольшой. Не обещали идеальную прибыль в реальном времени там, где себестоимость считается с лагом. Не делали вид, что разные Excel от дистрибьюторов — это простая задача на один день.

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

Честный кейс — с ошибками, поэтому вот где было негладко:

После интервью, демо и обсуждений мы согласовали рамку работ и вышли на договор.

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

Мы не делаем «ещё один дашборд». Мы собираем управленческую ERP над текущими данными завода.

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

— что происходит;

— где проблема;

— что делать сегодня.

Если у вас производство, попробуйте ответить на несколько вопросов.

Если на половину вопросов ответ: «это надо собрать отдельно», проблема не в отсутствии отчётов.

Рост производственного бизнеса — это не только новые клиенты, больше заказов и выше отгрузки.

Рост — это способность управлять связкой:

спрос → склад → производство → отгрузка → деньги.

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

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

Влад Медведев
Стратегический партнёр по росту, продукту и AI
Telegram: @vladislav_medv