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