Как описать бизнес-процессы: реестр, границы и схема

Реестр процессов

Реестр отвечает на вопрос, что у компании вообще есть. Для среднего бизнеса это десяток-полтора сквозных процессов: обработка заказа, согласование договора, закупка, приём сотрудника, рекламация, выпуск релиза.

Правильный уровень дробления проверяется просто. Процесс начинается запросом заказчика — внутреннего или внешнего — и заканчивается результатом для него. «Проверка комплектности документов» этому не отвечает: это шаг внутри процесса.

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

Границы

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

Событие начала должно быть наблюдаемым: поступила заявка, подписан акт, наступила дата. «Возникла потребность» наблюдать нельзя, и такой процесс невозможно ни измерить, ни запустить.

Событие окончания определяется по заказчику. Для процесса согласования договора это не «юрист поставил визу», а «договор подписан обеими сторонами»: именно этого ждёт тот, кто его запускал.

Схема за одну встречу

Соберите участников всех шагов на два-три часа и нарисуйте фактический порядок. Схема, составленная по регламенту в кабинете аналитика, описывает задуманное; работа при этом идёт по другому пути.

Начинайте с основной ветки без исключений: как проходит типовой случай. Развилки добавляют вторым заходом, иначе схема разрастается и встреча вязнет в редких сценариях.

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

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

Насколько строгая нотация нужна

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

Из BPMN на практике хватает четырёх вещей: события начала и конца, действия, развилки по условию и дорожки по ролям. Полный набор элементов велик, но остальное требуется редко и обычно указывает на то, что процесс стоит упростить.

• Событие. Что запускает процесс и чем он заканчивается. Обязательно наблюдаемое.
• Действие. Шаг работы с исполнителем-ролью. Название по глаголу: «проверить комплектность».
• Развилка. Условие ветвления с явно названными вариантами. Вариант «прочее» — признак недоописанного процесса.
• Дорожка. Роль, выполняющая шаги. Роль без фамилии и без названия отдела.

Чтобы описание не устарело

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

Поставьте пересмотр в календарь: полдня раз в квартал вместе с владельцем. На пересмотр приносят данные об отклонениях — они прямо показывают, какие места схемы разошлись с жизнью.

Ведите журнал изменений с причинами. Через год он отвечает на вопрос, почему шаг выглядит именно так, когда автора уже нет в компании.

Уровни описания

Описание сделано пригодным к работе

Описание считается готовым, когда по нему может сработать новый человек и когда его есть кому обновлять. Проверьте по пунктам перед тем, как утверждать.

Где держать описание в Shtab

Держите схему страницей внутри того же проекта, где идёт работа по процессу: тогда она открывается в два клика с доски и обновляется вместе с процессом.

Частые вопросы