При описании бизнес-процессов часто сталкиваешься с ситуацией, когда нужно определить, до какого уровня копать? Некоторые процессы интуитивно понятны и просты, а некоторые являются сложными комплексными. Как понять, где остановиться?
Один из примеров процессной иерархии приведен в BPM CBOK:
Уровень 1: Процесс
Уровень 2: Подпроцесс
Уровень 3: Бизнес-функция
Уровень 4: Поток работ
Уровень 5: Задачи и сценарии
Цель декомпозиции процессов и процессной иерархии — не только показать, что куда входит, но и иметь возможность создавать схемы и описание процессов, действий, работ по каждому блоку отдельно, не теряя целостность картины, понимая место конкретных действий.
Полная схема всех процессов в рамках одного дерева, скорее всего, будет нечитаемой. Гораздо удобнее сначала создать схему 1го — 2го уровней, а затем на отдельных схемах показать их декомпозицию на бизнес-функции, работы, действия.
Всегда ли нужны все пять уровней? Думаю, что не обязательно. Работа не должна быть ради работы, если уже на 3 уровне будет ясно и понятно, что делать, то на нем можно остановиться, отложив более глубокую проработку на будущее, и приступить к более приоритетным задачам.
Как понять, где остановиться в декомпозиции процессов?
Можно ответить на него так: описывать нужно до такого уровня детализации, когда каждому в процессе ясно:
- Что (конкретное действие),
- Кто (ответственный),
- Когда (в какой момент времени, когда начинать, сколько времени выполнять),
- Как (конкретный алгоритм, инструкция),
- Где (рабочее место, ПО),
- Чем (инструментарий)
- С чем (активы/пассивы, информация,…) делает.
Т.е. ключевой параметр – понятность и однозначность.
Например, есть процесс «Продажи».
В чем он заключается: Менеджер по продажам находит клиента, договаривается, заключает сделку, выполняет условия сделки, предоставляя объект сделки покупателю и получая от покупателя определенные в сделке активы.
Вроде бы, всё понятно, но чего-то не хватает.
Если мы торгуем на рынке в розницу «с колес» за наличный расчет (купил-продал) по фиксированным ценам, то, возможно, продавцу будет понятно: видишь человека, предлагай ему товар, бери деньги, отдавай товар. Всё.
Но, что делать, если условия чуть сложнее и выбор вариантов чуть больше? Например, продать можно за наличные или по безналу, в рассрочку или в кредит? Если покупатель просит скидку? Если на рынке есть ограничения? Если рынок высококонкурентный, а покупателей найти не просто? Если можно использовать различные методы привлечения клиента, какой выбрать? И т.д.
В этом случае процесс необходимо детализировать до подпроцессов:
Например, описать отдельно поиск клиента (первый подпроцесс), заключение сделки (второй подпроцесс) и т.д.
А что, если какой-то из подпроцессов выполняется несколькими подразделениями, для каждого из которых также существует несколько вариантов действий?
В этом случае стоит описать функции каждого подразделения, его задачи, конкретные работы и действия.
Т.е. остановиться стоит тогда, когда исполнитель понимает: «делать только так» — простая понятная цепочка действий. В итоге не должно остаться развилок, алгоритм которых не описан. Если есть в процессах или функциях участок, где у исполнителя есть выбор, делать/не делать/делать так или иначе, эти ситуации должны быть описаны.