Развёрнутый комментарий к статье Фактический владелец бизнес-процесса. Кто им является? Вопрос по Владельцам - сложный, тут привел только то, что "на поверхности".
В той статье проблема показана верно, но решения ее так и нет. И это одна «из подножек» концепции процессного подхода. Лозунг «руководитель компании – владелец всех процессов» - формально верен, но не практичен, а отсылка к бригадной организации работ – это к доФордовской промышленности.
1. Проблема «Обязанности без полномочий»
никто из руководителей функциональных подразделений не стремиться взять на себя еще одну дополнительную ответственность и обязанность,
Да, в сквозном кросс-функциональном процессе роль «Владелец процесса» - проблематичная.
С одной стороны, он должен иметь власть \ полномочия и «рулить» своим процессом, т.е. должно быть «процессное единоначалие» в рамках выделенного верхнеуровневого процесса (обычно сквозного). С другой стороны, уже есть руководители отдельных подразделений (орг-структура), т.е. «власть уже поделена ранее». Создавать еще одну руководящую структуру – накладно (а руководителей обычно и так как …). В целом дилемма «процессное управление» vs «функциональное», а некое "матричное управление" – это некий не особо работающий компромисс, см. 2.4 Матричная организационная структура.
На текущий момент проблема взаимодействия разных подразделений (разного подчинения) решается через процессные регламенты \ инструкции, но это как правило решение «так себе».
Как правило, назначение Владельцем процесса (а это как правило один из руководителей структурного подразделения – оно же «функциональное») – добавляет только обязанности, но не выдает прав и полномочий, т.к. «власть над подразделениями» уже поделена в рамках орг-структуры. Поэтому от статуса «Владелец процесса» обычно сторонятся (зачем лишний «груз» \ ответственность), т.к. "власти над процессами \ его ресурсами" не дают.
2. «Всему нужна голова» (владелец, хозяин)
А нужно ли вообще назначать владельца бизнес-процесса?
Вспоминаем А. Райкина «Кто сшил костюм?». Конечно единый ответственный должен быть. Хотя бы общий координатор, который пусть и не детально, но знает весь процесс (костюм) целиком. Примерно, как ГИП в строй-проектах. Пока в процессной (BPM) литературе содержатся только общие лозунги в части «Владелец процесса». Вообще, пока BPM-литература далека как от реального «научного менеджмента», так и вообще от «научного подхода» в «процессом подходе».
Проблема процессных регламентов (без владельцев процессов) в том, что именно по ним будут «искать крайнего» - когда «что-то пошло не так», поэтому в них стараются занизить степень своей ответственности и указать, что каждый отвечает только за «пуговицы или рукава». При этом образуется много «пустых» зон ответственности и соответственно возникает проблема «по Райкину» - отсутствие «зонтичного» подхода \ агрегированной ответственности (не путать с коллективной). Назначив «номинального» владельца процесса мы тем самым заранее указываем, кто будет виноват «если что-то пошло не так», или с кого начать «искать крайнего» и далее вычитывать и интерпретировать «обтекаемые» формулировки в «толстом» регламенте процесса. Кстати, часто поэтому и не делают полностью автоматическими процессы – тогда кого наказывать-то? Робота \ RPA?
3. Подходы к назначению Владельцев
Владелец продукта
На выходе сквозного процесса – Продукт и логично было бы назначать Владельцем процесса – Владельца результата этого процесса – т.е. Владельца продукта. Однако часто Владелец продукта вообще не участвует в этом процессе.
Топ-менеджмент
Логично было бы назначение Владельцев процессов из Топ-менеджмента компании. Только это бывает редко, т.к. это также добавляет не только ответственности и «волокиты», но и непонятные взаимоотношения (конфликты интересов) с другими Тор-менеджерами – участниками этого же процесса (подчиненные им подразделения). Кроме того, небольшая группа Топ-менеджеров и большая номенклатура сквозных верхнеуровневых процессов не совсем хорошо согласуются.
Руководитель компании
Наиболее подходящей креатурой для назначения «владельцем» процесса с точки зрения понятия операционного процесса является только руководитель компании
Вывод верный, но утопичный. Он и так отвечает за "всё" в компании. Владельцы процессов - это по сути "его замы", только в процессной плоскости.
Бригадир
Бригадное управление – это организация труда в доФордовской промышленности. Подробнее показано в 3.1 Бригады дофордизма.
В них (бригадах) – да, проблемы с назначением Владельца процесса не стояло - это был бригадир. Сменный бригадир или постоянный – вопрос отдельный, но не столь принципиальный, если технология работы не меняется «под нового бригадира».
К бригаде и бригадиру
Возврат к бригадам – это конечно не выход. При бригадном подходе нет балансировки загрузки узко-специалистов разных бригад (неравномерная загрузка)), узко-специалисты разных бригад не обмениваются опытом (даже скрывают, если есть соревнования между бригадами, а механизм соревновательности – хороший метод) и т.п.
Пример формирования бригад («Назад к Э. Левассору»): Этап 1. Формирование кросс-функциональных подразделений: расформировать ИТ-подразделение и передать специалистов кого-то в производство, кого-то в бухгалтерию.
Этап 2. Формирование сквозных (end-to-end) бригад, когда даже отдельных бухгалтеров могут переводить в производственную бригаду для учета операций, выполненных бригадой.
При этом, бригадир не может оценить проф-пригодность узко-специалиста. Узко-специалисты становятся незаменимыми и начинают вести себя соответственно (в т.ч. «дурят» бригадира).
Хотя преимущества также есть (единоначалие, сплоченность коллектива, работа на общий результат, гибкость тех-процесса, например, внесение корректировок в технологию «на лету» и т.п.), но это все же «позапрошлый век».
Задача не перейди обратно к бригадам, а использовать их преимущества, в том числе, наличие Владельца процесса – Менеджера процесса – Бригадира. Однако решения пока нет.
«Синий» подход
В «бирюзовых» компаниях или при социализме \ коммунизме тоже видимо не должно быть проблем с назначением Владельца процесса. В корпорате, а это обычно «синие» компании (бюрократия и «порядок-закон»), внутри компании работают такие же рыночные принципы: борьба за ФОТ, за лучшие помещения \ условия (только) своим сотрудникам, за расположенность руководителя компании и т.п. Поэтому призывать внутри компании «чтобы всем было хорошо» (и "всем процессам" и всем подразделениям) - это, как и на «большом рынке» (в рыночной экономике) - призывать чтобы всем компаниям «было хорошо», что исключает конкурентную борьбу – основу «невидимой руки рынка».
Тем не менее и в современных капиталистических «синих» компаниях встречается добровольный выбор статуса «Владелец процесса». Иногда выбор очевиден и «деваться некуда», например, когда львиная доля процесса за одним подразделением хоть он и кросс-функциональный.
Иногда бывают ситуации, когда образуются новые подразделения – которые должны или «себя проявить» или «собрать под себя» побольше задач \ ресурсов и т.п. («застолбить поляну»). В этом случае подразделение берет «на себя» авансом дополнительную нагрузку – ответственность, как правило, с расчетом на ее «монетизацию» в будущем, т.е. в перспективе под нее выделения статусности и ресурсов.
4. Итого: Что делать?
Обычно статус Владельца процесса – это (в общем случае, хотя конечно есть исключения) некий «Козел отпущения», который отвечает за всё: все неудачи процесса, надежность его функционирования и результат процесса, но реальных рычагов управления не имеет, т.к. делиться властью и полномочиями никто с ним не хочет.
Как дать полноту власти «над процессами», при этом не ущемив власть «над сотрудниками» (власть руководителей структурных подразделений, закрепленную орг-структурой) – не понятно, т.к. процессными регламентами решается только частично (такой регламент - основа матричного управления). Да и вообще процессный регламент даже в «синей» компании – редкость, т.к. в основном подразделения делают «свои» - «функциональные регламенты» (локальную нормативку) - в одну инструкцию вписывают только свои операции, а целостный сквозной процесс – нужно «руками собирать» по нескольким таким инструкциям.
Чаще всего происходит директивное назначение руководителем компании кого-либо Владельцем процесса: раз желающих нет, то «кто не спрятался я не виноват», но «зонтик» \ единый ответственный нужен. Условно: выбрали основных участников процесса и "бросили жребий" (выдали «черную метку»).
Хотелось бы формализовать вариант – «справедливого» \ объективного назначения Владельцев. Как-то было собрался составить алгоритм выбора: собрать побольше критериев в анкете и далее через веса каждого критерия формулой задать автоматический выбор (назначение). Однако думаю, что скоро это сможет сделать ИИ. Только он должен это делать не по регламентам (проблемы указаны выше), а на основе чего-либо типа Process \ Task Mining (регламенты только как дополнение). При появлении внутри компании «Enterprise RAG» - это станет простой задачкой, впрочем, как и многие другие задачки «процессного управления». Возможно на роль Владельца процесса будет назначен «цифровой руководитель» - ИИ «Искусственный Владелец процесса».
Некоторые ссылки
Треугольник орг-структур компании. Часть 1
Digital Twin. Часть 2. Инструментальный Цифровой двойник
Проектный Менеджер в IT. Обязанности без полномочий
owner.md - Geary Rummler, Michael Hammer и др., все говорят, что Владелец процесса - нужен, но как организовать институт Владельцев - остается загадкой.
Что понимается под управлением процессом и процессом управления
Функциональный и процессный подход к управлению – это альтернативы или тождества?
PS1
Некоторые подходы
1 "Бить врага поодиночке"
Чтобы упростить задачу, можно ее декомпозировать. Декомпозировать задачи Владельца («размазать» роль), например, выделить Куратор процесса, Менеджер процесса и др. (например, выделенный проектный менеджер по управлению изменениями процесса).
2 В основе - бригадный подход
Задача – взять лучшее от бригадного подхода и его применить на функциональную орг-структуру предприятия. Компромисс процессной структуры – в виде (форме) матричной – обычно нерабочий вариант.
Как в КросФункциональную команду, реализующую сквозной end-to-end процесс, добавить «бригадира» - Владельца? Который не только видит весь процесс целиком (видит «лес», а не «деревья»), но и имеет полномочия «подруливать процессом» - полномочия управлять участниками процесса в каждом экземпляре процесса. Последнее это уже скорее Менеджер процесса (Координатор процесса).
Владелец процесса vs Менеджер процесса. Владелец процесса может совмещать роль Менеджера процесса, но это более низкий уровень операционного управления (Владелец процесса – обычно из ТОП-менеджмента).
3 SuperOwner
Что Владельцы процессов нужны – это понятно. Но откуда их взять, особенно с указанными на слайде В. Репина требованиями (см. спойлер, такие вообще бывают кандидаты)?
Критерии выбора владельца процесса
1 Глубокие знания бизнес компании и достаточный опыт работы
2 Хорошие навыки менеджмента, в том числе, управления проектами, навыки системного мышления и анализа информации
3 Лидерские качества, умение выполнять роль тренера, навыки презентации и убеждения
4 Высокие коммуникационные навыки, эмоциональный интеллект
5 Уважение в коллективе
6 Знание методик процессного управления, бережливого производства, управления рисками и проч.
7 Знание современных технологий автоматизации и цифровизации
Создать выделенный (без совмещения с руководством подразделений) институт Владельцев процессов – скорее не реально, т.к. это увеличит руководящий (высокооплачиваемый) состав вдвое (если не втрое).
«Навесить» на текущих руководителей подразделений (орг-структуры) дополнительно роли Владельца – решение «так себе», т.к. по сути приведет к их перегрузке и также увеличению штата топ-ов.
4 Мотивация и KPI
КПЭ владельца – против КПЭ исполнителя владельца? У KPI Владельца процесса вроде как должен быть кумулятивный эффект по отношению к участникам. Однако ожидания исполнителя процесса от процесса и владельца от процесса - разные и вообще "Свойства целого не равны сумме свойств элементов". Скорее всего процессу свойственна Эмерджентность (синергичность, системный эффект) и вообще интересы участника процесса и владельца могут быть взаимоисключающие.
Более того, полагаю, что цели Владельца продукта процесса и цели Владельца продукта тоже могут быть разные и во многом противоречивые. Хороший результат процесса (результативность процесса) и оптимальный процесс – это две большие разницы. Поэтому назначать владельцем процесса – владельца продукта (продукт процесса, выход процесса) – не совсем верно, т.к. у него может не быть заинтересованности в оптимальности процесса. Не участника процесса – тоже проблематично, но как вариант - некий «смотрящий» (его подразделение не участник процесса), который "погружен" в процесс на основе какой-то мотивации. Только лучше выбирать Владельца процесса конечно из участников процесса, причем с наибольшей долей загрузки в этом процессе.
5 Change Management
Управление изменениями в процессе - тема из "Управление изменениями в проекте" (для значимых изменений). На эту тему в BPM отдельная ветка как смесь BPM \ PMBOK.
Только бывают разные изменения. Например, типовая ситуация - приходит новый ТОП и под него кроят орг-структуру компании: от одних подразделений "отщипывают" отделы и добавляют во вновь создаваемое или укрепляемое (расширяемое). Когда приходит новая команда ТОП-ов, то орг-структура может измениться "до неузнаваемости". Это про орг-структуру. Только примерно то же самое может случиться и с нарезкой верхнеуровневых процессов: одни сквозные процессы укорачивают, а другие наоборот удлиняют (или иначе "перетусовывают"). При этом процессы на нижнем уровне могут не меняться (меняется только верхнеуровневая схема).
Формально результат изменений процесса - обновленный регламент процесса. Каково участие Владельца процесса в этом "проектном мероприятии"? Точно не в качестве Менеджера проекта (при значительных изменениях в бизнес-процессе).
6 Мониторинг процесса
Хорошо, когда у Владельца процесса (да и остальных, включая ГД) есть монитор реализации экземпляра процесса в реальном времени. При этом фиксируется самый плохой экземпляр и самый хороший. Далее разбор причин \ полетов. Потом поощрение конкретных ФИО - исполнителей этого "хорошего" экземпляра (не роли или подразделения, а именно конкретного участника, точнее участника большинства "хороших" реализаций процесса), доска почета, премия и т.п.
Через мониторинг отдельного экземпляра можно внедрить мотивацию (это основа), но главное можно говорить о реальном управлении, т.к. «можно управлять только тем, что измеряется». Однако часто руководители скрывают такой мониторинг, ибо "вдруг все узнают, как мы плохо работаем" и тема мониторинга процессов ими блокируется (мы сами промониторим то, что нужно). Тема мониторинга (в т.ч. президентского мониторинга в компании) - это про организацию независимого подразделения мониторинга процессов, а не мониторинг "на местах".
7 Конференция «Практика анализа и оптимизации кросс-функциональных бизнес-процессов» (19.11.25)
Конференция во многом была посвящена именно проблеме Владельца процесса. Только решения проблемы я так там и не услышал. Сознательность Владельцев процессов (якобы должны проявлять сознательность и не отказываться от предложения роли Владельца процесса), вызванная «высокой зрелостью процессного управления в компании» - это «сказки» процессного управления, которые может быть и реализуются в бирюзовых компаниях, которые к тому же в РФ никто не видел (про них обычно только говорят).
Слайд В. Репина с конференции:
п. 5 Стимулирование. Однако, если в компании нет денег под выделенный институт Владельцев процессов, то про дополнительное стимулирование исполнителей обычно: "Денег нет, но вы держитесь" (даже появление на "доске почета" требует хоть небольшой, но премии, иначе станет анекдотом). Поэтому, видимо инструментом остаётся только наказание за нарушения утвержденного регламента процесса.
8 co-owner
Когда не могут найти Единое ответственное лицо по процессу, то прибегают к уловке: или создать "коллегиальный орган" - "группа владельцев процесса Х" или (что в целом тоже самое) - назначить несколько совладельцев на процесс. Это неверный путь.
Владелец может иметь замов по каждому направлению - группы подпроцессов или по каждому подпроцессу. В этом случае, он являясь "зонтичным" владельцем и формально (номинально) отвечая за "процесс в целом" делегирует полномочия и ответственность своим замам. Подобное нужно фиксировать: формально оформлять статус "Владелец подпроцесса" = "зам. Владельца процесса" (для каждого зама).
9 Владелец автоматического процесса
Для процессов с высоким уровнем автоматизации процесса (для коэффициента автоматизации k=1 получаем полностью автоматический процесс) вопрос владельца уходит "в сторону ИТ". В большинстве случаев логика выполнения процесса в этом случае "спрятана в коде" и бизнес-руководитель говорит, что он не особо понимает "как там всё работает".
Например, бухгалтера не понимая алгоритм расчета часто перепроверяют расчет из бухгалтерской программы в excel.
В подобных случаях есть порочная практика (тенденция) назначать владельцем автоматических бизнес-процессов (не ITIL) - службу автоматизации компании. Иногда главной причиной не внедрять полностью автоматический процесс является: А кого мы тогда сделаем виноватым (крайним), если что-то пойдет не так? Тем самым подчеркивается статус Владельца процесса - как "козла отпущения".
Конечно Владелец процесса - это "Главный по процессу" вне зависимости от уровня автоматизации (гиперАвтоматизации) процесса, как впрочем BPM в общем случае - это не про автоматизацию, а про формализацию (и немного семантизацию процесса и предприятия и стандартизацию операций \ ресурсов).
PS2 Владелец процесса vs скрам мастер
1 Процессный и Проектный подход – разные по природе, см.
В толковый словарь Business Process Management: Процесс vs Проект
Проектирование процесса, проектная команда, не важно она из мира эджайла или каскада, но это про созидание, проектные риски (неопределенность – новизну) и т.п. Если говорить про перепроектирование процесса – это «сюда», но это (проектирование процесса) все же не основная составляющая деятельности Владельца процесса, хотя и важная. Владелец процесса - скорее дирижёр, а не compositor (составитель).
Процессная команда и Владелец процесса – это скорее, когда уже есть ноты, оркестр и дирижёр. Исполнение партии возможна и без дирижёра, т.к. есть ноты - регламент. Понятно, что кроме регламента (нот) нужны квалифицированные исполнители процесса (см. Квартет Крылова).
Дирижёр не только формирует динамику, ритм, артикуляцию, которые могут отличаться от нотной записи, что является обычным явлением и зависит от художественной интерпретации дирижером произведения, но и в зависимости от контекста он добавляет некоторые более существенные акценты. Он реализует свое понимание музыкального произведения (бизнес-процесса) для улучшения его исполнения. Например, если нот�� указывают на медленное tempo, но дирижер при этом показывает очень быстрый темп, он может делать это, чтобы передать определенное настроение или эмоцию, которое не отражено в нотах. Если в нотах есть ошибка, то дирижер исправляет ее на ходу. В целом, хорошо было бы, если Владелец процесса некоторые экземпляры мог бы притормозить, а другие наоборот, ускорить, но это не основная его задача и обычно у него нет таких «рычагов» (возможностей, полномочий) – что опять же упирается в проблемы матричного управления.
Процесс (бизнес-процесс, регулярный процесс) – это «рутина», высокий уровень повторяемости операций и т.п. Обычно скрам, эджайл – это про разработку (обычно ПО), т.е. проект, проектный менеджер, команда проекта. В процессной части - изменения обычно редкие и там в основном уже устоявшийся процесс и Владелец процесса - скорее дирижер, который просто координирует участников. Процесс «в основе» остается прежним, только более контролируемым и с лучшей реакцией при возникновении критических ситуаций (чрезвычайных, нестандартных). Это не совсем про Case management, но «где-то рядом».
В части работы с процессной командой (исполнители конкретного сквозного процесса), - да как раз задача владельца — это преодолевать "функциональные колодца" и делать кросс-функциональный процесс более гармоничным (согласованные действия), командным, «прозрачным». Только это не в процессе проектирования процесса, а в процессе эксплуатации процесса, т.е. при выполнении рутинных (ежедневных) операций уже регламентированного процесса. Хотя задача улучшения \ реинжиниринга \ автоматизации процесса – на Владельце остается, но как отдельная и не основная.
2 Несмотря на то, что Процессный и Проектный подход – по своей природе разные, все же роль Скрам мастер во многом близка Владельцу процесса. Каскадную модель проектирования можно во многом считать «функциональным подходом» в регулярном процесса (бизнес-процессе), а agile – как более близкий к гармонизации сквозных процессов в борьбе с «функциональными колодцами». "Функциональный колодец" — это метафора для обозначения изолированных отделов, работающих независимо от других и не интегрированных в общую систему процессов организации.
Функциональный колодец – это не только про проблемы при реализации сквозных / кросс-функциональных процессов (BPM, процессный подход), проблема silos также присутствует как при проектном, так и кросс-продуктовом подходе.
Более того, если проектном управлении есть роль портфельный менеджер (менеджер портфеля проектов, программы проектов), то и в процессном – целесообразно выделить менеджера портфеля процессов \ программы процессов (направления процессов, например, в банке – все расчетно-кассовое обслуживание). Однако, образ «Владелец процесса vs скрам мастер» - это скорее не про «регулировщика на перекрестке» («высший» уровень полномочий в регуляции экземпляра процесса), а про некоторого наставника, «замполита», который обычно не имя реальных рычагов (руления) «управления процессом» мотивирует всех участников процесса на общий результат – «выход процесса» («агитирует за советскую власть»). Видимо это пока некий прототип из концепции «бирюзовых компаний», который частично встречается в некоторых компаниях (причем очень давно).
Далее текст, полученный в обратной связи с читателем:
В современных моделях гибкого подхода к созданию продукта в идеале это выглядит вот так:
Процессник (Scrum Master, SDM..) — это человек, который отвечает за эффективность команды в целом. Он не командует людьми сверху, а скорее помогает команде быть лучшей версией себя. Инструментарий у него для этого широкий – тут и научить чему-то новому надо уметь, и помочь совместно принять решение (при этом желательно без драки). Если привести пример из ресторанного бизнеса, то эту роль может выполнять менеджер зала. Он не говорит поварам и официантам, как готовить или обслуживать, но следит, чтобы все понимали общую цель: быстро и качественно обслужить гостей. Если бармен и сомелье спорят, чьи напитки подойдут к новому блюду, он помогает им договориться и найти оптимальное решение. И при этом он же может научить молодого официанта паре фишек в обслуживании, чтобы повысить общий уровень сервиса.
Взято из статьи
Эта роль есть сразу, и она закреплена за скрам мастером, но я не видел идеального эджайла, всегда реалии вносят коррективы, но по задумке роль владельца процесса тут похожа на роль дядьки воспитателя в дореволюционной Россиюшки, он отвечает за эффективность. В малых компаниях, стартапах это могут быть основатели, идейные вдохновители и руководители, являющиеся движком. В больших компаниях процессы должны быть декомпозированы и распределены по командам, где будут свои роли. Эти все про гибкий подход и то как в идеале должен разрабатываться и улучшаться продукт, это я вижу в IT, но не вижу в больших корпорациях. Сбер давно использует эджайл, но что там у них внутри делается доподлинно сам не видел и фантазировать не буду. Тот, кто горит своим делом, тот кто может оценить эффективность процесса и что нужно для этого делать - тот и должен быть этим владельцем процесса. На деле многое зависит от того, кто формирует команду и как он правильно подберет кандидатов на роли.
Но если вопрос стоит так что в уже имеющейся команде/коллективе нужно найти того, кто будет улучшать процесс, то это должен быть инициативный сотрудник, с опытом в области в которой нужно улучшать продукт, и задача руководителя поддерживать инициативы такого сотрудника поощрять его и адекватно оценивать эффективность, приносимую производимыми действиями этого сотрудника.
В больших корпорациях есть болезнь закисания и потери интереса к процессу, застревание в трясине интриг и боязнь что-то сделать вообще, чтобы не получилось хуже, тут без экспериментов не обойтись, а на это не все способны. Поэтому назначают козлов отпущения и иногда уже по факту провала, а по факту успеха, иногда не предвиденного, в крупных корпорациях, доход от прибылей делят в соответствии с личными интересами, те у кого есть такая возможность, иногда обойдя сотрудников или даже целые команды, благодаря которым этот успех/результат был достигнут. У отца на работе был такой кейс. Соседняя лаборатория получила премию за работу, которую выполнила лаборатория отца.
Мой комментарий о том, что роль такая есть. В идеальной команде, по учебнику она прописана, как быть с этим в конкретной компании это уже вопрос компетенций лиц, принимающих решение и их вовлеченность и заинтересованность в результате процесса создания и улучшения продукта.
У нас в компании был такой пассажир и это был коуч, приглашенный со стороны, он достал всех и его уволили, но работу он наладил и процессы улучшил.
Конец цитаты
