Автор материала — архитектор ERP-систем, не разработчик — столкнулся с тем же эффектом, который программисты называют «мёртвым кодом», только в области проектной аналитики. ChatGPT выдавал структурированные, уверенно написанные описания бизнес-процессов, которые при ближайшем рассмотрении оказывались непригодными для работы: по ним нельзя настроить систему, провести тестовый сценарий, обучить пользователя или принять проектный результат. Автор назвал это явление «вайбаналитикой» — по аналогии с «вайбкодингом».
Первый эксперимент был прямолинейным: автор передал модели старые проектные материалы и попросил подготовить аналогичный результат. Внешне всё выглядело убедительно — аккуратная структура, связный текст, правильные термины. Но при детальном разборе модель путала предмет и документ, процесс и процедуру, роль и подразделение, статус и пользовательский комментарий. Где-то придумывала переходы, где-то смешивала уровни абстракции. Проблема была именно в том, что текст не выглядел глупым — он выглядел профессиональным.
| Признак | Мёртвый бизнес-процесс | Рабочий бизнес-процесс |
|---|---|---|
| Предмет | Не задан или размыт | Есть предмет-драйвер |
| Границы | Неясно, где начало и конец | Есть вход и выход маршрута |
| Роли | Названы общо | Есть ответственность и действие |
| Статусы | Декоративные слова | Есть состояния и события перехода |
| ERP-связь | “Оформляется в системе” | Указан документ, объект или действие |
| Проверка | Нельзя пройти сценарий | Можно проверить в тестовой базе |
| Следующий шаг | Непонятно, что делать дальше | Становится входом для инструкции, теста или настройки |
Попытка исправить ситуацию через промпты оказалась тупиком. Промпты становились длиннее, жёстче, подробнее — добавлялись роли, запреты, форматы, примеры, критерии проверки. Результат улучшался, но проблема лишь лучше маскировалась. Автор сформулировал диагноз точно: промпт задаёт ближайшее действие, но не заменяет предметную модель. Если в каждом промпте приходится заново объяснять термины, объекты и статусы — промпт выполняет чужую работу.
Удлинение промптов маскировало проблему, но не устраняло её: промпт не заменяет предметную модель.
Корень проблемы оказался глубже. Для LLM слово «резерв» — просто слово, пока не указано, о каком резерве речь: складском, производственном, бюджетном или управленческом. «Заказ на производство» может означать документ ERP, распоряжение цеху, строку производственного плана или управленческое обязательство перед клиентом. Живой консультант восстанавливает смысл из опыта; модель достраивает его вероятностно. Автор выстроил цепочку уточнения: слово → термин → предмет → объект → экземпляр → статус → событие перехода → проверенный факт. Галлюцинация, по его наблюдению, начинается не с неверного факта, а с нестрогого предмета.
Решение, к которому пришёл автор, — ввести жёсткий критерий: пока результат нельзя проверить сценарием, это не проектный артефакт, а текстовая гипотеза. Проверяемость означает, что по описанию можно установить: кто действует, на каком основании, в какой системе, каким документом, с каким исходным статусом, с каким результатом и какой проверкой. Другой человек должен суметь пройти маршрут в тестовой базе или хотя бы однозначно указать, где маршрут обрывается.
Минимальная формула рабочего процесса, которую автор выработал для работы с LLM, включает девять элементов: предмет-драйвер, границы маршрута, роли, действия, документы или объекты системы, статусы, события перехода, входы и выходы, проверочный сценарий. Отсутствие любого из них ведёт к провисанию. Нет предмета-драйвера — непонятно, что движется через процесс. Нет статусов — нечего контролировать. Нет проверочного сценария — результат нельзя доказать.
Автор проводит параллель с производством: нельзя сказать автоматизированной фабрике «сделай комбайн» и получить изделие из тысяч деталей без маршрутов, операций и контроля. Сложный аналитический результат требует технологической последовательности — каждый артефакт становится входом для следующего. Интервью даёт материал для требований; требования — основу для модели процессов; модель — основу для настройки системы. Если пропустить слой, следующий строится на догадке.
Мёртвый бизнес-процесс, по наблюдению автора, опаснее мёртвого кода. Код всплывает на ревью или в тестах. Процесс может пройти согласование, лечь в регламент, попасть в проектную документацию и годами создавать иллюзию управляемости — пока при внедрении не выяснится, что работать по нему невозможно.