Вайб-кодинг позволяет производственным компаниям проверять логику будущих ИТ-решений до интеграции с корпоративными системами и больших вложений в разработку. Производитель компьютерного оборудования «Инферит Техника» примерно за месяц и без выделенной команды собрал таким способом экспериментальный стенд для планирования. Что показал этот опыт и где заканчиваются возможности вайб-кодинга, рассказывает директор «Инферит Техники» (кластер «СФ Тех» ГК Softline) Олег Епишин.
Как не остаться со складом левых ботинок
Мы производственники — выпускаем персональные компьютеры и серверы. Как и любая производственная компания, должны продавать и зарабатывать. Одна из самых сложных задач здесь — планирование.
И планировать нужно очень точно. Чтобы собрать готовое изделие, комплектующие надо сначала произвести или купить, а в этот момент еще не до конца понятно, что и когда из пайплайна продаж действительно отгрузится. При этом сделки находятся на разных стадиях — одна практически подтверждена, другая только появилась, а третья может сдвинуться на другую неделю.
Готового оборудования на складе у нас незначительное количество, все собирается из комплектующих. Если бы заказчикам нужна была одна и та же конфигурация, планировать было бы проще, но в 70% случаев она хотя бы немного отличается: процессором, материнской платой, объемом памяти, дисками или другими опциями.
Мы работаем примерно с 3000 активных номенклатурных позиций, общее количество существенно больше. Склад и закупки стоят дорого, поэтому вопросы всегда одни и те же: «Что именно?», «Когда?» и «В каком количестве покупать?». И чтобы на них ответить, нужно понять, как эти 3000 позиций сочетаются между собой и сколько реальных конфигураций учитывать в планировании.
Ситуацию осложняют и сроки поставки. Одни комплектующие дистрибьютор привезет примерно за неделю, других приходится ждать до четырех месяцев, и не всегда понятно, придут ли они вовремя. Дополнительно к этому нужно учитывать график производства, чтобы синхронизировать закупки комплектующих с теми номенклатурами, которые выходят с линий поверхностного монтажа.
Главный страх продавца обуви — остаться со складом левых ботинок. У нас похожий риск, ведь можно закупить нужные сами по себе комплектующие, но не те, которые потребуются для выполнения конкретных заказов.
Поэтому задачи две, и решать их надо одновременно: как можно меньше денег заморозить в избыточных запасах и как можно больше продаж обеспечить нужным товаром в нужный момент. Для обычной Excel-таблицы такая комбинаторика — сведение номенклатуры, резервов и сделок — становится неподъемной. Поэтому мы активно пошли в вайб-кодинг.
Эксперимент из разряда «получится — не получится»
Данные для планирования у нас лежат в двух источниках: склад и производство — в ERP, все продажи — в CRM. Чтобы собрать единый план, их нужно свести. Привычный путь — доработать одну из систем или настроить интеграцию между ними, но это долгий и дорогой проект, а нам сначала хотелось понять, какую логику планирования и архитектуру взаимодействия вообще имеет смысл реализовывать.
Про вайб-кодинг мы слышали, но считали его инструментом разработчиков. Когда начали осторожно пробовать, оказалось, что с его помощью можно быстро собрать отдельный стенд, проверить гипотезу и отсеять нежизнеспособные варианты без вмешательства в рабочие системы.
Нам не требовалась замена ERP — нужен был стенд, где можно свести данные, смоделировать логику производственного планирования и посмотреть, работает ли она.
Так появился внутренний стенд Inferit Analytics. Это даже не MVP, а MMVP — «минимум-минимум», который решает несколько ежедневных задач. Идея возникла спонтанно, выделенной команды у нас не было. Сначала это был эксперимент из разряда «получится — не получится». В течение месяца мы занимались стендом параллельно с основной работой, по мере появления времени.
Мы описывали задачу так, как объясняли бы ее человеку: вот продукт и его состав, вот склад, резервы и сделки, вот что должно пересчитываться. ИИ предлагал вариант реализации, мы его запускали, смотрели на результат и уточняли формулировки. Не просили сразу «написать нам систему планирования», а сначала собрали иерархию продуктов, затем добавили данные о складе и продажах.
Самое сложное — правильно объяснить производственную логику и потом проверить, что она нигде не исказилась. ИИ сам не знает, какие комплектующие совместимы, какую вероятность сделки мы считаем рабочей и что для нас означает резерв. Все это нужно сначала задать, а потом проверить на знакомых примерах.
Где густо, где пусто
Мы не стали сразу загружать все 3000 позиций. Сначала взяли часть номенклатуры и собрали дерево продуктов — описали, из каких комплектующих состоит каждая модель и как они сочетаются между собой. Например, один и тот же диск можно использовать практически во всех конфигурациях, а материнскую плату уже нет, так как различаются форм-факторы и другие параметры. На этой основе сделали достаточно простой конфигуратор, который позволяет воссоздать всю эту вариативность.
Когда дерево было готово, стали смотреть, какие модели используют одни и те же комплектующие. Это важно для планирования, ведь если один процессор входит в несколько конфигураций, нужно учитывать потребность в нем по всем соответствующим заказам.
Сначала поиск строился по любому совпадению. Выбираешь одну модель, и система выводит все остальные, в которых встречается хотя бы один такой же компонент. Но диски, например, используются практически везде, поэтому в выборку попадала чуть ли не вся продуктовая линейка. Работать с таким массивом, понятное дело, невозможно. В связи с этим поиск сузили по типам комплектующих, платформам и уровню детализации. После этого стало видно, какие пересечения действительно нужно учитывать в планировании.
Дальше первая точка принятия решений — гэп-анализ. Мы брали популярный процессор, который используется во многих моделях, и смотрели, сколько единиц есть на складах, сколько зарезервировано, сколько остается свободными и сколько потребуется для выполнения запланированных заказов.
Допустим, на складе 47000 процессоров, а для продаж нужно 68000. Не хватает 21000 штук. Если учесть стоимость недостающих комплектующих, видим сумму, необходимую для покрытия дефицита.
Второй срез — продажи. В стенде заложена недельная дискретность, но важно понимать, что предстоит отгрузить в каждый период и достаточно ли для этого комплектующих. Раз в неделю мы вместе с командой продаж сравниваем текущую версию с предыдущей: где сдвинулись сроки, появилась новая сделка или уменьшился плановый объем.
По каждой сделке видно, насколько она обеспечена. Если заказ нужно выполнить раньше, меняем дату и смотрим, как пересчитается остальной план.
Все это можно делать и в Excel, пока данных немного. Но когда речь идет о тысячах номенклатурных позиций, их сочетаниях, складских остатках, резервах и сделках, обычная таблица уже не справляется. Именно для работы со всем массивом и понадобился стенд — он сводит данные в одну модель и показывает, как изменение сделки, срока или объема влияет на остальной план.
Нужный компонент в нужный момент
Пока стенд дает нам базовую картину о том, где и каких комплектующих не хватает, сколько нужно закупить и какой объем продаж этим можно обеспечить. Когда накопится достаточно данных, следующий шаг — прогнозные модели. Они должны отвечать уже не только на вопрос, чего не хватает сейчас, но и подсказывать, в какой момент и какие именно комплектующие заказать под будущие продажи.
Даже небольшое сокращение избыточных запасов при масштабе нашего склада может дать эффект, измеряемый десятками миллионов рублей.
Где заканчивается вайб-кодинг
Синхронизацию с рабочей базой мы сознательно не делали, поэтому все изменения переносятся в первоисточник вручную. Для экспериментального этапа такое ограничение даже полезно: если в заложенной логике или расчете есть ошибка, она не повлияет на закупки, резервы и сроки отгрузки. Если же решим развивать стенд дальше, потребуются проверка кода, полноценная архитектура, меры безопасности и интеграция с корпоративными системами.
Вайб-кодинг не сделал из нас разработчиков, но убрал главный барьер — цену эксперимента. Раньше для проверки любой гипотезы в области планирования нужно было закладывать бюджет на доработку. Теперь между идеей и ИТ-проектом появился промежуточный шаг: собрать базовый рабочий стенд, проверить его на реальных данных и только потом решать, что переносить в ERP. При этом стенд справляется со своими задачами, и его можно использовать в рабочем процессе как хороший инструмент поддержки.
Вайб-кодинг не сделал из нас разработчиков, но убрал главный барьер — цену эксперимента.
Ценность здесь не в том, что любой сотрудник теперь может сам написать промышленную систему. Мы получили возможность сначала проверить себя: действительно ли понимаем процесс, который собираемся автоматизировать. Иногда стенд подтвердит, что логика работает, иногда покажет, что мы неправильно поставили задачу. Оба результата дешевле получить до начала большой разработки.
Но проект дал нам больше, чем просто стенды с аналитикой и прогностическими моделями. На этих примерах команда увидела, насколько снизился порог технических требований к сотруднику для решения его задач. Сейчас не нужно изучать Visual Basic, чтобы делать сложную логику в Excel, можно работать на уровне постановки задачи.
Сегодня в команде происходят намного более важные перемены — мы начинаем все больше и больше задач тестировать, исходя из подхода AI-first, то есть как реализовать задачу с помощью ИИ. В работу с нейросетями активно включаются пресейлы, маркетологи, производственники. И уже на многих этапах либо сокращается время выполнения рутинных операций, либо повышается их качество, а также проще находится решение каких-то существующих проблем.
Наш бизнес, в конце концов, не про код. Он про то, чтобы обеспечить клиентов нужными продуктами и не накапливать на складе левые ботинки.