Мы знаем из Agile что лучший метод постановки задачи и описания ТЗ на разработку это истории пользователей (ИП).

Как-то описывали бизнес-процесс для одной строительной компании по методу ООР и осознал что это по сути структурированный набор ИП.

Берем инструкцию и понимаем что нам нужно дописать в системе чтобы этот процесс пошел как по маслу.

Обычно описание процесса в такой форме состоит из 5 разделов и составляет от 1 до 3 страниц.

Если описание процесса заняло более 3 страниц, вероятно вы описываете не процесс, а что то иное.

Перед тем как начать описание процесса — важно понять, а процесс ли это?

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

Как определить процесс?

Самый простой способ понять процесс перед нами или нет, это чек лист из 3-х условий:

1. Результатом будет какой-то продукт

2. Начинается он с какого-либо понятного события

3. Его операции подлежат регистрации и могут иметь регистрационный номер

Если хотя бы один из этих пунктов — отрицательный. Это не процесс. Вы можете начать это описывать, но толку не будет.

Как его описать?

Если вы убедились что перед вами процесс, и вы хотите его описать 🙂 То нужно разбить его на 5 основных шагов:

  1. Определение — тут прописываем условия по которым определяем событие, с которого начинается процесс. Это нужно чтобы сотрудники могли отличать начала одних процессов от других.
  2. Регистрация — тут прописываем действия о том где и как мы должны зарегистрировать операцию по процессу
  3. Подготовка — тут описываем действия требуемые для подготовки
  4. Исполнение — все то что нужно для исполнения
  5. Закрытие — все то что нужно сделать для закрытия. Какие галочки и кнопочки нажать. Какие документы и куда подшить, и т д

Особенности

Нужно понимать ряд особенностей, которые встречаются в этих делах:

  1. Как правило все описание процесса это структурированные истории о том кто и что делает. Это очень просто читается для тех кто будет исполнять процесс. И очень круто помогает программистам понять как настроить ПО для автоматизации процесса, если таковое имеется или планируется.
  2. Все пункты инструкции должны иметь уникальный номер. Это важно в тех ситуациях, когда процесс дает сбой и нужно понять какой шаг вызвал сбой, обсудить его и понять как исправить проблему. Да и просто удобно ссылаться на нужный шаг, когда обсуждается процесс или происхоит обучение сотрудников.
  3. Основных шагов 5. Но никто не мешает делать нам их разделять на более мелкие шаги. Я не уверен что можно делать 6 шагов. Но и не имею ничего против. Опасаюсь только процессов описанных через более чем 7 шагов.
  4. Картинки, видео, аудио, схемы — все что касается визуализации и озвучивания — это круто. Не стесняйтесь включать эти элементы в описание. Правда для этого нужно чтобы ваши регламенты работали на базе веб-технологий и облаков. Бумажные носители или что-то типа Word — не позволят нормально реализовать эту идею. Мы делаем описание процессов на базе WordPress и потому у нас с этим проблем нет 🙂

Выводы

Как понять что вы сделали правильно описание бизнес-процесса?

Все очень просто — его начнут использовать.

Мы проверяли это через метрики. Отслеживали читаемость процессов на портале для сотрудников. Правильно описанные процессы — были очень популярны и сотрудники к ним обращались чтобы уточнить те или иные моменты. Обучиться или проверить себя или коллег.

Также эти процессы попадают почти без изменений к программистам, чтобы оптимизировать процесс при помощи ПО.