Назначение владельцев процессов решает проблему, при которой сквозной процесс, проходящий через несколько отделов, не принадлежит никому целиком — у процесса есть множество исполнителей отдельных этапов, но нет ни одного человека, который отвечал бы за результат процесса в целом. Когда что-то идёт не так на границе между отделами, каждый указывает на соседний отдел, а процесс как единое целое остаётся без хозяина.
Реальный, ставший хрестоматийным пример цены отсутствия сквозной ответственности за процесс — департамент кредиторской задолженности Ford Motor Company в Северной Америке начала 1990-х годов. В отделе работало 500 человек, каждый из которых отвечал за свой узкий участок сверки счетов, заказов на закупку и накладных — но ни один сотрудник не отвечал за процесс оплаты поставщикам целиком. Когда руководство Ford изучило аналогичный процесс у японского партнёра Mazda, выяснилось, что тот же результат там обеспечивают всего пять человек. Вместо того чтобы оптимизировать отдельные задачи внутри существующего разделения труда, Ford перепроектировала процесс целиком: закупка регистрируется в единой базе данных, поступление товара на склад автоматически инициирует оплату — необходимость сверки бумажных счетов-фактур с накладными и заказами на закупку, из-за которой возникала львиная доля работы, была устранена как класс. Итог реинжиниринга, ставший одним из самых цитируемых кейсов в литературе по управлению процессами, — сокращение штата отдела на 75%, ускорение оплаты поставщикам и резкое снижение числа расхождений. Показательно, что сама возможность увидеть проблему целиком, а не по частям, появилась только тогда, когда процесс перестали рассматривать как сумму независимых задач разных подразделений и начали анализировать как единое сквозное целое, — ровно то, для чего и вводится роль владельца процесса.
Процесс без владельца — это процесс, за который никто не отвечает целиком, а значит, никто не может и не будет его системно улучшать, только чинить локальные симптомы в своём отделе.
Происхождение и исследовательская база
Концепция владельца процесса (process owner) — центральный элемент процессного управления (BPM), возникший как ответ на ограничения чисто функциональной организационной структуры, где сквозные процессы, пересекающие границы отделов, оказывались без единой точки ответственности. Впервые концепцию системно описали американские консультанты Джири Раммлер и Алан Браш в книге «Improving Performance: How to Manage the White Space on the Organization Chart» (1990) — они ввели метафору «белого пространства» организационной схемы: зон между прямоугольниками отделов на оргструктуре, где, собственно, и живут сквозные процессы, но которые обычно никак не обозначены и никому формально не принадлежат. Три года спустя Майкл Хаммер в основополагающей книге «Reengineering the Corporation» (в соавторстве с Джеймсом Чампи, 1993) сделал владельца процесса обязательным элементом «процессного предприятия», сформулировав это буквально: «каждый процесс в процессной организации требует владельца процесса — менеджера, ответственного за то, чтобы весь процесс продолжал процветать».
Ключевые идеи и принципы
Принцип: Владелец отвечает за процесс целиком, независимо от отделов
Владелец процесса несёт ответственность за результат процесса сквозным образом, невзирая на то, что отдельные этапы процесса выполняются в разных функциональных отделах с разными непосредственными руководителями. По формулировке Раммлера, без явного владельца «белые пространства» между функциональными отделами систематически игнорируются — каждый отдел оптимизирует свой участок, но никто не отвечает за результат на стыках, что и создаёт классическую субоптимизацию: локально всё выглядит эффективно, а сквозной процесс в целом работает плохо.
Принцип: Владелец обладает полномочиями инициировать изменения в процессе
Назначение владельца без реальных полномочий на изменение процесса (в том числе затрагивающих работу нескольких отделов) превращает роль в формальность — владелец должен иметь возможность реально влиять на процесс, а не только числиться ответственным. Раммлер описывал четыре конкретные функции полноценного владельца: регулярно отслеживать показатели процесса и отчитываться перед высшим руководством; возглавлять кросс-функциональную команду, устанавливающую цели и бюджет процесса; выступать «омбудсменом белого пространства», разрешающим споры на границах функциональных зон; и быть «совестью и защитником» процесса, когда его интересы конфликтуют с интересами отдельных отделов.
Принцип: Владелец отличается от функционального руководителя участников процесса
Владелец процесса не обязательно является прямым руководителем всех сотрудников, выполняющих этапы процесса — его полномочия распространяются на процесс, а не на людей организационно, что требует чёткого разграничения зон влияния с функциональными руководителями. Раммлер специально подчёркивал: роль владельца процесса не создаёт вторую, параллельную организационную структуру и не превращает компанию в матричную — вертикальные отношения подчинения сохраняются, функциональные руководители остаются на своих местах. Разница философская и практическая одновременно: продукты и проекты появляются и исчезают, а процессы — постоянны, поэтому у процесса, в отличие от проекта, должен быть не временный менеджер, а постоянный владелец.
Принцип: У каждого процесса — ровно один владелец
Как и в матрице RACI с правилом единственного Accountable, у процесса должен быть ровно один владелец — распределённая между несколькими людьми ответственность за процесс снова создаёт ту же проблему отсутствия единой точки ответственности.
Ограничения, слепые зоны и критика
Назначение владельца процесса без изменения системы полномочий и мотивации часто остаётся формальностью — владелец де-юре, но без реального влияния де-факто, особенно в компаниях с сильной функциональной иерархией, где влияние функционального руководителя перевешивает влияние владельца процесса. Конфликт интересов между владельцем процесса и функциональными руководителями участников процесса неизбежен и требует явного механизма разрешения. Наконец, для небольших процессов формальное назначение владельца может быть избыточной бюрократией, если ответственность и так очевидна.
Роль владельца процесса плохо приживается в организациях с сильной проектной или матричной культурой управления, где менеджеры уже привыкли к временным, проектным зонам ответственности, — постоянная, бессрочная ответственность за процесс психологически воспринимается иначе, чем ограниченная сроками ответственность за проект, и требует отдельного разговора о карьерной траектории и статусе такой роли.
Типовые ошибки
Ошибка 1: Владелец процесса назначен формально, но без реальных полномочий инициировать изменения.
Роль существует только на бумаге, реальные решения по процессу принимаются в другом месте. Классический симптом: на визитке и в оргструктуре человек значится «владельцем процесса обработки заказов», но любое изменение в этом процессе фактически согласуется и решается на уровне директоров профильных отделов — сам «владелец» узнаёт об изменениях постфактум.
Как избежать: Наделять владельца процесса реальными полномочиями влиять на изменения, затрагивающие несколько отделов.
Ошибка 2: На один сквозной процесс назначено несколько владельцев из разных отделов.
Ответственность снова размывается между несколькими людьми, конфликт интересов не разрешается. Пример: у процесса «онбординг нового клиента» назначены сразу «владелец со стороны продаж» и «владелец со стороны сопровождения» — при задержке на этапе передачи между отделами каждый указывает на партнёра как на источник проблемы, а конечный клиент по-прежнему не получает результат вовремя.
Как избежать: Назначать ровно одного владельца на каждый сквозной процесс.
Ошибка 3: Конфликт между владельцем процесса и функциональными руководителями не имеет механизма разрешения.
Разногласия между владельцем и функциональным руководителем блокируют изменения в процессе. Владелец сквозного процесса обработки заявок настаивает на изменении порядка работы склада ради ускорения доставки, руководитель склада считает изменение непроработанным и просто саботирует внедрение — без заранее оговорённого механизма эскалации (например, до уровня генерального директора) спор может тянуться месяцами, а процесс так и остаётся неизменным.
Как избежать: Явно зафиксировать процедуру разрешения конфликтов между владельцем процесса и функциональными руководителями.
Ошибка 4: Владельцы назначаются формально сразу для всех процессов компании без приоритизации.
Значительные трудозатраты уходят на процессы, где отсутствие владельца некритично. Компания одновременно назначает владельцев для 40 внутренних процессов, включая второстепенные вроде заказа канцелярии, — усилия распыляются, а по-настоящему критичные сквозные процессы (например, обработка клиентских жалоб) получают ровно такое же формальное, поверхностное внимание, как и малозначимые.
Как избежать: Начинать с назначения владельцев для наиболее критичных сквозных процессов, расширяя охват постепенно.
Ошибка 5: Роль владельца процесса не подкреплена системой мотивации, связанной с результатом процесса.
У владельца нет личной заинтересованности реально улучшать процесс, роль остаётся формальной. Годовая премия владельца процесса обработки заказов зависит от показателей его родного отдела продаж, а не от сквозных метрик самого процесса (общего времени от заявки до доставки, доли ошибок на стыках) — в результате он рационально продолжает оптимизировать то, за что реально вознаграждается, а не то, за что формально отвечает.
Как избежать: Связывать мотивацию владельца процесса с измеримыми KPI самого процесса.
Главное, что нужно знать
Владелец процесса несёт сквозную ответственность за результат процесса целиком, независимо от того, через сколько функциональных отделов он проходит, и обладает реальными полномочиями инициировать изменения. Роль работает только при выполнении трёх условий — ровно один владелец на процесс, реальные (а не формальные) полномочия, и явный механизм разрешения конфликтов с функциональными руководителями.
План внедрения
Неделя 1: выбрать наиболее критичные сквозные процессы для назначения владельцев.
Неделя 2: назначить по одному владельцу на каждый выбранный процесс и определить их полномочия.
Неделя 3: зафиксировать механизм разрешения конфликтов с функциональными руководителями.
Неделя 4: связать мотивацию владельцев с измеримыми KPI соответствующих процессов.
Далее: постепенно расширять назначение владельцев на другие процессы компании.
Как реализовать этот план с помощью фрейма «Назначение владельцев процессов» в OrgDevTools
Фрейм устроен как редактируемый реестр-таблица, а не как статичный список карточек — это точно соответствует природе методики: владельцев процессов обычно несколько одновременно, и их нужно сравнивать между собой, а не заполнять по одному.
Каждая строка реестра — один сквозной процесс с полями: название процесса, имя владельца, отделы-участники, и два независимых чекбокса — «реальные полномочия» и «мотивация = KPI». Фрейм автоматически формирует по этим двум флагам текстовый вывод для строки: «формальный владелец» (нет полномочий — прямая защита от Ошибки 1), «есть полномочия, не привязана мотивация» (защита от Ошибки 5) или «полноценный владелец процесса».
Фрейм программно проверяет ключевое правило методики — ровно один владелец на процесс: если два и более рядов реестра называют один и тот же процесс (без учёта регистра), оба ряда помечаются предупреждением «более 1 владельца» прямо в интерфейсе — структурная защита от Ошибки 2, которую невозможно не заметить.
Вкладка «Итоги» считает долю полноценных владельцев (полномочия + KPI одновременно) от общего числа названных процессов и явно перечисляет число формальных владельцев без реальных полномочий — кнопка задачи создаётся именно на дачу реальных полномочий такому формальному владельцу, замыкая цепочку от диагностики к конкретному действию.