Команда полгода описывала процессы. Получился реестр на пару сотен моделей со строгой иерархией папок.
Потом в общем чате кто-то спросил, есть ли у нас регламент по возвратам. Ответил коллега - по памяти, и часть шагов переврал.
Сам регламент в реестре при этом был: согласованный, действующий, лежал в папке постпродажного обслуживания. Просто спросить оказалось проще, чем искать в дереве.
Метрика «сколько описано» не показывает пользу
О процессной работе чаще всего отчитываются объёмом: количество моделей, процент покрытия, глубина декомпозиции. Эти цифры показывают, сколько произведено, и ничего не говорят о том, пригодилось ли. Польза наступает в тот момент, когда сотрудник с вопросом нашёл ответ и применил его.
Если считать именно найденные ответы, результат часто близок к нулю. Причём описано может быть добротно. Между человеком с вопросом и нужной моделью просто лежит несколько лишних шагов, и на каждом теряются читатели.
Почему иерархия папок не доводит до ответа
Реестр процессов - инструмент архитектора. Он отвечает на вопрос «как устроена система процессов целиком»: иерархия, владельцы, связи, покрытие. Сотруднику с конкретным вопросом нужно другое - короткая дорога к одной модели. У иерархии на этой дороге четыре слабых места:
Архитектор раскладывает по своей логике, а читатель ищет по своей. Процесс лежит в «Постпродажном обслуживании», искать его будут по слову «возвраты».
Пять уровней вложенности - пять решений подряд. Ошибся веткой на втором уровне, и дальше путь тупиковый: проще уйти спрашивать в чат, чем возвращаться.
Названия моделей написаны языком архитектора, а спрашивают иначе. Модель называется «Управление обращениями по качеству продукции», вопрос звучит «куда жаловаться на брак».
Папки устаревают. Оргструктуру поменяли, направление переименовали - выученные маршруты перестали работать.
Любая из этих мелочей терпима по отдельности, но вместе они делают поиск в реестре дороже, чем вопрос коллеге. Поэтому реестром не пользуются.
Петля: от ненайденного ответа до потери бюджета
Дальше запускается цепочка, которую мы видели у клиентов не раз:
Описали процессы → сотрудники не смогли найти → перестали искать → модели никто не читает → модели устаревают, ведь незачем актуализировать то, что не читают → доверие к базе падает → «зачем мы вообще это описывали?» → процессная команда теряет бюджет.
Петля стартует не с качества описаний, а с того, что ответ не нашли. Знание, которое не находится за десять секунд, проигрывает вопросу в чат при любом качестве моделей: люди идут самым дешёвым путём к ответу. А поиск внутренней информации дорог даже там, где работает: McKinsey оценил, что на него и на обращения к коллегам у сотрудника уходит почти день каждой рабочей недели.
Чем короче путь от вопроса до ответа, тем больше людей по нему дойдёт. Каждый лишний шаг отсеивает часть: другая система, забытый логин. А если ответ доступен только в десктопной программе, которую ставят по заявке в ИТ, дойдут единицы - какой бы хорошей ни была модель внутри. Лучше всего, когда ответ есть в инструменте, который у сотрудника и так открыт.
Значит, чинить надо стоимость пути: чтобы найти было дешевле, чем спросить.
Поиск по бизнес-процессам: Ctrl+K с любого экрана
Этим летом Stormbpmn запускает поиск как главный вход к процессам - вместо навигации по дереву. Нажмите Ctrl+K в любом месте приложения, чтобы искать сразу по всей процессной архитектуре: моделям, ролям, элементам архитектуры, задачам на диаграммах и статьям справки.
Один запрос «как согласовать договор» - и в выдаче сразу процесс, ответственная роль, конкретная задача на диаграмме и статья справки.
Поиск идёт по содержимому, а не только по названиям: индексируются элементы диаграмм, описания ролей, текст задач. Достаточно помнить, про что был процесс, - название модели и папку знать не обязательно.
Семантика: искать своими словами
Классический полнотекстовый поиск ломается на синонимах: в модели написано «закупка», человек ищет «покупка» - и получает пустую выдачу, хотя ответ существует. Поэтому под поиском в Stormbpmn работает семантический движок: он сопоставляет смысл запроса с содержимым, даже когда слова не совпадают.
Слова «покупка» нет ни в одной модели - но поиск понимает, что речь про закупку, и находит и процесс, и нужную задачу в нём.
Работает и автодополнение: «согласо…» уже подтянет согласования.
AI-ассистент отвечает по вашим процессам
Следующий шаг - когда искать не нужно вовсе. AI-ассистент в Stormbpmn подключён к рабочему пространству команды: он видит ваши модели, роли, элементы архитектуры и базу знаний. Спросите «кто у нас оформляет командировки и по какому процессу» - он разберёт вопрос по вашим реальным моделям и ответит со ссылками на них, а не перескажет учебник по BPM.
Ответ привязан к контексту спрашивающего: команде, процессам, зоне ответственности. Один и тот же вопрос - скажем, про согласование - у юриста и у менеджера по закупкам ведёт к разным процессам, и ассистент понимает это, потому что знает, из какого рабочего пространства и от кого вопрос пришёл. На типовые вопросы описанная архитектура отвечает без участия аналитика.
Найденному ответу нужно доверие
Найти - это ещё не всё. Если сотрудник открыл модель, но не понимает, актуальна ли она и можно ли по ней работать, он всё равно пойдёт переспрашивать в чат, и выигрыш от короткого пути пропадёт.
Доверие создаётся подтверждением: владелец процесса согласовал, коллеги работают именно по этой версии. Поэтому у моделей в Stormbpmn есть статусы и согласование. Открыв найденный процесс, человек сразу видит, что модель согласована, кем и когда, действует ли она сейчас. Поиск приводит к ответу, а статус показывает, можно ли на него опираться.
Кто в компании должен подтверждать знания, чтобы доверие не держалось на одном энтузиасте, - отдельная большая тема.
Что меняется, когда вход - поиск
Сразу оговоримся: поиск не чинит качество самих описаний. Если модели сделаны для галочки, семантика будет быстро находить мусор. Поиск снимает барьер доступа, а актуальность и качество остаются на владельцах процессов.
Реестр тоже никуда не девается: архитектору по-прежнему нужна карта целиком - владельцы, связи, покрытие, метрики. Для остальных сотрудников входом становится строка поиска, и петля начинает крутиться в обратную сторону. Сотрудник нашёл ответ за несколько секунд - в следующий раз он снова пойдёт в поиск, а не в чат. Модели читают, значит владельцам есть смысл держать их актуальными. Доверие к базе растёт, и процессная работа становится видна бизнесу не килограммами описаний, а отвеченными вопросами.
Проверка для вашей компании: засеките, сколько занимает путь от вопроса «как у нас оформляется возврат?» до открытой модели. Если счёт пошёл на минуты - описания есть, но не работают. И чинится это не переписыванием регламентов, а поиском.
Глобальный поиск с семантикой выходит этим летом, и ему хватит тех моделей, которые у вас уже описаны. Опишите процессы в Stormbpmn сейчас - и поиск заработает по ним с первого дня. А если только присматриваетесь к инструменту - вот опыт, как внедрить Stormbpmn в команду и не услышать «рисуйте в Paint».
