Как описать бизнес-процесс: пошаговая методика

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

Начните с рамки

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

Соберите фактический путь

Интервью недостаточно: сопоставьте ответы участников с документами, задачами и реальными примерами. Зафиксируйте:

• Шаг и его измеримый результат
• Роль, выполняющую работу, а не имя сотрудника
• Входные данные, документы и системы
• Условие перехода к следующему шагу
• Срок ожидания и правило эскалации
• Исключения, возвраты и ручные обходы

Проверьте схему на экземпляре

Возьмите несколько недавних случаев, включая проблемный, и проведите их по схеме. Если реальный путь не помещается в модель, уточните условие или исключение. После проверки участники должны одинаково понимать начало, завершение и ответственность.

Подготовьте к улучшению

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

Перенесите схему в исполняемый процесс

Покажем, как связать шаги, роли, условия и сроки в процессном модуле Taska.

Минимальный комплект рабочего описания

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

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