Вайбаналитика: как я учил LLM описывать бизнес-процессы, а не имитировать их

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

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

В моей области LLM тоже сначала производит результат, который выглядит убедительно. Он написан гладко, структурированно, с правильными словами и уверенным тоном. Но при проверке выясняется, что это не рабочий бизнес-процесс, а его имитация. По нему нельзя настроить ERP, обучить пользователя, пройти сценарий в тестовой базе и принять проектный результат.

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

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

Первый заход: “вот мои конспекты, сделай так же”

До сильных LLM эта работа была медленной и ручной. Интервью, расшифровки, схемы, таблицы, уточнения у пользователей, сверка с ERP, переписывание инструкций, согласование формулировок, проверка в тестовой базе. Консультант вытаскивает из предприятия требования, роли, документы, исключения, статусы, маршруты, точки контроля и пытается собрать это в связанную модель.

Первый заход к ChatGPT был наивным. Я дал модели старые материалы и попросил подготовить аналогичный результат. Ответ выглядел так, будто половина работы уже сделана. Структура аккуратная, текст связный, формулировки уверенные, блоки на месте. Если читать по диагонали, можно было испытать ровно тот самый эффект: “вот теперь всё будет быстрее”.

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

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

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

Почему длинный промпт не спас

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

Промпт задаёт ближайшее действие, но не заменяет предметную модель.

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

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

То же самое с “заказом”. Когда модель пишет “заказ на производство”, она может не понимать, говорит ли о документе ERP, о распоряжении производству, о строке производственного плана или об управленческом обязательстве перед клиентом. Для живого консультанта часть смысла восстанавливается из опыта. Для LLM это пространство вероятностного достраивания.

Дальше появляются уровни: объект и экземпляр. Тип документа “заказ поставщику” и конкретный заказ №123 — разные вещи. Если один заказ завис из-за материала, это ещё не значит, что весь процесс снабжения сломан. Если один склад показывает ошибку, это не значит, что складская модель неверна. Модель должна понимать, на каком уровне она делает вывод.

Ещё глубже — статус, событие и факт. Статус без события перехода — это просто слово. “Согласовано”, “проведено”, “отгружено”, “закрыто” должны иметь правила перехода: что перевело объект в этот статус, где это зафиксировано, кто отвечает за достоверность и из какого источника это подтверждается. Если статусы существуют только в тексте, модель начинает обращаться с ними как с декоративными метками.

слово→ термин→ предмет→ объект→ экземпляр→ статус→ событие перехода→ проверенный факт

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

Что такое рабочий бизнес-процесс

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

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

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

Рабочий бизнес-процесс начинается не с глагола “согласовать”, “оформить”, “проверить” или “передать”. Он начинается с вопроса: какой предмет движется через процесс? Если этот вопрос не задан, процесс начинает расплываться.

Например, когда говорят “процесс закупки”, нужно сразу уточнять: движется потребность, заявка, заказ поставщику, товар, счёт, обязательство или платёж? Это разные маршруты. У них разные роли, документы, статусы, события перехода и критерии завершения. Если не различить предмет, модель будет описывать “закупку вообще”. Такой текст может быть красивым, но он не будет рабочим.

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

Артефакт — это не бумажка

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

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

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

Здесь хорошо работает аналогия с производством. Нельзя сказать автоматизированной фабрике: “сделай мне комбайн”. Комбайн состоит из тысяч деталей. У каждой детали есть материал, чертёж, допуски, технологический маршрут, операции, оборудование, контроль качества, сборочная позиция и связь с другими деталями. Без этого получится не производство изделия, а желание об изделии.

Когда я прошу LLM “описать бизнес-процессы предприятия”, я фактически прошу произвести сложное изделие. Если я не дал деталей, маршрутов и правил контроля, модель начинает собирать видимость изделия из статистически похожих фрагментов. Внешне это похоже на процесс. Внутри нет технологической состоятельности.

Постепенно я пришёл к тому, что LLM должна быть не только “умной”, но и встроенной в технологию работы: что она получает на вход, что делает, в каком порядке, что выдаёт и как это проверяется. Обученная модель умеет писать, обобщать и связывать. Но технологизированная работа с моделью задаёт последовательность действий, границы вывода и критерии приёмки.

Почему “и так понятно” не работает

В человеческой команде многое держится на фразе “ну это же понятно”. Консультант понимает контекст. Снабженец понимает, что такое резерв. Бухгалтер понимает, что такое факт. Производственник понимает, что такое маршрут. Руководитель понимает, где реальное решение, а где формальная бумага.

С LLM это не работает.

LLM не работает с вашим “и так понятно”. Она работает с тем, что вы смогли явно задать.

Модель не живёт внутри вашего предприятия. Она не знает, что именно в этой компании означает “партия”, “потребность”, “закрытие”, “резерв”, “лимит”, “согласовано”, “проведено”, “отгружено”. Она может написать правдоподобный текст, потому что видела похожие тексты. Но правдоподобие не равно предметной определённости.

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

Я опирался на привычные архитектурные и внедренческие дисциплины: UML, ArchiMate, TOGAF, Oracle AIM. Но постепенно обнаружил, что этого мало. Пришлось возвращаться к более старому уровню — к дисциплине определения у Аристотеля, к кантовскому вопросу о предмете и к гегелевской логике различий и переходов. Это звучит академично ровно до того момента, пока не начинаешь каждый день ловить LLM на том, что она галлюцинирует не потому, что “не знает факт”, а потому что ей не задано, что именно является предметом, где его границы и чем он отличается от соседней сущности.

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

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

Смысл Excel-ядер не в том, чтобы заменить мышление набором таблиц. Смысл в другом: дать модели устойчивую опору, к которой можно возвращаться при каждом новом шаге. В тексте можно красиво объяснить, что такое предмет, маршрут или статус. Но если эти сущности не вынесены в связанные реестры, модель каждый раз получает пространство для вольного восстановления смысла. Когда же термины, предметы, объекты, статусы, источники и связи лежат в слоистой структуре, связанной ключами, у LLM появляется рабочая опора, а не повод заново изобретать предметную область.

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

От текста к проверяемому маршруту

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

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

Мини-чек-лист: как я сейчас проверяю процесс, созданный с участием LLM:

• Понятен ли предмет-драйвер?

• Где начало и конец маршрута?

• Кто действует и за что отвечает?

• Какие документы или объекты системы фиксируют события?

• Какие статусы возможны?

• Что переводит объект из статуса в статус?

• Где источник данных?

• Что является проверенным фактом?

• Можно ли написать операционную инструкцию?

• Можно ли проверить маршрут в тестовой базе?

Отдельная тема — начинающие специалисты. Здесь легко уйти в спор “джуны плохие” или “джуны хорошие”, но это не тот вопрос. Проблема не в джунах как людях. Проблема в том, что LLM слишком рано даёт форму результата. Человек ещё не прошёл сопротивление материала, но уже получил документ.

Джун с LLM может быстро получить описание процесса. Но если у него нет предметного опыта, он не увидит, что именно модель подменила. Процесс процедурой. Статус комментарием. Факт строкой таблицы. Роль подразделением. Управляемый предмет названием документа. Он получит текст быстрее, чем успеет понять, что именно произвёл.

После этой работы я перестал бояться, что “сейчас все украдут промпты и всё автоматизируют”. Оказалось, что промпта мало. Основная трудность не в формулировке запроса, а в предметной и технологической дисциплине. Кто-то ещё долго будет рисовать процессы вручную. Кто-то будет строить технологизированные контуры работы с LLM. Разница будет не в том, кто написал красивее запрос, а в том, кто умеет получать проверяемый результат.

Куда всё идёт дальше

Поэтому я иначе смотрю на движение крупных корпоративных вендоров к knowledge graph, ontology, process intelligence и агентным платформам. Похоже, они решают тот же класс проблемы: как дать ИИ не хаос данных, а описанную предметную реальность.

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

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

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

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

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

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