В этом месяце уже дважды на курсах возникало обсуждение роли владельца процесса. Точнее, очень практический вопрос по этой роли: «Кто бы это мог быть?»
У меня уже давно сложился подход к поиску ответа на этот вопрос. И, более того, в организациях, где с выстраиванием сквозных процессов есть сложности, можно предположить и наиболее вероятный ответ на этот вопрос. Под сквозным процессом здесь понимаю процесс, в выполнение работ в котором вовлечено более одного подразделения. Это, кстати, самый часто обсуждаемый вариант; некоторые эксперты даже утверждают, что это вообще одна из существенных характеристик процесса – быть кроссфункциональным (мне так не кажется, но речь не об этом).

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

1. Мы говорим о роли, не о должности/позиции. Т.е. мы говорим о процессной роли, исполнять которую может как выделенный человек, так и человек, совмещающий эту роль с другими ролями.
2. Нам, разумеется, нужно чёткий список требований к этой роли. Такие списки есть, но в разных источниках эти списки не совпадают. Поэтому нужно договориться, как в нашей процессной модели будет выглядеть эта роль. Сейчас в качестве примера возьмём список для владельца процесса (process owner) из ITIL (в т.ч. потому, что он неплохо соотносится с тем, о чём говорят авторы других умных книг). Если мы при строительстве процессной модели опираемся на другие источники, то описание роль может отличаться, но подхода к поиску ответа на основной вопрос данной заметки это не меняет.

Из раздела 6.3.2 Generic process owner role книги «Проектирование услуг» (Service Design) библиотеки ITIL мы имеем.
«В обязанности владельца процесса входит:

• Спонсорство, разработка и управление изменениями процесса и его метрик
• Определение стратегии процесса
• Помощь в разработке процесса
• Обеспечение наличия и актуальности соответствующей процессу документации
• Определение соответствующих политик и стандартов, которые будут использоваться в процессе
• Периодический аудит процесса для обеспечения соответствия политике и стандартам
• Периодический пересмотр стратегии процесса, чтобы убедиться, что она по-прежнему актуальна и изменяется по мере необходимости
• Обмен информацией о процессе или изменениях, если это необходимо, для обеспечения осведомленности
• Предоставление ресурсов процесса для поддержки видов деятельности, необходимых на протяжении всего жизненного цикла услуги
• Обеспечение того, что исполнители видов деятельности в процессе обладали необходимыми техническими знаниями и пониманием бизнес-составляющей для реализации процесса, а также понимали свою роль в процессе
• Рассмотрение возможностей совершенствования процесса и повышения его эффективности и результативности
• Решение проблем с работой процесса
• Идентификация возможностей совершенствования для включения в реестр постоянного совершенствования (CSI)
• Работа с менеджером CSI и менеджером процесса для анализа и приоритизации инициатив в реестре CSI
• Совершенствование процесса»

На всякий случай ещё раз, описание роли и источник, на который мы опираемся при формировании описания, могут быть другими. Для текущего обсуждения это не так важно.

Теперь мы берём каждый пункт и пытаемся понять, насколько отработка конкретного буллита в списке критична для того, чтобы в нашей конкретной организации процесс функционировал. В том числе можно использовать стандартный подход – оценить все пункты списка, например, по десятибалльной шкале. Где «10» – это «в нашей организации конкретно вот этот анализируемый процесс без этого не выживет» или «мы уже имеем массу проблем в работе процесса ровно потому, данный пункт не отрабатывается».

Таким образом мы получим приоритизированный список требований к роли (и исполнителю) владельца процесса в конкретной организации и для конкретного процесса. Для разных процессов оценки могут различаться. На разницу в оценке может влиять различия в критичности процессов, уровня сложности, и, возможно, организационных/культурных особенностей в определённой части организации. Например, наличие локальной напряжённости между подразделениями, являющимися смежниками в конкретном процессе. Или какой-нибудь специфичный стиль работы конкретного линейного руководителя. Но, на мой взгляд, это оценка всё же в большей степени – оценка организации (собственно, пара последних примеров – это ведь тоже про организацию).

Например, довольно часто в крупных организациях возникают проблемы, связанные с тем, что владельцем процесса назначается руководитель одного из подразделений, задействованных в процессе (например, руководитель первой линии поддержки – владелец процесса управления инцидентами [видели в реальной жизни, и не раз]). Что это означает с формальной точки зрения? Нарушение одного из пунктов списка выше – невозможность обеспечить необходимые ресурсы. Ведь для того, что процесс работал, необходимы не только сотрудники первой линии, но и всех последующих. К чему это может приводить на практике? К тому, что собственными силами данный человек не сможет обеспечить то, что все последующие линии будут работать в соответствии с тем, как процесс был спроектирован. Просто власти не хватит.
Будет ли это реальной проблемой для данной конкретной организации? Как обычно, «это зависит». Если в организации процессный подход уже работает, то, скорее всего, проблем не возникнет (для такой организации данный пункт в списке получил бы невысокую оценку). В конце концов, необязательно, чтобы человек, играющий роль владельца процесса, сам обладал всеми необходимыми полномочиями (хотя некоторые эксперты явно настаивают на том, что владелец процесса должен быть менеджером большинства сотрудников, задействованных в процессе). Ну, а в организации, где так называемая горизонтальная составляющая в матричной структуре и так сильна, тем более. Поэтому в таких организациях владельцы процессов – иногда просто назначенные люди, которые, как и менеджеры процессов/проектов не обладают большими полномочиями и не являются начальниками всем исполнителям в своих процессах. Слово «владелец» к ним применимо довольно условно (они ничем не владеют). Но при этом схема работает.

Но если мы только строим сквозные процессы, и, стало быть, наверняка сталкиваемся с противодействием и непониманием новых порядков, на роль владельца процесса, скорее всего понадобится человек, который обладает полномочиями, достаточными для устранения всех проблемных мест (scope of control охватывает все подразделения, задействованные в процессе). В этом случае тот же самый пункт в списке получит высокую оценку.

Здесь обычно возникает возражение типа: «Позвольте, вы что, предлагаете делать владельцем процесса (например, управление инцидентами) директора по ИТ?»
Это возможный вариант. Но с ним, скорее всего возникнут сложности по другим пунктам списка. Ведь владелец процесса, хоть внепроцессная роль (роль не участвующая непосредственно в работе процесса), всё же нагружена некоторым объёмом работы, которую нужно выполнять на регулярной основе. Вряд ли ИТ-директор [ДИТ] с этим всем справится (особенно с учётом того, что при выбранном подходе этот человек быстро окажется владельцем всех процессов). Как же быть, если размер нашей ИТ-службы не таков, что мы можем наградить данной обязанностью должность ДИТ-1 или ДИТ-2, и эта должность при этом будет выше должностей всех линейных руководителей подразделений, задействованных в процессе? Это случай средних и небольших организаций. Тогда, если мы не можем нагрузить ДИТ этой ролью, нам нужно разрабатывать дополнительные механизмы эскалации, вовлечения и т.п. Потому, что владелец (не обладающий в выбранном сценарии достаточными полномочиями) должен обеспечить… (далее по тексту). Если не своей властью, то административным ресурсом, к которому есть доступ. Насколько оперативен и стабилен этот доступ? Вот об этом и нужно будет подумать.

В этом случае опять слово «владелец» применимо весьма условно. Именно поэтому в литературе по процессному управлению (не ITIL) встречаются названия «управляющий процесса» (хотя мне лично больше нравится «распорядитель» – process steward), «спонсор процесса» (process sponsor) и т.п. Т.е. картина усложняется.

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