Читать книгу: «Свод знаний по управлению бизнес-процессами: BPM CBOK 3.0», страница 8

Коллектив авторов
Шрифт:

2.10.5. Переход от интегрированных к проактивно управляемым бизнес-процессам

Под проактивным (или упреждающим) BPM понимается способность предвидеть и планировать изменения так, чтобы воспользоваться предоставляемыми преимуществами или предотвратить негативное воздействие на создание ценности для потребителя. Проактивное управление бизнес-процессами есть священный Грааль BPM. Организации, последовательно практикующие проактивный BPM, способны управлять изменениями на всех уровнях вместо того, чтобы становиться жертвой изменений. В качестве примера в организациях, практикующих проактивный BPM:

• реорганизации основываются на архитектуре и стратегическом планировании и являются способом оптимизации функциональной структуры в интересах исполнения бизнес-процессов и создания ценности для потребителя. На стадии планирования выясняется, какая продукция, какие услуги, процессы, процедуры, функции, роли, информационные пособия и системы будут затронуты реорганизацией. Оценивается воздействие на все эти компоненты: планы их адаптации и модификации составляются и могут быть проконтролированы в ходе реорганизации, а не в виде борьбы с ее последствиями;

• организация способна быстро, легко и адекватно реагировать на изменения во внешних регламентах и другие воздействия и угрозы. Например, по многим оценкам, суммарные затраты на решение проблемы-2000 и выполнение требований Закона Сарбейнса – Оксли42 превысили триллион долларов США. Значительная часть этих затрат была связана с неэффективными средствами выявления воздействия этих угроз на операции и неэффективным проведением соответствующих изменений.

Организации, практикующие проактивный BPM, обладают зрелыми способностями, обеспечивающими поддержку всех стадий цикла управления процессом (рис. 2.11).


• Способности, обеспечивающие определение и планирование процессов (стадия «Планирование» цикла PDCA), гарантируют, что контекст и высокоуровневая архитектура всех основных, вспомогательных и управляющих процессов по всей организации оптимизированы и соответствуют стратегии.

• Способности, обеспечивающие детальное проектирование, разработку и внедрение (стадия «Действие» цикла PDCA), гарантируют, что все бизнес-процессы функционируют в соответствии со спецификациями, разработанными на стадии «Планирование».

• Способности, обеспечивающие мониторинг и отчетность по эффективности (стадия «Проверка» цикла PDCA), гарантируют, что эффективность процесса последовательно и всесторонне измеряется и сопоставляется с нормативами, установленными на стадии планирования, и что информация об эффективности доступна и используется всеми заинтересованными сторонами.

• Способности, обеспечивающие преобразование и непрерывное совершенствование (стадия «Корректировка» цикла PDCA), гарантируют, что организация способна точно оценивать и адекватно реагировать на информацию, собранную на стадии «Проверка». Эти способности обеспечивают целостность процессов в условиях нестабильности и изменчивости окружения и являются катализатором непрерывного совершенствования процессов во времени.

• Новые стратегические, функциональные и операционные команды передаются со стадии «Корректировка» на стадию «Планирование» для описания и планирования, тем самым замыкая цикл системы управления.

2.11. Внедрение BPM требует введения в организации новых ролей

BPM – это управленческая дисциплина, которая имеет дело с принципами и практикой бизнес-администрирования и определяет способы и методы управления бизнес-ресурсами.

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

• структурированное принятие решений о том, как организация функционирует с точки зрения создания ценности для потребителя;

• структурированный подход к реализации изменений в функционировании организации с точки зрения создания ценности для потребителя.

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

Внедрение BPM, как правило, влечет за собой появление в организации новых ролей, отвечающих за сквозное управление процессами, пересекающими функциональные границы.

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

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



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

• владелец процесса;

• процессный лидер;

• администратор процесса;

• процессный аналитик;

• процессный методолог44.

2.11.1. Владелец процесса

Владельцу процесса принадлежит центральная роль во внедрении BPM. Он отвечает за сквозное управление одним или несколькими бизнес-процессами. В частности, это означает, что владелец процесса отвечает за соответствие показателей процесса целевым значениям эффективности (производительности и результативности). Например, на рис. 2.13 для определенного процесса задан целевой показатель эффективности: продолжительность цикла – 100 дней. Владелец процесса отвечает за то, что процесс спроектирован, внедрен и что его мониторинг и контроль осуществляются таким образом, что эта цель достигается каждым экземпляром процесса.

Владелец процесса отвечает за один или несколько сквозных бизнес-процессов. Основная задача владельца процесса – обеспечить, чтобы производительность процесса соответствовала ожиданиям



Чтобы соответствовать предъявляемым к нему требованиям, владелец процесса обычно:

• формирует из заинтересованных лиц команду, которая должна определить контекст процесса и увязать процесс со стратегическими целями;

• формирует из заинтересованных лиц и экспертов предметной области команду, которая проектирует процесс так, чтобы он соответствовал ожиданиям;

• является контактным лицом по всем связанным с процессом вопросам;

• добивается понимания того, как люди и системы участвуют в процессе;

• является активным заинтересованным лицом в бизнес- и IТ-инициативах, затрагивающих процесс;

• содействует принятию бизнес-процесса;

• осуществляет мониторинг и отчитывается за эффективность процесса;

• предлагает корректирующие действия, если эффективность процесса не соответствует ожиданиям;

• эскалирует экземпляры важного процесса, требующие внимания из-за существенных отклонений эффективности;

• возглавляет команду по оценке, приоритизации и реализации запросов на изменение процесса;

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


Существует два принципиально разных подхода к положению владельца процесса в организации: внутри и вне функциональной иерархии.

Владелец процесса внутри функциональной иерархии

При этом подходе владельцы процессов подчинены руководителям функциональных подразделений (рис. 2.14). Если бизнес-процесс пересекает организационные границы (что, как правило, имеет место), то ответственность (и, следовательно, подотчетность) владельца процесса может устанавливаться по одному из двух вариантов.

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

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



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

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

Владелец процесса вне функциональной иерархии

При таком подходе владельцы процессов подчиняются непосредственно руководителю организации (или организационной единице непосредственно под руководителем). В этом варианте владельцы процессов встают вровень с руководителями функциональных организаций (рис. 2.15).



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

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

2.11.2. Процессный лидер

Роль процессного лидера играет кто-то из команды высшего руководства, и она может совмещаться или не совмещаться с ролью владельца процесса (рис. 2.16).



Обычные обязанности членов команды высшего руководства – разработка концепции, миссии, ключевых ценностей, постановка стратегических целей – в организации, внедрившей у себя BPM, остаются неизменными.

В связи с исполнением роли процессного лидера могут появляться следующие дополнительные обязанности:

• выработка концепции и стратегии BPM и спонсирование ее реализации;

• установление целевых показателей эффективности процесса в соответствии со стратегическими целями;

• контроль за тем, чтобы рекомендации по изменениям процесса и их приоритизация соответствовали стратегическим планам.

2.11.3. Администратор процесса

Роль администратора процесса выполняется представителями функционального менеджмента, то есть непосредственными руководителями персонала, выполняющего действия в рамках сквозного процесса (рис. 2.17).



Обычные обязанности функционального менеджера с внедрением в организации BPM не меняются.

• Накопление знаний и опыта в рамках функциональной области.

• Привлечение и удержание самых талантливых сотрудников.

• Структурирование и описание ролей в функциональной команде.

• Описание и поддержка процедур операционного уровня.


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

• Забота о том, чтобы процедуры операционного уровня соответствовали требованиям вышестоящего бизнес-процесса, обеспечиваемого функцией.

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

• Сбор и отправка владельцу процесса откликов и предложений по совершенствованию процесса.

• Участие в работе команды, оценивающей и приоритизирующей (под руководством владельца процесса) запросы на изменения процесса.

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

2.11.4. Процессный аналитик

В небольших проектах BPM процессный аналитик может выполнять обязанности на всех стадиях цикла управления процессом. В более крупных проектах процессный аналитик может специализироваться на одном или двух ключевых аспектах дисциплины (рис. 2.18). Характерные примеры обязанностей:



• сквозное проектирование бизнес-процесса под руководством владельца процесса и на основании сведений, получаемых от экспертов в предметной области;

• ведение репозитория процессных моделей;

• диагностика проблем и выработка предложений по их решению совместно с владельцем и администраторами процесса;

• проведение анализа (например, анализа эффективности, анализа «что, если» и имитационного моделирования процесса) по запросу владельца и/или администраторов процесса;

• участие в работе команды, проводящей оценку и приоритизацию запросов на изменение процесса;

• участие в работе команды, реализующей процессные изменения.

2.11.5. Процессный методолог

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

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



Обычно в обязанности процессного методолога входит:

• описание принципов, методов и стандартов BPM;

• забота о том, чтобы принципы, методы и стандарты BPM соответствовали текущему и будущему масштабу реализации BPM;

• консультирование, наставничество и обучение передовым методам и стандартам, проведение их в жизнь и контроль за соблюдением.

2.12. BPM не предписывает определенный фреймворк, методологию или набор средств

Существует множество фреймворков, методологий и средств описания, проектирования, разработки, исполнения, мониторинга и анализа бизнес-процессов. Например, такие.

• Для описания организационного контекста бизнес-процессов и, в частности, их связи со стратегическими целями часто используют фреймворки и методологии корпоративной архитектуры45, такие как матрица Захмана, TOGAF, DODAF, FEAF.

• Для оптимизации модели бизнес-процесса с точки зрения выполняемых действий, выходов и использования ресурсов – людей и информационных систем – часто используются такие фреймворки и методологии, как Раммлер – Брейч (Rummler – Brache) и бережливое производство.

• Процессы могут исполняться разными средствами: людьми, машинами (например, сверлильным станком или конвейером), информационными системами (например, функциональным приложением или процессным движком) – или их комбинацией.

• Для мониторинга бизнес-процессов в реальном времени или близком к реальному и для отчетности могут использоваться такие методы и средства, как функционально-временной анализ, функционально-стоимостной анализ (ABC), SERVQUAL, Система сбалансированных показателей46.

• Аналогичным образом, существуют бесчисленные подходы, способные помочь в бизнес-анализе, – такие как шесть сигм, Монте-Карло и дискретное имитационное моделирование событий47.

Дисциплина BPM помогает организации выработать такие принципы и методы, которые приводят к максимально производительному и результативному исполнению бизнес-процессов. Организация, внедряющая BPM, может использовать любой из вышеупомянутых фреймворков, методологий и средств, и в результате конкретный набор для каждой организации будет своим. Приведем примеры.

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

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

• Производственная компания может инвестировать в обеспечение мониторинга себестоимости на уровне действий и задач (ABC), а компания, предоставляющая финансовые услуги, может предпочесть мониторинг восприятия качества услуг потребителем и сопоставления с ожиданиями потребителя (SERVQUAL).

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


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

2.13. Информационные технологии во внедрении BPM играют не основную, а обеспечивающую роль

В последнее десятилетие мы наблюдаем невероятный прогресс программного обеспечения, предназначенного для поддержки таких составляющих дисциплины BPM, как:

• архитектура бизнес-процессов и моделирование бизнес-процессов в контексте вышестоящей корпоративной архитектуры;

• проектирование бизнес-процессов, включая обсуждение проекта с различными заинтересованными сторонами и загрузку в процессный движок;

• исполнение бизнес-процессов и оркестровка действий, выполняемых людьми и информационными системами;

• анализ бизнес-процессов и автоматизация таких методов, как функционально-временной анализ, функционально-стоимостной анализ и имитационное моделирование на основе сценариев48;

• управление бизнес-правилами, в том числе независимо от бизнес-процессов для большей гибкости;

• разработка веб-сервисов, сервис-ориентированная архитектура и предоставление корпоративных данных по запросу в ходе исполнения процесса;

• обратная связь – использование показателей эффективности процессов для анализа и учета в будущей версии процесса.


BPM – это управленческая дисциплина, практикуемая людьми. Можно следовать методологии BPM, не прибегая к помощи информационных технологий, но инвестировать в технологии BPM, не определившись с методологией, не имеет смысла. Говоря коротко:

• информационные технологии могут быть задействованы в помощь практикам BPM, реализующим методологии BPM;

• роль IТ-подразделения в BPM – помощника, а не лидера;

• внедрение BPM – это не IТ-проект, а согласованное изменение методов управления процессами, которое может быть поддержано информационными технологиями.


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

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

42.Sarbanes-Oxley Act. – Прим. пер.
43.Governance. – Прим. пер.
44.Process Owner, Process Leader, Process Steward, Process Analyst, Process Governor. – Прим. пер.
45.Enterprise Architecture Frameworks. – Прим. пер.
46.Activity Based Timing, Activity Based Costing, Balanced Scorecard. – Прим. пер.
47.Discrete Event Simulation. – Прим. пер.
48.Scenario based simulation. – Прим. пер.
1 149 ₽
Возрастное ограничение:
12+
Дата выхода на Литрес:
22 июля 2016
Дата перевода:
2016
Дата написания:
2013
Объем:
677 стр. 113 иллюстраций
ISBN:
978-5-9614-4208-3
Правообладатель:
Альпина Диджитал
Формат скачивания:
epub, fb2, fb3, html, ios.epub, mobi, pdf, txt, zip

С этой книгой читают