В крупных компаниях процессная архитектура неизбежно усложняется. Чем больше команд, продуктов и внутренних систем, тем выше зависимость от прозрачных и управляемых процессов. В теории.
На практике даже при наличии каталога процессов сотрудники продолжают задавать одни и те же вопросы в личных сообщениях, искать инструкции по разным хранилищам и опираться на устные договорённости. Документация существует, но пользоваться ей неудобно.
В Островке (тысячи сотрудников, распределённые команды, несколько продуктовых направлений и операционная работа 24/7) мы столкнулись с этой проблемой в полном объёме. Каталог процессов начал формироваться, но быстро стало ясно: сам по себе он не создаёт ценности. Читать схемы BPMN готовы немногие, а поддерживать актуальность описаний вручную — дорого и нестабильно.
Так мы встали на путь превращения каталога процессов из статичного документа в сервис. Поверх него был построен чат-бот на базе LLM и RAG с low-code автоматизацией, который стал точкой входа в процессную архитектуру: отвечает на вопросы, инициирует обновления, обучает сотрудников и принимает заявки на оптимизацию.
В этой статье — практический разбор того, как это ��строено, какие ограничения мы получили и какие результаты увидели.
Привет, Хабр! Меня зовут Артём Санаев, я Integrated Business Processes Planning Manager в Островке. Ниже расскажу, с какими проблемами я столкнулся, выстраивая управление бизнес-процессами в крупной travel-tech компании, и какие решения в итоге сработали.
Речь пойдёт о том, как из разрозненных описаний и неформальных договорённостей собрать работающий каталог процессов — а затем превратить его в инструмент, которым реально пользуются сотрудники. В моём случае таким инструментом стал чат-бот на базе LLM с RAG и low-code автоматизацией вокруг него.
По ряду причин я не могу раскрывать конкретные названия инструментов, но подробно разберу архитектурные принципы, подход к проектированию и ограничения — этого достаточно, чтобы воспроизвести идею в своей компании.
Сперва немного контекста: почему я вообще оказался в BPM? Мой профессиональный бэкграунд — корпоративное обучение (L&D). Со временем зона ответственности расширилась: процессы всего HR-контура, развитие HRIS и построение HR-аналитики. Я занимался настройкой ETL, качеством данных, дашбордами, автоматизацией процессов и внедрением data-driven подхода — от проектирования до аналитики.
Этот опыт дал главное — системное мышление. В какой-то момент стало очевидно, что локальная оптимизация HR имеет ограниченный эффект, если в компании нет прозрачной процессной архитектуры в целом.
Так я оказался в BPM — уже не как методолог внутри функции, а как интегратор на уровне компании: нужно было связать процессы, данные, автоматизацию и людей в единую работающую систему.
Отправная точка
Наша компания — travel-tech с несколькими продуктовыми направлениями: B2C, B2B и корпоративный сегмент. Распределённые команды, десятки внутренних систем и сотни процессов.
В такой конфигурации управляемость быстро становится сложной задачей. На практике картина была типичной:
часть процессов вообще не описана,
часть описана в разных форматах,
один и тот же процесс мог существовать в 3–4 версиях,
инструкции и SOP отличались структурно,
информация быстро устаревала,
целостной процессной архитектуры не существовало.
Понять, как реально работает компания, можно было только «прожив» внутри какое-то время.
Собираю каталог as-is
Первым шагом я решил собрать каталог текущего состояния процессов (as is). Фактически его не существовало — были разрозненные артефакты в виде wiki-страниц и отдельных документов
Я разработал единый шаблон описания, который в том числе включал:
цели и границы процесса,
входы и выходы,
стейкхолдеров и зоны ответственности,
RACI,
используемые системы и трекеры,
ключевые коммуникации,
графические схемы.
В качестве нотации для схем выбрал BPMN 2.0 — она достаточно универсальна для разных функций и позволяет формально описывать сложную логику (исключения, компенсации, альтернативные сценарии).
Практически ни один процесс в компании не был описан в BPMN. После составления нескольких описаний я понял: в таком темпе масштабировать каталог невозможно.
В среднем:
по��троение схемы в BPMN занимало ~2 часа (иногда больше),
заполнение текстового шаблона — ещё около 4 часов.
Шесть часов на один процесс — это узкое место.
Автоматизирую генерацию описания
Решение оказалось неожиданно простым: использовать LLM для генерации текстовой части на основе диаграммы.
Ключевая идея — не анализировать картинку схемы, а конвертировать BPMN в XML и передавать его в контекст модели. Это позволило:
избежать использования нескольких моделей (vision + text),
снизить стоимость и сложность пайплайна,
работать напрямую со структурированными данными процесса.
Размер диаграмм оказался вполне рабочим для LLM: в среднем процесс содержит около трёх зон ответственности, в каждой — от нескольких до нескольких десятков задач в зависимости от глубины проработки. В одних случаях мы фиксируем только магистральный путь — основной сценарий из 4–5 ключевых шагов. В других — моделируем процесс на аналитическом уровне: с развилками, обработкой ошибок, эскалациями и альтернативными сценариями.
LLM получает диаграмму, конвертированную в XML, и инструкцию сформировать описание строго по нашему шаблону. Результат требует редактирования, но основная структура генерируется автоматически. По сути, LLM превращает графический язык сложных схем в формат, понятный сотрудникам.
Отмечу, что я не занимался отдельной оптимизацией модели и использовал стандартные настройки — основной эффект дал не выбор LLM, а архитектура данных и сценарии использования.
Итог: время заполнения шаблона сократилось примерно с 4 часов до 10 минут.
Таким образом за первые полгода удалось собрать приличную базу описаний по нескольким департаментам. Для них я выделил пространство в корпоративной wiki — с заданной структурой, иерархией, правилами работы; возможностями для навигации и поиска.
Но возникла новая проблема. Почти на каждой презентации я слышал одни и те же вопросы:
«Для кого это?»
«Слишком много текста»
«Как здесь вообще что-то найти?»
«У нас же есть инструкции — зачем ещё каталог?»
На текущем этапе LLM решала прежде всего задачу масштабирования каталога — ускоряла создание описаний, но не меняла способ взаимодействия сотрудников с ними. Несмотря на более понятный текст, каталог оставался большим массивом документов — их нужно было самостоятельно искать и читать.
И тогда возник главный вопрос: как превратить каталог из набора описаний в инструмент, которым действительно пользуются?
Бот вместо навигации по каталогу
Итак, каталог рос, а сотрудники продолжали работать по старым сценариям.
Формально ответы уже существовали в каталоге. Практически — искать их долго, сложно и неочевидно. Более того, о самом существовании реестра знали далеко не все.
Решение, которое я выбрал: RAG-бот поверх каталога.
Вместо того чтобы упрощать схемы или писать ещё больше инструкций, я сделал над каталогом интерфейс — чат-бот в корпоративном мессенджере.
Архитектура состоит из трёх слоёв:
каталог процессов —источник истины,
RAG-сервис — слой поиска и извлечения; генерация ответа «человеческим языком»
low-code — логика, сценарии, обратная связь.
Бот отвечает исключительно на основе проиндексированного корпуса. В системном промпте я отдельно зафиксировал ограничения: бот обязан опираться на найденные фрагменты, ссылаться на процесс и не «додумывать» детали (профилактика галлюцинаций).
Логика обработки запроса здесь чуть сложнее чем «не нашёл — ответь нейтрально». Если релевантный процесс не находится с первой попытки, бот выполняет дополнительные шаги: проверяет словарь синонимов и внутренних терминов и запускает повторную генерацию. Если и после этого подходящего материала не находится, модель следует заранее заданному сценарию — направляет сотрудника в конкретные каналы поддержки или к ответственным ролям с готовой формулировкой запроса.
Помимо структуры ответа, я задал тон коммуникации: кратко, без канцелярита, с понятными формулировками и явным указанием дальнейших действий.
Механизм самоулучшения
Каждый ответ бота сопровождается возможностью обратной связи. Низкая оценка автоматически становится задачей для разбора, после чего я анализирую, в чём именно проблема: неточная формулировка, пробел в описании процесса, ошибка в схеме или расхождение между ожиданием пользователя и формально корректным ответом. В среднем в улучшении нуждаются 25% ответов бота, но низкий рейтинг не всегда означает ошибку — часто пользователи ожидали другой уровень детализации или информацию, которой бот пока не обладает.
По результатам правятся разные элементы системы — описания процессов, BPMN-схемы, словари терминов и синонимов, FAQ и другие вспомогательные материалы. Таким образом улучшаются не только ответы бота, но и сам источник знаний.
Фактически бот стал интерфейсом к процессной архитектуре и одновременно механизмом её постоянного улучшения. Это напрямую влияло на качество ответов: при повторных запросах система работает точнее. В результате сотрудник получает ответ примерно за 10 секунд вместо 20–30 минут поиска или ожидания коллег, а продуктовые метрики постепенно растут — например, NPS с момента запуска прирастает на 5-7% в месяц.
Автоматическая валидация актуальности
С появлением бота требования к актуальности каталога резко выросли. Если источник устаревает, устаревают и ответы. Практика показала, что уже через месяц около 3–6% описаний содержат изменения. В условиях активной операционной среды это означает постоянный дрейф знаний.
Я добавил механизм контроля через low-code.
Для каждого процесса:
фиксируется владелец,
фиксируется дата последнего подтверждения актуальности,
задаётся «срок годности» (в моём случае — 180 дней).
Если срок истекает, бот автоматически пишет владельцу и предлагает выбрать один из вариантов:
всё актуально,
я больше не владелец,
нужно обновлять — давайте встречаться.
В зависимости от выбора создаётся задача в трекере.
Если процесс меняет владельца, бот помогает зафиксировать новую точку ответственности — система опирается на корректное распределение ролей. При отсутствии ответа бот отправляет повторные напоминания (минимум раз в неделю).
После обновления описания датасет RAG синхронизируется автоматически, поэтому бот всегда работает с актуальной версией процесса.
Сейчас на сообщения бота отвечают примерно 4 из 10 владельцев процессов. Если считать от общего числа отправленных уведомлений (с учётом повторных напоминаний), доля ответов не превышает 12%. Даже этого хватает, чтобы заметно снизить объём ручного контроля и поддерживать каталог в рабочем состоянии.
Обучение для пользователей
При наличии каталога и бота всё же остаётся системная проблема: не все сотрудники понимают ценность процессного подхода.
Организовывать очное обучение для смешанной аудитории (удалёнка, разные функции, разные уровни) — дорого и тяжело.
Поэтому я решил сделать микрообучение через того же бота.
В RAG-дaтасет добавил:
теорию процессного управления,
внутреннюю методологию,
шаблоны,
правила автоматизации,
политику управления процессами.
Сформировал программу из нескольких тем и реализовал через low-code сценарий микрообучения:
сотрудник записывается,
бот отправляет по одной теме в рабочий день,
можно задавать вопросы и сдавать домашние задания,
в конце — измерение NPS.
Каждое учебное сообщение формируется моделью заново на основе заданной темы и структуры программы. Это не заранее подготовленная рассылка, а динамически генерируемый контент: формулировки и примеры могут отличаться, но логика и состав тем определяются программой обучения.
Чтобы обновить программу, достаточно изменить знания в датасете и скорректировать структуру тем в системном промпте. После этого бот автоматически начинает формировать сообщения на основе обновлённой версии материалов — без переписывания курсов и ручной переработки контента.
Результаты по обучению:
90% NPS,
единичные отписки,
~10% целевой аудитории охвачено за 3 месяца.
В какой-то момент стало очевидно: если бот помогает разобраться в процессе, он должен помогать и запускать изменения. Разрыв между «узнать» и «сделать» создаёт лишнее трение. Логичным продолжением стало добавление сервисного слоя.
Единое окно процессных услуг
Бот уже помогал сотрудникам находить информацию и разбираться в процессах. Через него же я сделал единую точку входа для процессных запросов: инициирования проектирования процессов, запросов на их оптимизацию и, при необходимости, запуска автоматизации.
Сценарий простой: сотрудник выбирает пункт в меню, описывает задачу, после чего low-code автоматически создаёт задачу в трекере и передаёт её в работу. Вместо поиска нужных контактов или каналов взаимодействие начинается в одном месте.
В результате бот стал частью операционного контура — он помогает не только получать ответы, но и запускать изменения в процессах.
Вместо заключения
С появлением «цифрового сотрудника» ключевое изменение произошло не в количестве процессов и не в красоте диаграмм. Изменилась модель взаимодействия: вместо того чтобы заставлять людей читать каталог, я дал им интерфейс. Каталог перестал быть документом и стал источником данных для сервисов.
Подход не идеален. Модель может ошибаться, владельцы процессов не всегда оперативно подтверждают актуальность, а качество ответов напрямую зависит от качества исходных описаний. Но даже с этими ограничениями система снижает нагрузку на менеджеров и экономит часы работы сотрудников.
Главный вывод для меня — в крупных компаниях ценность BPM появляется только тогда, когда процессная архитектура встроена в повседневные инструменты. Документация сама по себе не работает. Работает инфраструктура вокруг неё.
Отдельно отмечу ключевые моменты, с которыми пришлось сталкиваться в процессе:
Критически важна поддержка руководства — причём с самого верхнего уровня.
Многое зависит от готовности людей к внедрению BPM: чем выше степень организационного хаоса, тем больше усилий потребуется на стабилизацию процессов и принятие новых подходов.
Большое значение имеют коммуникационные особенности компании — единая среда общения (например, общий корпоративный мессенджер, где присутствуют все сотрудники) значительно ускоряет распространение практик и снижает трение при внедрении.
Дальше задача и в расширении базы знаний, и в развитии агентного контура. Чем больше процессов описано и структурировано, тем больше ценности можно извлечь из системы — от поддержки сотрудников до проактивных рекомендаций по улучшению. Например, модель может периодически анализировать процессы вместе с текущими метриками и выходить к владельцам с предложениями по оптимизации. И это только начало — потенциал здесь значительно шире.
Про автоматизацию, аналитику, карьеру и просто наблюдения о том, как меняются рабочие процессы и жизнь вокруг, я периодически пишу у себя в блоге. Если интересно — велком!
