Выделение процессов

Какое количество процессов целесообразно выделять в деятельности подразделения? Как и в случае с операциями, количество процессов определяется уровнем рассмотрения. Мы предлагаем следующий вариант выделения процессов (см. рисунок 1.). В первую очередь, необходимо проанализировать результаты деятельности подразделения («выходы») и объединить их по группам (если выходов мало, то группировка может не потребоваться). Далее необходимо понять, как создаются данные выходы (продукты). Другими словами, какие процессы внутри подразделения создают эти выходы. Если выходы существенно отличаются друг от друга, то, очевидно, нужно различать и создающие их процессы.

Рисунок 1. Группы операций.

На рисунке 1 показаны группы операций, каждая из которых включает 3-5 операций. Это одно из возможных представлений деятельности подразделения. Если мы построим более детальную схему, то количество операций и связей между ними станет большим. Если попытаемся сгруппировать операции в более крупные блоки, то схема станет менее подробной. Как быть в такой ситуации, сколько процессов выделять? В случае, когда в деятельности подразделения можно выделить несколько четких, отличающихся друг от друга цепочек создания продуктов, именно эти цепочки стоит брать в качестве основы при построении системы процессов. Если цепочки нельзя выделить очевидным образом (или такие цепочки охватывают лишь часть деятельности), то количество процессов и их границы нужно определять исходя из соображений практической целесообразности. Например, для подразделения из 3 человек выделение двенадцати процессов будет чрезмерным усложнением, а для подразделения из 20 человек выделение 2 процессов может оказаться недопустимым упрощением ситуации. На рисунке 2 показана ситуация после выделения процессов в деятельности рассматриваемого подразделения.

Рисунок 2. Выделенные процессы.

Как видно на рисунке 2, существует две группы операций (А и Б), которые включены в разные процессы. Так группа операций А включена в процессы 2 и 4, а группа операций Б – в процессы 3 и 4. Такая ситуация обусловлена способом определения границ процесса. Если определять процессы, избегая указанной ситуации, то в результате получится система процессов, напоминающая лоскутное одеяло – в каждом процессе будут только уникальные, неповторяющиеся операции. Такой взгляд (его мы называем «сегментированием» процессов) на деятельность обеспечивает четкость, но при этом сложно анализировать и управлять цепочками создания продуктов подразделения в целом. По сути, процессы оказываются во многом искусственно «разорванными» на несколько частей. При другом подходе (как показано на рисунке 2) возможно отнесение одних и тех же операций к разным процессам, которые в этом случае получаются более «длинными», «сквозными». Однако и в этом случае возникают проблемы. Если выделить слишком много таких «сквозных» процессов, то состав операций в этих процессах будет в значительной степени повторяться. Это может привести (при непродуманном подходе к документированию) к дублированию информации в регламентах процессов и к существенным сложностям при разработке и использовании системы показателей для управления процессами. При построении системы процессов подразделения необходимо соблюдать определенный баланс между «сегментированием» и выделением «сквозных» процессов, и, кроме того, помнить о субъективности определения границ процессов.
Возвращать к рисунку 2, отметим, что все 50 операций, выделенных в подразделении, были распределены по четырем процессам.
Очевидно, что выделение процессов в деятельности подразделения является делом достаточно субъективным. Тем не менее, такое выделение позволяет распределить ответственность за выполнение процессов между сотрудниками подразделения и выполнить регламентацию этих процессов. Если при выполнении регламентации окажется, что границы процессов определены некорректно, они могут быть изменены.
Обратим внимание читателя, что построении в компании «сквозных» процессов на межфункциональном уровне, придется прослеживать операционные цепочки за рамками подразделения. Если на предприятии комплексно внедряется процессный подход к управлению, то сначала определяются бизнес-процессы верхнего уровня и участвующие в них подразделения. На основе этой информации определяются процессы (сегменты процессов), выполняемые в подразделениях. В этом случае руководителю подразделения легче установить, в каких бизнес-процессах компании участвует его подразделение, определить границы этих процессов и взаимодействие с другими подразделениями на уровне входов/выходов. В противном случае могут возникнуть серьезные проблемы на «стыках» между подразделениями.

Пример. В одной из крупных российских компаний на протяжении двух лет реализовывались проекты по анализу и описанию двух бизнес-процессов – бюджетирования и материально-технического снабжения. Оба процесса охватывали заранее определенные группы функциональных подразделений. По проекту работали две рабочие группы, в состав которых входили как внешние ИТ-консультанты, так и сотрудники профильных подразделений компании. Модели процессов неоднократно переделывались, уточнялись, проходили многочисленные согласования. На определенном этапе возникла необходимость согласовать две комплексные модели процессов между собой. И тут выяснилось, что группа, занимавшаяся процессом МТС, включила в свою модель операции, связанные с планированием закупок, подготовкой и проведением расчетов за поставляемые материалы, запчасти и оборудование. А вторая группа – выделила и описала эти же процессы в несколько ином виде и включила их в состав процесса бюджетирования. При сопоставлении моделей выяснилось, что не только по составу процессов, но и по входам/ выходам на уровне связанных между собой операций процессы МТС и бюджетирования не стыкуются между собой. Работа проектных групп «зависла» на несколько месяцев из-за нового круга согласований и переработки моделей. Менеджеры обеих проектных групп были заменены.

Для четкого структурирования процессов подразделения целесообразно использовать матрицу ответственности.

Дата добавления: 2015-08-21