Бизнес-процессы

Описание любого бизнес-процесса осуществляется в три очевидных шага.

• Шаг. 1. Описание границ бизнес-процесса.
• Шаг 2. Построение схемы бизнес-процесса верхнего уровня.
• Шаг 3. Разрабатывается схема нижних уровней для каждого подпроцесса.

Давайте рассмотрим эти шаги на примере процесса подбора персонала.

Шаг. 1. Описание границ бизнес-процесса  

На рисунке 1 показана схема окружения процесса, которая задает его границы. Мы видим, что процесс начинается, когда поступает заявка на подбор и эта заявка поступает от руководителя подразделения. Окончанием процесса или выходом является подобранный сотрудник, а потребителем — тот же самый руководитель подразделения. То есть, с помощью такой схемы мы показываем входную границу, инициатора, выходную границу и кто является потребителем.

Если взять аббревиатуры от английских слов supplier — это поставщик, input — вход, process — это сам процесс, output — выход и customer — потребитель, то и получается SIPOC. Поэтому описание границ бизнес-процесса также называют SIPOC-описанием.

Рис. 1. Шаг. 1. Описание границ бизнес-процесса «Подбор персонала».

Шаг 2. Построение схемы бизнес-процесса верхнего уровня

Далее на шаге 2 процесс разбивается на крупные подпроцессы. На рисунке 2 приведен пример разбиения бизнес-процесса «Подбор персонала». Этот процесс разбит на пять подпроцессов и, таким образом мы получаем диаграмму верхнего уровня процесса «Подбор персонала». В зависимости от нотации, соглашений по моделированию или стандартов по описанию процессов могут использоваться различные виды диаграмм верхнего уровня. Однако, в общем случае на диаграмме верхнего уровня для процесса показываются крупные подпроцессы, ответственные за эти подпроцессы, а также потоки. Каждый поток является выходом одного подпроцесса, является входом для другого подпроцесса. В данном примере для всех процессов показан один вход, один выход. Потоки могут быть информационные или материальные.

Я рекомендую на таких диаграммах показывать только самые главные потоки. Те потоки, которые запускают подпроцесс, и те, которые являются главным выходом подпроцесса. Потому что, если показывать много дополнительных потоков, то получается большое количество стрелок, они пересекаются, это существенно ухудшает читабельность схемы бизнес-процесса. Поэтому на рисунке мы показали лишь наиболее главные потоки, а все вторичные и второстепенные потоки, о которых мы конечно же не забываем, мы покажем на диаграммах более нижнего уровня.

Рис. 2. Пример разбиения процесса «Подбор персонала» на крупные подпроцессы

Шаг 3. Разрабатывается схема нижних уровней для каждого подпроцесса

И далее, на третьем шаге, для каждого подпроцесса, строятся диаграммы нижнего уровня. Если мы хотим этот процесс описать полностью, то мы должны для пяти подпроцессов построить 5 диаграмм нижнего уровня.

На рисунке 3 показана диаграмма для подпроцесса «Стандартное согласование кандидатуры». Такая диаграмма называется диаграммой нижнего уровня. Здесь у нас появляются более мелкие подпроцессы или действия и на таких диаграммах показываются новые элементы: события и логические операторы (операторы XOR (исключающее ИЛИ), AND (И), NOT (НЕ), а также OR (ИЛИ)). В данном случае я показал простую нотацию, на которой события показываются только в начале и в конце подпроцесса. Мы видим, что подпроцесс состоит из четырех действий. И с помощью логических операторов мы показываем куда процесс дальше движется, в зависимости от некоторых условий. Сначала происходит оформление листов согласования кандидатур, это делает менеджер по подбору персонала. Далее руководитель подразделения согласовывает кандидатуры. И здесь возможны две ситуации: согласование либо пройдено, либо нет. Если нет, то наступает событие «кандидатура отклонена». Если да, то дальше, начальник отдела кадров принимает решение о необходимости согласования кандидатуры гендиректором. Здесь также возникает аналогичный логический оператор, так как возможны две ситуации.

Если мы видим согласования не требуются, то кандидатура принята. Если согласование требуется, то возникает еще действие — согласование кандидатуры гендиректором. И здесь также возможны две ситуации: согласование либо пройдено, либо нет.

Если нет, то наступает отрицательное событие: «Кандидатура отклонена». Если да, то наступает положительное событие «Кандидатура принята». С помощью такой блок-схемы мы описываем алгоритм процесса, четко показываем последовательность шаги процесса, а также в зависимости от каких условий наступают те или иные события, либо начинают выполняться шаги процесса.

Рис. 3. Диаграмма для подпроцесса «Стандартное согласование кандидатуры»

Также обращаю внимание, что вот на диаграмме для подпроцесса «Стандартное согласование кандидатуры» не показаны входы-выходы. Это сделано по той причине, что, во-первых, на этом уровне действия уже достаточно простые, и всех уже понятно, что является входом, а что выходом. Этого достаточно, чтобы прочитать диаграмму и, таким образом, мы добиваемся того, что диаграмма остается простой и читабельной.

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

Цель — двухуровневое описание бизнес-процесса

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

• делать диаграмму верхнего уровня; 
• для каждого подпроцесса делать диаграмму нижнего уровня.

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

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

Комментарии 0