Четыре прототипа, ноль релизов — пока не нашли, куда релизить

Контекст

«Парус Электро» — московский завод силовой электротехники. К началу работы ИИ там уже был — и пришёл он сверху. Генеральный директор сам, руками, собрал через ИИ-редактор кода сервис проверки конструкторской документации и показывал его команде. Это редкая и очень выгодная стартовая позиция: не нужно доказывать, что технология работает, — первое лицо уже доказало это себе само.

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

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

Что болело

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

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

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

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

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

Как подходил

Первая сессия с финансовым блоком была аудитом, а не внедрением: искали, где вообще есть смысл ставить автоматизацию. Нашли два направления — управленческая отчётность как веб-сервис и личные сценарии работы в ИИ-редакторе.

Для сервиса отчётности я не стал давать задание в терминах «сделай дашборд». Вместо этого написал архитектурный playbook: четыре слоя — приём данных, сопоставление, расчёт, интерфейс; неизменяемая исходная строка выгрузки, которую нельзя перезаписывать; и «оракул» — два-три направления, посчитанные вручную и служащие эталоном. Именно отсутствие эталона было корнем недоверия к предыдущей версии агента: пока нельзя сказать «вот здесь правильный ответ», спор о цифрах не заканчивается никогда.

Сознательное решение, которое многих удивляет: первый прототип делался вообще без ИИ внутри. ИИ-редактор использовался только для того, чтобы сгенерировать код на Python, а данные брались из обычных выгрузок учётной системы и Excel. Причина — на предприятии с недостоверными данными вероятностная модель поверх недостоверного источника не даёт ничего, кроме красиво оформленной ошибки.

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

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

Что мешало и что не получилось

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

1. Некуда релизить. Прототип рождается на ноутбуке своего автора, а промышленного контура, куда его можно поставить, к этому моменту, как правило, ещё нет. Вопрос «куда мы это выложим» всплывает последним — когда выкладывать уже есть что.
2. Нет единой точки входа в данные. Выгрузку каждый добывает своим способом, и на выходе у каждого получается своя версия правды. Спор о том, чья цифра верная, в такой конфигурации не заканчивается никогда.
3. Данным нельзя верить в том виде, в каком они лежат. Учётные системы на производстве десятилетиями наполнялись под задачи, далёкие от аналитики. Любая надстройка наследует их расхождения целиком — и чем она быстрее, тем быстрее производит недостоверный результат.

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

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

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

Отдельным риском я зафиксировал вещь, которая в такой работе стоит дороже техники: через два-три месяца заказчик может сказать «мы и так всё умели». Единственная защита — фиксировать стартовую точку в самом начале. Здесь мы зафиксировали её не полностью.

Что стало

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

В августе 2026 закрылись все три условия из списка выше — нашлось, куда релизить; данные проверили; определился способ их забирать. После этого из трёх треков до реальной работы дошли два.

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

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

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

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