Описание бизнес-процесса проверяют на последнем реальном случае

В «Островке» сотни процессов и десятки внутренних систем. Часть процессов не была описана, часть существовала в разных форматах, а один и тот же процесс мог жить в трёх–четырёх версиях. Единой картины того, как идёт работа, у компании не было. Об этом 26.02.2026 написал на Хабре менеджер по бизнес-процессам компании, который собирал каталог описаний.

Сначала сделали единый шаблон описания: цели и границы, входы и выходы, участники и ответственность, используемые системы, коммуникации и схема в нотации BPMN. После нескольких описаний автор понял, что вручную каталог не вырастить. По его оценке, схема занимала около 2 часов (иногда больше), а текстовая часть по шаблону ещё около 4 часов. Получалось около 6 часов на один процесс при сотнях процессов.

С 4 часов до 10 минут: что ускорили в «Островке»

Ключевая идея автора: не анализировать картинку схемы, а конвертировать BPMN в XML, структурированное представление процесса. Модель получает эту структуру и заполняет по ней текстовый шаблон. По данным автора, заполнение сократилось примерно с 4 часов до 10 минут.

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

В «Островке» AI работал с готовой схемой, то есть с фактами, которые человек уже собрал.

Описание бизнес-процессов: что собрать за одно интервью

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

Аналитик-практик советует до встречи подготовить 7–9 основных вопросов и шаблон результата. После встречи он проверяет полученное по другим источникам и согласует итог.

В исследовании с AI-помощником для сбора процессных знаний (Business & Information Systems Engineering, декабрь 2025) помощник задавал уточняющий вопрос, когда ответ был недостаточным, а участник видел формирующуюся схему и исправлял её прямо во время разговора. На выходе сохранялись история разговора, текстовое описание и редактируемая модель процесса.

Где описание расходится с работой

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

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

ERP-архитектор в публикации на Хабре (29.05.2026) описывает похожий опыт: языковая модель по существующим материалам выдавала убедительный документ, который не выдерживал проверки ролями, статусами и маршрутами в системе.

1. Покажите черновик тому, кто рассказывал процесс, и попросите пройти маршрут от запуска до результата.
2. Для каждого решения спросите об альтернативном пути и об исключении.
3. Отметьте сведения, которые собеседник не может подтвердить.
4. Если процесс пересекает несколько функций, сверьте этот участок со вторым носителем знаний.
5. Спорные точки проверьте по документам и данным системы.

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

Коротко

1. Определите, кто будет пользоваться описанием От читателя зависит, какие поля нужны в таблице.
2. Подготовьте вопросы и шаблон результата до встречи На встрече тогда записывается структура, а не пересказ.
3. Записывайте границы, шаги, роли, исключения и пробелы Неизвестное остаётся в описании отмеченным вопросом.
4. Не принимайте гладкий текст за рабочее описание Покажите черновик тому, кто рассказал процесс, и пройдите последний реальный случай.
5. Сверьте спорные участки со вторым носителем знаний и документами Особенно там, где процесс пересекает несколько функций.
6. Назначьте владельца описания и дату проверки Так видно, когда описание пора подтверждать заново.